Charles and Dan dive deep into the world of programming languages, development practices, and the trade-offs that shape our daily coding lives. Joining them is special guest Tomer Gabel, an experienced backend engineer, and consultant.

In this episode, they unpack the productivity benefits and challenges of using Rails, deliberate on the pros and cons of dynamic languages, and explore the fascinating topic of convergent evolution in programming ecosystems. They also discuss TypeScript's value proposition, the intricacies of static typing, and the sometimes controversial principles of "clean code." Get ready for an engaging conversation packed with expert insights, practical advice, and a few surprising takeaways. Let’s get started!

Charles Max Wood [00:00:05]:
Hey, folks. Welcome back to another episode of JavaScript Jabber. This week on our panel, we have Dan Shapiro.

Dan Shappir [00:00:11]:
Hello from Israel.

Charles Max Wood [00:00:13]:
I'm Charles Max Wood from Top End Devs, and we have a special guest this week, and that is, Tomer Gable. I am sorry. I don't do the Hebrew pronunciation. So

Tomer Gabel [00:00:23]:
That was actually fairly accurate.

Charles Max Wood [00:00:27]:
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 wanna kinda give us a little bit more of your background?

Dan Shappir [00:00:39]:
Sure. Who

Charles Max Wood [00:00:40]:
you are, where where you're coming from with this stuff?

Tomer Gabel [00:00:43]:
Sure. So as you mentioned, Dan and I have been friends for a while. We used to work together at Wix 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 developments. 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.

Tomer Gabel [00:01:20]:
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. Mine doesn't lead towards, well, users really and people. So that's why I'm in back end. You might say I'm a I'm a back end engineer, system architect, DevOps guy, whatever, whatever is needed at the time. I've been in the industry for over 20 years now, and for the last, 3 and change have been, independent, so consulting companies. On basically everything they need, everything except front end.

Tomer Gabel [00:02:07]:
Yeah. And I kinda see myself as as an engineer that solves problems, whether they be educational, functional performance, or anything else really, or organizational at times.

Dan Shappir [00:02:20]:
I'll I'll just add to that, that, you know, Tom 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 and I hope also convincing, but Thomas somehow are very often able to kind of force my hand to kind of change my opinions on stuff. So I I really am looking forward to our discussion today.

Charles Max Wood [00:03:09]:
Yeah. Though those kinds of debates, in my opinion, are important because, yeah, they they force you to really solidify where you're at or change your mind.

Tomer Gabel [00:03:21]:
Or just learn to express your opinions. Right.

Charles Max Wood [00:03:24]:
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 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 kinda gets threaded out during the conversation. So it's I I love it.

Charles Max Wood [00:04:08]:
I love it.

Dan Shappir [00:04:09]:
As as long as it's done in good faith Yes. Yes. That that's really what I care about. And, of course, when it's tech, it it should be, based on 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.

Charles Max Wood [00:04:33]:
Yep. Yep. Cool. May So

Tomer Gabel [00:04:37]:
I may challenge that a little bit. That can be one of the topics for discussion if you want.

Charles Max Wood [00:04:42]:
But I think, honestly,

Tomer Gabel [00:04:44]:
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 are qualitative almost by definition, and trying to inject data into those arguments tends to like, at this point, they view it as as in many cases, more of a logical fallacy than an actual argument.

Charles Max Wood [00:05:13]:
Mhmm.

Tomer Gabel [00:05:13]:
But, we can circle back to that if you

Dan Shappir [00:05:15]:
It's like lies, damn lies, and statistics?

Tomer Gabel [00:05:19]:
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.

Dan Shappir [00:05:28]:
Yeah. That that is fair.

Charles Max Wood [00:05:31]:
So I got this list of things that are, I I guess, ideas. You guys said slaughtering sacred cows, and and mentioned that this is a 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 where are we going with this?

Dan Shappir [00:05:53]:
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 roast to discuss or roast or eat or whatever, then they should know they can feel free to just post them in in the relevant chats.

Charles Max Wood [00:06:17]:
Yeah. Absolutely. Yeah. The more

Tomer Gabel [00:06:20]:
the better. There's always, always something to argue about. I'm sorry. Debate in good faith about.

Dan Shappir [00:06:29]:
Don't do that when I'm drinking.

Tomer Gabel [00:06:31]:
Of course, the fun in not doing that when you're drinking. Yeah.

Charles Max Wood [00:06:36]:
So so where where do you guys wanna start?

Dan Shappir [00:06:39]:
With the first one, I guess. Alright.

Tomer Gabel [00:06:41]:
Alright. So we we kinda put together a list, and sort of prioritized it by 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 for what to talk about, then, that would be terrific. But, Dan, you wanna introduce the the first hypothetical item on

Charles Max Wood [00:07:12]:
this? Yeah.

Dan Shappir [00:07:13]:
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, 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 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 Tomer doesn't think that that's the case. So, Tomer, take it away.

Charles Max Wood [00:08:25]:
Well, I I wanna pile on here because it goes the other way too. Right? It's not just programmers saying, you you 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. This right? And so it it kinda cuts both ways. Anyway, go ahead, Tomer.

Tomer Gabel [00:08:48]:
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 listing, those requirements because, functionally speaking, when you hire an engineer, you may or may not need someone with immediately applicable experience or you might not be able to afford a long onboarding or whatever it is. So it's a it's a much more kind of tactical, decision, I think. There's nothing. I have yet to encounter a company that is about the you know, we only hire for these languages because we think everyone else is is garbage, right, or or whatever way you wanna put it. So it's a much more functional decision. On the other hand, I would say that to to Don'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.

Tomer Gabel [00:09:58]:
I would agree with you. It is the first priority, 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 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 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.

Tomer Gabel [00:10:40]:
You don't go which is the language that best suits my domain. 99% 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 then might just be you, right, if you're on a startup, you're gonna 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.

Tomer Gabel [00:11:34]:
As for why I think it doesn't matter as much as people think, there's there's 2 ways to make that argument. 1 is the sort of highfalutin 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 that respect, they're 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 wanna build an airplane, turns out you can engineer an airplane in French, you know, or in German or in English. And I'm not gonna 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 90% of the domains.

