Speaker 1: Hey, folks, welcome back to another episode of JavaScript Jebber.
Speaker 2: This week, on our panel we have Dan Shapier, Hello
Speaker 2: from Israel.
Speaker 1: I'm Charles Maxwood from Top End Devs and we have
Speaker 1: a special guest this week, and that is tomar Gable.
Speaker 1: I am sorry, I don't do the Hebrew pronunciation.
Speaker 3: So that was actually fairly accurate.
Speaker 2: Awesome. Now you and Dan are friends.
Speaker 1: You do JavaScript, mostly not on the front end, which
Speaker 1: is kind of interesting. But yeah, do you want to
Speaker 1: kind of give us a little bit more of your background.
Speaker 2: Sure, we are where you're coming from with this stuff.
Speaker 4: Sure.
Speaker 3: So, as you mentioned, Dunn and I have been friends
Speaker 3: for a while. We used to work together at Twigs
Speaker 3: for a few years and then we kind of split
Speaker 3: ways professionally but remain friends. As you might have mentioned,
Speaker 3: I am not very heavily into front end development. I
Speaker 3: will reiterate the usual disclosure, which is I have nothing
Speaker 3: against it. I'm just not very good at it and
Speaker 3: therefore leave it to people who are good at it
Speaker 3: and are passionate about it. On the other hand, I
Speaker 3: do see myself as kind of a general purpose engineer,
Speaker 3: so I don't really see the distinction between front end
Speaker 3: back end. In the general sense, engineering is engineering is engineering.
Speaker 3: Some of these disciplines require skill sets that slightly differ
Speaker 3: mind doesn't lead towards well users really and people. So
Speaker 3: that's why I'm in back end. You might say I'm
Speaker 3: a back engineers. It's the marketect, DevOps guy, whatever whatever
Speaker 3: is needed at the time. I've been in the industry
Speaker 3: for over twenty years now and for the last three
Speaker 3: and change have been independent, so consulting companies and basically
Speaker 3: everything they need, everything except front end. Yeah, and I
Speaker 3: kind of see myself as an engineer that solves problems,
Speaker 3: whether they be educational, functional performance, or anything else really
Speaker 3: or organizational at times.
Speaker 4: I'll I'll just add to that that you know, Toma
Speaker 4: and I we we meet, we hang out when we can,
Speaker 4: and when we do, we almost inevitably also get into
Speaker 4: technical debates. Like we both hold strong opinions, and interestingly
Speaker 4: enough they sometimes conflict. And that's the best, and that's
Speaker 4: the best. And I'm usually pretty that's stubborn and I
Speaker 4: hope also convincing. But Toma is somehow very often able
Speaker 4: to kind of force my hand to kind of change
Speaker 4: my opinions on stuff. So I really am looking forward
Speaker 4: to our discussion today.
Speaker 1: Yeah, those kinds of debates, in my opinion, are important because, yeah,
Speaker 1: they force you to really solidify where you're at, or
Speaker 1: change your mind.
Speaker 3: Or just starting to express your opinions.
Speaker 1: Right, Yeah, I was gonna say. So, we're in the
Speaker 1: middle of the political season here in the United States.
Speaker 1: I'm fairly involved in one of the major political parties.
Speaker 1: I'm the vice chair of the local the county party,
Speaker 1: and right, so we have discussions and often we have
Speaker 1: discussions with people that don't agree with us, both within
Speaker 1: the party and outside the party. And yeah, it's terrific
Speaker 1: because you get to have the back and forth and yeah,
Speaker 1: sometimes it's you know, you make a really good argument
Speaker 1: and I have to go think about that. And sometimes
Speaker 1: it's you've made excellent arguments and you've convinced me. And
Speaker 1: sometimes it's you know, we agree, but some of the
Speaker 1: nuance kind of gets threaded out during the conversation. So
Speaker 1: it's I love it.
Speaker 4: I love it as long as it's done in good faith. Yes,
Speaker 4: that's really what I care about. And of course, when
Speaker 4: it's tech, it should be based on actual you know,
Speaker 4: information or data as much as possible, rather than just
Speaker 4: you know, this is my opinion, and I'll die on
Speaker 4: this hill because it is yep, yep cool.
Speaker 3: Maybe I mean may challenge that a little bit. That
Speaker 3: can be one of the topics for discussion if you honestly,
Speaker 3: I think it's not so much that data is overrated,
Speaker 3: because it's not. It's that many fewer discussions, especially around
Speaker 3: issues of how to engineer what good engineering is a
Speaker 3: lot of these discussions are qualitative almost by definition, and
Speaker 3: trying to inject data into those arguments tends to like
Speaker 3: at this point they view it as in many cases
Speaker 3: more of a logical fallacy than an actual argument. But
Speaker 3: we can circle back.
Speaker 4: To that it's like lies, damn lies and statistics.
Speaker 3: It's more like, if you're measuring what's easy, because that's
Speaker 3: all you can measure, then don't expect me to take
Speaker 3: it very seriously.
Speaker 4: Yeah, that that is fair.
Speaker 1: So I got this list of things that are I
Speaker 1: guess ideas you guys said slaughtering sacred cows and mentioned
Speaker 1: that this is a Hebrew term, but it's it's a
Speaker 1: term that's used in English in America too, So I'm
Speaker 1: just gonna hang with it here. But yeah, so what
Speaker 1: what sacred cows are we slaughtering? Where are we going with?
Speaker 4: By the way, if we're just before we start, you know,
Speaker 4: if if you've got you know, some listeners and they
Speaker 4: have ideas for additional you know, sacred cows they might
Speaker 4: like us to to discuss or roast or eat or whatever,
Speaker 4: then they should know they can feel free to just
Speaker 4: post them in the very relevant chats.
Speaker 3: Yeah, absolutely, Yeah, the more the better. There's always always
Speaker 3: something to argue about, I'm sorry, debate and good faith.
Speaker 4: About don't do that when I'm drinking.
Speaker 3: Of course, the fun in not doing that when you're drinking.
Speaker 2: Yeah. So, so where where do you guys want to start?
Speaker 4: Well, the first one, I guess, right.
Speaker 3: So we kind of put together a list and sort
Speaker 3: of prioritize it by nothing so well defined as our
Speaker 3: hunch at what would be engaging for the audience, which
Speaker 3: is to say that if the audience actually wants to
Speaker 3: participate and indicate to us whether we're on the right
Speaker 3: track or they have some other ideas for what to
Speaker 3: talk about, then that would be terrific. But Daniel want
Speaker 3: to introduce the first hypothetical.
Speaker 4: Yeah, so everybody, you know, we all of us here
Speaker 4: are programmers, and probably the number one tool for programming
Speaker 4: is the programming language, because at the end of the day,
Speaker 4: that's how you convey your intentions to the computer that
Speaker 4: actually hopefully executes something similar to what you wanted it
Speaker 4: to do. And consequently, people or developers are really hung
Speaker 4: up on their choice of a programming language, to the
Speaker 4: extent that I still remember when I interviewed somebody for
Speaker 4: a position way back in the nineties, I think they
Speaker 4: told me, if you're not working in Java, I'm not
Speaker 4: interested in working here. And so it seems that the
Speaker 4: choice of programming language should be like the number one priority.
Speaker 4: It's like the number one most important tool in your toolbox.
Speaker 4: So it's the number one priority of making the right choice.
Speaker 4: And yet it seems that Tomar doesn't think that that's
Speaker 4: the case. So Tooma take it away.
Speaker 1: Well, I want to pile on here, because it goes
Speaker 1: the other way too, Right. It's not just programmers saying,
Speaker 1: you know, I want to work in dot Net or
Speaker 1: Java or Ruby or JavaScript or whatever node, but the
Speaker 1: employers list the jobs that way, right. This is a
Speaker 1: React job, this is a PHP job, right, And so
Speaker 1: it kind of cuts both ways.
Speaker 2: Anyway, go ahead Tomar.
Speaker 3: So there's there's a few angles with which we could
Speaker 3: sort of tackle this, But I'll start by saying this,
Speaker 3: I don't actually think there's any any argument to be
Speaker 3: made about companies listening uh those requirements, because functionally speaking,
Speaker 3: when you are an engineer, you may or may not
Speaker 3: need someone with immediately applicable experience, or you might not
Speaker 3: be able to afford along onboarding or whatever it is.
Speaker 3: It's a it's a much more kind of tactical decision.
Speaker 3: I think there's nothing I've yet to encounter a company
Speaker 3: that is about the you know, we only hire for
Speaker 3: these languages because we think everyone else is garbage, right,
Speaker 3: or whatever way you want to put it. So it's
Speaker 3: a much more functional decision. On the other hand, I
Speaker 3: would say that to to Doune's earlier point, which is,
Speaker 3: you know, it's it should be priority one of the
Speaker 3: decisions you make, presumably in that in this context it's
Speaker 3: on a new project or a new company, a new organization,
Speaker 3: whatever it is. I would agree with you it is
Speaker 3: the first place, but I would disagree on why that is.
Speaker 3: I don't think it's because the choice matters as much
Speaker 3: as people think. I think it's because it is the
Speaker 3: first choice you have to make before you actually start
Speaker 3: doing anything beyond brainstorming on what it is you're building. Right,
Speaker 3: the first line of code you write has to be
Speaker 3: in some language, which means making that decision, and that
Speaker 3: is a very strategic, far reaching decision. It applies to
Speaker 3: everything else you do moving forward from that point. But
Speaker 3: oftentimes the way you make that decision is not a
Speaker 3: didactic thought process. You don't go which is the language
Speaker 3: that best suits my domain percent of the time, and
Speaker 3: of course there are exceptions to that, but for the
Speaker 3: most part, what you do is you look at the
Speaker 3: people you have, You look at the ecosystem chunks that
Speaker 3: you know best, that match the domain you're you're working in,
Speaker 3: and then you just reach for the language that most
Speaker 3: of them know best, or at least most of them
Speaker 3: are most eager to learn, because that is how you
Speaker 3: get them productive as soon as humanly possible, and them
Speaker 3: might just be you. Right, if you're on a startup,
Speaker 3: you're going to reach out to the language you're most
Speaker 3: comfortable in. So it is the priority one decision because
Speaker 3: it is the most urgent decision, or one of the
Speaker 3: most urgent decisions you need to make it is not
Speaker 3: the first priority because it's so important. As for why
Speaker 3: I think it doesn't matter as much as people think,
Speaker 3: there's two ways to make that argument. One is the
Speaker 3: sort of high falutin philosophical allegory, which is to say
Speaker 3: a language is a communication mechanism. Programming languages are unusual
Speaker 3: in that they provide a medium for communication both between
Speaker 3: humans and between humans and machines. In doctor expect there
Speaker 3: they look different and act different than the languages we
Speaker 3: speak in. But fundamentally speaking, you can get anything done
Speaker 3: in any language as a human being, irrespective of computers. Right,
Speaker 3: you want to build an airplane, turns out you can
Speaker 3: engineer an airplane in French, you know, or in German
Speaker 3: or in English. And I'm not going to extend that
Speaker 3: joke in the obvious direction. But more importantly, though, the
Speaker 3: point I'm making here is you can end up with
Speaker 3: a functional system in ninety percent of the domains. There
Speaker 3: are always exceptions to this, There are always domains where
Speaker 3: one language would have a clear benefit over another. But
Speaker 3: for the vast majority of sort of general purpose business software,
Speaker 3: whether web or not, that everyone writes you can start off,
Speaker 3: you know, I'll use the example of a back end,
Speaker 3: because that just happens to be what I know best.
Speaker 3: You have massive, massive functional systems built in Java, in Python,
Speaker 3: in o Camel, in PHP, in variants of Php, because
Speaker 3: you have you know, Wikipedia on the one hand, and
Speaker 3: you have Facebook and the other virtually anything you'd care
Speaker 3: to mention. And I'm not even going in the direction
Speaker 3: of the obvious. You know, people are still writing inkbol
Speaker 3: I'm talking about mainstream, purpose built, relevant software that's been
Speaker 3: developed in the last twenty years, not in the last
Speaker 3: you know, sixty, So we're talking Internet facing software. What
Speaker 3: I feel matters when you're not in a domain where
Speaker 3: which lends itself really really well to the advantages or
Speaker 3: disadvantages of any particular language, it ends up being mostly
Speaker 3: an aesthetic choice, like which language do I personally love better?
Speaker 3: Because if I can, and you know, over a long
Speaker 3: enough stretch of time, all systems can. If I can
Speaker 3: build my system in you know, PHB or JavaScript or
Speaker 3: typescript or Java or Continent or scholar any of those
Speaker 3: languages or Python, if you must, then which one I
Speaker 3: choose becomes either a functional decision, which is usually the case,
Speaker 3: it's just the one I happen to know best when
Speaker 3: I started on this system, and for the vast majorities
Speaker 3: of businesses, this will end up being the stack for
Speaker 3: the life cycle of the company, you know, barring a
Speaker 3: fundamental rewrite or in you know, the kind of growth
Speaker 3: that could not have happened twenty years ago, where you
Speaker 3: go multi lingual, if you have a lot of services
Speaker 3: in your company or whatever it is, if you remain
Speaker 3: a domain specific business for any length of time, you're
Speaker 3: very likely to be not only on the same stack
Speaker 3: you started off with as a matter of convenience, but
Speaker 3: also potentially running code you wrote when you started with
Speaker 3: that staff as a matter of convenience. And yet you
Speaker 3: can find working production systems in any of these languages,
Speaker 3: which to me says it is a matter of aesthetics
Speaker 3: more than anything else. Some people coming, yeah, sorry, go
Speaker 3: for it.
Speaker 4: So I get what you're saying, and it's obviously true.
Speaker 4: Like like I remember talking with various companies, there was
Speaker 4: a period of time where I was kind of interested
Speaker 4: what people was using in the industry. So you know,
Speaker 4: when you asked about the front end, and I was
Speaker 4: asking programming languages, not frameworks. You know, everybody was obviously
Speaker 4: JavaScript or typescript. But on the back end it was
Speaker 4: like this huge variety of things. It might be Ja,
Speaker 4: like you said, it might be Java, it might be Go,
Speaker 4: it might be dot Net, it might be php it
Speaker 4: and so on and so forth. Now, obviously all these
Speaker 4: languages are turingcomplete, and if they've got the appropriate libraries
Speaker 4: that you need you happen to need, then you know
Speaker 4: you can definitely go for it. And if you're doing
Speaker 4: web development then mostly what you need is like basically
Speaker 4: h GTP supportant to be able to connect to a database,
Speaker 4: and everybody's got that. But where I'm kind of pushing back,
Speaker 4: it's about the fact that you know, like you're kind
Speaker 4: of looking at them as they're kind of all equal,
Speaker 4: when you you know, different programming languages kind of represent
Speaker 4: at least in some cases, different philosophies or different approaches
Speaker 4: to programming. Like for example, Go, you might say, the
Speaker 4: philosophy is, you know, there should be only one way
Speaker 4: to do something, and that way should be obvious. Uh.
Speaker 4: If it's maybe, if it's Rust, then it's a system
Speaker 4: language that prioritizes uh resource uh lifetime over everything over
Speaker 4: everything else, resource ownership.
Speaker 3: I guess I would say, it's safety over everything.
Speaker 4: Resource safety over everything else. And and you know, obviously
Speaker 4: if you're looking at and like I don't know, another
Speaker 4: example might be uh uh.
Speaker 3: Like you know, like.
Speaker 4: C plus plus might be everything but the kitchen sink
Speaker 4: uh type of a philosophy uh. And and and then
Speaker 4: and in JavaScript, well you know was designed in ten
Speaker 4: days and and so so they do all represent two
Speaker 4: different approaches. It's like, you know, poetry sounds different when
Speaker 4: you say it in French or in German, or in
Speaker 4: Japanese or in Russia, even though all of them have poetry.
Speaker 4: So the question is don't these aesthetical or philosophical consideration
Speaker 4: make a significant difference in your opinion?
Speaker 3: No, they don't, because the reality of it is, if
Speaker 3: you look at every modern programming language ecosystem that's in
Speaker 3: the mainstream, the sort you would use as a general
Speaker 3: purpose language on the one hand, which admittedly is getting
Speaker 3: less and less kind of prevalent in the industry, or
Speaker 3: as shall we say, a language that's appropriate for whatever
Speaker 3: the type of web servers that we all build, or
Speaker 3: the type of front end applications that your listeners probably
Speaker 3: tend to build, or at least more so than I
Speaker 3: do you look at all these ecosystems and what they
Speaker 3: have is in common is while they all have different nuances,
Speaker 3: and a lot of these nuances are definitely the result
Speaker 3: of this sort of start philosophical difference in how they
Speaker 3: start it off, they all end up converging on the
Speaker 3: same set of tools, or at least tools that look
Speaker 3: very very similar. So I think at this point it
Speaker 3: would be fair to say that as an industry, we've
Speaker 3: learned that statically known types are useful for code organization
Speaker 3: and for code reuse. It is debatable whether when you
Speaker 3: build a system it's better not to use it. To
Speaker 3: have my own opinions, as I say, it's an esthetic
Speaker 3: choice because you turns out you can build systems in
Speaker 3: all of these but with JavaScript, with Python, with Php.
Speaker 3: I'm less familiar with the Ruby angle of things. Admittedly,
Speaker 3: certainly with Java and that whole ecosystem which started off
Speaker 3: as statically type you see in the mainstream, which was
Speaker 3: not the case twenty years ago. All of these ecosystems
Speaker 3: have first class typing, whether gradual or optional, piping kind
Speaker 3: of shoehorned onto the ecosystem, as is the case with Python,
Speaker 3: or sort of building an ecosystem and top of one,
Speaker 3: as is the case with Typescript, or built into the mix,
Speaker 3: as with Java. But all of them have this because
Speaker 3: we as an industry learned that this is a very
Speaker 3: beneficial tool for code reuse. When you have libraries, and
Speaker 3: those libraries expos static types, and those types are known
Speaker 3: in advance. It makes code reuse a lot easier because
Speaker 3: you don't have to reach into the code to figure
Speaker 3: out how it's going to behave in an error condition. Right,
Speaker 3: So that's just one example. Debittably, that's just one reason why.
Speaker 4: So talking about that particular reason and Chuck you know
Speaker 4: him better than I do, or we do. Dage Age
Speaker 4: has a very contrarian opinion here. You know, every everybody, everybody.
Speaker 4: It's like, from my perspective, looking at the JavaScript ecosystem,
Speaker 4: you can say that typescript has one. I mean it's
Speaker 4: possible that they are, you know, looking at the market
Speaker 4: as a whole, maybe still more JavaScript is being written
Speaker 4: than typescript. But when I look at enterprise companies, the
Speaker 4: type of companies you know that I the type of
Speaker 4: large scale projects that I tend to work on, you know,
Speaker 4: it's JavaScript only if it's legacy. Everything new is being
Speaker 4: written in typescript. Would you agree, But that's totally the
Speaker 4: contrary to dh Age's opinion of how we should be
Speaker 4: developing software.
Speaker 1: Well, so there are a couple of things here. One is,
Speaker 1: you know, just coming at it. You know, Tomer mentioned
Speaker 1: that he's not as familiar with the Ruby ecosystem.
Speaker 2: The typing is it's not even hotly debated anymore.
Speaker 1: The there are type systems that you can plug in
Speaker 1: to get type annotations on your Ruby. The vast majority
Speaker 1: of the community doesn't use them as far as typescript
Speaker 1: goes big part of it. If you've been watching, especially
Speaker 1: like the keynotes from Rails World for the last which
Speaker 1: was a couple of weeks ago, and then like last
Speaker 1: year and when in October, it's been pretty clear that
Speaker 1: David is much more a DHH. He's much more in
Speaker 1: favor of He's moved a lot more toward import maps
Speaker 1: and and a lot of the benefit that he's talking
Speaker 1: about is not having a build step.
Speaker 2: Right, if you have typescript, you have.
Speaker 1: To have it transpiled the JavaScript, and so by not
Speaker 1: using typescript, you avoid that step and you can actually
Speaker 1: just have your JavaScript written and have it loaded into
Speaker 1: your import map and then just come into your application
Speaker 1: that way, and so you avoid that.
Speaker 4: But did we also say that he's kind of opposed
Speaker 4: to static typing on principle.
Speaker 2: I've gotten that impression.
Speaker 1: I don't know that I could go find a place
Speaker 1: where he's actually directly said that you may be able to,
Speaker 1: and that's definitely the sentiment that comes through. But yeah,
Speaker 1: and I'm kind of in the same boat, right. I
Speaker 1: am not a big fan or proponent of having typing
Speaker 1: built into my stuff, and I think that, as Tomas mentioned,
Speaker 1: is kind of more of an aesthetic thing.
Speaker 2: I've never really felt the benefit of it when.
Speaker 1: I've done it, and so I, you know, I'm just
Speaker 1: not a huge proponent of it.
Speaker 2: It doesn't mean I'm against it.
Speaker 1: It's just that, you know, some of the other benefits,
Speaker 1: like not having a build step and things like that,
Speaker 1: you know, make it so that I look at it
Speaker 1: and say, well, in order to get that, the trade
Speaker 1: off just isn't worth it because I don't see the
Speaker 1: benefit for it, If that makes sense.
Speaker 2: It's interesting.
Speaker 1: I'm gonna kind of take it back because I have
Speaker 1: some other thoughts on this particular premise that is being
Speaker 1: brought forward because I generally agree that in a lot
Speaker 1: of cases, you know, capability wise, and you know, the
Speaker 1: different approaches that the different languages are going to kind
Speaker 1: of push you toward to get a job done. Yeah,
Speaker 1: you know, there's not a major difference as far as
Speaker 1: them being able to do the job. One thing that
Speaker 1: I've seen though, is that depending on what the advancement
Speaker 1: is and how actively those are being worked on.
Speaker 2: So this has more to do.
Speaker 1: With ecosystem really than language, we see that they tend
Speaker 1: to converge, like you said, Tomer, But the difference is
Speaker 1: that depending on where those innovations are coming from, being
Speaker 1: on the leading edge of a lot of that stuff
Speaker 1: is a benefit. But like I said, I think that
Speaker 1: has more to do with the ecosystem you're in. So
Speaker 1: for example, I just I just watched last week the
Speaker 1: Key from Rails World, right, and so he's talking about, Hey,
Speaker 1: we're simplifying the stack, and we're simplifying deployment, and we're
Speaker 1: making it easier and you know, and so he's talking
Speaker 1: about all these different things. A lot of these a
Speaker 1: lot of good ideas have come out of Ruby into
Speaker 1: other languages. A lot of great ideas have come from
Speaker 1: other parts other languages into JavaScript or into Ruby. Ruby's
Speaker 1: adopted some of this stuff, right, and so the convergence
Speaker 1: is there. But I also look at it and think, Okay, well,
Speaker 1: because I have the benefit of these particular things that
Speaker 1: have come into the ecosystem that haven't been adopted elsewhere, yet,
Speaker 1: I'm able to get more done in the system I
Speaker 1: use and things like that. And yes, some of that
Speaker 1: comes down to experience, but I think some of it
Speaker 1: also comes down to the language and its approach and
Speaker 1: the philosophy behind it and things like that. And so
Speaker 1: I generally mostly agree with you that programming languages it
Speaker 1: You know that there may be differences in hey, I
Speaker 1: want to pick this for this, right, if I'm doing
Speaker 1: system programming or something that needs that kind of characteristic,
Speaker 1: I'm probably going to reach for us as opposed to.
Speaker 2: Ruby your JavaScript.
Speaker 1: But beyond those basic things, I still think that there
Speaker 1: are meaningful differences between languages and systems that allow us
Speaker 1: to operate and be more productive. You know, certain goals.
Speaker 1: If if you care more about some characteristics than others,
Speaker 1: then you can reach for one over the other. And
Speaker 1: so like, I don't know that there's an empiric this
Speaker 1: this language is better than that language so much as
Speaker 1: you know, if you're working in this area. It's not
Speaker 1: just down to does it give you better tools? But
Speaker 1: does it give you better tools that literally make you
Speaker 1: move that far ahead?
Speaker 2: And Web in.
Speaker 1: Particular and back end is so disparate that that I
Speaker 1: feel like there really are I mean, I use Rails,
Speaker 1: and I'm biased that way, but I feel like there
Speaker 1: are a lot of really serious advantages that come from
Speaker 1: using Rails that other systems don't have.
Speaker 4: Yeah, but those advantages are those advantages from Rails are
Speaker 4: from Ruby, and could and could a Rails like system
Speaker 4: have been built on something other than Ruby, Right, because
Speaker 4: the discussion here at the end of the day, it's
Speaker 4: not so much about Rails. It's more about Ruby versus
Speaker 4: other programming languages.
Speaker 3: I would distinction that's I think.
Speaker 2: Some of them come from Ruby, but I think, yeah,
Speaker 2: I think some come from Rails. It could be built
Speaker 2: in other systems.
Speaker 3: I would argue that that distinction doesn't really exist when
Speaker 3: you pick a language, you pick an ecosystem. We are
Speaker 3: so far as an industry, as a as a discipline,
Speaker 3: we're so far beyond the point where you would build
Speaker 3: something on the language plus a very very lean standard library,
Speaker 3: you'd have to reach out to a whole bunch of
Speaker 3: stuff to build even the simplest of systems of the
Speaker 3: sort that we're talking about. Again, there might there not
Speaker 3: night there are exceptions to that rule. So if you're
Speaker 3: a kernel development developer, you absolutely have to have you
Speaker 3: have to do some degree of control over what the
Speaker 3: compiler generates and how these parts integrate and in with
Speaker 3: each other, which is why you would reach for a
Speaker 3: systems programming language that doesn't have a live runtime, right,
Speaker 3: that doesn't have garbage collection or whatnot. That being said
Speaker 3: for the mainstream, and by the mainstream, I mean, you know,
Speaker 3: the let's put it this way, not the part of
Speaker 3: the industry that existed twenty thirty years ago when a
Speaker 3: lot of us were starting our careers, but the part
Speaker 3: of the industry that grew up on top of that.
Speaker 3: Because the industry didn't just change, it grew exponentially, like
Speaker 3: it grew crazy wise in the last twenty years. So
Speaker 3: a lot of the software that end up writing today
Speaker 3: in the mainstream. There are nuances. Sure, you might prefer
Speaker 3: some element of an ecosystem or language or other, but
Speaker 3: as if what you're building is not in a domain
Speaker 3: where there is a tangible E system advantage. So, for instance,
Speaker 3: right now, if you're you know, if you're training models
Speaker 3: and you know, integrating in l lens and whatnot, probably
Speaker 3: you are going to reach for Python because it's you know,
Speaker 3: it's the go to ecosystem, it's the one that moves
Speaker 3: the fastest, et cetera, et cetera. That is why you'd
Speaker 3: reach for Python, not because you think Python is a
Speaker 3: better language for that sort of worse than Java or whatever. Now,
Speaker 3: once the ecosystems reach that kind of parody, which again
Speaker 3: for most kind of business use case sort of software
Speaker 3: that you would build, if you're in the front end
Speaker 3: and you're not a native, you're on the web, you
Speaker 3: don't really have that much of a choice. You can
Speaker 3: basically choose JavaScript or something that compiles the JavaScript, which
Speaker 3: again becomes more of an aesthetic choice than anything like
Speaker 3: you want to use ELM. Sure there are trade offs
Speaker 3: for your organization, not for the system you end up building,
Speaker 3: because it's all going to be running in a browser,
Speaker 3: the same as any other JavaScript based thing you're going
Speaker 3: to build.
Speaker 4: So yeah, but people writing ELM, for example, will swear
Speaker 4: by the fact that when they can get when their
Speaker 4: code compiles, it's correct.
Speaker 3: So speaking in.
Speaker 4: Which is not something you can say about JavaScript.
Speaker 3: Or I would say two things to that. One. It's hyperbole. Okay.
Speaker 3: If someone actually came up to my face and uttered
Speaker 3: that sentence with a serious face, I'd call their bullshit
Speaker 3: because that's that's just what it is. No, if your
Speaker 3: code compiles, it's not production grade. Don't give me that crap.
Speaker 3: Come on, we're grown ups.
Speaker 2: Second, I think we just hamburger out of that one.
Speaker 3: Yeah, just to qualify that assertion, Okay. I am strictly
Speaker 3: in the statically type statically compiled language camp. As an
Speaker 3: aesthetic preference. I'm a I'm I'm a Scalar guy, right
Speaker 3: and been for many years. I'm a co founder of
Speaker 3: what ended up being the Scala community in Israel and
Speaker 3: the conference that we hang around that So that's that's
Speaker 3: kind of my personal bias, and I can, you know,
Speaker 3: explain why that is my preference. But fundamentally, I come
Speaker 3: from the camp of languages that don't provide because no
Speaker 3: language can provide that. But that sort of drives you
Speaker 3: towards building code in a way where if it compiles,
Speaker 3: there is a very good chance that will actually run
Speaker 3: correctly in production. It's not going to guarantee that neither
Speaker 3: WLL one hundred percent code coverage in your tests, but
Speaker 3: will probably circle that to that point later. The point
Speaker 3: I'm trying to make here is.
Speaker 4: So before you get before you get to that point,
Speaker 4: because you brought up Scala and the fact that you
Speaker 4: were founding father of the Scala community, based on what
Speaker 4: you're saying today, would you have founded Scala the Scala
Speaker 4: community today given what Java can do, Because effectively what
Speaker 4: you seem to be saying is you know Scala, Java,
Speaker 4: they both run on the JVM. They're kind of parents.
Speaker 3: So I absolutely would because of two very fundamental things.
Speaker 3: One is circling back to my original assertion it's a
Speaker 3: matter of aesthetics. I don't say that aesthetic preferences don't matter.
Speaker 3: These are my aesthetic preferences. You know, if I'm growing
Speaker 3: flowers and vases around my house and I start a
Speaker 3: community around that, it's because I like flowers. It doesn't
Speaker 3: necessarily mean that flowers are objectively important. That's one thing.
Speaker 3: The second thing is that when I was heaving into
Speaker 3: skal and espousing Scala and the you know, in the
Speaker 3: Israeli tech community, Java couldn't do what Java can do
Speaker 3: now in the sense of expressivity. Sure, you could build
Speaker 3: systems in Java, but I would argue then, as now
Speaker 3: that Scala has advantages over Java, it doesn't make it
Speaker 3: a more useful language, or a more successful language, or
Speaker 3: even a preferable language necessarily for some people. There were
Speaker 3: organizations that have managed to convince to take the plunge,
Speaker 3: and they decided to do so with the trade off
Speaker 3: that it's going to be much harder to hire people
Speaker 3: to work in Scala, which by the way, did not
Speaker 3: turn out to be the taste. But that was the
Speaker 3: assumption because they felt they had something to gain from
Speaker 3: that choice. But it's not to say that if they
Speaker 3: had de picked Java instead or Python instead, they would
Speaker 3: have been any less successful. Wicks, by the way, which
Speaker 3: is a company you and I worked for, was for
Speaker 3: many years a poster child of Scala industry use, especially
Speaker 3: in Israel. Was it a good call for Wicks? I
Speaker 3: think so for a variety of reasons. But I don't
Speaker 3: think that decision made a significant contribution or put any
Speaker 3: sort of significant chunk of Wix's success in business or
Speaker 3: finance on the table. It just didn't have anything to
Speaker 3: do with it. Wix could have been developed in Java
Speaker 3: and Skala and Python in any of those languages.
Speaker 1: So would you make then the same argument around typescript
Speaker 1: versus JavaScript, where you know it's it's an aesthetic decision.
Speaker 1: Doesn't mean that typescript is necessarily better, but you know
Speaker 1: it does have some areas where it reads better, and
Speaker 1: it's a little nicer to work in and has some
Speaker 1: other advantages to it.
Speaker 3: I would, and this is I would argue against that,
Speaker 3: or rather I would say yes, I would make the
Speaker 3: same argument with respected typescript and JavaScript because and this
Speaker 3: is a qualitative argument with no data could back it up.
Speaker 3: Circling back to an original sentiment, we as an industry
Speaker 3: have learned that static types that known ahead of time.
Speaker 3: Static types are extremely useful in some cases. So JavaScript, sorry,
Speaker 3: just doesn't have that. Typescript adds that on top of
Speaker 3: JavaScript in a way that's been tried before to some
Speaker 3: degree of success or other with Coffee Script and with Flow.
Speaker 3: But Typescript made it work substantively better than those other
Speaker 3: options in a way that allowed it to enter the mainstream.
Speaker 3: But what caused the adoption of Typescript, in my opinion,
Speaker 3: is the very real value of having static types, especially
Speaker 3: in libraries of which you integrate a great many in
Speaker 3: any front end project. So in that respect, Typescript is
Speaker 3: quote unquote better than JavaScript because it's super set of
Speaker 3: JavaScript and because it adds something we as an industry
Speaker 3: find useful. That being said, it compiles down to JavaScript.
Speaker 3: So clearly everything you build in Typescript you can build
Speaker 3: in JavaScript.
Speaker 4: This is beyond instance, just to say it's beyond being
Speaker 4: compiled down to JavaScript. It's effectively you invest a lot
Speaker 4: of effort into writing Typescript types, and then they all
Speaker 4: get erased out of your code when it's deployed into
Speaker 4: the production.
Speaker 3: But the value proposition isn't at run time, Oh yeah,
Speaker 3: is a distinction from the dot Net and Java ecosystems,
Speaker 3: where types do matter at run time. That being said,
Speaker 3: us that depends on how you write it. But sure,
Speaker 3: the point I'm making here is Typescript to me is
Speaker 3: an evolutionary state of JavaScript, like treating it as a
Speaker 3: separate language. To my mind, as sort of an out
Speaker 3: side observer, I have no dog in this race, right
Speaker 3: I don't do my everyday work in JavaScript or typeescript.
Speaker 3: I do occasional work in JavaScript and typescript and Python
Speaker 3: and a whole plethora of other languages. So I don't
Speaker 3: care in a sense, but as an outside observer perspective
Speaker 3: in tying to this convergent evolution of languages, statement or
Speaker 3: argument is that this is that evolutionary stip. So piping
Speaker 3: at around three eighth or three seven, I think started
Speaker 3: getting optional typing around the same time type script started
Speaker 3: taking off.
Speaker 2: These are the.
Speaker 3: Those ecosystems version of a worthwhile feature that they took
Speaker 3: from statically type languages just to make things.
Speaker 4: You know, how would I praise it? Just things factually
Speaker 4: correct typescript in JavaScript? You know, there might be some
Speaker 4: conversion evolution. Obviously these two are tied at the waist,
Speaker 4: but they are distinct programming languages. There's a JavaScript that
Speaker 4: the ecmoscript standard says nothing about standard typing. It's highly
Speaker 4: probable that it never will you know where.
Speaker 3: And this is a production that may or may not
Speaker 3: prove true, and I might eat my words. But it
Speaker 3: also means that it's a standard that in five to
Speaker 3: ten years, the only relevance it has is for supporting
Speaker 3: legacy software, of which there is a lot. I don't
Speaker 3: deny it, but the ECMAScript standard that doesn't have anything
Speaker 3: to do with typing is about as relevant as the
Speaker 3: latest COBOL standard.
Speaker 4: Chuck, I will say this about the value of types.
Speaker 4: So I'm actually going through fairly large legacy project at
Speaker 4: work that's been that's like one hundred percent JavaScript, and
Speaker 4: we are gradually adding static typing into it. And I
Speaker 4: actually tweeted about this that the biggest challenge in adding
Speaker 4: the static typing is fixing all the bugs that it discovers.
Speaker 4: So for example, just just like yesterday, I ran into
Speaker 4: the problem there where this legacy system uses mobics, and
Speaker 4: mobiics has this concept of an observable array, which is
Speaker 4: kind of like which extends regular JavaScript arrays. It's very
Speaker 4: similar to JavaScript arrays, but it's not quite the same.
Speaker 4: It has methods that regular jobscript arrays don't have. For example,
Speaker 4: and people played fast and loose with it, they would
Speaker 4: a sign like observable arrays and arrays into the same variables.
Speaker 3: And the system.
Speaker 4: Now that you know and obviously the software works, it's legacy.
Speaker 4: It's you know, I like to say legacy software is
Speaker 4: software that works. It's deployed, customers are using it, so
Speaker 4: it works somehow. But it's also obviously a bug. Now,
Speaker 4: maybe this bug doesn't actually manifest itself in production. Maybe
Speaker 4: it does, and this system still somehow works because the
Speaker 4: web platform is very forgiving for both good and bad.
Speaker 4: But like I said, it's obviously a bug, and it's
Speaker 4: been around probably for years, and I've found it now
Speaker 4: because I'm adding static type information into the project.
Speaker 1: Yeah, I would just put forward that, you know, because
Speaker 1: we're talking about different languages having different characteristics. The two
Speaker 1: systems for Ruby are RBS and sorbet. RBS is maintained
Speaker 1: kind of by the Ruby core team, and then sorbet
Speaker 1: is put out by Shopify.
Speaker 2: They tend to feel more onerous than.
Speaker 1: Surfacing any issues like this, right and so, and I
Speaker 1: think sure, as some systems get more complex, I don't
Speaker 1: know if I have the right terminology for exactly what.
Speaker 2: It's kind of a vague term.
Speaker 1: But you know, as things become more interconnected, as people
Speaker 1: are pulling in more libraries, maybe you know, it might
Speaker 1: begin to pay off. But my theory is more that,
Speaker 1: as Thomas said, there are a lot of efforts that
Speaker 1: were tried to get something like typescript to work in JavaScript,
Speaker 1: to add the static types, and I'm thinking more along
Speaker 1: the lines of these just aren't the right solution if
Speaker 1: we're going to do it in Ruby, it just doesn't
Speaker 1: jive with the way the language goes. I also have
Speaker 1: to say that the duck typing and the approach that
Speaker 1: we take to a lot of things in Ruby, it
Speaker 1: really feels just free. I can just do what I
Speaker 1: need to do and so, and I'm not saying that's
Speaker 1: right or wrong. I'm just saying they're definitely things that
Speaker 1: inform the way people work in these languages to where, Yeah,
Speaker 1: I don't think just saying static typing is necessarily the answer.
Speaker 2: Think you.
Speaker 1: I think there's more nuanced to a lot of this,
Speaker 1: And I think to be to be honest, as we've
Speaker 1: kind of seen the convergence evolution of a lot of
Speaker 1: these languages, that's what we see there too, right, is
Speaker 1: that everybody kind of does it kind of their own
Speaker 1: way as they adopt these things. And so it's it's
Speaker 1: not just this language is picking up with this other
Speaker 1: language innovated, it's that we've found a way to do
Speaker 1: it in a way that works with the way that
Speaker 1: people approach and think about problems in that language. Yeah,
Speaker 1: you know, I guess I'm not really trying to defend
Speaker 1: anything more.
Speaker 2: I'm just trying to say.
Speaker 1: I have I haven't seen the benefit, and it's mostly
Speaker 1: because what I'm doing just it hasn't it hasn't had
Speaker 1: the payoff. But you know, I mean, all of this
Speaker 1: could change.
Speaker 2: You just never know, So.
Speaker 3: I would I would add to that that, first of all,
Speaker 3: I think it's not just legit or fine that you
Speaker 3: hold to those positions. It's a valid trade off to make.
Speaker 3: So one canonical difference, which I think was very evident
Speaker 3: in both what done describing his experiences and what you
Speaker 3: Charles did, is that it's all a trade off. It's
Speaker 3: it's a difference of what it is that you stress
Speaker 3: in the system. So my intuition and again qualitative argument,
Speaker 3: I have no data to back it up, and I
Speaker 3: don't think anyone ever will, or at least not in
Speaker 3: my lifetime. I could be wrong what pace even are.
Speaker 3: Sometimes what I see is the value of static typing,
Speaker 3: or rather static typing is a bit of a large term.
Speaker 3: The value of the sort of typing that I'm talking
Speaker 3: about which can be achieved with static typing, but also
Speaker 3: with gradual typing, as you can see in typescript or
Speaker 3: pipes in other languages. Really starts to bear fruit at
Speaker 3: a certain not complexity level, but at a certain size
Speaker 3: of the thing that you're building and the number of constituent,
Speaker 3: interconnected parts that comprise it. So it's not so much
Speaker 3: about whether what you're building is is a state.
Speaker 2: I couldn't find the way of saying it, but yeah,
Speaker 2: that makes sense.
Speaker 3: It mostly starts manifesting for real. In my experience, two cases.
Speaker 3: One is when the system grows past a certain volume
Speaker 3: of stuff that's in it, and that's true of any
Speaker 3: language I've ever worked with, including statically, dynamically ted, what
Speaker 3: have you. The other situation, which I think is where
Speaker 3: the sort of productivity gains perceived by the industry are
Speaker 3: coming from, is it aids in someone not knowing what
Speaker 3: the code is and how it's constructed, but knowing what
Speaker 3: it is supposed to do and how code is constructed
Speaker 3: in the general sense of things, being able to get
Speaker 3: involved with the system or engage with the system at
Speaker 3: a fairly deep level. The only way you can do
Speaker 3: that rapidly without signalificant onboarding and significant prior knowledge, which,
Speaker 3: by the way, as a Rails guy, you already have.
Speaker 3: So when you come into another system built on Ruby,
Speaker 3: built in Ruby on Rails, you already have that massive
Speaker 3: baggage of how the system is built. Because Rails is very,
Speaker 3: very prescriptive, and that is the trade off. I feel
Speaker 3: that DHH is kind of espousing and fair enough. There
Speaker 3: is no denying that you can be extremely productive if
Speaker 3: you're a rails engineer moving from one system built and
Speaker 3: Rails to another. I've seen it, right, I've seen people
Speaker 3: do that and they're extremely productive. The difference is Rails
Speaker 3: is incredibly prescriptive and as a result of that, is
Speaker 3: a good fit for some systems, maybe even most systems
Speaker 3: of that sort, I don't know, but it is definitely
Speaker 3: a very very poor fit for other types of systems
Speaker 3: that are in the mainstream. Otherwise, you know, I think
Speaker 3: we would be seeing more success in Ruby and Rails
Speaker 3: as we did in the two thousands. So my argument
Speaker 3: here is there are trade offs that stress different parts
Speaker 3: of the system under different circumstances. The most visible trade
Speaker 3: off of picking a dynamic versus static language is in
Speaker 3: a dynamic language especially on projects that don't meet that
Speaker 3: sort of size or volume threshold and have a relatively
Speaker 3: small number of people that engage with that system in
Speaker 3: its life cycle, which, by the way, is you know,
Speaker 3: a thing that happens very often, which is why rails
Speaker 3: was and continues to be somewhat successful as long as
Speaker 3: those limits are meant. It is an incredible experience. And
Speaker 3: you see that with a variety of languages that some
Speaker 3: of which have inspired Ruby. So you still see people
Speaker 3: that have worked on production systems in small talk raving
Speaker 3: about what it felt like to work on production systems
Speaker 3: in small talk, right, not having had that experience. I
Speaker 3: you know, I'm not going to argue with them about it,
Speaker 3: but they kind of express what that did for them
Speaker 3: in the same way that it felt very liberating. And
Speaker 3: I categorically will not deny that or that there's a
Speaker 3: productivity boost to be had by that. But you take
Speaker 3: a Ruby rails engineer, you drop them into you know,
Speaker 3: no prior knowledge, you drop them into a sufficiently voluminous
Speaker 3: base in any other language, they will be able to onboard.
Speaker 3: Not because there's nothing wrong with Ruby, and you're not
Speaker 3: you know, you don't not owe something coming from group.
Speaker 3: You have your preferences, but my point is that the
Speaker 3: reverse is not true. You take people that are well
Speaker 3: versed in production systems in a variety of languages, you
Speaker 3: drop them into a rail system to extend it or
Speaker 3: fix it, or improve the build process or whatever it
Speaker 3: is that they want to do in that system, because
Speaker 3: it relies so heavily on sort of ingering knowledge of
Speaker 3: the philosophy of rails, how things are designed, how things
Speaker 3: are built. If you don't have that coming in, and
Speaker 3: you don't have that also kind of dated to when
Speaker 3: that system was built, because modern rails doesn't look quite
Speaker 3: like rails from five or ten or fifteen years ago,
Speaker 3: and in some cases vastly different. Unless you have that knowledge,
Speaker 3: you're just not going to be able to get up
Speaker 3: to speed and be productive in that system in any way,
Speaker 3: shape or form without significant handholding. And I've been in
Speaker 3: that position myself, and it's not pleasant. Whereas you have
Speaker 3: the same experience, by the way, with the system built
Speaker 3: in Python or PHP from ten years ago, because then
Speaker 3: they didn't have some of these quality of life enhancements,
Speaker 3: you didn't have known types and known error conditions, and
Speaker 3: a hell of a lot more Python docs that you
Speaker 3: could see in your idee, and you know, you just
Speaker 3: didn't have those things ten years ago. Whereas today, coming
Speaker 3: from any language that's modern in mainstream to any other
Speaker 3: language that's modern in mainstream is not going to be
Speaker 3: smooth sailing because languages are different than there are nuances.
Speaker 3: But you're gonna be able to figure out where you
Speaker 3: are in the code. You are going to be able
Speaker 3: to navigate to related things in the code without having
Speaker 3: a lot of ahead of time knowledge. And that matters.
Speaker 3: That matters with bigger products, with bigger teams, with products
Speaker 3: whose life cycle spans many years and many teams and
Speaker 3: many people. And I think that is the primary motivator
Speaker 3: for those typing systems. Even in traditionally dynamic languages like Python, JavaScript, whatever. Again,
Speaker 3: Ruby spouses a different philosophy, a different set of trade offs.
Speaker 3: I don't deny that they're valid, I don't necessarily subscribe
Speaker 3: to them. And if I were to find a legit
Speaker 3: argument against that, I would say, simply look at the
Speaker 3: you know, look at the math, look at the popularity.
Speaker 3: Ruby was extremely popular for just short of a decade.
Speaker 3: A decade is long gone, and it never picked up
Speaker 3: since and there's nothing to indicate that it will. And
Speaker 3: it's not because Ruby is bad or Rails is bad. Right,
Speaker 3: it's against my personal biases. But you can build systems.
Speaker 3: I mean, I've used based camp extensively. It's a great product.
Speaker 3: I don't care what it's written in as long as
Speaker 3: it works. So, yeah, you see the languages in the mainstream.
Speaker 3: Circling back to our original premise, right, you see the
Speaker 3: languages in the mainstream. There are nuances, there are philosophical differences.
Speaker 3: Those do matter in the tactical sense, like as you
Speaker 3: write code, you're not going to write the same code
Speaker 3: in Python as you do in Java or Skylla or
Speaker 3: any of those languages, or in type stript or in JavaScript.
Speaker 3: But you look at the ecosystems and they're all learning
Speaker 3: from each other and offering what appears to be a
Speaker 3: productive in the broad sense set of features and type
Speaker 3: systems is I think just the most visible of those.
Speaker 3: You also have dependency management, which frankly wasn't the thing
Speaker 3: years ago, right. Maven was probably one of the first
Speaker 3: two major dependency management stacks.
Speaker 2: Uh.
Speaker 3: Pip picked up a lot of that. Then Pip kind
Speaker 3: of languished. Poetry came along to fix you know, some
Speaker 3: of these things and learn other lessons. And then you
Speaker 3: have Cargo, which is probably the biggest, newest one of
Speaker 3: the bunch, that learned a lot of those lessons from
Speaker 3: languages that are in completely different spaces.
Speaker 4: Rus typescript, don't forget NPM.
Speaker 3: I'm trying to, but it's not gonna work out. But no,
Speaker 3: I mean that I'm being you know, I'm being intentionally
Speaker 3: cynical here.
Speaker 2: I would say.
Speaker 3: Colossal influence. I do not have a dog in this
Speaker 3: race either, but I can say it's this interested observer
Speaker 3: that NPM has had a colossal impact on pretty much
Speaker 3: every ecosyste them out there. Without NPM, we would not
Speaker 3: have Cargo, including the things that Cargo does better, simply
Speaker 3: because it learned those lessons, right right, So that is
Speaker 3: what I mean by convergent evolution. You have a lot
Speaker 3: of the same things. And by the way, a lot
Speaker 3: of languages. JavaScript used to be the poster child for
Speaker 3: oh there's no build, isn't it great? I just update
Speaker 3: the code and there it is, which comes with an
Speaker 3: incredible set of trade offs, and some of those trade offs,
Speaker 3: by the way, were very early on ruled not by
Speaker 3: me and not by people hating on JavaScript like i I do,
Speaker 3: ruled by the reality of it, ruled by the community
Speaker 3: of people producing functional production code as being a non issue.
Speaker 3: You had a build process in many, many, many, many
Speaker 3: JavaScript systems over the last twe years, if only for
Speaker 3: you know, dependency management, asset bundling, obfuscation, minifit cation, what
Speaker 3: have you. All these things you couldn't get in a
Speaker 3: runtime system. So it was not a worthwhile trade off, right,
Speaker 3: So that ostensible advantage is not an advantage as such.
Speaker 3: It's a tradeoff, And I think a lot of those
Speaker 3: trade offs are made because the ecosystem hasn't met those
Speaker 3: challenges properly in a way that doesn't require a trade off.
Speaker 4: I really, I really want to try to get to
Speaker 4: the second sacred cow, and we seem.
Speaker 2: To be that. I was wondering if we were going
Speaker 2: to get to any others.
Speaker 4: So so, unless you've got something really insightful to add tomorrow,
Speaker 4: I would like to move along.
Speaker 3: I think I think that that does not have much
Speaker 3: chance of ever happening.
Speaker 2: If we do number two, we're not getting to any
Speaker 2: any of the.
Speaker 4: Other ones we can have Tomorrow on again.
Speaker 2: I'm fine with that this has been fascinating to doctor.
Speaker 4: All right, so let's try to at least on the
Speaker 4: second one. Let's Chuck say you're going to read the
Speaker 4: second one.
Speaker 1: I will read the second one. So this is what
Speaker 1: he's going to debunk.
Speaker 2: This is not so anyway, It's clean code is important.
Speaker 4: All right.
Speaker 3: So I'll start by qualifying that.
Speaker 2: I was gonna say, I don't know if I agree
Speaker 2: with you, and.
Speaker 3: I'm going to be talking about exactly what you think
Speaker 3: I'm going to be talking to. I just want to
Speaker 3: make sure we're all on the same page. So when
Speaker 3: I say clean code, what I mean is the set
Speaker 3: of perceived notions of what clean code is and how
Speaker 3: to write it as had been espoused in the industry.
Speaker 3: And we said we might name drop, but I mean,
Speaker 3: you can't not name drop uncle Bob as the progenitor
Speaker 3: of these practices.
Speaker 2: Uncle Bob's a good friend of.
Speaker 3: Mine, but muh cool, so one, I'm one of them.
Speaker 2: I disagree with him too, So that's fine.
Speaker 3: All right. So so here's here's what I have to
Speaker 3: say on the subject. My issue with the with clean
Speaker 3: code has nothing to do with its intent, and the
Speaker 3: intent the way I see it is to help people
Speaker 3: design systems that are more readable, that are more sensible. Uh,
Speaker 3: you know, it's all those best intentions that the way
Speaker 3: way to help.
Speaker 2: Is the way I typically approach it.
Speaker 4: You just noticed what Thomers said. He said, that's the way,
Speaker 4: you know, the way to hell is paved with good intentions.
Speaker 3: Because the rules of because what clean code is is prescriptive,
Speaker 3: and the way people understand it is as a set
Speaker 3: of rules and practices that must be adhere to or
Speaker 3: code is bad or the code isn't clean. So there
Speaker 3: are a lot of examples to this, but the kind
Speaker 3: of most obvious, and I think in many ways the
Speaker 3: most egregious one is dry is do not repeat yourself.
Speaker 3: And there is a fascinating amount of the magogaery going
Speaker 3: on in the industry around that in similar rules where
Speaker 3: you will, sooner or later in your career if you
Speaker 3: haven't already, and by you, I mean everyone with more
Speaker 3: than half a year of experience, run into someone telling you, oh,
Speaker 3: but why don't you extract these two identical lines that
Speaker 3: come with you know, within twenty lines of each other
Speaker 3: into a method because they're the same and they're reusable,
Speaker 3: or if they're slightly more advanced, and they're digging into
Speaker 3: this only when those that identical line shows up three times.
Speaker 3: Because if it doesn't show up three times and it's not,
Speaker 3: you know, you don't.
Speaker 2: Dry it be juice, beetle juice.
Speaker 3: Yeah. No, No, that's a prescription, and it's a really
Speaker 3: terrible prescription, first of all because it doesn't do anything.
Speaker 3: Second of all, it's because it wastes a whole heap
Speaker 3: of people's time thinking about their own thing. And third
Speaker 3: because it causes it and other uh. Discussions of clean
Speaker 3: code end up wasting no more and no less time
Speaker 3: than arguments about code formatting used to back in the day.
Speaker 3: Because the rules are approximate, the rules are intended, are
Speaker 3: are prescriptive and intended not for you to follow religiously.
Speaker 3: That's my read on it, And that's kind of the
Speaker 3: you know, my assumption of the intent behind the words, right, I.
Speaker 2: Don't that's my understanding as well.
Speaker 3: Yeah, I don't know, uncle Bob. You know, I'm not
Speaker 3: gonna there's not an ad hominem thing. My concern with
Speaker 3: these rules is that people take them as gospel without
Speaker 3: considering what it is that they're trying to accomplish. So
Speaker 3: the rules of clean code are not in and of themselves.
Speaker 3: You know, they might be evil, but the intent isn't.
Speaker 3: Intent to my mind is just misguided. The intent is
Speaker 3: to build systems that are more maintainable, as you say,
Speaker 3: or readable, or any of these things, without actually reaching
Speaker 3: for what it is that that makes a system more
Speaker 3: maintainable or readable or navigable or any of these things,
Speaker 3: which is simplicity versus complexity. And I can define those things,
Speaker 3: and we may want to. But critically, those rules, to
Speaker 3: my mind, right as in my own reading of them,
Speaker 3: were they are not so much that people know not
Speaker 3: to repeat themselves more than twice in code, because that's
Speaker 3: just garbage. The rules are there to get people thinking,
Speaker 3: what is simple? What will make this code easier to grasp,
Speaker 3: easier for another person, which, as the saying goes, might
Speaker 3: be mean in six weeks. What will make it easier
Speaker 3: to read this code, figure out what it does, why
Speaker 3: it does it, how it does it with a minimal
Speaker 3: of external drivers or external knowledge, And that means simplicity.
Speaker 4: So here I'm going to push back on something. I
Speaker 4: think what you might be ignoring is the fact that
Speaker 4: is kind of the thing that comes up. It came
Speaker 4: up very early in the in the industry in the
Speaker 4: form of the mythical manment. Is the fact that not
Speaker 4: all such by the way, yeah, the fact that not
Speaker 4: all programmers are.
Speaker 3: Another sacred cow too.
Speaker 4: Yeah yeah, the fact that half the programmers in the
Speaker 4: world are worse than the average programmer.
Speaker 2: And definitionly, I guess it's mean.
Speaker 4: It's mean, it's true, it's mean, but it's true by definitely.
Speaker 3: Yeah.
Speaker 4: Well, okay, yeah, I think in this particular case, the
Speaker 4: average and the mean are probably fairly close.
Speaker 3: We're talking humans, for a change, the normal distribution.
Speaker 4: Yeah, it's not like wealth. So what I'm trying to
Speaker 4: say is, if you've got a team on which you've
Speaker 4: got a top notch developer that is able to make
Speaker 4: sure that the system as a whole retains this attribute
Speaker 4: of simplicity, then you need you You don't need to
Speaker 4: adhere as much to these kinds of strict rules and
Speaker 4: guidelines when you're on teams that don't have such a person,
Speaker 4: then maybe having overly strict rules is a good thing,
Speaker 4: don't you.
Speaker 3: Think, Well, speaking is a statically typed guy, I can't
Speaker 3: very well rail against that argument. But taking a little
Speaker 3: bit more head on. There's two issues I have with
Speaker 3: that argument that I think kind of nullify that argument.
Speaker 3: The first is it doesn't actually argue anything beyond oh,
Speaker 3: other people are stupid. It's for their own goods, which
Speaker 3: is not an argument that I buy, even though you
Speaker 3: know I might subscribe to that opinion. The second issue
Speaker 3: I have with it is engineers that don't have in
Speaker 3: that haven't over the course of presumably several years. They
Speaker 3: don't have to be super senior developers, right, But if
Speaker 3: you've been in the industry for a couple of years,
Speaker 3: presumably wrote a bunch of code, presumably read quite extensively
Speaker 3: more code than you wrote to begin with, and you
Speaker 3: haven't developed an appreciation for the basic truth that copy
Speaker 3: pasting a complex bit of code over and over again
Speaker 3: is bad, then your problem isn't that you have don't
Speaker 3: have the right rules in place to limit you. Your
Speaker 3: problem is that your company hired you to do a
Speaker 3: job that you're probably incapable of doing. Now that being
Speaker 3: said that that sounds like gatekeeping, probably because it is,
Speaker 3: because I can't help it. But to bring that home
Speaker 3: and perhaps you know, save my own skin with other people,
Speaker 3: my point is this, some types of programming you can
Speaker 3: do with these types of guardrails in place, and there
Speaker 3: is room for that work in the industry, I hope, right.
Speaker 3: But the types of systems that you will be able
Speaker 3: to work on is not infinite. You're not going to
Speaker 3: be able to build large, production grade, long lived, difficult
Speaker 3: systems that deal with actual problems that are interesting if
Speaker 3: you are not willing to put in the thought and
Speaker 3: learn what makes code more readable, more navigable, et cetera,
Speaker 3: and you have people around you to help you do that.
Speaker 3: So it's not like if you are a junior developer
Speaker 3: and you come in and you make a quote unquote
Speaker 3: dry violation mistake, you're going to get fired. You're hopefully
Speaker 3: going to because you're a junior developer. You were hired
Speaker 3: in the context where you can be you know, functional,
Speaker 3: and you have support. You're probably going to have the
Speaker 3: person next to you, that senior developer, explaining why this
Speaker 3: makes the code worse. But you're not likely to have
Speaker 3: a set of guardrails keeping you from making those mistakes
Speaker 3: because those guardrails are literally anathema to the way virtually
Speaker 3: any any practicing software engineer works. So if imagine you
Speaker 3: were working on a system and you were writing code,
Speaker 3: and your code would not compile because the compiler feels
Speaker 3: that you have, you know, those two lines of code
Speaker 3: identical in three places. So that's a dry violation, and
Speaker 3: you you know you can't compile the code, right. That
Speaker 3: is that sounds ridiculous because it is because the assumption
Speaker 3: is if you're working on those systems, you have to
Speaker 3: have both a taste four code, whereby you wouldn't necessarily
Speaker 3: you would learn very early on why that's mistake, and
Speaker 3: you would stop making it because it's communication. There is
Speaker 3: nothing inherently wrong with having several copies of the same
Speaker 3: code in the same place. It's a tradeoff, right, What
Speaker 3: is the tradeoff? If you can't have that conversation, you're
Speaker 3: never going to become a better developer. The guardrails aren't
Speaker 3: going to help you get there. They're just going to
Speaker 3: stop everyone else from doing their job.
Speaker 4: So I think this is a great topic and one
Speaker 4: I think we should probably have you on to discuss
Speaker 4: at length about what is actually simplicity and coding. We
Speaker 4: probably don't have time to do it, justice. I'll I'll
Speaker 4: just add the fact that I, you know, I never
Speaker 4: liked Douglas Crockford's linter, what's it called j slint, the
Speaker 4: original linter, because it basically say, you know, Douglas Crawford said,
Speaker 4: this is you know, this is JavaScript the good parts.
Speaker 4: Everything else is not good by definition, because I said so,
Speaker 4: and I built the splinter to enforce my rules, and
Speaker 4: you know you can't you can't modify it. And there's
Speaker 4: a reason E a splint one and because you know
Speaker 4: it's it's when you're so dogmatic, it's it's a problem.
Speaker 3: Contrary wise, there's a reason Java lost, if you can
Speaker 3: call it that. And the reason Java isn't anywhere near
Speaker 3: as popular as it used to be percentage wise for
Speaker 3: building the types of systems that Java used to be
Speaker 3: popular for is because a lot of people were thrown
Speaker 3: off and turned away by what is to a you know,
Speaker 3: a seasoned experienced engineer after the mission, a rigorous type
Speaker 3: system that forces you to not make mistakes, whereas a
Speaker 3: lot of practicing developers would look at it and go, yeah,
Speaker 3: but who gives a dam that's you know, that's completely trivial.
Speaker 3: I don't care. I don't want to have to miss
Speaker 3: with it, and moved on. So the languages that ended
Speaker 3: up being successful are the ones that found a workable
Speaker 3: middle ground, and I include on that list, by the way,
Speaker 3: later iterations of Java. Modern Java isn't anywhere near as
Speaker 3: verbose or part of my French anal retentive as traditional
Speaker 3: Java used to be, and that is because other languages
Speaker 3: showed that that kind of It's not just verbosity. Everyone
Speaker 3: you know, rails against Java being verbos but it's also
Speaker 3: that precision just isn't necessary in a lot of things. Right.
Speaker 3: The common case where you have a class and that
Speaker 3: class has hash code into string and a few constituent
Speaker 3: components is common enough that it makes sense to have
Speaker 3: a first class language concept around it. And it took
Speaker 3: Java way too long to reckon with that, but eventually
Speaker 3: it got record classes, you know, the sort of same
Speaker 3: ad hoc data containers that every other type every other
Speaker 3: language has had since the beginning of time, because it's
Speaker 3: convenient and useful and doesn't require the level of control
Speaker 3: and precision that Java espoused at the beginning. So things
Speaker 3: evolve across the board. It's not I'm not trying to
Speaker 3: make the point. You know, this kind of circles back
Speaker 3: to original Kyle, But with this as well. Is the
Speaker 3: tools that win tend to be the tools that are
Speaker 3: not the most rigid or the most liberating, and for
Speaker 3: a very good reason. It's because having absolutely no guardrails
Speaker 3: is a recipe for disaster, which is why hardly anyone
Speaker 3: writes business software in C or SQLS plus anymore. It's
Speaker 3: because you don't get anything in return to that level
Speaker 3: of precision and control. You only get deviced. Like for
Speaker 3: those domains, anything that's sufficiently successful in the modern sense
Speaker 3: has made those trade offs willingly, and I think we
Speaker 3: find those trade offs being made in every ecosystem, kind
Speaker 3: of converging on the same set of trade offs, roughly
Speaker 3: with nuances and preferences. As for clean code, clean code
Speaker 3: is prescriptive and therefore bogus. The problem is the rules
Speaker 3: are not. The rules are well intentioned, but they provide
Speaker 3: the wrong kind of guidance and end up causing more
Speaker 3: damage than harm in my opinion.
Speaker 1: So I'm gonna jump in on some of this. So,
Speaker 1: like I said, I've talked to Uncle Bob quite a bit.
Speaker 1: I've actually talked to him about the Clean Code book.
Speaker 1: We also I ran a book club for a while.
Speaker 1: In fact, I still kind of do. But so we
Speaker 1: did clean Code. We also did Clean Architecture. A lot
Speaker 1: of the things that we talked through as we talked
Speaker 1: through the book, right, he wrote it when he was
Speaker 1: writing a lot of languages that frankly are pretty different
Speaker 1: from Ruby or JavaScript where I was primarily working. And
Speaker 1: so I point some of these out, either, you know, hey,
Speaker 1: this doesn't make as much sense in the world I
Speaker 1: live in as the world that you know this seems
Speaker 1: to be written for. And he agreed, right, And so
Speaker 1: in a lot of cases, yeah, they're they're kind of prescriptive,
Speaker 1: and maybe he doesn't make that as clear that hey, look,
Speaker 1: you've got to apply this is makes sense depending on
Speaker 1: what you're doing.
Speaker 2: A lot of the ideas.
Speaker 1: In the book Clean Code, and a lot of the
Speaker 1: ideas in the book Clean Architecture, I picked up another
Speaker 1: one I can't clean Agile. I think I also read.
Speaker 1: And the main thing is is I find that the
Speaker 1: rules or ideas behind the rules are definitely worth discussing
Speaker 1: with your team, right and having the conversation, hey, look,
Speaker 1: when we're naming variables, we ought to consider these things,
Speaker 1: you know, when we're writing out our code, we ought
Speaker 1: to consider these things, right, so when you when you
Speaker 1: get down to you know, follow standard conventions, I mean,
Speaker 1: that makes it approachable for anybody who works in the
Speaker 1: language or framework or whatever.
Speaker 2: You know, you get into.
Speaker 1: Keeping it simple, I think is one of his points,
Speaker 1: which is also your point. But yeah, as you get
Speaker 1: into some of the other ones where it's like here's
Speaker 1: how you formulate comments, and here's how you name variables,
Speaker 1: and here's how you you know, do these kinds of things. Yeah,
Speaker 1: some of those I found just you know, we're a
Speaker 1: little bit tough to swallow. But it was mainly because
Speaker 1: my context was different enough to where I could come
Speaker 1: up with a guideline that made sense for what I
Speaker 1: was doing, and to like dry.
Speaker 2: Yeah.
Speaker 1: I think it's funny because you mentioned, you know what
Speaker 1: if your tool told you that it wouldn't compile if
Speaker 1: it wasn't dry enough. And back in the day, earlier
Speaker 1: in the Ruby community, there were tools that would do
Speaker 1: code analysis and they would point out areas of your
Speaker 1: code that weren't dry. And what I found was at
Speaker 1: least half, if not more than, you know, significantly more
Speaker 1: than half in some cases, in some of the code
Speaker 1: bases I worked in, it point out something wasn't dry,
Speaker 1: and it was wrong, right, it was it? It like,
Speaker 1: structurally the code looked similar, but in reality the concern
Speaker 1: was different enough to where it didn't make sense to
Speaker 1: combine them like you would have been putting in edge
Speaker 1: cases every other line. Oh this is different from that here,
Speaker 1: and so we're going to do this this way instead
Speaker 1: of that way. And it's just, you know, you're better
Speaker 1: off having two things that look kind of the same.
Speaker 2: And so.
Speaker 1: Again, I think I think there's a heavy dose of
Speaker 1: common sense that comes with this. Initially, when I saw
Speaker 1: your point, I thought you were going to make the
Speaker 1: point that, you know, trying to have code that's easy
Speaker 1: to understand and clean and maintainable and stuff like that
Speaker 1: is kind of an overblown.
Speaker 3: Making the case for cowboy coding.
Speaker 1: And yeah, and I was gonna say, no, you really
Speaker 1: do need to, you know, have some level of hey,
Speaker 1: you can look at this, you can understand it, and
Speaker 1: then that, like you said, that's the goal of clean code.
Speaker 1: But my deal is is with a lot of these
Speaker 1: or if you read other because there are other books
Speaker 1: that give different rules or standards. Yeah, and the reality
Speaker 1: is is you've got to figure out what works and
Speaker 1: in some cases it's not just works for your team.
Speaker 1: Sometimes it's this code base has a set of problems
Speaker 1: that if you apply the standard from the other codebase
Speaker 1: you're working in, it's just not going to work. One
Speaker 1: other case I want to make is several years ago
Speaker 1: Sandy Metz. She had a set of rules for how
Speaker 1: you formatted your Ruby code, and it was you should
Speaker 1: never have a method that's longer than so many lines.
Speaker 1: You should never have more than so many arguments in
Speaker 1: your methods, you shouldn't have many more than so many lines.
Speaker 4: And then I hate that so much when my method
Speaker 4: ends up being one line too long.
Speaker 2: Yeah, and that was the problem.
Speaker 1: And then you're looking at it and you're scrutinizing it,
Speaker 1: and you're trying to figure out right, because there were
Speaker 1: there were linters in Ruby that would enforce it and
Speaker 1: it would fail to build if or fail you know,
Speaker 1: fail ci if if it was right. So, you had
Speaker 1: an eight eight line method and you're looking at and
Speaker 1: you're going, well, the only way to get it that
Speaker 1: way is essentially to create a second method and just
Speaker 1: put two of the lines in it, which doesn't help, and.
Speaker 3: So I will I will add to there's there's two
Speaker 3: things here, right. There's, first of all, circling back to
Speaker 3: the really the beginning of the conversation, a programming language language.
Speaker 3: It's about communication, yes, funda mentally, you know. I think
Speaker 3: I've read some guy at some point, probably twenty thirty
Speaker 3: years ago putting it as a prose that's readable by
Speaker 3: humans and executable by machine, right, which I think is
Speaker 3: a very high fludent way of putting it. But it's
Speaker 3: close enough to reality. What matters when it comes to
Speaker 3: the way the code is structured and formatted are the people.
Speaker 3: If it does what it's supposed to do, then the
Speaker 3: only reason why you should ever care what the machines
Speaker 3: think is when the code doesn't compile. Obviously, in the
Speaker 3: one hand, but if you have a typically a performance
Speaker 3: oriented thing that requires you to express something in a
Speaker 3: way convoluted to humans but more easily executable to a machine,
Speaker 3: that can happen. That's niche though, so by and large,
Speaker 3: when when you did the work you do, you do
Speaker 3: it for other humans, and one of those humans might
Speaker 3: be in six weeks. Clean code as it is is
Speaker 3: a very good thing in the sense that it was
Speaker 3: one of the few and only resources in sort of
Speaker 3: the space of how to build better code. Like it
Speaker 3: was an honest attempt at it, but I think a
Speaker 3: lot of people read into it as again, more of abscription.
Speaker 3: More it became its own thing. I'm railing not against
Speaker 3: the intent or against Uncle Bob personally again, I don't
Speaker 3: know him that I've got nothing to add to that,
Speaker 3: but I am railing against the way it became embedded
Speaker 3: in the industry, because much like a topic we're not
Speaker 3: going to have time to discuss here again, which is TDD,
Speaker 3: it became more of a on the one hand, or
Speaker 3: religion and on the other hand, a gate keeping practice
Speaker 3: than what it was originally designed for, which is a
Speaker 3: set of useful tools deriving from a lot of thinking
Speaker 3: about a set of useful ideas that can make you
Speaker 3: more productive or a better communicator. So saying clean code
Speaker 3: is bad is obviously a hyperbole to some extent, but
Speaker 3: it is analogous to reading The Elements of Style in English,
Speaker 3: which is a fascinating book, very much worth reading for
Speaker 3: anyone who cares about communicating better in English, but it
Speaker 3: is also chock full of anachronisms and opinions that are
Speaker 3: not necessarily born out in the intervening years, and I
Speaker 3: think clean code is kind of like.
Speaker 4: That as well. Before we conclude, I just have to
Speaker 4: give my number one rule. It's almost the only rule really,
Speaker 4: is be consistent. A code base should strive for consistency.
Speaker 3: Yeah, it's somewhat an important rule, and I think it's
Speaker 3: also very overrated because now you run a foul of Okay,
Speaker 3: what is a code base? If a code base contains
Speaker 3: one thousand classes, do they have to be consistent considering
Speaker 3: you might have had forty different people from five teams
Speaker 3: working on them. Not necessarily. It's a trade off. There
Speaker 3: is value to that, but there is also.
Speaker 4: There are trade offs to everything, and there are exceptions
Speaker 4: to then. There obviously are exceptions to every rule. But
Speaker 4: I'm very much in favor of code consistency, and I
Speaker 4: think that these days we have tools in place to
Speaker 4: provide consistency guard rails across larger projects, and if you
Speaker 4: can nage it, it's a huge benefit because otherwise, when
Speaker 4: you read code, you get hung up on things that
Speaker 4: you shouldn't get hung up on, like why is this
Speaker 4: code different than that code? Well, because this was written
Speaker 4: by George and that was written by team, it's not
Speaker 4: a good enough.
Speaker 2: We upgraded the framework. The old way works and this
Speaker 2: is the new way.
Speaker 5: So those are the valid reason, actually because a very
Speaker 5: different reasons, and I think both are valid by the way,
Speaker 5: because again, when you code, whatever it is that you program,
Speaker 5: you are expressing a part of a problem both to
Speaker 5: the machine and another human.
Speaker 3: It is a form of expression by definition, which means
Speaker 3: by definition, two different people are going to express it
Speaker 3: differently times. My point is, consistency is a valuable asset
Speaker 3: to some degree, and it becomes a liability from some
Speaker 3: other threshold. And assuming that consistency is always positive is
Speaker 3: every bit as risky as saying no, who cares about consistency.
Speaker 3: Let's all have you know whatever, different code formatting for
Speaker 3: each code file. Right, that's dumb, But it's no more
Speaker 3: or less dumb than saying no, all files have to
Speaker 3: be identical, have to have consistent whatevers. Because what you're
Speaker 3: doing is you're constraining all of your engineers, all of
Speaker 3: your communicators effectively in the same way where you know
Speaker 3: they're not going to be working in the same way
Speaker 3: on the same thing, even if it's the same person
Speaker 3: coming to the same piece of code. Three six nine
Speaker 3: months later, they might have a different and potentially better
Speaker 3: way of expressing something. And a lot of the times
Speaker 3: the ability to express something elegantly in code actually runs
Speaker 3: a fall of Even something I'm not going to argue against,
Speaker 3: which is automatic code for matting. I'm all for automatic
Speaker 3: code formatting for a very simple reason, because I'm sick
Speaker 3: and tired of arguing, debating, or even talking about it.
Speaker 3: That is the only reason why i want to have,
Speaker 3: you know, a code reformatter as part of my pipeline
Speaker 3: is because they don't want to ever have one of
Speaker 3: those conversations. Again, that being said, I've often been in
Speaker 3: the position where the reformatic code just does not express
Speaker 3: the solution as elegantly as the code I would have
Speaker 3: formatted in some other way, because it trans the file
Speaker 3: of that whatever rule the team put in place. Right, So,
Speaker 3: even trivial rules like line length or how many lines,
Speaker 3: whatever it is that you end up having, you're going
Speaker 3: to have some subset of those in every project. Even
Speaker 3: those sometimes constrain your expressivity as an engineer more than
Speaker 3: and you would like. Now, again we're talking trade offs.
Speaker 3: The trade off of having those arguments about code formatting
Speaker 3: for the better part of thirty forty years of my
Speaker 3: life is exactly why this trade off is worthwhile. I
Speaker 3: will give up a bit of expressivity so I don't
Speaker 3: have to ever have those conversations again. But that is
Speaker 3: why it's not because inherently the consistency is a positive
Speaker 3: or the expressivity is a positive. It's always a trade off.
Speaker 4: I think we need to start wrapping up.
Speaker 3: Yeah, I think so, But we didn't even get to
Speaker 3: dunking on code coverage and dependency injection.
Speaker 4: Right next time, next time.
Speaker 2: Yeah.
Speaker 1: So people want to see what you're working on writing
Speaker 1: speaking about these days, where do they find your stuff?
Speaker 3: Well, I'm running my own consulting company, so that's substrate
Speaker 3: Substrate Software Engineering upstraight, dot co, dot I yell is
Speaker 3: the website. What I'm working on in commercial settings is
Speaker 3: not something I can generally talk about because it's customers stuff,
Speaker 3: not mine. That being said, I have as always there's
Speaker 3: something writing or presentation related down the road. So recently
Speaker 3: I gave a talk about migrating to a WS graviton,
Speaker 3: you know, taking a big production set of production systems
Speaker 3: actually and moving them over to ARM sixty four. So
Speaker 3: that was an AWS hosted event a few months ago.
Speaker 3: What happens next is anyone's guests. But I'm always ranting
Speaker 3: about something or other on Twitter at tomerg And if
Speaker 3: you want to argue with me, engage with me, talk
Speaker 3: to me, or hire me, then you're more than welcome
Speaker 3: to reach out. Just look up my name. It's pretty
Speaker 3: Internet unique.
Speaker 4: I would like to add that Toma has a whole
Speaker 4: bunch of talks which are all styled around the title
Speaker 4: of how shit works, and you know, like how shit
Speaker 4: works as CPU, how shit works, time, how shit works, memory, whatever.
Speaker 4: And you can find all of these talks on YouTube
Speaker 4: and I highly recommend watching them. They're all irreverent and
Speaker 4: all very highly educational and informative.
Speaker 3: Awesome, highly I reverent is my middle name.
Speaker 2: I'm getting there anyway. Let's go ahead and get to
Speaker 2: some pics. Dan, do you want to start us off
Speaker 2: with picks?
Speaker 4: Sure? So our listeners might have noticed that this is
Speaker 4: my return after a bit of atis. I haven't participated
Speaker 4: in like four or five episodes. Part of the reason
Speaker 4: was that I was on vacation. My wife and I
Speaker 4: just the two of us went to Italy together and
Speaker 4: toured all through South Italy. It was awesome. So my
Speaker 4: first picks would be, first of all, taking a vacation,
Speaker 4: second taking a vacation with your spouse, and third taking
Speaker 4: that vacation in Italy. All of these would be my picks.
Speaker 4: I would like to mention two places in particular that
Speaker 4: we visited in our extremely unique and really breathtaking and amazing.
Speaker 4: One of them is this town or city in Italy
Speaker 4: called Matterra's. I don't know if you visited. It's like
Speaker 4: nothing else I've ever seen. It's kind of like this
Speaker 4: place where people lived in caves in the rock and
Speaker 4: effectively built their city over the caves that they built in,
Speaker 4: and the living conditions used to be terrible, which is
Speaker 4: why this whole city was kind of evacuated in the
Speaker 4: beginning of the twentieth century. But then they realized that
Speaker 4: it really can be turned into an amazing tourist destination,
Speaker 4: so they've renovated it and rebuilt it and it's just gorgeous.
Speaker 4: And we stayed there in a hotel that was like itself,
Speaker 4: like kind of half a cave, and it's really amazing.
Speaker 4: It's like nothing I've ever seen, and I highly recommend
Speaker 4: visiting there, and if you do, and you go there,
Speaker 4: stay at the Query Resort. It was an amazing hotel,
Speaker 4: just twelve rooms and it's really amazing. So that would
Speaker 4: be one place that's really worth mentioning in. Another one
Speaker 4: is an even smaller town called almost a village, somewhere
Speaker 4: between a village and a town called Ostuni. It's again,
Speaker 4: it's a really old place that's been lived in for
Speaker 4: a millennia. But the city was built in the Middle Ages.
Speaker 4: It's kind of like inside effectively, it's almost like a fort.
Speaker 4: It's the old city is surrounded by walls. It's on
Speaker 4: the top of a hill with like these winding streets
Speaker 4: and and they're all coupled and staircases and whatnot. And
Speaker 4: it's also called the The Italians call it the White
Speaker 4: Town because the walls are like, you know, painted white,
Speaker 4: and the city really shines in the sun. It's it's
Speaker 4: an amazing sight. I highly recommend staying there. And and yeah,
Speaker 4: so these two places especially, but in general, just take
Speaker 4: a vacation with your spouse and have time and work
Speaker 4: on that relationship and you know, And so that would
Speaker 4: be my first pick. My second pick is I'm having
Speaker 4: an interesting time following along this whole krofuffle or well,
Speaker 4: it's way more than a kerfuffle now, it's a drama,
Speaker 4: I guess in the worldpress community. Between you know, Mett
Speaker 4: mullen went, I always forget how he pronounces his name,
Speaker 4: and WP Engine. I think it's like the first example
Speaker 4: that I can think of of an entire company and
Speaker 4: its user base and its contributions and whatever being ejected,
Speaker 4: forcefully ejected out of a large open source community. It's
Speaker 4: really quite amazing what's going on there. And you know,
Speaker 4: it's it's it's if you like the drama, then follow along.
Speaker 4: And those are my picks for today.
Speaker 2: So I'm going to pile on there.
Speaker 1: Because over the weekend they actually went after Advanced Custom
Speaker 1: Fields as well, which is a play in for WordPress
Speaker 1: that's pretty popular.
Speaker 4: They took it over I think it was.
Speaker 1: Yes, it took it off of their basically their app store,
Speaker 1: I can't reme call it plug in directory, and they
Speaker 1: put their own in.
Speaker 4: And the funny thing is, if I understand correctly, their
Speaker 4: justification for doing it was that it had security issues.
Speaker 4: What they didn't say is that those security issues were
Speaker 4: not being fixed by the original developers because those developers
Speaker 4: were affiliated with WP engine and were ejected off of
Speaker 4: the WordPress community.
Speaker 1: So I didn't follow that. I didn't realize that was
Speaker 1: the case that it had to tie into the other issue.
Speaker 3: So my qualm with this whole set of shenanigans not
Speaker 3: being a WordPress user. I don't have anything to do
Speaker 3: with the community, but just reading about this and assuming
Speaker 3: what I read was even remotely accurate, It's not just
Speaker 3: that the plug in in question was uh, you know,
Speaker 3: taken off because of a security issue or even because
Speaker 3: of something irrelevant like being affiliated with a company. It's
Speaker 3: that it was forked, and the fork was served from
Speaker 3: the whatever software repository that serves the whole community. So
Speaker 3: this isn't just a spat control of it.
Speaker 4: They basically took their project away.
Speaker 3: So it's not just that, which is again not fully
Speaker 3: understanding the details or the companies involved. It's what I'm
Speaker 3: thinking thinking about is from the perspective of a user.
Speaker 3: Imagine you're using mac os or Buntu or whatever system
Speaker 3: you use. There's a product you got off the respective
Speaker 3: app store for that you know it would be especially
Speaker 3: in a commercial setting, which is easier to explain because
Speaker 3: because the outrage is a lot more kind of obvious
Speaker 3: is imagine I'm using a Norton Commander Modern clone for
Speaker 3: mac os called Martha, which I highly recommend, by the way,
Speaker 3: now I'm paying for it happily. Now imagine if I
Speaker 3: bought that off of the Apple Max Store, and then,
Speaker 3: you know, a couple of years later, Apple just decided
Speaker 3: not just to yank it off the app Store with
Speaker 3: some you know, made up claim, but replace it with Marty,
Speaker 3: their own version of Maria that was forked without my knowledge, consent,
Speaker 3: or you know, ignoring the commercial and human shenanigans behind
Speaker 3: the scene.
Speaker 4: That is.
Speaker 3: Effectively a betrayal of trust of whoever is running that
Speaker 3: software repository that I haven't yet seen many people decrying,
Speaker 3: but you know, I would expected them to have them
Speaker 3: being users, not WP engine, actual WordPress users. I would
Speaker 3: have expected to hear a lot of outrage over this,
Speaker 3: because that's, you know, that's taking it one step further
Speaker 3: than the usual open source versus versus commercial drama that
Speaker 3: we're kind of used to seeing at this point. And
Speaker 3: that drama is explainable. You know, the whole rigg is thing,
Speaker 3: the elastic thing, you can you can see where it's
Speaker 3: coming from. This This is the same drama with someone
Speaker 3: abusing their you know, authority in a way that is
Speaker 3: probably legal, I wouldn't know, but is incredibly harmful to
Speaker 3: the community around the product.
Speaker 1: Yeah, I was just going to say, I saw the
Speaker 1: advanced custom fields piece of things kind of unfolding on Saturday.
Speaker 2: I want to say.
Speaker 1: So, it's entirely possible that the community comes around and
Speaker 1: does what you're saying, right because it's Monday morning.
Speaker 2: But I don't know. Maybe they won't, maybe they won't.
Speaker 3: Whether they do or not, we'll tell you a lot
Speaker 3: about open source governance in the coming years.
Speaker 1: I think that's that's where I'm interested. Is Hey, okay,
Speaker 1: so what does this mean for anyone else? And not
Speaker 1: necessarily that I'm in communities where I anticipate this from
Speaker 1: anybody who leads any of those communities, but the fact
Speaker 1: that it can happen.
Speaker 2: You have to at least think about it.
Speaker 4: So did you see the checkbox that they put on
Speaker 4: WordPress dot org.
Speaker 3: Yeah that if you want to log in you have
Speaker 3: to certify that you're not affiliated with WP engine or
Speaker 3: something like that.
Speaker 1: No way, y, Yes, that had happened, And and like
Speaker 1: you said, Tomer, it's it's also not whether or not
Speaker 1: it's legal, this is so toxic to the community.
Speaker 4: They basically ejected wp engine out of the WordPress community
Speaker 4: in a way that I've not seen done in any
Speaker 4: other open source project, like very abruptly and very violently.
Speaker 4: Now it might be justified, like Tomela, I don't have
Speaker 4: sufficient contexts, but the fact that it can be done is.
Speaker 2: I would have.
Speaker 3: I would have been a lot more at ease with
Speaker 3: even even with this whole bizarre kerfuffle between two companies
Speaker 3: that are ostensibly complementary in the market. Again, as an
Speaker 3: outside observer, I don't actually know the details, but I
Speaker 3: would have been a lot more at ease if the
Speaker 3: plugin in question had been removed from the software repository
Speaker 3: because it had whatever. Even if you used that excuse
Speaker 3: of it had unpatched security vulnerabilities, fine, that's, you know,
Speaker 3: at least a valid excuse. But it wasn't yanked. It
Speaker 3: was replaced with a fork, which is not okay under
Speaker 3: any like. This is basically I, you know, I, as
Speaker 3: a user, gave permission to the toolchain around this repository
Speaker 3: to install a certain piece of software, assuming you know
Speaker 3: certain characteristics of the people running the show. Both the
Speaker 3: repository and the people writing the plug in based on
Speaker 3: their reputation. Suddenly not only does that go away, but
Speaker 3: my you know, authorization to the toolchain to do that,
Speaker 3: on my behalf is effectively usurped to support a different
Speaker 3: effort by different people that may or may not have,
Speaker 3: you know, the reputation or characteristics that that I want
Speaker 3: or that I agree to. So that, to me is
Speaker 3: the really new thing about this whole drama, because everything
Speaker 3: else is just the usual. You know, open someone did
Speaker 3: something good open source wise, it succeeded, they built a
Speaker 3: company around it. Someone else built a different company with
Speaker 3: a different business model that you could, you know, discuss
Speaker 3: whether or not they're leveraging off of someone else's work.
Speaker 3: But the point is it's open source. If you didn't
Speaker 3: want someone to leverage off your work on their terms,
Speaker 3: you should have licensed it, not openly, right. That's that's
Speaker 3: on whomever released the software in first place. And again
Speaker 3: that's not discounting moral arguments, right, But this is not
Speaker 3: my issue with what Automatic did is not a moral argument.
Speaker 3: It is something that, not being a lawyer, I could
Speaker 3: never say is but should be in the vicinity of actually,
Speaker 3: you know, bordering on antitrust like this is people that
Speaker 3: have signed a yulaw, that have worked under some assumptions,
Speaker 3: and you yank the carpet and replace it under their feet.
Speaker 3: That should not. Ever.
Speaker 4: The answer, by the way, is that if WP engine
Speaker 4: wants to continue working with quote unquote WordPress, they should
Speaker 4: create their own fork, and.
Speaker 3: They probably will because there's a business there. Otherwise they
Speaker 3: wouldn't be in the situation to begin with.
Speaker 1: Yeah, I will also put out there that whatever the
Speaker 1: beef was, I remember looking at it and I didn't
Speaker 1: understand how because WP engine has been around for years,
Speaker 1: years and years and years and years, right, and so
Speaker 1: I didn't understand that the situation had changed it all
Speaker 1: to prompt this.
Speaker 2: Right, it was just out of.
Speaker 1: The blue from what I could tell. We should just
Speaker 1: do an episode on it and then just talk about how.
Speaker 4: What assuming we have sufficient information. Yeah, it certainly has
Speaker 4: an impact for the web on the web before the
Speaker 4: other reason that the third of websites on the web
Speaker 4: are still WordPress websites, not by traffic, I'm just by
Speaker 4: counting domains.
Speaker 1: Yeah, but there's a lot of people use WordPress on
Speaker 1: the back end of their JavaScript apps.
Speaker 3: Yeah, it's gonna have an interesting to track effect and
Speaker 3: a set of second order effects in the industry. If
Speaker 3: you really want to see something that most everyone ignores
Speaker 3: but that is coming and it is gonna affect the web.
Speaker 3: Is the whole profuffle with the io domain.
Speaker 4: Oh yeah, that's the second one.
Speaker 2: You heard about that, Chuck, No, I haven't. But so
Speaker 2: when we get into it another time.
Speaker 3: Yeah, okay, I.
Speaker 4: Just say this. You know, the io domain, like you know, Google,
Speaker 4: dot io and stuff like that.
Speaker 3: It's going away, Yeah, okay for very simple and good reasons.
Speaker 3: But it's gonna have a heck of a.
Speaker 1: It's gonna affect on things, yeah, for sure, Like businesses
Speaker 1: are built on dot.
Speaker 2: Io domains that yeah.
Speaker 3: Yeah, all right, So well so that's coming. Yeah.
Speaker 2: Fun, I'm gonna jump in with my picks.
Speaker 1: So the game that I've been playing lately with my
Speaker 1: friends is Risk Legacy. I'm pretty sure I've picked this before.
Speaker 1: Board Gang Geek has a weight on it of two
Speaker 1: point five to nine, which means that it's.
Speaker 2: Pretty approachable for casual gamers.
Speaker 1: Is a little more complicated than like Settlers of Catan,
Speaker 1: but you can play it and it's not terribly hard
Speaker 1: to pick up. If you've played risk before it's mostly
Speaker 1: risk with some twists. We'll just put it that way.
Speaker 1: So yeah, so I'm enjoying that. And then real quick,
Speaker 1: just a couple of other picks I have been reading lately.
Speaker 1: What's this book called. It's right here on my desk.
Speaker 1: It's Awaken the Giant Within by Tony Robbins. It is awesome.
Speaker 1: I'm really liking that, and so I'm going to pick that.
Speaker 1: I'm also going to encourage people to go out and vote.
Speaker 1: I recognize that I don't know how you vote, and
Speaker 1: many of you will vote different from how I vote,
Speaker 1: But do your homework, figure out who these people are.
Speaker 2: And to make the best decision you can. And yeah,
Speaker 2: those are my picks. Oh.
Speaker 1: One other thing, and this is kind of a self plug,
Speaker 1: but I am working on putting together a boot camp
Speaker 1: starting in January.
Speaker 2: That will show people how to build AI agents.
Speaker 1: I'm gonna have examples in Ruby and JavaScript, and so
Speaker 1: if you're interested in that, stay tuned because I'm going to.
Speaker 2: Put the sales page up soon. Tomer, what are your picks?
Speaker 3: So, I mean, beyond the whole thing with the IO
Speaker 3: country country code, top level domain going away, which is
Speaker 3: its own thing, one I guess I would say pick
Speaker 3: is retro computing is awesome. On a previous visit to
Speaker 3: Germany a couple of weeks ago, I got a TI
Speaker 3: ninety nine eight bit computer from nineteen seventy eight to.
Speaker 4: The first computer that I owned. By the way, it
Speaker 4: was it had a sixteen bit GPU or something like that.
Speaker 3: Or something like that, but anyway, it's a it's a
Speaker 3: very early computer. It gets added to my collection. This
Speaker 3: collection will be the seed to a full blown interactive
Speaker 3: computer museum in the north of Israel when I retire
Speaker 3: and or the war ends, whichever happens first, which brings
Speaker 3: me to my last pic, which is, don't be in
Speaker 3: a war. It's not good for you as a plug.
Speaker 3: I am. I just finished the first operation of and
Speaker 3: hammering on a Prometheus workshop for developers, so if anyone's
Speaker 3: interested in that, it will probably show up both as
Speaker 3: a commercial offering, but I'll probably be running it in
Speaker 3: some conferences in the foreseeable future. So if there's any
Speaker 3: interest in that, ping me and we'll see what we
Speaker 3: can make happen.
Speaker 4: We should talk about that, Tom, because I've done some
Speaker 4: done quite a bit of Prometheus development relatively recently. And
Speaker 4: even gave a talk or two about it, so you know,
Speaker 4: we had we had an episode where about Prometheus here.
Speaker 3: And everyone that uses Prometheus as an episode sooner or later,
Speaker 3: don't worry about it.
Speaker 2: All right, Well we'll go ahead and wrap it up here.
Speaker 2: Thanks for coming tomorrow.
Speaker 3: Sure, it's been a pleasure, all right, Thanks for thanks
Speaker 3: for opposing some of my opinions. It's always better when
Speaker 3: there's a you know, some back and forth.
Speaker 2: Until next time, folks, max out