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