Tomer Gabel [00:12:34]:
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 OCaml, in PHP, in variance of PHP because you have, you know, Wikipedia on the one hand and you have Facebook on the other, and Ruby in virtually anything you'd care to mention. And I'm not even going in the direction of the obvious you know people are still riding in COBOL. I'm talking about mainstream purpose built relevant software that's been developed in the last 20 years, not in the last, you know, 60. 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 or disadvantages of any particular language, it ends up being mostly an aesthetic choice.

Tomer Gabel [00:13:51]:
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, PHP or JavaScript or TypeScript or Java or Kotlin 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 the 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 20 years ago where you go multilingual if you

Charles Max Wood [00:14:44]:
have a lot

Tomer Gabel [00:14:44]:
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 stack 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.

Dan Shappir [00:15:22]:
So I I I'm I I get what you're saying, and all and it's obviously true. Like, like, I remember talking with various companies. There was this 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 of the and I was asking programming languages on frameworks, You know, everybody was obviously JavaScript or TypeScript. But on the back end, there was, like, this huge variety of things. It might be like you said, it might be Java. It might be Go. It might be, dot net.

Dan Shappir [00:15:56]:
It might be PHP and so on and so forth. Now, obviously, all these languages are true and complete. And if they've got, the appropriate libraries that you knee 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, HTTP support and to be able to connect to a database, and everybody's got that. But where I'm kinda pushing back, it's about the fact that, you know, like, you're kind of looking at them as as they're kind of all equal. When you, you you know, different programming languages kind of represent, in 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. If it's, maybe if it's, Rust, then it's a system language that, prioritizes, resource, lifetime over everything, over everything else.

Dan Shappir [00:17:19]:
Resource ownership, I guess. I

Tomer Gabel [00:17:20]:
would say it's safety over everything else.

Dan Shappir [00:17:23]:
Resource safety over everything else. And and, you know, obviously, if you're looking at, and and, like, I don't know, another example might be, like, you know, like, c plus plus might be everything but the kitchen sink, type of a philosophy. And and and and and JavaScript, well, you know, was designed in 10 days. And and so so they do all represent different approaches. It's like, you know, poetry sounds different when you say it in French or in German or in Japanese or in Russian, even though all of them have poetry. So so the question is, don't these, aesthetical or philosophical consideration make a significant difference

Tomer Gabel [00:18:25]:
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 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, language that's appropriate for, whatever. The the type of of web servers that we all build or the type of of front end applications that 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 they while they all have different nuances, and a lot of these nuances are definitely the result of this sort of stark philosophical difference in how they started 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. I have my own opinions.

Tomer Gabel [00:19:48]:
As I say, it's an aesthetic 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 and that whole ecosystem, which started off as statically typed, you see in the mainstream, which was not the case 20 years ago, all these ecosystems have first class typing whether gradual or optional typing kind of shoehorned onto the ecosystem, as what is the case with Python or sort of, building an ecosystem on top of 1 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 expose 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 gonna behave, you know, in an error condition. Right? So that's just one example, and debatably, that's just one reason

Dan Shappir [00:21:01]:
why So talking about that particular reason, and, Chuck, you know him better than I do or we do. DHH has a very contrarian opinion here. Right? You know, every everybody everybody it's it like, from my perspective, looking at the JavaScript ecosystem, you can say that TypeScript has 1. I mean, it's 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 but that's totally the contrary to DHH's opinion of how we should be developing software.

Charles Max Wood [00:22:06]:
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. Mhmm. 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 weeks ago and then, like, last year and when in October. It's been pretty clear that, David is much more DHH.

Charles Max Wood [00:22:52]:
He's much more in favor of, he's moved a lot more toward import maps import maps. 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 to 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 you avoid that.

Dan Shappir [00:23:23]:
But did he also say that he's kind of opposed to static typing on principle?

Charles Max Wood [00:23:30]:
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 and that's definitely the sentiment that comes through. But yeah. And 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 Tomer's mentioned, is kind of more of an aesthetic thing. I've never really felt the benefit of it when I've done it.

Charles Max Wood [00:24:04]:
And so I, you know, I'm 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'm I 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 it's interesting. I'm gonna kinda take it back because I 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, the the different languages are gonna kinda push you toward to get a job done. Yeah. You know, there there's not a major difference as far as them being able to do the job.

Charles Max Wood [00:25:01]:
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 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 I I just watched last week the the key from Rails World. Right? And so he's talking about, hey. We're simplifying the stack and we're simplifying deployment. We're making it easier.

Charles Max Wood [00:25:44]:
And, you know, and so he's talking about all these different things. A lot of these I a lot of my good ideas have come out of Ruby into other languages. A lot of great ideas have come from other part 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 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 I generally mostly agree with you that programming languages, it it you know, there may be differences in, hey.

Charles Max Wood [00:26:37]:
I wanna pick this for this. Right? If I'm doing system programming or something that needs that kind of, characteristic, I'm probably gonna reach for Rust as opposed to Ruby or JavaScript. But, beyond those basic things, I still think that there are meaningful differences between languages and systems that that allow us to to operate and be more productive, you know, reach 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 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, in 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.

Dan Shappir [00:27:44]:
Yeah. But are those advantages are those advantages from Rails or 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 is not so much about Rails. It's more about Ruby versus other programming languages.

Tomer Gabel [00:28:05]:
That's fair. Right? Distinction. That's a distinction. Of them come

Charles Max Wood [00:28:09]:
from Ruby, but I think, yeah, I think some would come from Rails and could be built in other systems.

Tomer Gabel [00:28:13]:
I would argue that that distinction doesn't really exist. When you pick a language, you pick an ecosystem. We are so far, you know, 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 they're not nice. There are exceptions to that rule. So if you're a kernel development developer, you absolutely have to have

Charles Max Wood [00:28:52]:
Yeah. You have to

