Hey, folks, welcome back to another JavaScript jabber. This week on our panel, we have Dan.
Shapier, Hello from Tel Aviv.
We also have Aj O'Neill.
Yo, yeah, y'oa coming at your live from Pneumonia or Corona or something.
Wow. Man, I'm Charles max Bood from Top End Devs. I'm just gonna shout out about AI dev bootcamp page will be up today. We often also have a special guest. This week it is Uncle Bob Martin. Bob, how are you doing.
I'm pretty good right now. Life is treating me very well.
Yeah, we've we've chatted a bunch and yeah, Dan tossed a video over to me where you were let's say this as controversially as possible, you were bagging on all our favorite frameworks and so yeah, he asked if we can invite you on, and I'm like, yeah, Bob's always game for that kind of thing.
So you're here, I'm here, fire away when when ready?
Yeah, and maybe it's worthwhile. But before we start, I just need to tell Aj. You know, Aj, that pneumonia has one distinct advantage over you know, COVID or the cold. You know what that is. No, it's usually well, we've got met exactly, We've got medicines for pneumonia, so.
You can usually take an antibiotic and get rid of it.
I mean, I don't want to turn this to a health episode, but pneumonia is a symptom that means fluid in the lungs and can be caused either virally or back toia.
That's fair, that's true.
Then get the bacterial kind and then okay, so.
Take it back to Walmart and get the other brand.
Since we're here. Since we're already here. So one of the things that happened that I think set me back was I took some cough medicine and I coughed while taking the cough medicine, and you know, the cough goes like who right, and so then the cough medicine went into my lungs and then it got way worse. So I might still be recovering from the actual inhaling coughs.
I'm always surprised with you know, my kids. I have a kid in elementary school that I'm always surprised I'm not sick like every other week. And then I was thinking, well, I only have one in elementary school anymore. But my wife is the lunch lady, So yeah, I am surprised. I'm not sick every other week. But anyway, what.
Doesn't kill, what doesn't kill you makes your stronger chuck.
Yeah, well we're going to see how close we can get to that one of these days. I'm pretty sure. All right, Well, let's let's talk about framework.
So Dan, we need to introduce uncle Bob first, though.
Yeah, he goes to it, doesn't he needs no introduction, but yeah, we did call him out, Bob. Is there anything you want people to know about? Are you working on anything coming up?
Oh? Hex, Yeah, I just finished a book and it should be out in time for Christmas.
I hope. It's called We Programmers and it's a history.
Of programmers, going back to Charles Babbage and then working forward in time Grace Hopper and and.
The trio that did see.
I'm so looking forward to this book. You don't know how much I'm looking forward to that book.
I was going to say, come out by Christmas. So are you coming back on in January? Please?
Sure?
Sure, I'm glad to talk about that book.
That stuff is so fascinating.
It it was a fun book that was that was just a giant entertainment for me.
I would love to know, for example, how you did the research, but I guess we could save it for a future episode. I do have the one question about it, you know, do the readers on Amazon confuse you with George Martin?
No one has ever confused me with George Mark.
His books are almost long enough Bob's are.
Anyway.
Yeah, I always love talking to Bob, So let's dive into the framework thing. Dan, you're the one that brought this video to me, so I'm gonna let you kind of set the stage and then Bob can defend himself vigorously from our onslaught.
So to be honest, I don't even know how I found the video. Maybe it just popped up in my timeline. I was watching some of Bob's other talks, and to be honest, it's not really a talk. It's more of a snippet from a talk. I was looking for the full talk, but I just couldn't find it. You know, for some reason, that particular YouTube channel basically sliced upped the talk into a lot of little parts, and, like Bob said, put some background music behind it to make
it more exciting. I guess but specifically that particular video was Bob warning the audience against using frameworks. And that's an interesting take in the context of web development these days. Let me put it this way, I don't think I've seen a vanilla JS implementation of something significant in a long time.
Hang on, I just looked up Bob's book on Amazon and it says it's available.
Now.
I'm going to put the link into the comments and that way people can go and devour it over Christmas. All right, go ahead.
So basically my opinion is a bit different than Bob's on this, potentially and interestingly to some extent, based on Bob's own clean code principle. So I was kind of interested to hear, you know, what he actually thinks of frameworks, even if his definition of framework matches what you know more or less the way that what we define to be a framework in the context of web development, like, maybe he means something else. So I'm really glad that you've got Bob, and so hi, Bob, Hi, So I.
Can go into this right now if you'd like, Yeah, do it.
So Frank Hurt called.
The definition of framework. The definition of framework that I'm using here is some piece of software written by someone else that takes a very large amount of control away from you, the programmer. You have to surrender in some way to it. You have to adopt its conventions, you have to integrate with its modules. If it's an object oriented program, you have to derive from its base classes
that kind of thing. A framework like that requires the programmer to make a very large commitment to the framework. The problem with that is that it's an asymmetric relationship. The framework author makes no commitment at all to those who must commit to them, So there's this very uneven relationship there. The framework author can do anything he wants or she, whoever this person is, They can do anything
they want. They can make a change to the framework in any way they feel like it, and drag a whole host of people kicking and screaming along with them because they have bound themselves so tightly to the framework. There is a very famous image of a person whom I have a very high regard for, David Hannameier Hansen, who several years ago at a rails conference, objecting to
all of his users. Man's against him put up on the screen towards the first one starts with f and the second one starts with Y and that's kind of a good symbol.
Well, he is the more or less the definition of a benevolent dictator, almost as much as Linus is.
Well, I have right, you've got a benevolent dictator. And if you go away that the dictator doesn't like, you're out in the cold.
So that wasn't the only point you made, but I want to address this particular one. No, you made several points, but I think that was one of the core points that you made. And what you said is obviously true. But it's also true when you consider the programming language you use, when you consider the platform you're running on, when you consider some of maybe even some of the core libraries that you're using. So no code runs in a vacuum. You're always dependent on something, you know, even
the hardware. So how is that really different than any of those other things, Because at the end of the day, your software is going to be running on something.
Well, there's a there's a difference in that. So the the asymmetry of the relationship in the case of a framework is greater than the asymmetry when, for example, with a programming language, let yarnistry, strip right makes the C plus plus programming language. His success depends on him being able to satisfy a very large number of people right at, which he's worked very hard at on the C plus plus Standards Committee until recently, has been doing a great job with that.
You know why I'm laughing, it's a pretty open secret.
It's an interesting question. Why i'm laughing. Well, you know the word question.
Yeah, we're not allowed to say that word anymore. He's not in the C plus plus community. Oh those guys, what what? I'm not going to go into it here. But someone can put up a framework, and in the case of dhh Rails is a really.
Good example of this. He did that for himself.
He did that for himself and for thirty seven Signal, and then he opened it up to the world and said, hey, guys, you want to use it, that's.
Great, but don't bother me. Okay, that's perfectly fair.
On the other hand, if you're the user caveat emptor and you use that at your own risk. If you're using C plus plus, well that's not quite at your own risk.
There's a difference in the relationship there.
If you're using a platform like os X, right, They've got a commitment to you, a small one. But but you know, Dha, no commitment to me if I'm using Rails.
Really, I think Apple more or less has only only has a commitment to their shareholders. I think that's about it.
When you're talking about Swift or their frameworks in particular.
Everything Yeah, Apple does.
Well, it's interesting too, right because you know, you bring up David Heinemeier Hansen. But I mean, this is a JavaScript podcast. I can I can argue both sides of anything with Rails. But and and it it's true a lot of the stuff that they put into the framework or things that they need for base Camp or something else, and so that that's what goes in the reality is is that you know, they recently form the Rails Foundation
and they get input from some of them now. But again, you know a lot of times it's stuff that Shopify needs, and that's stuff that I'm never going to touch. But let's switch gears here for a little bit, because you know,
Dan brought up Apple. You know a lot of the frameworks that a lot of people are using these days are frameworks like React and Angular, which are both sponsored and supported by large companies like Facebook and Google and they're solving the problems that they have, right, I mean a great.
It's actually interesting because I recently heard on a podcast that was on the JAS party I think podcasts they interviewed some of the React creators at the React con for something like that, the recent React conference, and they said something very interesting, and I think it also appears in the React documentary, which actually is pretty good and
I mostly recommended. I'm kind of annoyed with them that they didn't mention Wix, but that's an assign No, we were like the biggest implementation out of the first big implementation outside Meta, and you know, somehow it's totally missing. But anyway, the point they made actually totally matches what Bob said, which is they created React initially for internal use and then they thought, hey, it's interesting, so they
decided to open source it and let it out. And it was never a profit center for Facebook, so they didn't really care about their users as customers, and they mostly much of their motivation about what to do or not to do in that framework derived from Facebook's own needs.
So I'm totally in agreement with Bob about that. That being said, that's actually kind of changing now because a lot of what's driving innovation in the React world is kind of moving from React to next JS, and next JS is heavily associated with oursells, and much of ourselves business is based on their need for next JS to be successful. So it's changing now. I mean, it's starting
to become a two way street. And in fact, they actually said on the podcast that they're happy about the fact because they're now driven more by actual customer needs then by whatever somebody just says that should be done within Meta.
So I understand, and I agree with everything you just said. But back to Bob's point, and I'm kind of poking things both ways because I'm kind of curious where the balance is and I haven't made up my mind yet, right, so I kind of want to hear the arguments on both sides. But Meta could, right to React core team and their ownership over React decide to do something that people don't want, or decide not to implement features that people do want, and actively work against certain movements within
the community. Should they decide to Now I'm not saying they will, and I don't know why they would, but it could happen, right, you know.
But it's open source, and then somebody could theoretically fork it and do whatever they want with it.
Yeah, but most of the other frameworks we're talking about our two.
Well, the big difference is that React is more or less the only really successful framework, maybe also View to an extent, but probably also View. The other frameworks really need to incite or elicit elicit would be the better word, elicit to people to actually use them. So there the two way street is much more active. And I would argue that it's kind of the same thing with programming languages.
I mean, you know, once a programming language becomes super mainstream and used widely a lot of people, are the people who are using it use it really without a choice. Basically whatever job they got basically said you need to use language, acts, you need to use framework. Why. But when you're talking about a new programming language or a new framework that's like the up and coming thing, like you know, the then it's you're trying to convince people
to use what you're providing. And then it's much more of you know, trying to sell your benefits, like I think or would you disagree, Bob.
Oh No, I don't disagree at all.
You are trying to sell your benefits and everybody is trying to do that. That's what all the framework guys are trying to do. So my my position on frameworks is that you should be careful with them, right that you should understand relationship, understand that it is asymmetric, and weigh the costs and benefits. So, for example, it's very easy to get a Rubyon Rails application up and running in a matter of a few days, just trivial.
Yeah, I get ridiculous amounts of things done with Rails. I get ridiculous amounts of things done with some of the other frameworks I use on the front end. Right.
Then, as as time goes by and you want to start doing things that the framework doesn't support, well, all of a sudden the framework starts to fight against you. Then you're in this funny mode because you've already made this commitment and now the next thing you want to do is going to get hard, and the one after that is going to be even harder, and you have to violate the framework in ways that it doesn't care about. It didn't make it easy for you, and now you
have to subvert it in bizarre ways. So you need to know that going in. One of the problems that I see with frameworks is that they do a great job of selling just as you're saying, right, they'll do a terrific job, and they'll show you these lovely little applications on a YouTube video or something. Oh, look, you just have to write these seventeen lines of code and life will be glorious for you, and you're not really looking down the road next year.
When life is not going to be so glorious.
So my advice to people is to be careful with frameworks and to the extent possible, try to isolate yourself from them.
Not that you shouldn't use them, but.
You should use them in a way that is careful, so that if the framework turns around and invites you, you've got some options.
So before asking you about how to implement that type of isolation, I'll go one step back and ask you when if I'm in the process where if I'm in a situation where I can actually get to select the framework that I use rather than having it thrust on me by you know, the previous developers who worked at the company, any advice on how I should go about choosing the most appropriate framework for me.
Well, so that gets into the other discussion we were having, how how much of this how much of the attitude of the authors is geared towards the user community as opposed to their own community. You know, In the case of Rails, that was an interesting one because that just started. I keep going back to Rails, but that just started as a nice little framework for those guys, and then it leaked out into the community and everyone started using it.
And that's a bit of a warning sign, right.
You look at that and think, well, are they going to take this in some direction that I don't like. On the other hand, if you've got a very large organization and they're trying to keep you know, one hundred thousand programmers happy and their reputation hangs on that framework like versus, well, for example, that's a slightly better relationship. You can take a little more confidence in that. And that gets into the programming language argument.
Right.
If they're really trying to, you know, give programmers the language of the Internet, well then they're going to have to keep an awful lot of programmers happy and it's not quite as risky.
Interesting story though, is what happened with the Angular like Angular one and two kept a lot of developers really happy, and then they kind of broke that contract, and you know, and that's when React happened. But React, why are you making a face, Bob?
Well, the face I'm making has nothing to do with the Angular or React. It has to do with a meta issue, which is that frameworks are popularity fads. They come and go. This month it's going to be framework X. But next month somebody's going to say, oh, framework why is so much better? And so that's another one of
these risk factors of a framework. You don't know if the framework you choose is going to be popular next year, or you may have to convert everything over to the next new framework, or all your programmers may quit because they don't like this framework and they want to go to a company where they're using that framework.
So we wind up in this very strange.
Popularity contest which has almost no substance to it, almost no.
Well, so go ahead, Chuck. Sorry.
So the thing that I'm seeing that both kind of illustrates this but doesn't quite line up with it, is I've spoken with a whole bunch of people who still have apps that are running things like backbone JS, right, And so they want to move into something like React JS. Right. But it's not so much the fad cycle that's driving it so much as just the technology and the standards and things like that that are available today and that have been built into React that haven't been maintained into
something like backbone. And there's some very good reasons for that. So what they're looking to switch to is they're looking to switch to something that gives them the advantages that React has because Backbone no longer has them as opposed to a bad cycle.
I significantly disagree. I think the most significant consideration that developers have when thinking about switching frameworks is their higher ability.
No, that's true, but but my point is is typically the argument they're making is the technological one.
Oh, they might make a technological argument, but the real motivation is I don't want Backbone on my resume. I want React on my resume. That's the real reason.
It's true that they're so no to me, though. That's a sea of mediocrity. I mean, you're fighting against because nobody, nobody can identify who's a good React developer, right, Like, how would you even interview to find out which React developer is actually good because there's so much noise, how do you find the signal in that? I agree, it seems weird, weird to me.
I agree with what you said, Aj, but that still doesn't change the fact that the React that a person with React experience on their resume is more hirable than a person without React experience in their resume.
And that's just that's just insane.
It's you don't want to hire programmers based on their familiar familiarity with the framework, Bob.
Everybody does it, I know, and everybody does it.
It's more like a meme than it's not like a it doesn't seem like a conscious rational decision.
It's like, I'll take it even a step back. It doesn't even matter if it's true. It matters that the the developers picking the framework think that it's true.
Okay, and there's a bunch of HR guys that think it's true too.
Yeah, yeah, I think that in the in the age of AI hiring where you just have to stuff your resume with a bunch.
Of no it's so true. It is so true. If you want a resume.
Is going to get you an interview where they can see through this nonsense.
Yep.
If you want no, seriously, if you want to get an interview, you take the resume you wrote and you hand it off to an AI system and say, I want to get this job, and it'll you have to optimize it because people don't read your resume. They hand it off to an AI system that tells you, tells them how good a match you are. And you're cracking up because yeah, you could be a crappy developer that has a true the optimize resume. It's like SEO for job search.
Yeah, but it just through the door. At the end of the day, there is I've yet to see a job when there was no actual technical.
In fair but but they're there in my opinion, and I think a j is making this point. They're screening out a bunch of competent, really terrific people who didn't optimize their thing for the AI system.
Oh you know, that's what happens when the job market is weaker. When when the job market is is such that developers and high in high demand that there's not enough supply, then you can, you know, get by with whatever crap you happen to have in your resume. But when when the situation is reversed. You're absolutely correct, it's s CEO for getting a job.
Yeah. Now I want to divert us back to the discussion on you know, the frameworks and whether it's hype or not hype and things like that. I guess I guess the real thing that I'm wondering, and you know, I'm curious to see what you think, Bob.
But so but Chuck, I'm sorry, Bob did not answer my question.
Okay, well I think I'm asking you the same question another way, but go ahead.
Well, my question was how do you pick a framework?
Yeah, that's what I was going to go for, was, Yeah, if you're if you're looking at these frameworks and it's you know, you're you're worried about stability, You're worried about the team. You know, whether or not they're going to change stuff, whether or not they're going to implement the things you need. You know, what you're giving up versus what you're getting. Yeah, how do you pick.
Or do you know?
I mean you look at you look at the framework technically first to see if it's technically compatible. Right, you make sure that it's not just surface compatibility. Yeah, Oh, it's gonna help me for.
The next one weeks, compatible with.
What whatever your application is.
If you're if you're writing a, uh, I don't know, some kind of a desktop application or some kind of a handheld application, and you're you're trying to figure out is this frame are going to help me?
How much is it going to help me?
Is it just going to help me in the first two weeks or is it going to help me long term? That's one thing to look at, And then the other thing to look at is what's the user base? How many people are using this? Are they putting demands on the framework authors? And are the framework authors meeting those demands? And who are these framework authors anyway? Is it one guy in his basement or is it a group of
people who have made a commitment to the community. Those are the kinds of things you want to be looking at. And then even then, even then, you want to put that framework in your system and isolate yourself from it.
As much as you can. It's hard to do, but as much as you.
Can so that when they screw you, and they will screw you, you will have some options.
So I have a question, a follow up question on your first point, which is is it compatible with your application? Yeah, A lot of people that I talked to about their applications they don't have the depth of understanding of either the framework or the application to make a good call there. So what kinds of questions, Like, let's say that I'm building, you know, the dream app that does the podcast of all podcasting podcast stuff, Right, what kinds of questions do
I need to be asking about my app? And what kinds of questions do I need to be asking about the framework so that I can make at least a somewhat informed decision on this, knowing that my requirements may change.
So tell you a story. Twenty some add years ago, my son and I built an application. You're probably aware of it. It's called Fitness, and it's a web based application, right, so it puts up web pages. And the first decision you would make, the first framework decision you would make if you had to do a web app, is what web server should I use? Okay, well, we didn't use wouch.
We wrote one. Why did we write a webserver? Well, it turns out that a web server is about three hundred lines of code if you get rid of all the crap that the framework is going to put in there that you'd.
Have to carry with you.
A nice framework for doing web serving is three hundred lines of code. It's almost a trivial piece of work. And so we thought, and this is one of the ways you would do this decision right. You would look at what the framework gives you, and you'd have to look in some depth, and then you have to ask yourself the question, what would it take for me to write that? And in some cases it's not a lot. In some cases it's more so. I'll tell you another story.
About two years ago, maybe three years ago, I started writing a desktop application for a social network protocol called Noster. It's one of those federated social networking stuff that nobody can censor. I had it up on my screen and I was writing the code. I was writing it all inclosure. It's lots of fun, and I thought, I'm not using any framework.
I'm just gonna muscle through this thing.
And I picked up one little framework called processing, which is a nice little thing. It doesn't get in your way very much. And I fiddled around with that for a while, and it started to get hard because I had to implement all of the text editing stuff and all of the you know, double clicking and all that drag and drop.
Crud, and I thought, you know, I really need a framework.
Eh So I said, Okay, I'm gonna use a good old standard swing.
No, that was the worst decision I ever made in my life. Let me tell you.
I started against some sympathy on this podcast saying that.
I started an integrating swing into this thing, and I, God, it's up and running. It works, it's fine. It's just a hellhole. It's awful, and I'm thinking, now what I need to do is just rewrite the whole. That's there's two different stories with two different outcomes, right. I thought, oh, you know, I can probably make it with Swing. It's old, it's it's reliable, lots of people have used it.
Nah, it's just it's a nightmare.
So so go ahead, So go ahead, you go ahead. AJ. My question is than to be long.
The question I want to pose is what is the alternative to a framework?
Then?
Because the reason people choose frameworks they want a shortcut, They want some layer of abstraction that if you get chose the way problems stuff. Sure, So what's what's the alternative to a framework? Because I don't think that it's well you just write everything by hand.
Well, sometimes the alternative is to do it by hand. Sometimes right some Sometimes the benefit that the framework offers you offers you appears large but actually not. And that's that was the case with Fitness, right. The very idea that we would write our own web server had you know, had us going, oh my god, were and then we actually wrote the things three hundred lines of code. I can get stuff on a web on a website pretty dog oneasy, it's a little bit of socket manipulation, sore.
That's one case where you you overestimate the value of the framework compared to the effort to do it yourself.
Then the the the noster one that I did.
That's the opposite case where I underestimated the value of a framework and in the end I decided I had to have one, and then I chose the wrong one. Right, So there's there's no way out of this dilemma. We don't want to write everything from scratch. We do want to use what people have done. We want to build on the good work of others. But it's not a free lunch. You have to be really careful about the frameworks you used. You don't want that decision to be
a quickie. You don't want it to be one based on popularity. You don't want to do it because all your friends are doing it. You want to look at it good and hard, and you want to do some of the experiments. You know, how far can I get without the framework?
So you, in one of your talks might have been this one. You mentioned that in one of your projects. I think it was you. I'm pretty sure that it was you. You deferred the database decision to the very end of the project. Yep. Unfortunately, from my experience, that's not really something that you can do with the framework. And the problem is that you kind of need to choose a framework more or less upfront. And when you do that, like you said about that database selection, you
have the least amount of information. So, unless you happen to be rewriting an existing app, which you know is done but is fairly rare in our industry, for good or bad, you are making the decision about the framework while you have the least amount of information about what you're actually developing.
So what can you do to get more information before you make the framework decision? So, for example, most of the frameworks out there are some kind of UI framework. They help you manage the user interface, react Angular, all these things, right, it's all some way for all the little gestures on the user user interface to make sense. What if you did not do the UI first. What
if you focused on business rules first? What if you wrote the core of the application without a user interface so that you had information about what this application actually does.
And then you can back away from that and say, Okay, what kind of user interface do I really need? What features are really going to be necessary here? And you can make an informed decision about what kind of framework you're going to need.
Yeah, except that most product managers start with FIGMA.
Well, yeah, here's a problem for you.
I was going to make the joke that if everybody follows Bob's methodology here, no one would use react.
But well, I'm actually not sure.
I think a lot of people would opt for not something so heavy on the front end.
Well, I'll put it differently though. So when in the past when people ask me, I actually even we spoke about Quora before the recording started. I once answered a question of you know, frameworks, what are they good for? On Quorra and back in the day, back when I wrote that answer several years ago, what I said was that at the end of the day, most web applications
do more or less the same thing. You know, we all like to think that we're very original, but at the end of the day, like a significant portion of what we develop is more or less the same as what everybody else does. It's like, you know, filling forms, basically posting forms, stuff like that, and therefore it's it's kind of repetitive to write it again and again from scratch.
And frameworks, like you said, like provide a box solution that does a lot of the heavy lifting for you that you kind of you don't need to repeat yourself. And that's true, and I still think that's true. But my focus on what the frameworks provide has kind of shifted since then because I've been interacting a lot with a lot of framework creators and designers. So Ryan Carniato is a friend, Mishigo, hevery is a friend, you know.
So so I've been thinking about what it is that they're thinking, like when they explain to me their considerations
and their desig decisions. What I came to the conclusion is that The core difference between the frameworks is actually the mental model that they promote, and the different frameworks like React versus Solid, versus SVELT, versus View versus Angular, all have really different mental models of how applications in general and user interfaces in particular should be architected and consequently, to a great extent, ideally, when you choose a framework,
I think you should choose the framework that best matches your own particular mental model.
Now, how do you determine that mental model?
If you don't understand the details of the application, if you're working on a particular kind of application, and do.
You focus on the business rules, you may come to.
A very different decision about the mental model that you need for your user interface. If you've chosen a framework up front, that framework will drive you into a mental model that will then have incompatibility with the business rules themselves, or at least the ideal state of those business rules. That's the argument that you know, do you go inside out or do you go outside in?
And I like going inside out.
For sure, and I totally agree with what you're saying.
I'm just thinking that understanding the mental model or even the philosophy of a framework requires less initial investment that what you might then what most people might expect that even if you that you can devot up a fairly simple sample application, like a throwaway application, in order to kind of gauge the frameworks, philosophy and mental model and see not necessarily if it fits your needs in the context of that particular application you want to implement, but
rather your own personal preferences in general, and I would contend that your personal preferences supersede like the details of a particular application.
That one makes me a little nervous. First of all, you're probably working in a team. I mean, some of us don't, but probably you're working in a team, and everybody is going to have their own mental model preferences. I would hope that the application would focus that, and that you could have a reasonable debate about, Okay, what of our mental rules, which one of our mental models is most applicable to this particular application.
I would help.
Yeah, you're correct, but at the end of the day, there's a person. At the end of the day, it's a person that makes the decision. Yeah, and everybody else kind of has to live with it.
The benevolent dictator arises again, yes.
Yeah, but it might just be the first person on the team, you know, the original developer on the project.
If there was only one.
Yes, well, in a lot of startups there usually is one. And you know, I've worked at various you know, large organizations where I ask why are we using technology X? And the answer is this guy who worked here eight years ago, that's what he chose.
Yeah.
Yeah, I have joined startups and thrown away the work of the early developers.
I did this on a way to go forward part of our test framework on the I'm working on for a client literally on Friday. Why are we doing it this way? Well, the other developer couldn't figure out how to do it the normal way. I figured out how to do it the normal way.
Now another story, and this long, long time ago, I was working at a startup and.
We needed to store a bunch of data on disc.
And of course everybody says, well, you've got to get a relational database. This is like nineteen eighty five, right, You've got to get a relational database.
And I thought, we don't need a relational database.
All we need to do is store a couple of things on disc and that's fairly easy.
And we did. We just stored a real simple, little little thing that we cobbled together.
Long comes the marketing guy who joined the company about six months later.
You don't have a relational database in your system. Yeah, that's right, we don't need it.
Well, we can't even sell it if you don't have a relational database in your system.
It was the most absurd argument to.
Make to a bunch of technical people that the marketing guy said he could not sell the application if it did not have a relational database in it. And in the end they had to put a relational database in because the marketing guy was absolutely adamant and overrode all the technical people.
I didn't stay at that company.
Well on, Bob, So what you're saying is is if the framework doesn't implement AI and blockchain, and it's worthless.
I just want to mention that a few years ago we had Norm Honing on this show talking about their kind of framework called Remote. It's not a UI framework. It's more of a database or something like database connectivity layer that can work either from the back end or
from the front end. And interestingly, when you install their thing, it comes with the built in flat file based implementation that because they don't know what database you're you you're going to use and you know so, and but they want you to be able to play with it out of the box. And what he told us told me at least that in a lot of cases, companies just stick with their flat five based Yeah, mm hmmm, because it works for the amounts of data that they might have, it might be good enough.
You know.
Interesting what I'm but the point I'm trying to make is this, So for example, let's let's consider React and the reality. Interestingly, a lot of people who are using React are not actually aware or sufficiently cognizant of the React way, and and when they develop using reacts, they don't actually develop according to the way in which the React designers intended them to actually work.
They don't even do this on their documentation, by the way, like because there is the document, the React Rationale or whatever it is, and and like they're like, that's where things bugs me is the documentation goes against their own principles because they give examples to give the examples in the fewest lines, rather than to give examples that follow the patterns that they're prescribing. People use.
Anyway, what I'm trying to say, so, React, for example, is very much about the idea, the ideal of state in UI out like UI as a stateless functions. And you know, you can debate about how well they've been able to achieve it and some of the caveats that they have, and and so on and so forth, because at the end of the day, you know, UI just can't be totally pure functions. And but that's kind of the React way, and if you choose React, that needs to be kind of your design philosophy. And you know,
people ask like, why doesn't React have signals? And we had the people from React. They had Joe Savona from React, from the React core team on the show, and he basically said, because that's not React. That is contradictory to the React philosophy. On the other hand, if you want signals, then you've got solid or now you've got spelt. So really you can create a fairly small application and see do I like the React way or do I like
the Solid way? And if you actually start by thinking about what is the core philosophy of this framework and work from there, my assertion is that you'll probably make a better decision then, you know, trying to go based off of of your yet not yet fully formed understanding of what your application is going to be and what exactly it's going to need.
I'm not going to disagree with that.
I think the more experience you have with frameworks, the better information you're going to have to make a decision.
The problem, though, is you said to separate as much of the business logic out of the framework itself. I guess that means that if you've got some sort of business logic, you know, encapsulated in some pure function, and then you can call that function get the values, and you don't really care what you're calling it from. The problem is that, from what I've seen in reality, is
that frameworks tend to seep into those functions. You look at what should have been a pure function without any framework code, and then all of a sudden you find a lot of framework related code in it.
You're making my argument for me.
Earlier you were saying that people, you know, basically people ought to discover their business rules and then go into the UI afterwards. And I think an industry that's very rare. Yeah, it's kind of like the waterfall development got rebranded as agile, so you see the same you know charts in the
you know, twelve month timeline, but it's agile. Now. I think it's really really dangerous to start with the design and try to work backwards, because you would need to start with what business problem are you trying to solve, and then move forwards from there. I wish that every application the engineers created the super ugly prototype first, so that the designers knew what they had to work with.
So the alternate to that is you take an application with really significant business rules. So for example, some kind of insurance application. Uh, and and there's just a lot of number crunching that you're gonna have to do, and a lot of data lookups and all kinds of stuff with a relatively simple amount of incoming information. And the temptation there would be to show a nice little desktop app and and oh, here's the form, and look you
click on these things and you isn't it wonderful? And everybody's applotting and then and then you know, then you actually have to write the business rules. And the business rules it turns out completely thwart that whole idea of the user interface, right, So wait a minute. We can't do it that way, We got to do it a completely different way. It would be in my view, it would be better to start inside, get some feel for what the business rules look like, and then and then
you can start to project outwards. You don't have to finish all the business rules, but you start to project outwards that way, as long as you've got some idea of how you're going to manipulate all this data that's.
Going to be on the stream. So now, sometimes it's trivial.
Sometimes there's just nothing to do with The data goes into a database, it comes out of a database, nothing else, and you've got a credit application.
And okay, if all.
You've got is a credit application, you can probably make the framework decision pretty early.
So do you have any suggestions for because most people were just peons, right, we just like there's some sort of project manager and they're making all those decisions. How do you like if you've got this great wisdom, which I like, it's like product managers. I don't think that they learned that, right, how do you communicate that upstream to say, hey, to develop the best product.
You're triggering the AJA, you're triggering me. I've worked in those salt mines before.
But that's like most of the salt mines though, is that? Is it not? I mean that it's.
True you have the not technical, non expert people making these deep decisions on how you put your app together.
So, but what's what's your solution or what's a way, what's a way to bring some of this knowledge forward to help the development process, because I think I think many many people have been on a team where their intuition says, hey, this doesn't seem right. Maybe they don't feel like they've got the confidence to speak up because obvious people above them must know what they're doing.
So I believe in miracles.
I do. I do want to say to two things about this though, So like there are two problem there are two problems that I can that I can see with I'm just developing my APIs first, will invoke them from curl, and once we see those work, we'll start building the UI. The two the two problems are are A, how are you going to raise money that way? Uh?
Like you the AI generate the commercial and then it's been that way for decades. When was the last time that a company that was raising money had a product?
Well, it had a demo of a product.
Though demo it was like Wizard of Ozzie or it was like completely done by a three D animator.
The other problem the other but the more serious issue though, is that I'm kind of wary of uys that are built without any consideration for how they're ultimately going to be used yep, because then you're trying to build a user interface on top of them and you discover that they just don't actually fit your needs. They were great from the command line, but they they they're not really appropriate for the UI where we need to support dragon Drop and I don't know what.
So I I think that people should create UIs just dumb ones that are ugly to start with, that have the that have the benefits there like okay, It's it's like, like I've said before about suck driven development, you don't need to produce the most complete project with the most features, And there's an excellent y Combinator series I'll link to
in the in the Picks about this. You need to produce the product that does one thing significantly better than all the other products on the market, and you can do that with really bad UI. In terms of a test cycle like true agile, right, like you do the development sprint, you do the design spread, and then so on.
On the other hand, Apple conquered the world with building amazing UIs on top of products that in many cases did not provide features that were not available somewhere else before.
With not this great UI, I think you're making an earlier point that Bob pointed out, just maybe in a different way, and that is you have to understand your application of what matters, because I believe that there are situations where you know, the functionality and the way that things kind of bolt together and work matters more than how pretty your UI is. But in other cases, yeah, the UI not looking great. Just to give an example,
I'm part of an organization. I'm in leadership in this organization, and you know, we were looking for a solution to help collaborate, get people to collaborate, and the more we talked about it, the more it just looked and sounded and felt like discord. But I'm not. I'm not the ultimate leader, right, I'm I'm part of leadership, but I'm not I'm not the one that makes the ultimate call.
And the person was the person no telegram actually, but the issue was was that the person that made the ultimate decision, she took one look at the way that Discord is designed and said, this looks like a video game platform. No one's going to use it. And so in that case it mattered. But in other cases, you know, having the functionality and having people being willing to say, this doesn't look like what I wanted to look like,
but it does. All the things I wanted to do, you can do, and so you you have to understand your application. I guess part of understanding your application is also understanding the limitations and trade offs that your users are willing to make.
So the Apple story is a really interesting one because if you'll go all the way back to the.
Macintosh right nineteen eighty three?
Was that true?
I think something like a good long time ago.
And when that machine came out, it was absolute magic and I had to have one.
Everybody had to have one.
And you could you could do mach paint, you can do mac right, you could do MacDraw. They had all these applications. Nobody had ever seen anything like this before, and they conquered the world with that UI. Even Microsoft finally had to bow and go, okay, Windows is great.
Okay, so how did that happen?
And that happened through a series of experiments and iterations that mostly failed, right and most and a lot of it happened at Xerox a few years before Xerox Park mecking around with the Dina book and then eventually they come up with the small Talk browser, which you know, they they really had it kind of but not quite.
And then they came.
Up with the Xerox Star, one of the early word processors back in the day, and Apple said, oh, I'm going to steal that. Steve Johns literally stole it, said, okay.
I'm gonna I would say that Xerox literally gave it to him.
But they give away everything. Xerox Park gave away everything.
Just a remarkable story in all of this gold that came out of Xerox Park that the Xerox company just apparently had no interest in and gave it away, gave it.
Did you see that movie which wasn't so great? I think it's called Fire in the Valley or something like that. They have this amazing scene there where the people from the West Coast from Xerox Park come to the Xerox main office in New York, and there's this huge desk with all the CEO and all the vps and whatnot
sitting there in their suits. And on the other end you have you've got the guys in their T shirts and their beards, and there's this amazing scene where the CEO of Xerox picks up a mouse by the cord and he's holding it like a dead mouse, and he says that he goes, you want us to sell something called a mouse? They just didn't get it. It was
the culture was just too divergent, I guess. And then they gave it all away to it to Steve Jobs, who basically heard about them, and you know, and they literally told the head of that of Park to just show him, show him around, and you know, you can look at whatever he wants.
That wasn't the only thing Xerox Park gave away. They gave away just tons of stuff. But then Jobs takes it into Apple and their first product is the Lisa, which is another failure. Right, they couldn't quite get.
The idea that pixels ought to be square.
But they did make a great decision early on, which was the one button mouse, right, Xerox had the three button mouse. Apple said no, it should be one button. There were some very interesting decisions made that led finally to the Macintosh and then the the rollout of these very interesting user interfaces.
But it was not a burst of insight.
It came through a whole bunch of iterations, mostly failed iterations.
If I'm dragging us back to frameworks though the current.
The current well, I was thinking about doing the same thing, but I'm so fascinated by where this is gone.
No I know, but I do want to cover. So the reality is that for the past fourteen years, it seems that React rules the framework, the front and framework world, and that it's not going away. It's the default, it's the safe choice. It's like you never get fired for buying IBM kind of a choice. Now these days it's literally no choice at all. And I'm looking at some of the other frameworks that have amazing ideas again the Spelt or Solid or quick, and they're having and they're
unable to break through. Like the latest statistics that I've seen on the Google Crux website, which kind of analyzes websites that Google index indexes, it looks like React is like all the other framework. It's more than all the other frameworks put together. Second place is view and then all the rest are and then all the rest are
just like you know, minuscule in comparison. So we can talk about you know, developers needing to think about picking the correct framework all we all day long, at the end of the day, they're just gonna pick React.
Okay, that we could talk about whether or not people should build build their website or not, but all day long, they're just gonna pick WordPress, right, I mean, like the things that the things that React as capturing are not the things that are going to be unique in driving lots of value. Right Like, if there it is no significant benefit to something else and React is fine, then
React as fine. If there is something where there's a new type of value, where there's going to be new value driven in a significant way, people are gonna pick something else that matches where that value is. But in the same way that that, you know, if you were to compare React to word Press, you'd say, oh, well, you know, React just really isn't gaining any steam. But they React is a completely different use case than what
WordPress is. And I think the same is you know, every layer of the industry, right you know, you could look at it from Wix and word Press and react and you know, take it down the pipe. Where there's more unique value, people are going to make more unique choices. Where there's less unique value, people are going to make less unique choices.
So this kind of begs the question. And I'm curious, you know, AJ, what you think and what Bob thinks. Well,
I'm curious what Dan things do. But you're making the point is, then is it a problem that we necessarily have one sort of eight hundred pound gorilla that takes over the most of the market, or you know, does that stifle some of the innovation that's going to go on out there or is it more in the realm of kind of what AJ is putting out there, where maybe the people with these unique use cases will pick something else anyway, and so it doesn't matter.
Of course, it's going to stifle innovation.
That's that, that's my instinct.
But is word press stifling innovation?
Hmmm, I don't That's an interesting question. I would I would argue that the use case is different. The use case for WordPress is is basically somebody wants to have these days, is somebody wants to have a simple web presence as quickly, as as cheaply and ideally as reliably as possible, and not really and hopefully not think about it at all. Web development is actual development. I would argue that that that.
They're trying to bring it to the level of GPT, right, They're trying to get rid of the developer and say you're not gonna have a job. GPT is going to do it for you.
Reaction, wup GPT. What do you think, Bob?
Oh?
You mean CHETCHYPT taking. I've been writing an awful lot of code here. I've been doing the the Advent of code exercises, you know, every every December maybe that, and I'm reading them all enclosure, and I've got my i D set up with with GitHub Copilot, and it's really quite remarkable what that that thing puts up on my screen.
Half of it I have to throw out. More than half of it I have to throw away.
But every once in a while it's like, oh yeah, I figured that one out pretty well, So you know, I think there's some interesting stuff there.
I have no fear at.
All that anyone's job is going to be taken away by a large length which model that has been suffused with code.
I don't.
I want to back up, though, what do you feel like we gain or lose by having a kind of a dominant player in the framework market.
That's the VHS versus Betamax argument, right, Okay, So VHS is going to dominate for a while until the cvs come out. When when when is this model of application going to change?
Yeah?
Right now?
A matter of time.
That's an interesting question because the core thing is that in the web world we are kind of tied to JavaScript and the dom So because the platform isn't changing, that reduces the need of whatever we implement on top of the platform to change. Now, if you know, I don't know what happens, like if if we all go ar VR, then I don't know, there might be a new to change that I'm not sure to be honest, but I like and at talk I gave like fifteen years ago, I said that I'm annoyed with the fact
that laptops are still the dominant form factor. And you know what, fifteen years later, laptops for developers are still the dominant or for work are still the dominant form factor. So where's the thing that replaces the laptops? It's not here. So we are we are on top of the web, We are on top of the dom. We don't want to use the dom as is, and we can debate about why that is. You know, what do you think
people should be used? I don't know if you're the one to ask this question specifically, but do you think people should forego frameworks and just use JavaScript in the dome instead?
Oh? No, No, that would be silly. Right, You're going to have to get them just you just have to be careful, that's all. But yeah, you're going to want to have some kind of framework assistance because those problems have been solved eighty times by people who know a lot more than you.
Okay, but then the question is, you know, you've got the reacts and angulars and views that do a lot more then solve some of those problems, right, and then you've got like Alpine or you know, jQuery did some of this, or you know, I've been using stimulus right where it just solves some of the more fundamental issues, and then you know you wind up using the tom APIs and so there's a sliding scale even there.
Right, Well, there's a first of all, there's a question of again I kind of hinted toward that at the beginning of what is a framework? Like is reactive framework? Is Angular framework? Is next year as a framework? They're kind of really different from one another in what they divide and.
They are hostile takeovers of my UI is what they are well and.
Your your your idea about the mental model is a good definition of a framework?
Does it impose a mental model on you? And frameworks do.
That in that regard. They all are, but to a varying degree, right like and like. For example, next gs also tries to impose a certain mental model on how you implement the back end, which react in and off itself does not so it it it. It's kind of a question to the extent to which it invades or your your your entire stack as it were.
Well that that's what I was probing for earlier when I was saying, what's the the you know, what's the opposite of a framework or what's the what's the alternative choice?
Because the way that the way that I would describe a framework is a framework is something where you put your code in the framework, like you implement the abstract class of the framework, whereas a library would be something where you use the library like your code is on top and the library is in the middle, whereas a framework, the framework is the shaster control and your code is the little functions that fill out the gaps.
I would argue that at the end of the day, if it's not going to be the framework, then it's going to be the platform that does it for you. So at the end of the day, you are using some sort of framework, and if you think you're not, what I've seen happen is and I'm kind of quoting Tages who we've had on the show several times to talk about similar topics, is that if you don't use a framework, you end up implementing your own framework and it will likely be worse.
Yep, that's the old argument, right, that every every every application of mentally implements some bad version of Lisp.
Yeah. But the thing is is, again it's going back to the argument.
Of your JavaScript. By the way, sorry to interrupt.
True JavaScript Lisp, but my point is is that you know, if you have a really really simple application and you you know, it's a fairly well understood system, and you can get away with using the domain pis on it, and that's it right, and it's not going to grow in complexity or you know, it's need it's not a
common use case. But my point is is you can get away in a lot of cases with not having the framework or having a framework as we talk about it on the front end, as opposed to the more complicated things where yeah, you need some of these problems solved.
So the core question you need to ask these days in the front end world, in front end web dot world is do I really need this to be a single page application? And if the answer is yes, because sometimes you do, then you probably have to be using
a framework. If the answer is no, If the answer is it can be a multi page application, then you're correct that there's a good chance that you either don't really need a framework, or you can use a fairly minimalistic framework, or you can segregate the framework used to very specific parts. The reality, though, is that for some reason or reasons, it might have to do with what boot camps are teaching, it might be have to do
with what VC is like to invest in. Whatever the reason it might be have to do with what developers like to have in their resume. The reality is that these days a lot of web apps are being built a single page applications, whether they need to be or not. I had hoped that something like astro would reverse that trend, but it doesn't seem to be the case.
So what fascinates me about that, dan is is the vocabulary that we've all been using. That we've all mentioned the DOM, we've all mentioned JavaScript, We've all and you started mentioning single page applications as though that were some kind of fundamental constraint.
Why are we talking? Why are we using that vocabulary? The web?
The Web has imposed these vocabularies on us that create a mental model of how applications.
Ought to be. And I wonder if we aren't on the verge of leaving that mental model.
I remember an interesting thing I've tried to look for. It's an old video that I watched like probably like fifteen or something years ago. I've tried to search for
it on YouTube. I can't seem to find it. It's a video of Alan Kay, who I really admire, and apparently he got really annoyed with the Web when the web was gaining a lot of popularity because and he tried to build an alternative to the web using well surprise, surprise, small talk and it had like agents communicating with each other, sending small talk snippets and you know, like and the co group propagate where it needed to go. It was
really beautiful. And the way that he demoed it is he built the same application using web technologies and I'm talking about the web technologies from something like fifteen or maybe even twenty years ago, and he built the same application using his own platform and the interesting and like,
he achieved parity in terms of functionality. And then he ran them both on his laptop and measured the temperature of the laptop and he showed that his that the web was running very hot, whereas his application was running really cool. Yeah, exactly. And guess what. And I'm sure you know, given knowing Alan k and what he is and what he's done and and everything, and we were talking about Xerox park and whatnot, I'm sure that his
solution was beautiful. But look what's one And and I considered the web to be the modern web, to be one of the greatest achievements of humankind, despite its inefficiencies. So yes, it has created the vocabulary for developers. But the same was true for Unix, and for CE and C plus plus and for Windows and all the various platforms that we've had over the years, and for mobile
platforms these days. You know, we didn't talk about apps before the mobile platforms and the app store, you know, the de abomination that is the app store.
Well, the other thing is is that, I guess the point you're making is that the metric we used to just to talk about how good something is is not process or temperature, right, I mean, there were other things that people wanted from the web, and that's that's why we got what we got. The other thing, though, is that, you know, as things have innovated, a lot of those things have changed, right, you know, the web has become more efficient, or at least in a lot of ways
it has. It has, I think in some ways it has. I mean it's gotten faster and easier to use. I don't know if that's like you measure the temperature of your no.
I mean, if you measure load the websites loading times, have they gotten faster? Really?
Ten megabytes of JavaScript to get anything done?
Yeah, they've only seemed to be getting faster since Google kind of, you know, put their whip over the developer's head and started measuring it and telling the developers that it's in a ranking factor and whatnot. Then it kind of started to improve. But at the end of the day, the C plus plus developers who are creating the browsers have done more for web performance than all the JavaScript developers put together.
And that's my point is that, you know, it's it's the whole of the platform, not necessarily that we're writing better JavaScript or better HTML or whatever, right, that's my point. But the browsers faster, My machine's faster.
I'm writing better HTML, I'm sure in brackets and and the cool thing is that HTML itself is actually getting better.
You know, We've got we've got things like pop ups built in to the HTML that like, for years we didn't have it.
Nobody knows about it though that's another discussion for another day.
It makes me shiver?
Are you developing for the web these days? Bob?
I try to avoid it when I can.
I've got a website that I maintain, and you know that's really simple rides TML. I wrote it all on closure. I've got a little, you know, little very simple framework that I use. So if you need to create a try to avoid web development if I can.
So, if you need to create an interface for something, what do.
You use an interface for?
Like, if you're creating a user facing application, one that can't just be a CLI, what do you use.
So one of the one of the tools that I've been using lately is a very simple library. It's a graphics library called Processing, and it runs in JavaScript.
It wants in Java.
There's a closure shim on top of it that I like to use, and it allows me to build applications, run them on my laptop without worrying about JavaScript, and then compile them into closure script and run them on the on the web.
And that's fairly straightforward.
Now.
The problem with it is that it doesn't give me all the lovely forms and text capabilities. It's very similar to a graphics a graphics library without a lot of text editing, and so I don't typically do a lot of text. I can draw nice and pretty pictures, I can do interactive games that way. It's very easy, and I try to avoid all of the more traditional web based work.
Nowadays, I don't really have have to do much of that.
Cool.
Yeah, well, there's a bit of mold here. Is there anything else we want to talk about.
I could just talk with Bob forever, but you know, well.
I really want to do the history of programming thing, and I want to read the book, so we'll have to have you back. Okay, maybe I have a holiday in.
You know you you said when talking mentioning that book I think you have on the cover it says something like from add to what was do AIU? And you joked that Amazon, because you're it's a programming book, assumed that you were talking about added the programming language. The funny thing is, when I saw the title, I initially assumed you were talking about the programming language as well, and I was thinking, hey, the added programming language is
not that old, you know. So yeah, it took me a minute to realize that you were actually talking about Ada Lovelace.
Yes, yeah, good deal. You want to give us a quick pitch on the book, Just let people know what they're getting if they go by it.
It is a history of programmers from Babbage all the way up to Dennis Ritchie and Ken Thompson.
That's the first part of the book.
And I picked a few very interesting characters, so there's there's everybody.
You gotta do.
Babbage, and I did the guys who did Simula, you know, Christian Nigard and.
Toole Johan Dal and I did Distra because you've got to do Dykstra and several letters along the way. But the focus is technical.
This is a book for programmers, right, So I talk about the machines at the bit level. I talk about the way they wrote their code. I give examples of the code. You know, there's pictures of the machines and why the machines were built the way they were built, talk about the memory technologies and the computation technologies.
So it's not a layman's book.
This is a technical description so that programmers today can identify with what these guys were doing because it was pretty cool. And so that's the first part of the book, just just that. Then the second part of the book is it's where I step into the book at that point,
and it is essentially my history. It's almost autobiographical, except that I focus on on the technologies, or almost only on the technologies that I saw from starting in the late seventies going on into you know, twenty ten or so. And then the last part of the book is just fantasy that's me saying, well, gee, what's going to happen in the next twenty years, Which is why I could put Ai in the title.
I don't know if you put him in the book, but an amazing character in the early days of computation was a funnyman.
Van Neuman has his own chapter.
Okay, well yeah.
Vanman, Uh, Touring, Van Noyman, and David I can't remember the mathematician's name, the one that came up with Hilbert, David Hilbert.
Oh, David Hilbert, Hilbert Hilbert Space.
The three of them share a chapter with each other, Gilbert Touring and Van Noyman.
Oh, I have to have this meaning.
Now, yeah, me too.
And all of it from those earliest days was driven by war.
We have computers today because of war.
Well, most of human innovation is because of war. We don't like to think about it. We all want peace. But at the end of the day, and we have penicillain thanks to war. You know, most of human innovation is because of war.
Well, let's face it. I mean wars are won by technology. I mean even back to you know, I can ride up on a horse and do worse things to you than you can do to me. Technology one Wars, so you know, germs and steel.
Yeah, yeah, even though that book has fallen kind of fallen out of favor.
By the way, But Jared Diamond's book, Yeap Guns, it's great.
Yeah, it's a great book, but people don't prescribe to those theories as much as they did. It turns out that some evidence contradicting evidence was was. Since it's a pretty old book, let's put it in. So it's its age in terms of research. Ye, not my area of expertise, but I've read.
Yeah, well, you know, in putting up a risk, I guess of throwing something out that I would normally put into a pick. But if you go listen to hardcore history by Dan Carlin, I mean a lot of it where he breaks down different wars and war periods. I mean he basically explains this technology helped these guys win the war, right, and it was you know, sometimes it was just a marginal difference, but it was enough that
it really tipped the scales. So anyway, I'm going to roll us right into the picks and then we'll wrap up a j Do you want to start us with picks?
All right. So I mentioned earlier there's a series from y Combinator from twenty fourteen called How to Start a Startup, And I just think that anybody who works in development and sees it as a craft should watched the whole series. I think it's really valuable to understand business perspective, and especially anybody that's a product manager. If you have not watched this series, you're one of the reasons that Chuck
and I cry at night. Yeah, it's and I'm not I don't necessarily think that Why Combinator is the greatest, but when they put this series together, they they pulled from a seemingly diverse group of people in terms of their you know, businesses and whatnot. But the principles you can find them referenced in many other books. There's lots of little I don't know, catchphrases, sort of things like little one line ringers that are really really good sprinkled
throughout the series. And I think that it is a rare instance of really good, really valuable material that I guess was intended to generate some hype around Why Combinator or something, but ended up being not hype material. It's it's actually really valuable material. So I'm gonna put a link to that. Yeah, and I just think every everybody ought to avail themselves to to know. There's very few things in there that I disagree with. I think that it's it's really really high value stuff.
The other is.
We got the Dune to film collection. Of course, my wife did not like the ending of Dune two, but she did like Dune too, and she's now she's trying to get one of her girlfriends to watch it, and you know that's going over her, Like I forget what the idiom is for when something's not going overwhelm.
But my wife will not sci fi fan or fantasy TV shows or movies.
Well generally mine won't either. Dude. I was just like, you know, honey, you're probably not gonna like it, but will you watch.
This with me?
And she's like, oh okay, and then she's riveted by it.
Uh Yeah. The closest to my wife has come, I think was the movie Gravity.
Oh okay, Yeah, that was a very emotional. That was that that kind of had a chick flick feel to it, you know what I'm thinking of?
No, well, chick flip, I don't think so.
Oh no, I'm thinking of Interstellar. I'm thinking of Interstellar because that that one's all about the relationships and everything, and the it's kind of like a rival like.
A Gravity does have a strong female lead character, but she's interesting, let's put it this way, so she's she's not well, she's not a merry suit or whatever the colloquial term for uninteresting, strong meat female characters is. It's then.
Yeah.
The last thing I'll pick is I got a new hat, and my wife says, I look really good in a hat.
It's beautiful.
I love it, and I was actually inspired by Elon I saw him wearing it and I thought, you know, I'll get one actually. But the thing is, I'm just really glad we're back in a timeline where people can be honest again and some of that you know, bsing pretending to believe something that you don't believe to appease somebody else. Like, I'm glad we get to relax a
little bit from that. And it's been really it's been really great to just be able to wear my new hat around and you know, get some compliments and then you know, get some dirty looks too occasionally, but you know, it's just it's just nice to be like, I'm safe, Like America is a safer place again. You are safer to believe what you believe, and just like freedom of speech. You know, I'm just I'm I feel so much better now a lot of it.
It's interesting from somebody looking from the outside on the whole thing, as in ISRAELI, it's interesting to see a lot of similarities because there's a very very significant political divide in Israel right now. So there are a lot of similarities, but there are also a lot of differences, Like a lot of the issues that are you know, really almost tearing America society apart, are literally non issues in Israel. I think we discussed this in the past. Check.
Yeah, we've we've talked about it. I don't think we've done as much of it on the show, and fair enough, that's not what the show's about. But yeah, yeah, it's
always interesting to kind of see. It's also interesting to see what filters through, right you know, what you're hearing about us in Israel and what we're hearing about you here, And then as we talk about it, I find out that you know, you're you're seeing things completely differently about your situation there and about our situation there, and so anyway, Yeah, I love having the conversations with people.
Also, definitions like you know, what's right what's left are very different between different kinds.
Yes, yeah, absolutely. And if there's anything that I can just throw out there in relation to what ajs saying is I love talking to people about this stuff, right, whether you agree with me or not. By the way, I have a hat that looks a lot like AJ's, except it's red. And I got it way back in the day. I actually took a picture of myself in it on Twitter and that got me into trouble.
But anyway, and now we're going to get into trouble because we're on Twitter.
Yeah Twitter.
Twitter is different. Yeah, but see that's all the all the people, all the people that you guys are upsetting right now, are on uh blue sky.
On blue sky anyway. Yeah, yeah, I guess my pointing is though.
Guy, But I don't I don't really want to upset anybody like I just like it's just you know, it's been several years of a certain group of people can say whatever they want, and wear whatever they want and fly whatever they you know, like and and you know, and if you say, hey, you know, I'm not really I'm not really as comfortable with that, then you know
you're an infidel. And it's nice to be back in a in a society where it's more two sided, where we can both say, hey, you know, I don't agree with that, but that's okay, you do you, and somebody else is gonna say I don't agree with that, but it's okay, you do you. You know, That's where I want to be.
And here's one of the key difference is that when you say infidel in this part of the world has a lot of connotation going on with it.
Sure, yeah, absolutely. I think the other thing, though, if if we're going to discuss this here is I hear people basically say, well, you voted for Trump or you
voted for Harris because of X or why. And the reason reality is is I talk to people, and there are a whole bunch of people I talk to that have the one or two issues they care about, and so they voted based on those, and so all of the other things you get thrown at people who voted that way just are not applicable, and it doesn't make a lot of sense to lump people into that basket of thinking one way or the other, and then in other cases, yeah, there is a bunch of group think
around certain ideas that drive another group of people. And so for me, the fascinating thing is talking to people and really understanding why, you know, why do you care about this, why are you involved with it, and what what's driving your worldview so that you're doing what you're doing people to where you get to real people.
People choose political parties like they choose frameworks somebody.
A lot of times, You're right, I thought you were.
Any investigation or understanding what are not in aligns with their values?
Yeah?
Yeah, mostly mostly mostly they're either going according to what their dad voted or intentionally the opposite of what their dad voted.
Truth to that. All right, Dan, what are your picks?
So I've really got two picks, first of all, both of them non political. The first NBA started season has started, and I'm really happy about that. It's kind of challenging in Israel because the games are really late at nights, so usually we don't get up for them. Instead we record them and then try not to find out the results and watch them during the day. The benefit being that we can speed through the timeouts and stuff like that. But I'm enjoying myself a lot thanks to the NBA,
So that would be my first pick. And my second pick is a TV show on actually I'm not sure where it's airing. It's a British television series. Wherever you can get it, you I recommend watching it. It's called well, The Day of the Jackal. It's based on the book Day of the Jackal and the film Day of the Jackal. So maybe I should kind of go back and say that if you've not watched the movie Day of the Jackal from back in the seventies, you should. It's an amazing,
excellent movie. But the TV show, the Modern TV Show, is pretty good as well, and it's so I recommend watching that too. Being that it's a TV series rather than a movie, they can kind of take their time with it, which is, you know, both an advantage and a disadvantage, I guess. But we enjoyed it so and it's not science fiction, so my wife will watch it, and those would be my picks.
All right, I'm gonna jump in here with mine. Then I'm gonna do a board game pick as I usually do this one is called BLEM. It's l M L E M. And usually when board games have funny names like that, a lot of times there are acronyms. This one's not an acronym. I don't know why they called it BLEM, and I don't know where they came up with it, but it's uh. Cats in Space is kind of the theme. And so what you You have a rocket and you roll dice to move the rocket up
the board. So you each put one of your cats on the rocket, and all the cats do different things. Most of them are bonuses if if you're you have the most cats on a planet, or it doubles your score on the planet, or your doubles your score on the moon, or doubles your score if you get all the way to deep space. But some of them do other things to help the dice and stuff like that.
So you put your cats on the rocket, you roll the dice, and then if you have dice that match up with whatever the space you're on says will allow you to advance, then you can advance based on the rules. If you use numbers to advance, you pull all of the dice of that number out and you move up the number of pip showing if you use boosters, then you put the boosters back in and you keep rolling.
So typically people start bailing out when you start running out of dice because you only roll like five or six dice to start with, and so if you've pulled four dice out and you have to get two's and nothing else, then you're looking at it and going the odds of them rolling a two are lower than I'm comfortable with. And so you get your cat off the ship and they go and do their away mission on
the planet. And at the end of the game, you tally up all your points based on where your cat's landed, and if not all your cats landed, then you don't score all your cats. But you know, that's how you win it. It took us about forty five minutes to play with four people, and that was the game where we actually learned how to play it. So it's a
fairly quick game. It's something that I think my kids, like my nine year old, could, you know, pick up and play, and to be perfectly honest, she's nuts about cats and so she would very much love this game. Anyway. I think there are some expansions or alternate rules to it, but yeah, so yeah, we liked it with four players. Board game Geek has a weight of one point sixty nine, so, like I said, it's a very friendly game for people who kind of like a simple but fun game. And
it has a community rating of eight plus. So, like I said, you know your your younger kids could play it. If you have kids younger than that, they could probably play it. Just might have to help them and they're not going to understand all the strategy, but it's simple enough to write. Yeah, like I said, I think my eight year old could play it and reasonably be able to figure out whether or not she wants to use a particular cat and how to win it. So anyway,
really really enjoyed that game. And then a couple of other things that I'm gonna pick. One of them is the TV show Reacher. So I just finished season two. I am going to warn you a couple of the episodes have sex, nudity, violence. I mean you kind of what expected I think from an action show like that, if you want to be able to filter some of it out. My other pick is vid angel. You can use vid angel to watch shows on Amazon Prime, Netflix, and a couple of other places. Plus you get all
the Angel Studios stuff on the app. So that's the chosen. They have a bunch of movies they've made, which are terrific, by the way, And so I'm gonna pick Reacher and vid Angel. And you can filter curse words too, right, so if you don't want to hear the F word, then it'll cut the sound.
I heard Season two was it wasn't as good as season one. Do you think that's the case, Yeah, it was season one. I watched the one. I haven't yet wont season two, so.
It was it was kind of different. I'm trying to think better, not better. It's it's a little hard for me to specifically. So in the first season he's in, he basically winds up investigating a murder and you know a little bit of a spoiler. Within the first couple of episodes you figure out that one of the victims is his brother. Season two, he's investigating and this comes out right in the first episode. He's investigating the death of one of the guys that was in his special
Investigations unit when he was in the army. And anyway, it's it's got kind of the same dynamics with he he has other characters that he's doing the investigations with. Yeah, I would say I probably liked season one better, But like I said, it's it's got a bit of a different flavor because it's not kind of the small town you know, dive into stuff, mystery stuff. But yeah, so I I yeah, I don't know if I have a good answer for that. I enjoyed them both.
If you enjoy them both, then do try to find out. Try to find the series. I recommend The Dale of the Jackal. It's it's it's not the same vibe at all, but I think you'll enjoy it.
Yeah, it's it's interesting to kind of piece some of the stuff together. Another thing that I'm gonna pick, I'm just picking all kinds of stuff today is a book series. So I'm on book seven eight of this series. It's called The Sort of Truth by Terry Goodkind. Just awesome books. I just finished the I don't know the seventh book or the sixth book, I can't remember, but but I'm
really enjoying them. This last book was kind of interesting because the primary protagonists that are in the previous bunch of books, they don't even show up in this book. Until the end of the book, but I think he's it was a setup for some of the things that are going to happen later. And I think there are like twelve or thirteen books in this series as a whole.
You'll remind me of how Douglas Adams once referred to the Hitchhike Guides to the Galaxy Books as his five book trilogy. Yeah.
Yeah, those books are fun too. I mean, they're hilarious books. But anyway, so I'm going to pick those, and then the last pick I have is, like I said, if you're watching this live, I'm finishing up all the marketing materials and you being able to sign up for it and stuff like that, And honestly, I kind of want to talk to people before they sign up, just so that I make sure that I understand what people want and make sure that you're a good fit, because it's
going to be kind of a pricey deal. But I am putting on an AI dev boot camp starting the middle of January of next year, and so we're gonna it's gonna be a three month basically course. You're gonna get all the course material upfront as I put it together right on this first run. We're gonna have six months where you get on you know, weekly or biweekly calls and you know, so you'll be able to get help as things progress. But yeah, anyway, that'll be at
AI devboot Camp dot com. I'm also working on putting out some podcasts about AI specifically. It's not we have adventures in machine learning, which tends to get more into data science and machine learning model building things like that. These other podcasts are going to be more focused on using APIs and open source systems to build your aim machine learning stuff. And that's going to be at AI for Ruby dot com and AI for JavaScript dot com.
And so I'm going to get specifically into Okay, how do you build these kinds of features into your apps using Ruby or JavaScript depending on what you're doing. So, so those are my picks, Bob, do you have some picks for us?
Well, I'll just do one and it's it's it goes back to the framework discussion in tangentially about about a year ago, David Hannamier Hansen did a YouTube video and I think the name.
Of it is the Cloud Fugitive. I think that's the name.
Uh and and he has he has taken thirty seven signaled Off the Cloud, Out of the Cloud.
Yes, And it's very good video, and he.
Just walks through the rationale and why it was a good idea and why everybody else ought to be thinking about it.
So, you know what, you actually remind me off with that. So we've been forced to buy a new car, so we're actually buying a used car, but it's a new car for us. And they're all trying, all the car vendors are trying to sell us on leasing the car. Yea, and and we're know, we were like, no, we're gonna We're just gonna buy it. We don't want to lease it. So yeah, being on the cloud is kind of leasing your car.
Yeah, I'm using advantages. Sorry, No, I'm just saying I'm I'm I'm doing what he's doing.
No, Well, you're paying for comfort, really, or the perception of comfort.
Yeah, but the tooling that they've built around this move has made a lot of this stuff really simple.
Anyway, it's also cappax versus opex and various other similar things that are actually very similar to buying versus leasing.
Anyway, Bob, go ahead, No, that's it.
That was just.
I thought that's a good video for folks to watch.
They can get a different idea of how they could get their systems online as opposed to, you know, making some big commitment to a company that doesn't care about them.
Yep, very cool. All right, well let's go ahead and wrap it up, Bob. If people want to connect with you or find stuff that you're working on these days, where do they find you?
Cleancoder dot com. That's the website.
Videos are at cleancoders dot com the plural of clean coder.
That's good enough. Twitter, Uncle Bob Martin, Oh, I should say X, shouldn't I actually X?
I don't have a Blue Sky account, rather not have one.
To be honest, I told you I actually have both, which is really annoying for me, the fact that I that I need to Yeah, I actually did for a while, but it just, you know, it was too much hassle. But it is annoying to have two separate things of exactly the same thing, you know, if they were different than okay, But it's like, why do I need to have this twice? It's it's really annoying in that regard. But I do want to connect with some people who are only on Blue Sky, so you know, we'll see
what happens. Yeah.
Well, the thing that's interesting about it for me, just from the platform point of view, is that I've heard a few people talk about how Blue Sky is maybe cleaner and has less ads and stuff. But if you've been watching the discussions they're having around it, they're looking to add all of that stuff to Blue Sky. So I just yeah, so so it's.
Money will run out eventually, you know.
Yeah, the so the decision is not based on the what the platform offers, it's other things.
Look, I'm on social network to connect with Pao, and that's that's the bottom line.
That's what convinced me to go and create an account over there. But I'm I'm just as inactive over there as I am on Twitter.
So anyway, anyway, thank you Bob for coming on. This has been a pleasure.
Thank you certainly appreciate it. It's been a lot of fun.
Yeah, we'll get your schedule to come back and talk about the history of programming because that stuff's.
Say oh man, and I'm a history buff.
Yeah all right, Well, hang in there for just one more second while we end the stream to make sure you're uploaded, and until next time everybody max out,