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