Tomer Gabel [00:28:53]:
do some degree of control over what the compiler generates and how these, parts integrate and and interact with each other, which is why you would reach for a systems programming language that doesn't have a live run time. Right? That doesn't have garbage collection or whatnot. Mhmm. That being said, for the mainstream, and by the mainstream, I mean, you know, the the let's put it this way. Not the part of the industry that existed 20, 30 years ago when the 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 20 years. So a lot of the software that we end up writing today in the mainstream, there are nuances.

Tomer Gabel [00:29:45]:
Sure. You might prefer some element of of an ecosystem or language or other. But as if if what you're building is not in a domain where there is a tangible ecosystem advantage. So for instance, right now, if you're, you know, if you're training models and and, you know, integrating in all LLMs and whatnot, probably you're gonna reach for Python because it's, you know, it's the go to ecosystem. It's the one that moves the fastest, etcetera, etcetera. That is why you'd reach for Python, not because you think Python is a better language for that sort of work than Java or whatever. Now once the ecosystems reach that kind of parity, 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 on 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 to JavaScript, which again becomes more of an aesthetic choice than anything.

Tomer Gabel [00:30:52]:
Like, you wanna use Elm? Sure. There are trade offs for your organization, not for the system you end up building because it's all gonna be running in a browser the same as any other JavaScript based thing you're gonna build. So Yeah.

Dan Shappir [00:31:07]:
But people writing Elm, for example, will swear by the fact that when they can get when their code compiles, it's correct.

Tomer Gabel [00:31:18]:
So speaking of

Dan Shappir [00:31:19]:
Which is not something you can say about JavaScript or TypeScript.

Tomer Gabel [00:31:24]:
Say 2 things to that. 1, it's hyperbole. Okay? If someone actually came up to my face and 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.

Tomer Gabel [00:31:43]:
Second

Charles Max Wood [00:31:43]:
I think we just got a whole bunch of stinger hamburger out of that one.

Tomer Gabel [00:31:47]:
Yeah. And just to qualify that assertion, okay, I am strictly in the statically typed, statically compiled language camp. As an aesthetic preference, I'm a I'm I'm a scholar guy. Right? And I have been for many years. I'm I'm a cofounder of of what ended up being the community in Israel and and conference that we had 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 drive you towards building code in a way where if it compiles, there is a very good chance that it'll actually run correctly in production. It's not gonna guarantee that, neither will a 100% code coverage in your tests, but we'll probably circle that to that point later.

Tomer Gabel [00:32:40]:
The point I'm trying to make here is

Dan Shappir [00:32:43]:
So before you get to that before you get to that point Yeah. Because you brought up Scala and the fact that you were a founding father of the Scala community.

Tomer Gabel [00:32:52]:
Yeah.

Dan Shappir [00:32:52]:
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, parity.

Tomer Gabel [00:33:09]:
So I I absolutely would because of 2 very fundamental things. 1 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, if I'm growing flowers in 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 heavily into Scala and espousing Scala in the, you know, in the Israeli, tech community, Java couldn't do what Java can do now in the sense of expressivity.

Tomer Gabel [00:33:52]:
Sure. You can 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 to take the plunge, and they decided to do so with the trade off that it's gonna be much harder to hire people to work in Scala, which by the way did not turn out to be the case, 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 picked Java instead or Python instead of they would have been any less successful. Wix, 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 Wix? 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.

Tomer Gabel [00:35:16]:
Wix could have been developed in Java, in Scala, in Python, in any of those languages.

Charles Max Wood [00:35:21]:
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 but, you know, it 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.

Tomer Gabel [00:35:42]:
I would, and this is I would argue against that, or rather, I would say, yes. I would make the same argument with respect to TypeScript and JavaScript because and this is a qualitative argument with no data to 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 Java JavaScript, sorry, just doesn't have that. TypeScript adds that on top of JavaScript in a way that's been tried before to to some degree of success or other with with CoffeeScript and with Flow. But Mhmm. TypeScript made it work substantively better than those other 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.

Tomer Gabel [00:36:51]:
So in that respect, TypeScript is, quote, unquote, better than JavaScript because it's superset 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 an instance It's

Dan Shappir [00:37:14]:
just to say, it's beyond being compiled down to JavaScript. It's effectively you invest a 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.

Tomer Gabel [00:37:27]:
But the the value proposition isn't at runtime. Oh, yeah. Of course. Is a distinction from, the dot net and and Java ecosystems where types do matter at run time. That being said

Charles Max Wood [00:37:41]:
c plus us.

Tomer Gabel [00:37:45]:
That depends on how you write it for sure. The the 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 is is sort of an outside observer. I have no dog in this race. Right? I don't do my everyday work in JavaScript or TypeScript. 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 and tying to this convergent evolution of languages, statement or argument is that this is that evolutionary state. So Python at around 3 8 or 37, I think, started getting, optional typing.

Tomer Gabel [00:38:37]:
Around the same time, TypeScript started taking off. These are the those ecosystems version of a worthwhile feature that they took from statically, type languages.

Dan Shappir [00:38:54]:
Just to make things, you know how would I phrase it? Just to make things, factual, factually correct, TypeScript and JavaScript, you know, there might be some convergent evolution. Obviously, these 2 are tied at at the waist, but, they are distinct programming languages. There's a JavaScript. The the ECMAScript standard says nothing about standard typing. It's highly probable that it never will, you know, whereas

Tomer Gabel [00:39:27]:
And this is highly and this is a prediction that may or may not prove true, and I might eat my words, but it also means that it's a standard that in 5 to 10 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.

Dan Shappir [00:39:54]:
Chuck, I will say this about the value of types. So I'm actually going through a fairly large legacy project at work, that's been that that that's, like, a 100% JavaScript, and we are gradually adding static typing into it. And I I actually tweeted about this that the biggest challenge in adding the static typing is fixing all the bugs that it discovers. So for for example, just, just, like, yesterday, I ran into the a problem there where this legacy system uses MobX. And MobX 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 JavaScript arrays don't have, for example. And people played fast and loose with it.

Dan Shappir [00:40:59]:
They would assign, 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 the system still somehow works because the web platform is very forgiving, for both good and bad.

Dan Shappir [00:41:43]:
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.

Charles Max Wood [00:41:54]:
Yeah. I 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 as some systems get more complex, I I I I don't know if I have the right terminology for exactly what

Tomer Gabel [00:42:33]:
I would say large.

Charles Max Wood [00:42:34]:
Like, it's kind of a vague term. But, you know, as 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 Tomer 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 I'm thinking more along the lines of these just aren't the right solution if we're gonna do it in Ruby. It it just doesn't jive with the way the language goes. I also have to say that the the duck typing and the approach that we take to a lot of things in Ruby, it it really feels just free. I can just do what I need to do. And and so and I'm not saying that's right or wrong.

Charles Max Wood [00:43:17]:
I'm just saying, there there are definitely things that inform the way people work in these languages to where yeah. I I don't think just saying static typing is necessarily the answer. I think you I think there's more nuance 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 kinda 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 what this other language innovated. It's that we found a way to do it in a way that works with the way that people approach and think about problems in that language. So Absolutely.

Charles Max Wood [00:44:03]:
You know, I I guess I'm not really trying to defend anything. More, I'm just trying to say, I I haven't seen the benefit, and it's mostly because what I'm doing just it it hasn't it hasn't had the payoff. But, you know, I mean, all of this could change. You just never know.

Tomer Gabel [00:44:27]:
So I would I would add to that that first of all, I think it's not not just legit or 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 Dan, described in his experiences and 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 or at least not in my lifetime. I could be wrong. You

Dan Shappir [00:45:13]:
see Sometimes even are.

Tomer Gabel [00:45:16]:
Sometimes even are. I what I see is, the value of static typing or or rather static typing is 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 Python or 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

Charles Max Wood [00:45:58]:
is complex. That's probably a better way of stating. I couldn't find the way of saying it, but yeah, that makes

Dan Shappir [00:46:02]:
a lot

Tomer Gabel [00:46:02]:
of sense. It mostly starts manifesting for real in in my experience, two cases. 1 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 typed, 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 or engage with the system at a fairly deep level. The only way you can do that rapidly without significant on 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 is kind of espousing.

Tomer Gabel [00:47:27]:
And fair enough, there is no denying that you can be extremely productive if you're a rails engineer moving from one system built in rails to another. I've seen it. Right? I've seen people do that, and 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 I think we would be seeing more success, in Ruby on Rails as we did in the 2000.

Tomer Gabel [00:48:11]:
So my 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 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 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 gonna argue with them about it. But they kind of express what that did for them in the same way, that it felt very liberating.

Tomer Gabel [00:49:28]:
And I categorically will not deny that or that there's, a productivity boost to be had by that. But you take a Ruby on Rails engineer, you drop them into, you know, no prior knowledge, you drop them into a sufficiently voluminous based in any other language, they will be able to onboard. Because not because there's nothing wrong with Ruby and you're not, you know, you don't not know something coming from Ruby. 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 wanna do in that system. Because it relies so heavily on sort of ingrained knowledge of the philosophy of rails, how things are designed, how things are built.

Tomer Gabel [00:50:29]:
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 5 or 10 or 15 years ago, and in some cases vastly different. Unless you have that knowledge, you're just not gonna be able to get up to speed and and be productive in that system in any way, shape, or form without significant hand holding. And I've been in that position myself, and and it's it's not pleasant. Whereas, you have the same experience, by the way, with the system built in Python or PHP from 10 years ago because then they didn't have some of these quality of life enhancements. You didn't have Right. Known types and known error conditions and and a hell of a lot more Python docs that you could see in your IDE than you know, you you just didn't have those things 10 years ago. Whereas today, coming from any language that's modern and mainstream to any other language that's modern and mainstream is not gonna be smooth sailing because languages are different and there are nuances. But you're gonna be able to figure out where you are in the code.

Tomer Gabel [00:51:49]:
You are gonna 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 and I think that is the primary motivator for those typing systems even in traditionally dynamic languages like Python, JavaScript, whatever. Again, Ruby espouses a different philosophy, a different set of trade offs. I don't deny that they're valid. I don't necessarily subscribe to them. Right.

Tomer Gabel [00:52:31]:
And if I were to find a legit argument against that, I would say simply look at the, you know, look at the the math, look at the popularity. Ruby was extremely popular for just short of a decade. That 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. I Right. It's against my personal biases, but you can build systems. I mean, I've used Basecamp extensively. It's a great product.

Tomer Gabel [00:53:07]:
I don't care what is 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 gonna write the same code in Python as you do in Java or Scala or any of those languages, or in TypeScript 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.

Tomer Gabel [00:53:51]:
And type systems is, I think, just the most visible of those. You also have dependency management, which frankly wasn't a thing 20 years ago. Right? Maven was probably one of the first two major, dependency management stacks.

Charles Max Wood [00:54:09]:
PIP

Tomer Gabel [00:54:09]:
picked up a lot of that, then PIP kinda 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. Rust

Dan Shappir [00:54:29]:
Don't forget NPM.

Tomer Gabel [00:54:30]:
With typescript.

Dan Shappir [00:54:33]:
Don't forget NPM.

Tomer Gabel [00:54:36]:
I'm trying to, but it's not gonna work. But, no, I mean, the I'm being, you know, I'm being intentionally cynical here.

Charles Max Wood [00:54:43]:
I would say really good for installing yards.

Tomer Gabel [00:54:45]:
Slothful influence. I do not have a dog in this race either, but I I can say as a disinterested observer that NPM has had a colossal impact on pretty much every ecosystem out there. Without NPM, we would not have cargo, including the things that cargo does better simply because it learned those lessons.

Dan Shappir [00:55:08]:
Right.

Tomer Gabel [00:55:09]:
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 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 20 years.

Tomer Gabel [00:55:53]:
If only for, you know, dependency management, asset bundling, obfuscation, minification, 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 trade off. 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.

Dan Shappir [00:56:24]:
I I really I I really want to try to get to the 2nd sacred cow, and we seem

Charles Max Wood [00:56:29]:
to be stuck on the first. I was wondering if we were gonna get to any others.

Dan Shappir [00:56:34]:
Well So so unless you've got something really insightful to add, Tom, I would like to move along.

Tomer Gabel [00:56:41]:
I think I think that, that does not have much chance of ever happening.

Charles Max Wood [00:56:48]:
If we do number 2, we're not getting to any any of the other ones.

Dan Shappir [00:56:51]:
We can have tomorrow on again.

Charles Max Wood [00:56:53]:
I'm fine with that. This has been fascinating to talk through.

Dan Shappir [00:56:57]:
Alright. So let's try to at least touch on the second one.

Tomer Gabel [00:57:04]:
Let's.

Dan Shappir [00:57:06]:
Chuck, so you're gonna read the second one or should I

Charles Max Wood [00:57:08]:
I I I will read the second one. So this is what he's going to debunk. This is not Issue. So see anyway, it's clean code is important.

Tomer Gabel [00:57:22]:
Alright. So I'll I'll start by qualifying that. Clean code

Charles Max Wood [00:57:25]:
You better because

Tomer Gabel [00:57:27]:
Clean code

Charles Max Wood [00:57:28]:
is important. Gonna say. I I don't know if I agree with

Tomer Gabel [00:57:30]:
you on this. Gonna be talking about exactly what you think I'm gonna be talking to. I just wanna 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 cannot name drop uncle Bob as the progenitor of these practices.

Charles Max Wood [00:57:58]:
Uncle Bob's a good friend of mine.

Tomer Gabel [00:57:59]:
But cool. So what I'm what I'm gonna

Charles Max Wood [00:58:04]:
say where I disagree with him too, so that's fine.

Tomer Gabel [00:58:07]:
Alright. So so here's here's what I have to say on the subject. My issue with the the with clean code has nothing to do with its intents. And the intent, the way I see it, is to help people design systems that are more readable, that are more sensible. You know, it's all of those best intentions that the way way to hell is

Charles Max Wood [00:58:30]:
Warming chain will is the way I typically approach it.

Tomer Gabel [00:58:33]:
Fair enough. All those So

Dan Shappir [00:58:35]:
did you just notice what Omar said? He said that's the way, you know, the way to hell is paved with good intentions about Yeah.

Tomer Gabel [00:58:41]:
Clean code. 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 adhered to or

Charles Max Wood [00:58:56]:
Okay. The

Tomer Gabel [00:58:57]:
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 demagoguery going on in the industry, around that and 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 20 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 3 times because if it doesn't show up 3 times, then it's not you know, you don't dry it.

Charles Max Wood [01:00:02]:
Beetlejuice. Beetlejuice. Beetlejuice.

Tomer Gabel [01:00:05]:
Yeah. No. No. That's a prescription, and it's a really terrible prescription. First of all, because it it doesn't do anything. 2nd of all, it's because it waste a whole heap of people's time thinking about the wrong thing. And 3rd, because it causes it and other, 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.

Tomer Gabel [01:00:35]:
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 my assumption of the intent behind the words. Right? I don't

Charles Max Wood [01:00:50]:
That that's my understanding as well.

Tomer Gabel [01:00:52]:
Yeah. I don't know uncle Bob. I've you know, I'm not gonna this is 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. The intent isn't. The 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.

Dan Shappir [01:01:37]:
Which is?

Tomer Gabel [01:01:39]:
Simplicity versus complexity. And I can define those things, and we may want to. But, critically, those rules to my mind, right, as in in my own reading of them were they're 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 me in in 6 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 to me is simplicity.

Dan Shappir [01:02:36]:
So here, I'm gonna push back on something. I think what you might be ignoring is the fact that is kind of the thing that comes up came up very early in the in the in the industry in the form of the mythical man mods. It's the fact that not all programmers

Charles Max Wood [01:02:55]:
by the way.

Dan Shappir [01:02:55]:
Yeah. The fact that not all programmers are

Tomer Gabel [01:02:57]:
Another sacred cow to

Dan Shappir [01:03:00]:
Yeah. Be a lot smarter. Yeah. The the fact that half the programmers in the world are worse than the average programmer.

Charles Max Wood [01:03:10]:
And Definitely, I guess, it's mean.

Dan Shappir [01:03:14]:
It's mean, but it's true. It's mean, but it's true by definite the yeah. Well, okay. Whatever. Yeah. I think in this particular case, the average and the mean are probably fairly close.

Tomer Gabel [01:03:27]:
Yep. We're we're talking humans for a change, the normal distribution of value.

Dan Shappir [01:03:32]:
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 knee you you don't need to adhere as much to these kind of strict rules and guidelines. When you're on teams or or or that don't have such a person, then maybe having overly strict rules is a good thing. Don't you think?

Tomer Gabel [01:04:16]:
Well, speaking as a statically typed guy, I can't very well rail against that argument. But taking it taking it a little bit more head on, there's 2 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 good, which is not an argument that I buy even though, you know, I I might subscribe to that opinion. The second issue I have with it is engineers that don't have an that haven't over the course of 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 base 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.

Tomer Gabel [01:05:43]:
Now that being said, that is that sounds like gatekeeping probably because it it is because I can't help it. But the to to bring that home and 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 gonna 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, etcetera. 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, drive violation mistake, you're gonna get fired. You're hopefully going to because you're a junior developer, you were hired in a context where you can be, you know, functional and you have support.

Tomer Gabel [01:07:06]:
You're probably gonna have the person next to 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 3 places. So that's a drive 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 for code whereby you wouldn't necessarily you would learn very early on why that's a mistake and you would stop making it because it's communication. Right? There is nothing inherently wrong with with having several copies of the same code in the same place. It's a trade off. Right? What is the trade off? If you can't have that conversation, you're never gonna become a better developer.

Tomer Gabel [01:08:22]:
The guardrails aren't gonna help you get there. They're just gonna stop everyone else from doing their job.

Dan Shappir [01:08:28]:
So Uh-uh. I I I I think this is a a a great topic and and one I think we should probably have you on to discuss at length about what is actually simplicity in coding. We probably don't have time to do it justice. I'll just I'll just I'll just add the fact that I, you know, I never liked, Douglas Crockford's linter. What's it called? Jslint, the original, linter. Because it basically say you know, Douglas Crockford 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 and there's a reason ES Lind won.

Dan Shappir [01:09:21]:
And because, you know, it's it's when you're so dogmatic, it's it's a problem.

Tomer Gabel [01:09:29]:
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 or academician, a 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 damn? That's, you know, that's completely trivial. I don't care. I don't wanna have to mess 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 in that list, by the way, later iterations of Java. Modern Java isn't anywhere near as verbose or, pardon my French, anal retentive as traditional Java used to be.

Tomer Gabel [01:10:30]:
And that is because other languages showed that that kind of it's not just verbosity. Everyone, you know, rails against Java being verbose, 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 types 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 kinda 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 in c or c plus plus anymore.

Tomer Gabel [01:11:57]:
It's because you don't get anything in return to that level of precision and control. You only get the bugs, right, for those domains. Mhmm. 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 the rules are well intentioned, but they provide the wrong kind of guidance, and end up causing more damage than harm in my opinion.

Charles Max Wood [01:12:50]:
So so I'm gonna jump in on some of this. So, like I said, I've I've talked to uncle Bob quite a bit. I've actually talked to him about the Clean Code book. We also I I 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 is we talked through the book.

Charles Max Wood [01:13:15]:
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'd 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 gotta apply this as 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.

Charles Max Wood [01:13:55]:
I can't Clean Agile, I think I also read. And the the main thing is is, I find that the rules or ideas behind the rules are definitely worth discussing with your team, right, and 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 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.

Charles Max Wood [01:14:36]:
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, were were 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 down 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

Tomer Gabel [01:15:13]:
were tools that would do code analysis, and they would point out

Charles Max Wood [01:15:13]:
areas of your code that weren't dry. 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 gonna do this this way instead of that way, and it's just, you know, you're better off having 2 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 gonna 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 an overblown

Tomer Gabel [01:16:08]:
making the case for cowboy coding?

Charles Max Wood [01:16:11]:
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 of clean code. But my 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.

Tomer Gabel [01:16:29]:
Yeah.

Charles Max Wood [01:16:31]:
And and the reality is is you've gotta 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 code base you're working in, it's just not gonna work. One other case I wanna make is, several years ago, Sandy Metz, she 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 so many more than so many lines

Dan Shappir [01:17:10]:
in the past tense. Much when my method ends up being one line too long.

Charles Max Wood [01:17:16]:
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 the build if or fail, you know, fail CI if if it was right? So you had an 8 8 line method, and you're looking at it and you're going, well, the only way to get it that way is essentially to create a second method and just put 2 of the lines in it, which doesn't help. And so

Tomer Gabel [01:17:46]:
I will I will add to that. There's there's 2 things here. Right? There's first of all, circling back to the really the beginning of the conversation. A programming language is a language is above communication. Like, fundamentally, you know, I think I've I've read some guy, at some point, probably 20, 30 years ago, putting it as a a prose that's readable by humans and it executable by machine. Right? Which I think is a very high for the way of putting it, but but it's close enough to 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 when the code doesn't compile, obviously, in the one hand.

Tomer Gabel [01:18:40]:
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 do the work you do, you do it for other humans, and one of those humans might be you in 6 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 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 a subscription, more

Charles Max Wood [01:19:35]:
Right.

Tomer Gabel [01:19:36]:
It became its own thing. I'm railing not against the intent or against uncle Bob personally. Again, I don't know him, but I've got nothing to add to that. But I I am railing against the way it became embedded in the industry because much like a topic we're not gonna have time to discuss here again, which is TDD, it became more of a on the one hand, a religion and on the other hand, a a gatekeeping practice than in 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, 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 it is also chock full of anachronisms and opinions that are not necessarily borne out in the intervening years. And I think clean code is kinda like that as well.

Dan Shappir [01:20:57]:
And 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.

Tomer Gabel [01:21:09]:
Yeah. It's somewhat an important rule, and I think it's also very over overrated. Because now you're on a foul of okay. What is a code base? If a code base contains a 1,000 classes, do they have to be consistent? Considering you might have had 40 different people from 5 teams working on them? Not necessarily. There there it's a trade off. There is value to that, but there is also cost

Dan Shappir [01:21:36]:
There are 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 guardrails across larger pro projects. And and as and if you can manage 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 Tim is not a good enough We

Charles Max Wood [01:22:18]:
upgraded the framework the old way works, and this is the new way.

Dan Shappir [01:22:22]:
So that's that's a valid reason, actually.

Tomer Gabel [01:22:24]:
Because you different reasons, and I think both are valid, by the way. Because, again, when you when you code, whatever it is that you program, you are expressing a part of the problem both to the machine and another human. It is a form of expression by definition, which means by definition, 2 different people are gonna express it differently. Oh, yeah. My point is consistency is a valuable asset to some degree, and it becomes a liability from some other threshold. And it and assuming that consistency is always a 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.

Tomer Gabel [01:23:15]:
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 gonna be working in the same way on the same thing. Even if it's the same person coming to the same piece of code 3, 6, 9 months later, they might have a different and and potentially better way of expressing something. And a lot of the times, the ability to express something elegantly in code actually runs a foul of even something I'm not gonna argue against, which is automatic code formatting. 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

Charles Max Wood [01:24:13]:
it.

Tomer Gabel [01:24:13]:
That is the only reason why I wanna have, you know, a a a code reformatter as part of my pipeline is because I don't wanna ever have one of those conversations again. That being said, I've often been in the position where the reformatted code just does not express the solution as elegantly as the code I would have formatted in some other way because it runs afoul of that whatever rule the team put in place. Right? So even trivial rules like line length or how many lines per minute, whatever it is that you end up having, you're gonna have some subset of those in every project. Even those sometimes constrain your expressivity as an engineer more than 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 30, 40 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.

Tomer Gabel [01:25:19]:
It's not because inherently the consistency is a positive or the expressivity is a positive. It's always a trade off.

Dan Shappir [01:25:30]:
I think we need to, start wrapping up.

Charles Max Wood [01:25:36]:
Yeah. I think so. But

Tomer Gabel [01:25:37]:
We didn't even get to to dunking on code coverage and and dependency injection. Uh-huh.

Dan Shappir [01:25:43]:
Right? Next time. Next time.

Charles Max Wood [01:25:46]:
Yeah. So, Tomer, people wanna see what you're working on writing, speaking about these days, where do they find your stuff?

Tomer Gabel [01:25:54]:
Well, I'm running my own consulting company. So that's substrate, substrate software engineering, substrate.c0.io, 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 AWS Graviton, you know, taking a big production set of production systems, actually, and, moving them over to arm 64. So that was an an AWS, hosted event a few months ago. What happens next is anyone's guess, but I'm always ranting about something or other on Twitter, at Tomer g. 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.

Tomer Gabel [01:27:00]:
Just look up my name. It's pretty, Internet unique.

Dan Shappir [01:27:04]:
I would like to add that Tomer has a whole bunch of talks which are all styled around the title of how shit works and, you know, like, how shit works the 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.

Charles Max Wood [01:27:32]:
Awesome.

Tomer Gabel [01:27:33]:
Highly reverent is my middle name.

Charles Max Wood [01:27:39]:
Oh, I'm getting there. Anyway, let's go ahead and get to some picks. Dan, do you wanna start us off with picks?

Dan Shappir [01:27:45]:
Sure. So, what our listeners might have noticed that this is my return after a bit of hiatus. I I haven't participated in, like, 4 or 5 episodes. Part of the reason was that I was on vacation. My wife and I, just the 2 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. 2nd, taking a vacation with your spouse, and, 3rd, taking that vacation in Italy.

Dan Shappir [01:28:21]:
All of these would be my picks. I would like to mention 2 places in particular that we visited and are, like, extremely unique and really breathtaking and amazing. One of them is, this town or city in Italy called Matera. It'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, like, lived in caves in in the rock and effectively built their city over the caves that they built in. And it the the living conditions used to be terrible, which is why this whole city was kind of evacuated, in the beginning of 20th century. But then they realized that it's really can be turned into an amazing tourist destination.

Dan Shappir [01:29:12]:
So they renovated it and rebuilt it, and it's just gorgeous. And we stayed there in a hotel that was by itself, like, kind of half a cave, and it it 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 Quarry Re Resort. It was an amazing hotel, just 12 rooms, and it's really amazing. So that would be, one place that's really worth mentioning. And another one is an even smaller town called, almost a village, somewhere between a village and a town called Ostuni. It's, it's, again, it's it's a really old place that's been lived in for millennia, but the current city was built in the middle ages.

Dan Shappir [01:30:02]:
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 cobbled with and staircases and whatnot. And it's also called, the, the the Italians call it, the, white, town because, the, walls are, like, you know, painted white, and the it it the city really shines in the sun. It's it's an amazing sight. I I highly recommend staying there. And and, yeah.

Dan Shappir [01:30:46]:
So these two places, especially but in general, just take a vacation with your spouse and have a good 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 kerfuffle or well, it's way more than a kerfuffle now. It's a drama, I guess, in the WordPress community between, you know, Matt Mullenweg. Well, I I I always forget how he pronounces his name, and, WP Engine. It's 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.

Charles Max Wood [01:31:54]:
So I'm gonna pile on there because over the weekend, they actually went after advanced custom fields as well, which is a plug in for WordPress that's pretty popular.

Dan Shappir [01:32:03]:
They took it over, I think. It was

Charles Max Wood [01:32:05]:
Yes.

Dan Shappir [01:32:05]:
It was They

Charles Max Wood [01:32:06]:
took it off of their, basically, their app store. I can't remember what it's called. Plug in directory, and they put their own in.

Dan Shappir [01:32:13]:
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.

Charles Max Wood [01:32:35]:
So I didn't follow that. I didn't realize that was the case that it had to tie into the other issue.

Tomer Gabel [01:32:41]:
So my my qualm with this whole set of shenanigans is not being a WordPress user. I don't have anything, to do with the community, but, just reading about this and and assuming what I read was even remotely accurate. It's not just that the plug in in question was, 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 spam credential. Of

Dan Shappir [01:33:27]:
it. They they they they they basically took their project away.

Tomer Gabel [01:33:31]:
So it's not just that, which is, again, not fully understanding the details or the companies involved. It's what I'm think thinking about is from the perspective of a user. Imagine you're using Mac OS or Ubuntu 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, Norton Commander modern clone for Mac OS called Martha which I highly recommend by the way. Now I'm I'm paying for it happily. Now imagine if I bought that off of the Apple Mac Store and, then, you know, a couple 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 Mara that was forked without my knowledge, consent, or, you know, ignoring the commercial and and human shenanigans behind the scene. That is effectively a betrayal of trust of whomever is running that software repository that I haven't yet seen many people decrying, but, you know, I I would have expected them to to have them being users, not WP Engine, actual WordPress users.

Tomer Gabel [01:35:06]:
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 kinda used to seeing at this point. And that drama is explainable. You know, the whole real 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.

Charles Max Wood [01:35:45]:
Yeah. I was just gonna say, I saw the advanced custom fields piece of things kinda unfolding on Saturday, I wanna say. So it's entirely possible that the community comes around and and does what you're saying. Right? Because it's Monday morning, but I don't know. Maybe they won't.

Tomer Gabel [01:36:03]:
Maybe they Whether they do or not will tell you a lot about open source governance in in the coming years, I think.

Charles Max Wood [01:36:11]:
That's that's where I'm interested is. Hey. Okay. So what does this mean for anyone else? And, not 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 you have to at least think about it. So

Dan Shappir [01:36:34]:
Did you see the checkbox that they put on wordpress.org?

Tomer Gabel [01:36:38]:
Yeah. That, if you wanna log in, you have to certify that you're not affiliated with WP Engine or something like that.

Charles Max Wood [01:36:45]:
No way.

Dan Shappir [01:36:46]:
Yeah. Yes.

Tomer Gabel [01:36:47]:
That it happened.

Charles Max Wood [01:36:48]:
And 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.

Dan Shappir [01:36:54]:
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, Tomer, I don't have sufficient context, but the fact that it can be done is

Tomer Gabel [01:37:19]:
I would've I would've been a lot more at ease with even even with this whole bizarre kerfuffle between 2 companies that are ostensibly complementary in the markets. Again, as an outside observer, I don't actually know the details. But I would have been a lot more at ease if the the plug in in question had been removed from the software repository, because it had whatever. Even if you use 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 tool chain 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.

Tomer Gabel [01:38:20]:
Suddenly, not only does that go away, but my, you know, authorization to the tool chain 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 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, opens a 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, whomever released the software in the first place.

Tomer Gabel [01:39:23]:
And, again, that's not discounting moral arguments.

Charles Max Wood [01:39:27]:
Right.

Tomer Gabel [01:39:27]:
But 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 the EU law that have worked under some assumptions, and you yank the carpet and replace it under their feet. That should not ever

Dan Shappir [01:40:00]:
The answer, by the way, is that if WP Engine wants to continue working with, quote, unquote, WordPress, they should, create their own fork.

Tomer Gabel [01:40:12]:
And they probably will because there's a business there. Otherwise, they wouldn't be in the situation to begin with.

Charles Max Wood [01:40:18]:
Yeah. I I will also put out there that what whatever the beef was, I remember looking at it, and I didn't understand how because WP Engine has been around for years years years years years years. Right? Mhmm. And so I didn't understand that the situation had changed at all to prompt this. Right? It was just out of the blue from what I could tell. We we should just do an episode on it and then just talk about

Dan Shappir [01:40:44]:
how what Yeah. Assuming we have sufficient information. It it it certainly has an impact for the on the web before no other reason that a third of websites on the web are still WordPress websites. Not by traffic, I'm just by counting domains.

Tomer Gabel [01:41:01]:
Yeah. But the other thing is

Charles Max Wood [01:41:02]:
is a lot of people use WordPress on the back end of their JavaScript apps.

Tomer Gabel [01:41:08]:
Yeah. This it's gonna have an interesting to track effect

Charles Max Wood [01:41:12]:
Yeah.

Tomer Gabel [01:41:12]:
And and a set of second order effects in the industry. If you really wanna see something that most everyone ignores but that is coming and is gonna affect the web is the whole kerfuffle with the IO domain.

Dan Shappir [01:41:23]:
Oh, yeah. That's a funny one. You heard about that,

Charles Max Wood [01:41:27]:
Chuck? No. I haven't. But Alright. So We will get out into it another time.

Tomer Gabel [01:41:33]:
Yeah. Okay. If we're out of the

Dan Shappir [01:41:35]:
I just say this, you know the IO domain, like, you know, google.io and stuff like that? It's going away.

Tomer Gabel [01:41:42]:
Yeah.

Charles Max Wood [01:41:43]:
Okay. For for

Tomer Gabel [01:41:45]:
very simple and good reasons, but it's gonna have a heck of a

Charles Max Wood [01:41:49]:
Yeah. It's gonna affect some things. Yeah. For sure. Yeah. Like I know businesses are built on dot I o domains that yeah.

Tomer Gabel [01:41:57]:
Yeah. Alright. So Well so that's coming.

Charles Max Wood [01:42:00]:
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 picked this before. BoardGameGeek has a weight on it of 2.59, which means that it's pretty approachable for casual gamers. It's 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 played risk before, it's mostly risk with some twists.

Charles Max Wood [01:42:33]:
We'll just put it that way. So yeah. So I'm 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, and it is awesome. I'm really liking that, and so I'm gonna pick that. I'm also gonna encourage people to go out and vote.

Charles Max Wood [01:43:00]:
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 then make the best decision you can. And, yeah, those are my picks. Oh, one other thing, and 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 gonna put the sales page up soon. Tomer, what are your picks?

Tomer Gabel [01:43:38]:
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 retro computing is awesome. On a previous visit to Germany a couple weeks ago, I got a TI 99 4 a 8 bit computer from 1978 to add to

Dan Shappir [01:44:04]:
my connection. The first computer that I owned. By the way, was it had a 16 bit GPU or something like that.

Tomer Gabel [01:44:14]:
Or something like that. But, anyway, it's a it's a very early computer. It's 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 pick, which is don't be in a war. It's not good for you. As a plug, I am I just finished the first iteration of and am, hammering on a Prometheus workshop for developers. So if anyone's interested in that, it will probably show up both as a as a commercial offering, but I'll probably be running it in in some conferences in the foreseeable future.

Tomer Gabel [01:45:08]:
So if there's any interest in that, ping me, and we'll see what we can make happen.

Dan Shappir [01:45:13]:
We should talk about that, Tomel, because I've done some, I've done quite a bit of Prometheus development relatively recently and even gave a talk or 2 about it. So

Charles Max Wood [01:45:23]:
Mhmm. Okay. Sorry to leave you up. Do you

Dan Shappir [01:45:26]:
know where I'm at? We had we had an episode where Yes. About Prometheus here

Tomer Gabel [01:45:30]:
on JavaScript. That uses Prometheus has an episode sooner or later. Don't worry about it.

Charles Max Wood [01:45:39]:
Alright. Well, we'll go ahead and wrap it up here. Thanks for coming, Tomer.

Tomer Gabel [01:45:43]:
Sure. It's been a pleasure.

Charles Max Wood [01:45:45]:
Alright.

Tomer Gabel [01:45:46]:
Thanks for thanks for, opposing some of my opinions. It's always better when there's, you know, some back and forth.

Charles Max Wood [01:45:53]:
And until next time, folks. Max out.