0:00

Hey JavaScript Jabber fans, I wanted to

0:02

really quickly talk about the sponsor of

0:04

today's episode, me. I'm Jamin Holmgren, co-founder

0:06

and CTO of Infinite Red. We're a

0:08

small but experienced team of 30 US-based

0:10

React Native consultants. We've been around since

0:12

2015 and all we do is React

0:16

Native consulting. So if you're looking for expert

0:18

help building or optimizing deploying and supporting a

0:20

React Native app, I'd love to chat with

0:23

you. Just go to infinite.red slash jsjabber and

0:25

don't forget to mention that you heard about

0:27

us through the JavaScript Jabber podcast. So that

0:29

we can keep supporting the show. Now back

0:31

to the episode. All right,

0:34

let's be real. You get in, you're

0:36

trying to start up your new JavaScript application,

0:38

you want to do the front end stuff,

0:40

maybe you don't want to do a whole

0:43

lot of the design, maybe you want something

0:45

that already does, I don't know, e-commerce or

0:47

content or something else where you want to

0:49

build your own business. But at the end

0:51

of the day, you want to be controlling

0:53

the user experience and doing what you do

0:56

best in React or Vue or Angular or

0:58

something else. So what do you

1:00

do? Well, guess what? One of the

1:02

best understood back ends is WordPress.

1:05

And so all you have to do is spin

1:07

up WordPress, install the plugins that give you the

1:09

features you want. And if you really want to

1:11

get fancy, you can use Bluehost. They have an

1:13

AI powered design tool that'll give you a pro

1:15

level WordPress sites. Then all you have to do

1:17

is set up your front

1:19

end and off you go. You can

1:21

use plugins for the APIs, you can

1:24

use the back end for authentication. It's

1:26

already a CMS or content management

1:28

system. The AI makes it really easy to

1:30

get where you want to go. It loads

1:33

fast, it's well understood, it's got

1:35

a ton of people using it

1:37

already. And so why not? I

1:40

can't recommend highly enough that you give WordPress

1:42

a try if you're looking to build something

1:44

and need some kind of back end headless

1:46

CMS. And the place to host

1:48

that is Bluehost. So you go over to

1:50

Bluehost, you fire up their AI, like I

1:53

said, and off you go. So if you're

1:55

looking for a place where you can set

1:57

up WordPress in minutes and use their built

1:59

in marketing tools, you get 24 hours of

2:01

WordPress. for 7 support then go check them

2:03

out. If you use our code, you can

2:06

launch yours today and get a killer deal.

2:08

Go to bluehost.com/jabber. That's

2:10

bluehost.com/ jabber. Hey

2:17

folks, welcome back to another episode of

2:19

JavaScript Jabber. This week on our panel

2:21

we have Dan Shapiro. Hello

2:24

from Israel. I'm

2:26

Charles Max Wood from Top End Devs and we have a

2:28

special guest this week and that is Tomer

2:31

Gabel. I am sorry, I don't do

2:34

the Hebrew pronunciation so. That

2:36

was actually fairly accurate. Awesome.

2:41

Now you and Dan are friends. You

2:43

do JavaScript mostly not on the front

2:46

end which is kind of interesting but

2:49

yeah, do you wanna kind of give us a little bit more of your background?

2:52

Sure. Who you are, where you're coming from with this stuff?

2:55

Sure. So as you

2:57

mentioned Dan and I have been friends for a

2:59

while. We used to work

3:02

together at Wix for a few years

3:04

and then we kind of split ways

3:06

professionally but remain friends. As

3:09

you might've mentioned, I am not

3:12

very heavily into front end development.

3:15

I will reiterate the usual disclosure which

3:17

is I have nothing

3:19

against it. I'm just not very good at

3:21

it and therefore leave it to people who

3:24

are good at it and are passionate about it.

3:28

On the other hand, I do see

3:30

myself as kind of a general purpose

3:32

engineer. So I don't really see the

3:34

distinction between front end, back end. In

3:38

the general sense, engineering is engineering

3:40

is engineering. Some of these disciplines

3:43

require skill sets that slightly

3:45

differ. Mine

3:48

doesn't lead towards, well,

3:51

users really and people. So

3:54

that's why I'm in back end. You

3:57

might say I'm a back

3:59

end engineer, system market. a DevOps

4:02

guy, whatever is needed at the time,

4:05

have been in the industry for over 20 years

4:08

now. And for the last

4:10

three and change have been independent.

4:13

So consulting companies and

4:15

basically everything they need, everything except front-end.

4:19

Yeah, and I kind of see myself as an engineer

4:22

that solves problems, whether they

4:24

be educational, functional

4:27

performance or anything else really,

4:29

or organizational at times. I'll

4:33

just add to that, that,

4:36

you know, Tomer and I, we

4:38

meet, we hang out when we can. And

4:41

when we do, we almost

4:44

inevitably also get into technical

4:47

debates. Like we

4:49

both hold strong opinions and

4:51

interestingly enough, they sometimes conflict. And

4:55

that's the best. And that's the

4:57

best. And

5:01

I'm usually pretty, let's

5:05

stubborn and I hope also

5:07

convincing, but Tomer is somehow

5:09

very often able to kind

5:11

of force my hand to

5:14

kind of change my opinions on stuff. So

5:17

I really am looking forward to

5:19

our discussion today. Yeah,

5:22

those kinds of debates in my opinion

5:24

are important because yeah, they

5:27

force you to really solidify where you're at or

5:30

change your mind. Or

5:34

just learn to express your opinions. Right.

5:37

Yeah, I was gonna say, so we're

5:40

in the middle of the political season here in the United

5:42

States. I'm fairly involved

5:45

in one of the major political parties. I'm

5:47

the vice chair of the local, the county

5:49

party. And right, so

5:51

we have discussions and often we have discussions

5:53

with people that don't agree with us, both

5:55

within the party and outside the party. And

5:58

yeah, it's terrific. because you get

6:00

to have the back

6:02

and forth. And yeah, sometimes it's, you know, you make a

6:04

really good argument and I have to go think about that.

6:07

And sometimes it's, you've made excellent

6:09

arguments and you've convinced me. And

6:12

sometimes it's, you know, we

6:14

agree, but some of the nuance

6:16

kind of gets threaded out

6:19

during the conversation. So it's, I love it.

6:21

I love it. As long as it's done

6:23

in good faith. Yes. That's

6:26

really what I care about. And of course,

6:28

when it's tech, it

6:30

should be based on actual,

6:32

you know, information

6:35

or data as much as possible,

6:38

rather than just, you know, this

6:40

is my opinion and I'll die

6:42

on this hill because it is.

6:45

Yep. Yep. Cool.

6:49

So, I may challenge that

6:51

a little bit. That can be one of the

6:53

topics for discussion if you want. Honestly,

6:56

I think it's not so much that

6:58

data is overrated because it's not. It's

7:00

that many

7:03

fewer discussions, especially around

7:07

issues of how to engineer, what good

7:09

engineering is. A lot of

7:11

these discussions are qualitative,

7:13

almost by definition, and

7:16

trying to inject data into those arguments tends

7:18

to, like at this point, they view it

7:20

as, in many cases,

7:22

more of a logical fallacy than an actual

7:25

argument. But we can circle

7:27

back to that if you... It's like lies,

7:29

damn lies, and statistics. It's

7:32

more like if you're measuring

7:34

what's easy because that's all you can measure,

7:36

then don't expect me to take it very

7:38

seriously. Yeah,

7:41

that is fair. So,

7:43

I got this list

7:45

of things that are, I guess, ideas.

7:49

You guys said slaughtering sacred cows, and

7:53

mentioned that this is a Hebrew term, but

7:55

it's a term that's used in English in

7:57

America too. So, I'm just gonna hang... with

8:00

it here. But

8:02

yeah, so what sacred cows are we slaughtering? Where

8:04

are we going with this? By the way, if

8:06

we just before we start, you know, if you've

8:09

got, you know, some listeners, and

8:12

they have ideas for additional,

8:15

you know, sacred cows, they

8:17

might like us to roast

8:20

to discuss or roast or eat

8:22

or whatever, then they should know

8:24

they can feel free to just

8:26

post them in the very relevant

8:28

chats. Yeah, absolutely.

8:31

Yeah, the more the better. There's

8:33

always always something to argue about.

8:35

I'm sorry, debate in good faith

8:37

about. Don't

8:41

do that when I'm drinking. Of course,

8:44

the fun in not doing that when you're drinking. Yeah.

8:49

So, so where do you guys want to start?

8:51

With the first one, I guess. All right.

8:53

All right. So we kind of put together

8:55

a list and sort of

8:58

prioritized it by nothing

9:01

so well defined as our hunch

9:03

at what would be engaging for

9:05

the audience, which

9:07

is to say that if the audience

9:09

actually wants to participate and indicate to

9:12

us whether we're on the right track

9:14

or they have some other ideas for

9:16

for what to talk about, then that

9:19

would be terrific. But

9:21

then you want to introduce the first

9:24

hypothetical item on the agenda. Yeah. So

9:27

everybody, you know, we all

9:29

of us here are programmers and

9:31

probably the number one tool

9:34

for programming is the

9:36

programming language, because at the end of

9:38

the day, that's how you convey your

9:41

intentions to the computer that actually

9:43

hopefully executes something similar to what

9:45

you wanted it to do. And

9:50

and consequently, people or developers

9:52

are really hung up

9:54

on their choice of a programming language

9:57

to the extent that I still remember. when

10:00

I interviewed somebody for a position way

10:02

back in the 90s, I think, they

10:05

told me, if you're not working

10:07

in Java, I'm not interested in working

10:09

here. And

10:12

so it seems that the choice

10:14

of programming language should

10:19

be like the number one

10:21

priority. It's like the number

10:23

one most important tool in your toolbox.

10:26

So it's the number one priority of

10:28

making the right choice. And

10:31

yet it seems that Tomer

10:33

doesn't think that that's the case. So

10:36

Tomer, take it away. Well, I wanna pile

10:38

on here because it goes the other

10:40

way too. It's not just programmers saying, I

10:44

want to work in .NET or Java

10:46

or Ruby or JavaScript or whatever node, but

10:49

the employers list the jobs that way. This

10:52

is a React job, this is a PHP job. Right?

10:56

And so it kind of cuts both ways.

10:58

Anyway, go ahead, Tomer. So

11:01

there's a few angles with

11:04

which we could sort of tackle this,

11:07

but I'll start by saying

11:09

this. I don't

11:11

actually think there's any

11:14

argument to be made

11:16

about companies listing those

11:19

requirements because functionally speaking, when you hire

11:21

an engineer, you may or

11:23

may not need someone with

11:25

immediately applicable experience or you might

11:27

not be able to afford a

11:29

long onboarding or whatever it is.

11:31

So it's a much more kind

11:33

of tactical decision, I

11:36

think. There's nothing, I've

11:38

yet to encounter a company

11:40

that is, we

11:44

only hire for these languages because

11:46

we think everyone else

11:48

is garbage, right? Or whatever way you

11:50

wanna put it. So

11:52

it's a much more functional decision.

11:55

On the other hand, I would say that

11:57

to Dun's earlier point, which is, You

12:00

know, it should be priority one of

12:02

the decisions you make, presumably in this

12:04

context it's on a new project or

12:06

a new company, a new organization, whatever

12:08

it is. I

12:10

would agree with you, it is the

12:13

first priority, but I would disagree on

12:15

why that is. I don't think it's

12:17

because the choice matters

12:19

as much as people think. I

12:22

think it's because it is

12:24

the first choice

12:26

you have to make before you

12:28

actually start doing anything beyond brainstorming

12:30

on what it is you're building.

12:59

Ramp automates data entry and routine

13:01

tasks with automated approvals, expense categorization

13:03

and bill payments, time-consuming tasks. Which

13:05

means you'll stop wasteful spending and

13:07

close your books in hours instead

13:09

of days. Businesses that use Ramp

13:11

add up to 5% to

13:14

their bottom line the first year. If you're a

13:16

decision maker, adding Ramp could be one of the best

13:18

decisions you've ever made. Get $250 when you join Ramp

13:20

for free. Just

13:23

go to ramp.com.easy. ramp.com.easy.

13:27

ramp.com.easy. Currents

13:30

issued by Sutton Bank and Celtic Bank members

13:32

of DIC. Terms and conditions apply. Nah, not

13:34

quite. What's up? Ah, sell my car in

13:36

Carvana. It's just not quite the right time.

13:38

Crazy coincidence! I just sold my car to

13:41

Carvana. What? I told you about it two

13:43

days ago! When you know, you know. You

13:45

know, I'm even dropping it off at one

13:47

of those sweet car vending machines and getting

13:49

paid today. That's a good deal. Oh, great

13:51

deal. Come on, what's your heart saying? You're

13:54

right. When you know, you know. Sold.

13:56

Whether you're looking to sell your car right now or

13:58

just whenever feels right. or

16:01

in German or in English. And

16:04

I'm not gonna extend that joke in the

16:06

obvious direction. But more

16:09

importantly though, the

16:11

point I'm making here is you can end up

16:13

with a functional system in 90% of the domains.

16:16

There are always exceptions to this. There

16:18

are always domains where one language would have

16:21

a clear benefit

16:24

over another. But

16:26

for the vast majority of sort

16:28

of general purpose business software, whether

16:30

web or not that everyone writes,

16:33

you can start off, use the

16:35

example of a backend because that just happens to be

16:38

what I know best. You

16:40

have massive, massive functional

16:42

systems built in Java,

16:45

in Python, in OCaml,

16:47

in PHP, in variants

16:49

of PHP because you have Wikipedia

16:51

on the one hand and you have Facebook on

16:54

the other, in virtually anything you'd

16:56

care to mention. And I'm not even

16:58

going in the direction of the obvious,

17:01

people are still writing in COBOL. I'm

17:03

talking about mainstream, purpose-built

17:06

relevant software that's been developed in

17:08

the last 20 years, not in

17:10

the last 60. So

17:13

we're talking internet facing software. What

17:19

I feel matters when

17:22

you're not in a domain which

17:24

lends itself really, really well to

17:26

the advantages or disadvantages

17:29

of any particular language, it

17:32

ends up being mostly an aesthetic choice. Which

17:35

language do I personally love

17:37

better? Because

17:39

if I can and over

17:43

a long enough stretch of time, all

17:46

systems can. If I can build

17:48

my system in PHP or JavaScript

17:50

or TypeScript or

17:53

Java or Kotlin or Scala or any

17:55

of those languages or Python, if you

17:57

must. There

28:02

are type systems that you can plug in

28:05

to get type annotations on your Ruby. The

28:08

vast majority of the community doesn't use them. As

28:12

far as TypeScript goes, a

28:14

big part of it, if you've been watching, especially

28:16

like the keynotes from Rails World for

28:18

the last, which was a couple weeks

28:20

ago and then like last year and

28:24

when in October, it's

28:27

been pretty clear that David

28:30

is much more DHH. He's

28:33

much more in favor of, he's

28:37

moved a lot more toward import maps and

28:40

a lot of the benefit that he's

28:42

talking about is not having a build

28:44

step, right? If you have TypeScript, you

28:46

have to have it transpiled to

28:48

JavaScript. And so by not

28:50

using TypeScript, you avoid that step and

28:53

you can actually just have your JavaScript

28:55

written and have it loaded into your

28:57

import map and then just come into

28:59

your application that way. And

29:01

so you avoid that process. But

29:03

did he also say that he's

29:06

kind of opposed to static typing

29:08

on principle? I've

29:10

gotten that impression. I don't know that I

29:12

could go find a place where he's actually

29:15

directly said that. You may be able

29:17

to, and that's definitely the

29:19

sentiment that comes through. But

29:23

yeah, and I'm kind of in the same boat, right?

29:25

I am not a big

29:27

fan or proponent of having

29:31

typing built into my stuff. And

29:34

I think that as Tomer's mentioned is

29:36

kind of more of an aesthetic thing.

29:38

I've never really

29:42

felt the benefit of it when I've done it. And

29:44

so I'm just

29:47

not a huge proponent of it. It doesn't mean I'm

29:49

against it. It's just that

29:51

some of the other benefits like not

29:53

having a build step and things like

29:55

that, make

29:58

it so that I look at it. it and

30:00

say, well, in order to get that, the

30:02

trade-off just isn't worth it because I don't

30:04

see the benefit for it, if that makes

30:06

sense. It's interesting. I'm

30:09

going to kind of take it

30:11

back because I have

30:13

some other thoughts on this

30:15

particular premise

30:18

that is being brought forward

30:20

because I generally agree that

30:22

in a lot of cases, you know, capability

30:25

wise and, you know, the different approaches that

30:27

the different languages are going to kind of

30:29

push you toward to get

30:31

a job done. Yeah, you

30:33

know, there's not a major

30:38

difference as far as them being able to do the job.

30:41

One thing that I've seen though is that depending

30:43

on what the advancement is and how

30:45

actively those are being worked on. So

30:47

this has more to do with ecosystem

30:49

really than language. We

30:53

see that they tend to converge, like

30:55

you said, Tomer, but the difference is

30:57

that depending on where those innovations are

30:59

coming from, being on the leading

31:02

edge of a lot of that stuff is a

31:04

benefit. But like I

31:06

said, I think that has more to do with the ecosystem

31:08

you're in. So for example, I just

31:13

watched last week the

31:15

key from

31:17

Rails world, right? And so he's talking about,

31:19

hey, we're simplifying the stack and we're simplifying

31:21

deployment and we're making it easier. And you

31:24

know, so he's talking about all these different

31:26

things. A lot of these, a

31:28

lot of good ideas have come out of Ruby

31:30

into other languages. A lot of great ideas have

31:33

come from other languages into JavaScript

31:36

or into Ruby. Ruby's adopted some of this

31:38

stuff, right? And so the convergence

31:41

is there, but I also look at it and

31:43

think, okay, well, because I

31:45

have the benefit of these particular things

31:47

that have come into the ecosystem that

31:49

haven't been adopted elsewhere yet. I'm

31:53

able to get more done in the

31:55

system I use and things like that. And

31:57

yes, some of that comes down to experience,

31:59

but I think some of it also comes.

32:01

comes down to the language and its approach

32:03

and the philosophy behind it and things like

32:05

that. And so I generally

32:08

mostly agree with you that

32:11

programming languages, there

32:14

may be differences in, hey, I

32:16

want to pick this for this, right? If I'm doing

32:18

system programming or something that needs that

32:20

kind of characteristic, I'm probably going to

32:22

reach for Rust as opposed to Ruby

32:25

or JavaScript. Most

32:27

tax pros leave a message. It's

32:29

Jane. I'm moving on to a TurboTax

32:31

expert who beat your price. Adam Devine,

32:33

tell him how I feel. ♪ A tax pro,

32:36

she's been thinking twice ♪ ♪

32:38

Best believe TurboTax will beat your price

32:40

♪ ♪ This is a

32:42

tax break, ah! ♪ Switch to

32:44

a TurboTax Live expert and we'll beat what you

32:47

paid your pro last tax season. Make the switch

32:49

at turbotax.com slash beatyourprice. TurboTax full service only. Sign

32:51

up by 12-20-2024 and file by 4-1-2025. Full

32:55

details at turbotax.com/beatyourprice. What's

32:58

the easiest choice you can make? Window

33:00

instead of middle seat? Picking

33:02

a vendor who sends a great gift basket? Outsourcing

33:05

business tasks you hate? What about

33:07

selling with Shopify? Whether

33:10

you're selling a little or a lot, Shopify

33:12

helps you do your thing, however you cha-ching.

33:15

Shopify is the global commerce platform that

33:17

helps you sell at every stage of

33:20

your business. All

33:28

the way to the Did We

33:30

Just Hit A Million Orders stage?

33:32

Shopify's there to help you grow.

33:34

Whether you're selling scented soap or

33:36

offering outdoor outfits, Shopify helps you

33:38

sell, wherever and whatever you're selling.

33:41

Shopify's got you covered. Sign up

33:43

for a $1 per

33:45

month trial period at

33:47

shopify.com/try. Go to shopify.com/try

33:49

now to grow your

33:51

business, no matter what

33:54

stage you're in.

33:56

shopify.com/try. Beyond those basic things, I still think

33:58

that there are... differences between

34:01

languages and systems that allow

34:03

us to operate and be more

34:06

productive, you know,

34:08

reach certain goals. If you

34:10

care more about some characteristics than others, then

34:13

you can reach for one over the other.

34:15

And so like I

34:19

don't know that there's an empiric, this

34:22

language is better than that language so

34:24

much as, you know, if

34:26

you're working in this area, it's not just

34:28

down to does it give you better tools,

34:31

but does it give you better tools that

34:33

literally make

34:35

you move that far ahead and web

34:37

in particular in backend is so

34:40

disparate that I feel

34:43

like there really are, I mean I use

34:45

Rails and I'm biased that way, but I

34:47

feel like there are a lot of really

34:49

serious advantages that come from using Rails that

34:52

other systems don't have. Yeah,

34:54

but are those advantages from

34:58

Rails or from Ruby and

35:00

could a Rails-like system

35:02

have been built on something other

35:04

than Ruby? Because the discussion here

35:06

at the end of the day

35:09

is not so much about Rails,

35:11

it's more about Ruby versus other

35:13

programming languages. I think some of

35:15

them come from Ruby, but I think some

35:20

come from Rails and could be built in other systems. I

35:23

would argue that that distinction doesn't really

35:25

exist. When you pick a language, you

35:28

pick an ecosystem, we are so far

35:30

beyond, as an industry, as a discipline,

35:32

we're so far beyond the point where

35:35

you would

35:37

build something on the language plus

35:39

a very, very lean standard library,

35:41

you'd have to reach out to

35:43

a whole bunch of stuff to

35:46

build even the simplest of systems

35:49

of the sort that we're talking about. Again, there

35:53

are exceptions to that

35:55

rule. So if you're a kernel developer,

35:57

you absolutely... have

36:00

to have some

36:02

degree of control over what the

36:04

compiler generates and how these parts

36:07

integrate and interact with each other,

36:09

which is why you would reach

36:11

for a systems programming language that

36:13

doesn't have a live runtime,

36:16

right? That doesn't have garbage collection or

36:18

whatnot. That

36:21

being said, for the mainstream, and by

36:23

the mainstream, I mean, you know, the

36:26

let's put it this way, not the part

36:28

of the industry that existed 20, 30 years

36:30

ago when the

36:32

lot of us were starting our careers, but

36:34

the part of the industry that grew up on

36:37

top of that, because the industry didn't

36:40

just change, it grew

36:43

exponentially. Like it grew crazy wise

36:45

in the last 20 years. So

36:47

a lot of the software that we end up writing

36:50

today in the mainstream, there

36:53

are nuances. Sure, you might prefer

36:56

some element of an

36:59

ecosystem or language or other, but

37:01

as if what you're building

37:03

is not in a domain where there

37:06

is a tangible

37:08

ecosystem advantage. So for

37:10

instance, right now, if

37:13

you're training models

37:15

and integrating in all

37:17

LLMs and whatnot, probably

37:20

you're going to reach for Python because

37:22

it's, you know, it's the go to

37:24

ecosystem. It's the one that moves the

37:27

fastest, etc, etc. That is

37:30

why you'd reach for Python, not

37:32

because you think Python is a better language

37:35

for that sort of words from Java or

37:37

whatever. Now, once

37:39

the ecosystems reach that kind of parody,

37:43

for most kind of business use case

37:45

sort of software that you would build,

37:48

if you're in the front end and

37:50

you're not on native, you're on the web,

37:52

you don't really have that much of a

37:54

choice. You can basically choose JavaScript or something

37:57

that compiles to JavaScript, which again becomes more

37:59

of an aesthetic. choice than anything. Like you

38:01

want to use Elm? Sure,

38:03

there are trade-offs for your organization,

38:07

not for the system you end up building,

38:09

because it's all going to be running in

38:11

a browser the same as any other JavaScript-based

38:13

thing you're going to build. Yeah,

38:16

but people writing Elm, for

38:19

example, will swear by the

38:21

fact that when they can

38:23

get when their code compiles,

38:26

it's correct. So speaking

38:28

is not something you can say

38:30

about JavaScript or TypeScript. I would

38:32

say two things to that. One,

38:35

it's hyperbole. Okay, if someone actually

38:37

came up to my face and

38:39

uttered that sentence with a serious face, I'd

38:42

call their bullshit because that's that's just what

38:44

it is. No, if

38:46

your code compiles, it's not production grade. Don't

38:48

give me that crap. Come on, we're grownups.

38:50

Second, I think we just got a whole

38:53

bunch of stinger hamburger out of that one.

38:56

Yeah. And just to qualify

38:58

that assertion, okay, I am

39:00

strictly in the statically typed

39:02

statically compiled language camp. As

39:04

an aesthetic preference, I'm a

39:07

scholar guy, right? And

39:09

I have been for many years. I'm

39:11

a co-founder of what ended up being

39:13

the Scala community in Israel and the

39:15

conference that we had around that. So

39:17

that's, that's kind of my personal bias.

39:19

And I can, you know, explain why

39:21

that is my preference. But fundamentally,

39:24

I come from the camp

39:26

of languages that don't

39:28

provide because no language can provide that,

39:31

but that sort of drive you towards

39:33

building code in a way where if

39:35

it compiles, there is a very good

39:37

chance that it'll actually run correctly in

39:40

production. It's not going to guarantee that

39:43

neither will 100% code coverage in your

39:45

tests, but we'll probably circle that to

39:47

that point later. The

39:50

point I'm trying to make here is before

39:53

you get to that point,

39:56

because you brought up Scala and the fact

39:58

that you were a founding father of the

40:00

the Scala community. Based on

40:02

what you're saying today, would

40:04

you have founded Scala, the Scala community

40:07

today, given what Java can do? Because

40:09

effectively what you seem to be saying

40:12

is, you know, Scala, Java, they

40:14

both run on the JVM, they're

40:16

kind of a parrot. So I

40:19

absolutely would, because of two

40:21

very fundamental things. One is

40:23

circling back to my original

40:26

assertion, it's a matter of

40:28

aesthetics. I don't say

40:30

that aesthetic preferences don't matter.

40:33

These are my aesthetic preferences. You know,

40:35

if I'm growing flowers and vases around

40:37

my house, and I start a community

40:40

around that, it's because I like flowers.

40:43

It doesn't necessarily mean that flowers

40:45

are objectively important. That's

40:47

one thing. The second thing is that

40:49

when I was heavily into

40:52

Scala and espousing Scala in the, you

40:54

know, in the Israeli tech community, Java

40:57

couldn't do what Java can do now

41:00

in the sense of expressivity. Sure, you

41:02

can build systems in Java, but I

41:05

would argue then as now

41:07

that Scala has advantages

41:10

over Java. It doesn't make

41:13

it a more useful language or

41:15

a more successful language or even

41:17

a preferable language necessarily for some

41:19

people. There were

41:23

organizations that have managed to convince

41:26

to take the plunge and they decided

41:29

to do so with the trade off that it's

41:31

going to be much harder to hire people to

41:33

work in Scala, which by the way, did

41:35

not turn out to be the case, but that

41:38

was the assumption because

41:40

they felt they had something to gain

41:43

from that choice. But it's

41:45

not to say that if they had

41:47

picked Java instead or Python instead, they

41:50

would have been any less successful. Wix, by the way,

41:52

which is a company you and I worked for, was

41:55

for many years a poster child

41:58

of Scala in the In

44:00

that respect, TypeScript is better

44:04

than JavaScript because it's a super

44:06

set of JavaScript and because it adds

44:09

something we as an industry find

44:11

useful. That

44:14

being said, it compiles down to

44:16

JavaScript. Clearly, everything you

44:18

build in TypeScript, you can build

44:20

in JavaScript. This is beyond instance.

44:23

Just to say, it's beyond being

44:25

compiled down to JavaScript. It's effectively,

44:27

you invest a lot of effort

44:29

into writing TypeScript types and then

44:31

they all get erased out

44:34

of your code when it's deployed into

44:36

the product. But the value proposition isn't

44:38

at runtime. Oh yeah, of course. It

44:41

is a distinction from the

44:44

.NET and Java ecosystems where

44:46

types do matter at runtime.

44:49

That being said. That's us.

44:54

That depends on how you write it, but sure. The

44:57

point I'm making here

45:00

is TypeScript to me

45:02

is an evolutionary state of JavaScript, like

45:04

treating it as a separate language to

45:06

my mind as sort of an outside

45:08

observer. I have no dog

45:10

in this race. I don't do my

45:14

everyday work in JavaScript or

45:16

TypeScript. I do occasional

45:18

work in JavaScript and TypeScript and Python

45:20

and a whole plethora of other languages.

45:23

So Most tax pros leave a

45:25

message. It's Jane. I'm moving on

45:27

to a TurboTax expert who beat your

45:29

price. Adam Devine, tell him how I

45:31

feel. ♪ A tax pro, she's been thinking twice

45:33

♪ ♪ Best believe TurboTax

45:35

will beat your price ♪ ♪

45:38

This is a tax break, ah!

45:40

♪ Switch to a TurboTax Live expert and we'll

45:43

beat what you paid your pro last tax season.

45:45

Make the switch at turbotax.com slash beatyourprice. TurboTax full

45:47

service only. Sign up by 12-20-2024 and file by 4-1-2025.

45:51

Full details at turbotax.com/beatyourprice. Whether

46:07

you're selling a little or a

46:09

lot, Shopify helps you do your thing.

46:11

However you chiching, Shopify is the global

46:13

commerce platform that helps you sell at

46:16

every stage of your business. From the

46:18

launch your online shop stage to the

46:20

first real-life store stage, all the way

46:23

to the did we just hit a

46:25

million orders stage, Shopify is there

46:27

to help you grow. All the way to the did we just hit a million orders stage. Shopify

46:29

is there to help you grow.

46:31

Whether you're selling scented soap or

46:33

offering outdoor outfits, Shopify helps you

46:35

sell. Wherever and whatever you're selling,

46:37

Shopify's got you covered. Sign up

46:40

for a $1 per

46:42

month trial period at shopify.com.

46:44

Try go to shopify.com. Try

46:46

now to

46:49

grow your business no matter what stage

46:51

you're in. shopify.com. Try. I

46:53

don't care in

46:55

a sense, but as an

46:57

outside observer perspective and tying

46:59

to this convergent evolution of

47:02

languages, statement

47:05

or argument, is that

47:07

this is that evolutionary state. So

47:09

Python at around 3.8 or

47:12

3.7 I think started getting optional

47:14

typing. Around the same

47:16

time TypeScript started taking off. These

47:19

are those ecosystems

47:24

version of a

47:27

worthwhile feature that they

47:29

took from statically typed

47:31

languages. Just to

47:33

make things, how would I

47:37

phrase it, just to make things

47:40

factually correct. TypeScript

47:44

and JavaScript, there might be some

47:46

convergent evolution. I see these two

47:48

are tied at the waist, but

47:52

they are distinct programming

47:54

languages. There's JavaScript, the

47:56

ECMOC script standard says

47:58

nothing. about standard typing,

48:00

it's highly probable that

48:02

it never will, you

48:04

know, whereas... And

48:08

this is a prediction that may or may not

48:10

prove true, and I might eat my words, but

48:12

it also means that it's a standard that in

48:14

five to ten years the only relevance it has

48:16

is for supporting

48:19

legacy software of which there is

48:21

a lot. I don't deny it.

48:24

But the ECMAScript standard that doesn't have anything

48:26

to do with typing is

48:28

about as relevant as the latest COBOL

48:30

standard. Chuck,

48:32

I will say this about the

48:34

value of types. So I'm actually

48:37

going through a fairly

48:39

large legacy project at work that's

48:43

been... that's like 100% JavaScript,

48:46

and we are gradually adding

48:48

static typing into it, and

48:51

I actually tweeted

48:53

about this, that the biggest challenge

48:56

in adding the static typing is

49:00

fixing all the bugs that it discovers.

49:04

So for example, just like

49:08

yesterday I ran into

49:11

the problem there where

49:14

this legacy system uses

49:16

MobX, and MobX

49:18

has this concept of an observable

49:20

array which is kind of like...

49:23

which extends regular JavaScript arrays. It's

49:25

very similar to JavaScript arrays, but

49:27

it's not quite the same. It

49:30

has methods that regular JavaScript arrays

49:32

don't have, for example, and

49:35

people played fast and loose

49:37

with it. They would assign

49:41

observable arrays and arrays into

49:43

the same variables, and

49:46

the system... obviously

49:49

the software works. It's legacy... I

49:53

like to say legacy software is software

49:55

that works. It's deployed.

49:57

Customers are using it. So

49:59

it works. somehow but it's

50:01

also obviously a bug. Now

50:03

maybe this bug doesn't actually

50:05

manifest itself in production, maybe

50:08

it does and the system

50:11

still somehow works because the

50:13

web platform is

50:15

very forgiving for

50:18

both good and bad. But

50:21

like I said it's obviously a bug

50:23

and it's been around probably for years

50:26

and I've found it now because

50:28

I'm adding static type information into

50:31

the project. Yeah

50:33

I would just put forward that you know

50:35

because we're talking about different languages having different

50:38

characteristics. The two systems

50:40

for Ruby are RBS and Sorbet.

50:43

RBS is maintained kind of by the Ruby

50:45

core team and then Sorbet is put out

50:48

by Shopify. They

50:52

tend to feel more onerous than

50:58

surfacing any issues like this. And

51:01

I think sure as some

51:03

systems get more complex,

51:08

I don't know if I have the right terminology

51:10

for exactly what kind of a vague term but

51:14

you know as things become more interconnected

51:16

as people are pulling in more libraries

51:18

maybe it might begin

51:20

to pay off. But my theory

51:23

is more that as Tomer

51:25

said there are a lot of efforts that

51:27

were tried to get something like TypeScript to

51:29

work in JavaScript to add the static types

51:31

and I'm thinking more along the lines of

51:34

these just aren't the right solution if we're

51:36

going to do it in Ruby. It

51:39

just doesn't jive with the way the language

51:41

goes. I also have to say that the

51:43

duck typing and the approach that we take

51:45

to a lot of things in Ruby, it

51:48

really feels just free.

51:51

I can just do what I need to do. And

51:54

I'm not saying that's right or wrong. I'm just saying there

51:58

are definitely things that that

52:01

inform the way people work in these languages

52:03

to where, yeah, I

52:05

don't think just saying static

52:07

typing is necessarily the answer.

52:10

I think there's more nuance to

52:12

a lot of this. And I think to be

52:15

honest, as we've kind of

52:17

seen the convergence evolution of a lot of

52:19

these languages, that's what we

52:21

see there too, right? Is that everybody kind of does

52:23

it kind of their own

52:25

way as they adopt these things. And so

52:28

it's not just this

52:30

language is picking up with this other language

52:32

innovated, it's that we found a way to

52:35

do it in a way that works with

52:37

the way that people approach and think about

52:39

problems in that language. Yeah, absolutely.

52:41

So, you know, I

52:45

guess I'm not really trying to defend anything

52:47

more. I'm just trying to say, I

52:52

haven't seen the benefit and it's mostly because what

52:55

I'm doing just, it

52:59

hasn't had the payoff, but,

53:01

you know, I mean, all of this could change.

53:03

You just never know. So

53:05

I would add to that, first

53:07

of all, I think it's not

53:11

just legit or fine that

53:15

you hold to those positions, it's a

53:18

valid trade off to make. So

53:22

one canonical difference, which

53:24

I think was very evident in both what

53:26

Don described in his experiences

53:28

and what you Charles did, is

53:32

that it's all a

53:35

trade off, it's a difference of what

53:37

it is that you stress in the

53:39

system. So my intuition,

53:41

and again, qualitative argument, I have no

53:43

data to back it up and I

53:45

don't think anyone ever will or

53:48

at least not in my lifetime, I could be wrong.

53:53

What I see is the value of

53:55

the value of the system of

54:00

static typing, or rather static

54:03

typing is a bit of a large

54:05

term. The value of the sort of

54:07

typing that I'm talking about, which can

54:09

be achieved with static typing, but also

54:11

with gradual typing, as you can see

54:13

in TypeScript or Python and other languages,

54:17

really starts to bear

54:19

fruit at a certain not

54:22

complexity level, but at a certain size

54:27

of the thing that you're building

54:29

and the number of constituent interconnected parts that

54:31

comprise it. So it's not so much about

54:33

whether what you're building is complex. That's probably

54:35

a better way of stating. I couldn't find

54:37

the way of saying about it. Yeah, that

54:39

makes a lot of sense. It mostly

54:42

starts manifesting for real in my

54:44

experience two cases. One is when

54:46

the system grows past a certain

54:49

volume of stuff that's in it.

54:51

And that's true of any language

54:53

I've ever worked with, including

54:56

statically, dynamically type, what have you. The

55:00

other situation, which I think

55:02

is where the sort

55:05

of productivity gains perceived by

55:07

the industry are coming from

55:10

is it aids in someone

55:13

not knowing what the code is

55:15

and how it's constructed, but knowing

55:17

what it is supposed to do

55:20

and how code is constructed in

55:22

the general sense of things. Being

55:25

able to get involved

55:28

with the system or engage with

55:30

the system at a fairly deep

55:32

level, the only way

55:34

you can do that

55:37

rapidly without significant onboarding

55:39

and significant prior knowledge, which by

55:41

the way, as a Rails guy,

55:43

you already have. So when you

55:45

come into another system built

55:49

in Ruby on Rails, you

55:51

already have that massive baggage

55:53

of how the system is built,

55:55

because Rails is very, very prescriptive.

55:57

And that is the trade.

56:00

I feel that DHH

56:02

is kind of espousing.

56:06

And fair enough, there is no denying

56:08

that you can be extremely productive if

56:10

you're a Rails engineer moving from one

56:12

system built in Rails to another. I've

56:14

seen it, right? I've

56:17

seen people do that and

56:19

they're extremely productive. The difference

56:21

is Rails is incredibly

56:24

prescriptive and as a result of

56:26

that is a good fit for

56:28

some systems, maybe even most systems

56:30

of that sort, I don't know, but

56:33

it is definitely a very, very

56:35

poor fit for other types of

56:37

systems that are in the mainstream.

56:40

Otherwise, I think

56:43

we would be seeing more success in

56:47

Ruby and Rails as we did in the 2000s. So

56:53

my argument here is there are trade-offs that

56:57

stress different parts of the system

56:59

under different circumstances. The

57:03

Most tax pros leave a message. It's

57:05

Jane. I'm moving on to a TurboTax

57:07

expert who beat your price. Adam Devine,

57:09

tell him how I feel. ♪

57:12

A tax pro, she's been thinking twice ♪ ♪

57:14

Best believe TurboTax will beat your price

57:16

♪ ♪ This is a

57:18

tax break, ah! ♪ Switch to

57:21

a TurboTax Live expert and we'll beat what you

57:23

paid your pro last tax season. Make the switch

57:25

at turbotax.com slash beatyourprice. TurboTax full service

57:27

only. Sign up by 12-20-2024 and file by 4-1-2025. Full

57:31

details at turbotax.com/beatyourprice. Stop

57:34

by O'Reilly Auto Parts for the

57:37

power, performance and reliability of a

57:39

new Super Start battery. Visit oreillyauto.com.

57:42

Oh, O, O,

57:44

O, O'Reilly Auto

57:47

Parts. Most

57:50

visible trade-off of picking a dynamic

57:52

versus static language is

57:54

in a dynamic language, especially

57:57

on projects that don't meet

57:59

that. sort of size or

58:01

volume threshold and have a

58:04

relatively small number of people that

58:06

engage with that system in its

58:09

life cycle, which by the way

58:11

is a thing

58:13

that happens very often, which is

58:15

why Rails was and continues

58:17

to be somewhat successful. As

58:21

long as those limits

58:24

are met, it is

58:26

an incredible experience. And you see that with a

58:28

variety of languages that some

58:30

of which have inspired Ruby. So you still

58:32

see people that have worked on production systems

58:35

in small talk raving about what it felt

58:37

like to work on production systems in small

58:39

talk. Not having had

58:41

that experience, I'm not going to argue

58:43

with them about it, but they kind

58:45

of express what

58:48

that did for them in the

58:50

same way, that it felt very

58:52

liberating. And I categorically

58:54

will not deny that or that

58:56

there's a productivity boost

58:58

to be had by that. But

59:01

you take a Ruby on Rails

59:03

engineer, you drop them into no

59:07

prior knowledge, you drop them into

59:09

a sufficiently

59:11

voluminous base

59:13

in any other language. They

59:15

will be able to onboard because

59:19

there's nothing wrong with Ruby and

59:21

you're not, you don't

59:24

not know something coming from Ruby. You

59:26

have your preferences. But my

59:28

point is that the reverse is not

59:30

true. You take people that are well

59:32

versed in production systems in a variety

59:34

of languages, you drop them into a

59:36

rail system to extend it or fix

59:38

it or improve the build process or

59:40

whatever it is that they want to

59:42

do in that system. Because

59:45

it relies so heavily on

59:47

sort of ingrained knowledge

59:49

of the philosophy of Rails, how things

59:52

are designed, how things are built. If

59:54

you don't have that coming in and you

59:57

don't have that also

59:59

kind of dated to when that

1:00:01

system was built because modern

1:00:03

rails doesn't look quite like rails from

1:00:05

five or 10 or 15 years ago.

1:00:08

And in some cases vastly different. Unless

1:00:11

you have that knowledge, you're just not

1:00:14

gonna be able to get

1:00:16

up to speed and be productive

1:00:18

in that system in any way, shape or

1:00:20

form without significant

1:00:22

handholding. And I've been in that

1:00:24

position myself and

1:00:28

it's not pleasant. Whereas

1:00:31

you have the same experience, by the way,

1:00:33

with the system built in Python or PHP

1:00:35

from 10 years ago because then they

1:00:38

didn't have some of these quality

1:00:41

of life enhancements. You didn't have

1:00:44

known types and known air conditions and

1:00:46

a hell of a lot more Python

1:00:48

docs that you could

1:00:50

see in your IDE than you just didn't

1:00:52

have those things 10 years ago. Whereas

1:00:55

today coming from any language

1:00:59

that's modern and mainstream to any other

1:01:01

language that's modern and mainstream is

1:01:04

not gonna be smooth sailing because languages

1:01:06

are different and there are nuances, but

1:01:09

you're gonna be able to figure

1:01:11

out where you are

1:01:13

in the code. You are gonna be

1:01:15

able to navigate to related things

1:01:18

in the code without having a lot

1:01:20

of ahead of time

1:01:22

knowledge. And that matters. That

1:01:24

matters with bigger products, with bigger

1:01:27

teams, with products whose life cycle

1:01:29

spans many years and many teams

1:01:31

and many people. And

1:01:34

I think that is the

1:01:37

primary motivator for those typing

1:01:39

systems, even in traditionally dynamic

1:01:41

languages like Python, JavaScript, whatever.

1:01:44

Again, Ruby, it spouses

1:01:47

a different philosophy, a different set of

1:01:49

trade-offs. I don't deny that they're valid.

1:01:52

I don't necessarily subscribe to them. And

1:01:56

if I were to find... a

1:02:00

legit argument against that, I would say

1:02:02

simply look at the, you know, look

1:02:04

at the math, look at the popularity.

1:02:07

Ruby was extremely popular

1:02:09

for just short of a decade.

1:02:12

The decade is long gone and

1:02:14

it never picked up since and

1:02:16

there's nothing to indicate

1:02:18

that it will. And

1:02:21

it's not because Ruby is bad or

1:02:24

Rails is bad. It's against my personal

1:02:26

biases, but you can build systems. I

1:02:29

mean, I've used Basecamp extensively. It's a

1:02:31

great product. I don't care what it's

1:02:33

written in as long as it works. So,

1:02:36

yeah, you see the languages in the mainstream

1:02:39

circling back to our original premise, right? You

1:02:41

see the languages in the mainstream. There

1:02:45

are nuances. There are

1:02:47

philosophical differences. Those

1:02:50

do matter in the tactical sense. Like as

1:02:52

you write code, you're not going to write

1:02:54

the same code in Python as you do

1:02:56

in Java or Scala or any of those

1:02:59

languages or in TypeScript

1:03:01

or in JavaScript, but you look

1:03:03

at the ecosystems and they're all. Oh,

1:03:23

oh, oh, oh, O'Reilly. Need

1:03:26

a little help? O'Reilly Auto Parts

1:03:28

can help. Need advice? We've

1:03:31

got advice. No matter what you need,

1:03:33

we have thousands of professional parts people

1:03:35

doing their part to make sure you

1:03:37

have it. Exceptional customer

1:03:39

service. Just one part that

1:03:42

makes O'Reilly stand apart. The

1:03:44

professional parts people. Oh, oh,

1:03:46

oh, oh, O'Reilly. Auto

1:03:50

Parts. Learning

1:03:55

from each other and offering what

1:03:57

appears to be a productive

1:04:00

in the broad sense set of

1:04:02

features. And type systems is,

1:04:05

I think, just the most visible of

1:04:07

those. You also have dependency management, which

1:04:10

frankly, wasn't a thing 20 years ago, right?

1:04:13

Maven was probably one of

1:04:15

the first two major dependency

1:04:18

management stacks. PIP

1:04:21

picked up a lot of that.

1:04:23

Then PIP kind of languished, poetry

1:04:25

came along to fix some

1:04:28

of these things and learn other lessons. And

1:04:30

then you have cargo, which is probably

1:04:32

the biggest newest one of the bunch

1:04:35

that learned a lot

1:04:37

of those lessons from languages that

1:04:39

are in completely different spaces. Rust

1:04:41

doesn't compete with TypeScript. Don't

1:04:45

forget NPM. I'm

1:04:48

trying to, but it's not gonna work.

1:04:50

No, I mean, I'm being

1:04:53

intentionally cynical here. NPM's

1:04:55

really good for installing yarn. I'm being a

1:04:57

very colossal influence. I

1:05:01

do not have a dog in this race either, but

1:05:03

I can say as

1:05:05

this interested observer that NPM

1:05:07

has had a colossal impact

1:05:09

on pretty much every ecosystem

1:05:11

out there. Without NPM, we would

1:05:14

not have cargo, including

1:05:16

the things that cargo does better

1:05:18

simply because it learned those lessons.

1:05:21

Right. So that is what

1:05:23

I mean by convergent evolution. You have a

1:05:25

lot of the same things. And by the way,

1:05:27

a lot of languages, JavaScript used to be the

1:05:29

poster child for, oh, there's no build. Isn't it

1:05:32

great? I just update the code and there it

1:05:34

is, which comes

1:05:36

with an incredible set of

1:05:38

trade-offs. And some of those

1:05:40

trade-offs, by the way, were very

1:05:43

early on ruled not by me and not

1:05:45

by people hating on JavaScript like I do,

1:05:48

ruled by the reality

1:05:50

of it, ruled by the

1:05:53

community of people producing functional

1:05:55

production code as

1:05:57

being a non-issue. You had a...

1:06:00

build process in many,

1:06:02

many, many, many JavaScript

1:06:04

systems over the last

1:06:06

one years, if only

1:06:08

for dependency management, asset

1:06:10

bundling, obfuscation, minification, what

1:06:12

have you, all

1:06:14

these things you couldn't get in a runtime

1:06:17

system. So it was not a worthwhile trade-off,

1:06:19

right? So that ostensible

1:06:21

advantage is not an

1:06:24

advantage as such, it's a trade-off. And

1:06:27

I think a lot of those trade-offs

1:06:29

are made because the ecosystem hasn't met

1:06:32

those challenges properly in a way

1:06:34

that doesn't require a trade-off. I

1:06:38

really want to try to get to the second

1:06:40

sacred cow and we seem to be

1:06:42

stuck on the earth. I was wondering if

1:06:44

we were gonna get to any others. Well.

1:06:47

So unless you've got something really insightful

1:06:49

to add, Tomer, I would like to

1:06:51

move along. I think

1:06:54

that does not have much chance

1:06:56

of ever happening. If

1:07:00

we do number two, we're not getting to any of the

1:07:02

other ones. We can have Tomer on

1:07:04

again. I'm fine with that.

1:07:06

This has been fascinating to talk through. All

1:07:09

right, so let's just try to at least touch on

1:07:12

the second one. Let's.

1:07:18

Chuck, so you're gonna read the second one or should I? I

1:07:21

will read the second one. So this

1:07:23

is what he's going to debunk. This

1:07:25

is not. So anyway,

1:07:30

it's clean code is important. All

1:07:34

right, so I'll start by qualifying that

1:07:37

clean code. You better. I

1:07:40

was gonna say, I don't know if I agree with you

1:07:42

on this. I'm gonna be talking about exactly what you think

1:07:44

I'm gonna be talking to. I just want to make sure

1:07:46

we're all on the same page. So when I say clean

1:07:48

code, what I mean is

1:07:51

the set of perceived

1:07:53

notions of what clean

1:07:56

code is and how to write it

1:07:58

as had been. espoused

1:08:00

in the industry and we said we might

1:08:04

not name drop, but I mean, you can

1:08:06

not name drop Uncle Bob as

1:08:08

the progenitor of these practices. Uncle Bob's a

1:08:10

good friend of mine, but cool.

1:08:15

So what I'm gonna say- He knows where I disagree with

1:08:17

him too, so that's fine. All right,

1:08:19

so here's what I have to say

1:08:22

on the subject. My issue with clean

1:08:25

code has nothing to do with its intent.

1:08:28

It's intense and the intent, the way

1:08:30

I see it is to help

1:08:33

people design systems that are more readable,

1:08:35

that are more sensible. It's

1:08:38

all of those best intentions that the way

1:08:41

to hell- More maintainable is the way

1:08:43

I typically approach it. Fair

1:08:46

enough, all those- But did you just notice what

1:08:48

Tomer said? He said that's the way to hell

1:08:51

is paved with good intentions

1:08:53

about clean code. Because the

1:08:56

rules of, because what

1:08:58

clean code is, is prescriptive.

1:09:00

And the way people understand

1:09:03

it is as a set

1:09:05

of rules and practices that must be

1:09:08

adhered to, or the code is

1:09:10

bad or the code isn't clean. So

1:09:12

there are a lot of examples to this, but

1:09:14

the kind of most obvious, and I think in

1:09:17

many ways, the most egregious one is

1:09:20

dry, is do not repeat yourself. And

1:09:23

there is a fascinating

1:09:25

amount of demagoguery going

1:09:27

on in the industry

1:09:29

around that and

1:09:31

similar rules, where

1:09:35

you will sooner or later

1:09:37

in your career, if you haven't

1:09:39

already, and by you, I mean everyone

1:09:41

with more than half a year of

1:09:43

experience, run into someone telling

1:09:45

you, oh, but why don't you extract

1:09:47

these two identical lines that come within

1:09:50

20 lines of each other into a

1:09:52

method, because

1:09:55

they're the same and they're reusable.

1:09:58

Or if they're- slightly

1:10:01

more advanced and they're

1:10:03

digging into this only

1:10:05

when those that identical line shows up

1:10:07

three times because if it doesn't show

1:10:09

up three times and it's not you know

1:10:12

you don't dry it. Beetlejuice,

1:10:15

Beetlejuice. Yeah no

1:10:17

no that's a prescription and it's a

1:10:20

really terrible prescription first of all because

1:10:22

it it doesn't do

1:10:24

anything second of all it's because it

1:10:26

wastes a whole heap of people's time

1:10:28

thinking about the wrong thing and

1:10:31

third because it causes it and

1:10:33

other discussions

1:10:35

of clean code end up

1:10:37

wasting no more

1:10:39

and no less time than arguments about

1:10:41

code formatting used to back in the

1:10:44

day because the rules

1:10:46

are approximate the rules are

1:10:49

intended are prescriptive

1:10:51

and intended not for you to follow

1:10:53

religiously that's my read on it and

1:10:55

that's kind of the you know that's

1:10:58

my assumption of the intent behind the

1:11:00

words right I don't that's my understanding

1:11:02

as well yeah I don't know Uncle

1:11:05

Bob you know I'm not gonna this

1:11:07

is not an ad hominem thing my

1:11:10

concern with these rules is that people

1:11:12

take them as gospel without considering what

1:11:15

it is that they're trying to accomplish

1:11:18

so the rules of clean code are not

1:11:21

in and of themselves you know

1:11:24

they might be evil but the intent is

1:11:26

the intent to my mind is

1:11:30

just misguided the intent is to

1:11:33

build systems that are more maintainable

1:11:35

as you say or readable or

1:11:37

any of these things without

1:11:40

actually reaching

1:11:42

for what it is that that

1:11:44

makes a system more maintainable or

1:11:46

readable or inefficable or any of

1:11:48

these things which is simplicity

1:11:52

versus complexity and I can define

1:11:54

those things and we may want

1:11:57

to but critically those

1:12:01

rules to my mind, right? As

1:12:05

in my own reading of them were,

1:12:08

they're not so much that people know

1:12:11

not to repeat themselves more than twice

1:12:13

in code, because that's just garbage. The

1:12:15

rules are there to get

1:12:17

people thinking, what

1:12:20

is simple? What will make

1:12:22

this code easier to grasp,

1:12:24

easier for another person, which

1:12:26

as the saying goes, might

1:12:28

be mean in six weeks?

1:12:32

What will make it easier to rediscode,

1:12:35

figure out what it does, why

1:12:37

it does it, how it does it with

1:12:40

a minimal of external

1:12:44

drivers or external knowledge? And

1:12:47

that to me is simplicity. So here I'm

1:12:49

going to push back on something. I

1:12:53

think what you might be ignoring

1:12:56

is the fact that is kind of the thing

1:12:58

that comes up, came up very early in

1:13:00

the industry in the form

1:13:03

of the mythical manmothers. Is the

1:13:05

fact that not all programmers are community. Yeah,

1:13:08

the fact that not all programmers are community.

1:13:10

Another sacred cow to the old

1:13:13

estimator. Yeah. The

1:13:16

fact that half the programmers in the

1:13:18

world are worse than the average programmer.

1:13:22

And... I think that's the

1:13:24

definition. I guess it's

1:13:26

mean. It's mean, but it's true. Yeah,

1:13:30

well, okay. Whatever. Yeah,

1:13:33

I think in this

1:13:35

particular case, the average and the mean are

1:13:38

probably fairly close. We're

1:13:40

talking humans for a change. Yeah,

1:13:43

it's not like wealth.

1:13:46

So what

1:13:48

I'm trying to say is, if

1:13:50

you've got a team on

1:13:53

which you've got a top-notch developer

1:13:56

that is able to make sure

1:13:59

that... the system as a whole

1:14:02

retains this attribute of

1:14:04

simplicity, then you

1:14:06

don't need to adhere as

1:14:09

much to these kind of strict

1:14:12

rules and guidelines. When

1:14:14

you're on teams that don't

1:14:16

have such a person, then

1:14:20

maybe having overly

1:14:22

strict rules is

1:14:25

a good thing. Don't

1:14:27

you think? Well,

1:14:29

speaking as a statically typed guy, I

1:14:31

can't very well rail against that argument.

1:14:33

But taking it taking

1:14:35

a little bit more head on, there's

1:14:39

two issues I

1:14:41

have with that argument that I

1:14:43

think kind of nullify that argument.

1:14:45

The first is it doesn't actually

1:14:48

argue anything beyond, oh, other people

1:14:50

are stupid. It's for their own

1:14:52

good, which is not an argument

1:14:54

that I buy, even though I

1:14:58

might subscribe to that opinion. The

1:15:01

second issue I have with it is

1:15:05

engineers that don't

1:15:08

have and that

1:15:13

haven't over the course of presumably

1:15:16

several years, they don't have to be super senior

1:15:18

developers. But if you've been in the industry

1:15:20

for a couple of years, presumably

1:15:22

wrote a bunch of code, presumably

1:15:25

read quite extensively more code than

1:15:27

you wrote to begin with. And

1:15:30

you haven't developed an

1:15:33

appreciation for the basic

1:15:35

truth that copy

1:15:39

pasting a complex bit

1:15:41

of code over and over again is

1:15:43

bad, then your problem isn't that you

1:15:45

don't have the right rules in place

1:15:47

to limit you. Your problem is that

1:15:49

your company hired you to do a

1:15:51

job that you're probably incapable

1:15:53

of doing. Now, that

1:15:55

being said, that sounds like gate

1:15:57

keeping probably because it. is

1:16:00

because I can't help it, but to

1:16:04

bring that home and

1:16:06

perhaps save

1:16:08

my own skin with

1:16:10

other people. My point is this,

1:16:14

some types of programming

1:16:16

you can do with these types

1:16:18

of guardrails in place, and there

1:16:20

is room for

1:16:22

that work in the industry, I

1:16:25

hope. But the

1:16:30

types of systems that you will be able

1:16:32

to work on is not infinite.

1:16:35

You're not going to be able to

1:16:37

build large production-grade,

1:16:41

long-lived, difficult

1:16:44

systems that deal with actual problems

1:16:46

that are interesting if

1:16:49

you are not willing

1:16:51

to put in the thought and

1:16:54

learn what makes code more

1:16:56

readable, more navigable, etc. And you have people

1:16:58

around you to help you do that. So

1:17:00

it's not like if you are a junior

1:17:02

developer and you come in and you make

1:17:04

a quote-unquote dry violation mistake, you're going to

1:17:07

get fired, you're

1:17:09

hopefully going to, because

1:17:11

you're a junior developer, you were hired in

1:17:13

a context where you can be

1:17:15

functional and you have support, you're

1:17:17

probably going to have the person

1:17:19

next to you, that senior developer,

1:17:22

explaining why this

1:17:24

makes the code worse. But

1:17:27

you're not likely to have a

1:17:30

set of guardrails keeping you from

1:17:32

making those mistakes because those guardrails

1:17:34

are literally

1:17:36

anathema to the way virtually

1:17:39

any practicing software engineer works.

1:17:41

So imagine you were working

1:17:43

on a system and

1:17:45

you were writing code and your

1:17:47

code would not compile because the

1:17:49

compiler feels that you have those

1:17:51

two lines of code identical in

1:17:53

three places, so that's a dry

1:17:55

violation and you

1:17:58

can't compile the code. That

1:18:00

is, that sounds ridiculous because

1:18:03

it is, because the assumption is

1:18:05

if you're working on those systems,

1:18:08

you have to have both

1:18:10

a taste for code,

1:18:12

whereby you wouldn't necessarily, you would learn

1:18:15

very early on why that's a mistake

1:18:17

and you would stop making it because

1:18:19

it's communication. Like there

1:18:21

is nothing inherently wrong with having

1:18:24

several copies of the same code in the same

1:18:26

place. It's a trade-off, right?

1:18:29

What is the trade-off? If you can't

1:18:31

have that conversation, you're never gonna become

1:18:33

a better developer. The guardrails aren't gonna

1:18:35

help you get there. They're just gonna

1:18:37

stop everyone else from doing their job.

1:18:40

So- I

1:18:42

think this is a great topic.

1:18:44

And one I think we should

1:18:47

probably have you on to discuss

1:18:49

at length about what is actually

1:18:51

simplicity in coding. We

1:18:54

probably don't have time to do it justice. I'll

1:18:57

just add the fact that, I

1:19:02

never liked Douglas

1:19:04

Crockford's Linter. What's it called? JS

1:19:07

Lint, the original Linter.

1:19:10

Because it basically said, Douglas

1:19:13

Crockford said, this is JavaScript,

1:19:15

the good parts. Everything else

1:19:18

is not good. Getting

1:19:20

help for mental health shouldn't be as hard as

1:19:22

it is. Thankfully, Mindful Therapy Group is here to

1:19:25

make your mental health journey as

1:19:27

painless as possible. Be seen in as little as 48 hours for

1:19:30

in-person or telehealth appointments. Mindful partners

1:19:32

with thousands of licensed clinicians to

1:19:34

find the perfect fit for you.

1:19:36

Whether you need talk therapy, psychological

1:19:38

testing, even medication management, Mindful has

1:19:41

you covered. Mindful Therapy Group also

1:19:43

accepts insurance, so you can focus

1:19:45

on you and not your wallet.

1:19:47

Visit mindfultherapygroup.com to get started today.

1:19:50

Life can be hectic, and managing your

1:19:52

mental health is more important today than

1:19:54

ever before. That's why Mindful Therapy Group's

1:19:56

mission is to take the pain out

1:19:58

of finding a therapist. Whether you need

1:20:00

talk therapy. psychological testing, even medication management.

1:20:02

Mindful has you covered. Our mental health

1:20:04

providers are here for you with both

1:20:06

in-person and telehealth options to get you

1:20:08

seen in as little as 48 hours.

1:20:11

Mindful Therapy Group also accepts insurance.

1:20:13

Join us to start your journey

1:20:15

to a healthier and happier you.

1:20:17

Visit mindfultherapygroup.com to get started today.

1:20:20

By definition, because I said so and

1:20:23

I built this linter to enforce my rules

1:20:25

and you can't modify it. And

1:20:29

there's a reason ES Flint won. And

1:20:33

because, you know, it's, when

1:20:37

you're so dogmatic, it's

1:20:39

a problem. Contrary wise,

1:20:42

there's a reason Java lost,

1:20:44

if you can call it that. And

1:20:46

the reason Java isn't anywhere near as

1:20:48

popular as it used to be percentage-wise

1:20:50

for building the types of systems that

1:20:53

Java used to be popular for is

1:20:56

because a lot of people were thrown off

1:20:58

and turned away by what is to a,

1:21:00

you know, a

1:21:04

seasoned experienced engineer, active the

1:21:06

mission, a rigorous

1:21:09

type system that forces you to not make

1:21:11

mistakes. Whereas a lot of practicing developers would

1:21:13

look at it and go, yeah, but who

1:21:15

gives a damn? That's, you know, that's completely

1:21:17

trivial. I don't care. I don't want to

1:21:20

have to mess with it and moved on.

1:21:22

So the languages that ended up being

1:21:25

successful are the ones that found

1:21:27

a workable middle ground. And

1:21:30

I include in that list, by

1:21:33

the way, later iterations of Java.

1:21:35

Modern Java isn't anywhere near as

1:21:37

verbose or pardon my French, anal

1:21:39

retentive as traditional Java used to

1:21:41

be. And that is

1:21:44

because other languages showed that that

1:21:46

kind of, it's not

1:21:48

just verbosity. Everyone rails

1:21:50

against Java being verbose, but it's

1:21:53

also that precision just isn't necessary

1:21:55

in a lot of things, right?

1:21:58

The common case where you have... a

1:22:00

class and that class has hash code

1:22:02

into string and a few constituent components

1:22:05

is common enough that it makes sense

1:22:07

to have a first class language concept

1:22:09

around it. And it

1:22:11

took Java way too long to reckon with

1:22:13

that, but eventually it got record classes, you

1:22:16

know, the sort of same ad

1:22:18

hoc data containers that every other

1:22:21

types, every other language has had since

1:22:23

the beginning of time, because it's convenient

1:22:26

and useful and

1:22:28

doesn't require the level of control

1:22:30

and precision that Java espoused at

1:22:32

the beginning. So things evolve across

1:22:34

the board. It's not, I'm not

1:22:37

trying to make the point, you

1:22:41

know, this kind of circles back to original

1:22:43

Kyle, but with this as well is

1:22:46

the tools that Win

1:22:48

tend to be the

1:22:50

tools that are not the most

1:22:52

rigid or the most liberating and

1:22:55

for a very good reason. It's

1:22:58

because having absolutely no guardrails is

1:23:00

a recipe for disaster, which

1:23:03

is why hardly anyone writes

1:23:05

business software in C or

1:23:07

C++ anymore. It's

1:23:09

because you don't get

1:23:11

anything in return to that

1:23:13

level of precision and control. You only

1:23:15

get the bucks for those domains. Anything

1:23:21

that's sufficiently successful in the modern

1:23:23

sense has made those trade offs

1:23:25

willingly. And I think

1:23:28

we find those trade offs being

1:23:30

made in every ecosystem kind

1:23:33

of converging on the same set of

1:23:35

trade offs roughly with nuances and preferences.

1:23:40

As for clean code, clean

1:23:43

code is prescriptive and therefore bogus.

1:23:46

The problem is the rules are

1:23:48

not, the

1:23:52

rules are well intentioned, but they provide

1:23:55

the wrong kind of guidance and

1:23:59

end up causing. more damage than harm in my

1:24:01

opinion. So I'm going to jump

1:24:03

in on some of this. So like

1:24:06

I said, I've talked to Uncle Bob quite a

1:24:08

bit. I've actually talked to him about the Clean

1:24:11

Code book. I

1:24:14

ran a book club for a while. In fact, I still

1:24:17

kind of do. So

1:24:19

we did Clean Code. We also did Clean Architecture. A

1:24:23

lot of the things that we talked through as we

1:24:25

talked through the book, he wrote

1:24:28

it when he was writing a lot of languages

1:24:31

that frankly are pretty different from

1:24:33

Ruby or JavaScript, where I was

1:24:35

primarily working. And so I'd point

1:24:37

some of these out either, hey,

1:24:39

this doesn't make as much sense in the

1:24:41

world I live in as the world that

1:24:43

this seems to be written for. And he

1:24:46

agreed. And so in

1:24:48

a lot of cases, yeah, they're kind of

1:24:50

prescriptive. And maybe he doesn't make that as

1:24:52

clear that, hey, look, you've

1:24:54

got to apply this as makes sense depending

1:24:56

on what you're doing. A

1:24:59

lot of the ideas in the

1:25:01

book, Clean Code, and a lot

1:25:03

of the ideas in the book, Clean

1:25:05

Architecture, I picked up another one.

1:25:07

I can't read. Clean Agile, I think I also read. And

1:25:11

the main thing is I find

1:25:14

that the rules or ideas behind

1:25:17

the rules are definitely

1:25:19

worth discussing with your team and

1:25:22

having the conversation, hey, look, when

1:25:24

we're naming variables, we ought to

1:25:26

consider these things. When

1:25:28

we're writing out our code, we ought to

1:25:30

consider these things. So when

1:25:33

you get down to follow

1:25:35

standard conventions, that

1:25:38

makes it approachable for anybody who works in

1:25:40

the language or framework or whatever. You

1:25:43

get into keeping it simple, I think, is one of

1:25:46

his points, which is also your point. But yeah, as

1:25:48

you get into some of the other ones where it's

1:25:50

like, here's how you formulate comments, and here's how you

1:25:52

name variables, and here's how you do these kinds of

1:25:54

things. Yeah, some of those I found

1:25:57

just were a little bit

1:25:59

tough. swallow. But

1:26:02

it was mainly because my

1:26:04

context was different enough to where I could

1:26:07

come up with a guideline that made sense

1:26:09

for what I was doing. And

1:26:11

down to like dry. I think

1:26:14

it's funny because you mentioned, you know, what if your

1:26:16

tool told you that it wouldn't compile if it wasn't

1:26:19

dry enough. And back in

1:26:21

the day, earlier

1:26:23

in the Ruby community, there were tools that

1:26:25

would do code analysis, and they would point

1:26:28

out areas of your code that weren't dry.

1:26:31

And what I found was at least

1:26:33

half, if not more than

1:26:35

half, you know, significantly more than half in some

1:26:37

cases in some of the code bases I worked

1:26:39

in, it point out something wasn't dry, and it

1:26:41

was wrong. Right? It was

1:26:43

it, like, structurally,

1:26:45

the code looked similar. But

1:26:48

in reality, the concern was different

1:26:50

enough to where it didn't make sense to combine

1:26:52

them. Like you would have been putting in edge

1:26:54

cases every other line, oh, this is different

1:26:57

from that here. And so we're going to do this this way instead

1:26:59

of that way. And it's just, you know, you're

1:27:01

better off having two things that look kind of the same. And

1:27:04

so, again, I

1:27:06

think I think there's a heavy dose of common sense

1:27:08

that comes with this. Initially,

1:27:11

when I saw your point, I thought you were

1:27:13

going to make the point that, you know, trying

1:27:15

to have code that's easy to understand and clean

1:27:17

and maintainable and stuff like that, is

1:27:19

kind of an overblown making the

1:27:21

case for cowboy coding. And

1:27:23

yeah, and I was going to say, no, you

1:27:26

really do need to, you know, have some level

1:27:28

of, hey, you can look at this, you can

1:27:30

understand it. And then that, like you said, that's

1:27:32

the goal of, of clean

1:27:34

code. But my my deal is, is with

1:27:37

a lot of these, or if you read other, because

1:27:39

there are other books that give different rules or standards. And

1:27:43

and the reality is, is you've

1:27:46

got to figure out what works. And in

1:27:48

some cases, it's not just works for your

1:27:50

team. Sometimes it's this code base has a

1:27:52

set of problems that if

1:27:54

you apply the standard from the other code base you're working

1:27:57

in, it's just not going to work.

1:28:00

One other case I want to make is several

1:28:03

years ago, Sandy Metz, she

1:28:07

had a set of rules for

1:28:09

how you formatted your Ruby code. And it

1:28:11

was, you should never have a method that's

1:28:14

longer than so many lines. You should never

1:28:16

have more than so many arguments in your

1:28:19

methods. You shouldn't have

1:28:21

more than so many lines. And then I

1:28:23

hated so much when my method ends up

1:28:25

being one line too long. Yeah,

1:28:28

and that was the problem. And then you're

1:28:30

looking at it and you're scrutinizing it and

1:28:32

you're trying to figure out, right, because there

1:28:34

were linters in Ruby that would enforce it.

1:28:37

And it would fail the build if, or

1:28:40

fail, you know, fail CI if it was, right?

1:28:43

So you had an eight line method and

1:28:45

you're looking at it and you're going, well,

1:28:47

the only way to get it that

1:28:50

way is essentially to create a

1:28:52

second method and just put two of the lines in

1:28:54

it, which doesn't help.

1:28:57

And so- So I will add

1:28:59

to that. There's two things here,

1:29:01

right? There's, first of

1:29:03

all, circling back to the, really

1:29:07

the beginning of the conversation, a

1:29:11

programming language is a language above

1:29:13

communication. Yes. Fundamentally,

1:29:16

you know, I think I've read

1:29:18

some guy at some point,

1:29:20

probably 20, 30 years ago, putting

1:29:22

it as a prose that's

1:29:24

readable by humans and it executable by

1:29:26

machine, right? Which I think is a

1:29:29

very high for the living way of

1:29:31

putting it, but it's close enough to

1:29:33

reality. What matters when

1:29:35

it comes to the way

1:29:38

the code is structured and

1:29:40

formatted are the people. If

1:29:42

it does what it's supposed to do, then

1:29:45

the only reason why you should ever care

1:29:47

what the machines think is when

1:29:49

the code doesn't compile, obviously in the one

1:29:51

hand, but if

1:29:54

you have a, typically

1:29:56

a performance oriented thing that

1:29:58

requires you to- express

1:30:01

something in a way convoluted to

1:30:03

humans, but more easily executable to

1:30:05

a machine. That can happen. That's

1:30:08

niche though. So by

1:30:10

and large, when you do the work you

1:30:12

do, you do

1:30:14

it for other humans. And one of those

1:30:16

humans might be you in six weeks. Clean

1:30:19

code as it is, is

1:30:22

a very good thing in the

1:30:25

sense that it was

1:30:27

one of the few and only

1:30:30

resources in sort of the

1:30:32

space of how to build better code. Like

1:30:35

it was an honest attempt at it. But

1:30:40

I think a lot of people read

1:30:42

into it as, again,

1:30:46

more of a prescription, more, it

1:30:48

became its own thing. I'm really not

1:30:50

against the intent or against Uncle Bob

1:30:52

personally. Again, I don't know him, that

1:30:55

I've got nothing to add to that. But

1:30:58

I am railing against the way it. Life

1:31:01

can be hectic and managing your mental

1:31:03

health is more important today than ever

1:31:05

before. That's why Mindful Therapy Group's mission

1:31:07

is to take the pain out of

1:31:09

finding a therapist. Whether you need talk

1:31:11

therapy, psychological testing, even medication management, Mindful

1:31:13

has you covered. Our mental health providers

1:31:15

are here for you with both in-person

1:31:17

and telehealth options to get you seen

1:31:19

in as little as 48 hours. Mindful

1:31:22

Therapy Group also accepts insurance. Join

1:31:24

us to start your journey to

1:31:26

a healthier and happier you. Visit

1:31:28

mindfultherapygroup.com to get started today. Getting

1:31:31

help for mental health shouldn't be as hard as

1:31:33

it is. Thankfully, Mindful Therapy Group is here to

1:31:35

make your mental health journey as painless as possible.

1:31:37

Be seen in as little as 48 hours for

1:31:41

in-person or telehealth appointments. Mindful partners

1:31:43

with thousands of licensed clinicians to

1:31:45

find the perfect fit for you.

1:31:47

Whether you need talk therapy, psychological

1:31:49

testing, even medication management, Mindful has

1:31:51

you covered. Mindful Therapy Group also

1:31:53

accepts insurance so you can focus

1:31:55

on you and not your wallet.

1:31:57

Visit mindfultherapygroup.com to get started today.

1:32:01

became embedded in the industry

1:32:04

because much like the topic we're not

1:32:07

going to have time to discuss here

1:32:09

again, which is TDD, it

1:32:11

became more of a,

1:32:16

on the one hand, a religion and on the other hand,

1:32:18

a gatekeeping practice

1:32:21

than what it was originally designed for,

1:32:23

which is a set of

1:32:25

useful tools deriving from a

1:32:28

lot of thinking about a set of useful

1:32:30

ideas that can

1:32:32

make you more productive or

1:32:34

better communicator. So staying clean

1:32:37

code is bad,

1:32:40

is obviously hyperbole to some

1:32:42

extent, but it is

1:32:44

analogous to reading the elements of

1:32:46

style in English, which is a

1:32:49

fascinating book, very much worth

1:32:51

reading for anyone who cares about communicating

1:32:54

better in English. But it

1:32:56

is also chock full of

1:32:58

anachronisms and opinions that are

1:33:01

not necessarily born out

1:33:03

in the intervening years. And I think

1:33:05

clean code is kind of like that

1:33:08

as well. Before we

1:33:10

conclude, I just have to give

1:33:12

my number one rule. It's almost

1:33:14

the only rule really is

1:33:17

be consistent. A

1:33:19

code base should strive for consistency.

1:33:21

Yeah, it's somewhat

1:33:25

an important rule. And I think it's

1:33:27

also very overrated, because now you're on

1:33:29

a file of, okay, what is a

1:33:31

code base? If a code base contains

1:33:33

1000 classes, do

1:33:36

they have to be consistent? Considering you might have

1:33:38

had 40 different people from five

1:33:40

teams working on them? Not

1:33:43

necessarily. It's a trade-off. There is value

1:33:45

to that, but there is also cost.

1:33:48

There are trade-offs to everything, and

1:33:50

there are exceptions to them. There

1:33:52

obviously are exceptions to every rule.

1:33:55

But I'm very much in favor

1:33:57

of code consistency. And

1:33:59

I think that these days

1:34:01

we have tools in place

1:34:03

to provide consistency guardrails across

1:34:06

larger projects. And

1:34:10

if you can manage it, it's

1:34:13

a huge benefit because otherwise when

1:34:15

you read code, you get hung

1:34:17

up on things that

1:34:19

you shouldn't get hung up on. Like

1:34:21

why is this code different than that

1:34:23

code? Well, because this

1:34:26

was written by George and that was written by

1:34:28

Tim, it's not a good enough way. We upgraded

1:34:30

the framework the old way works and this is

1:34:32

the new way. So that's

1:34:34

a valid reason actually. Those are two

1:34:37

very different reasons and I think both

1:34:39

are valid by the way because again,

1:34:42

when you code, whatever it is that you

1:34:44

program, you are expressing a part of the

1:34:46

problem both to the machine and another human.

1:34:50

It is a form of expression

1:34:52

by definition, which means by definition,

1:34:54

two different people are going to express

1:34:56

it differently. My

1:35:00

point is consistency is

1:35:02

a valuable asset to

1:35:04

some degree and

1:35:07

it becomes a liability from

1:35:09

some other threshold. And

1:35:13

assuming that consistency is always a

1:35:15

positive is every bit as risky

1:35:18

as saying, know who cares about

1:35:20

consistency, let's all have whatever

1:35:22

different code formatting for each code

1:35:24

file. That's dumb, but

1:35:27

it's no more or less dumb than

1:35:30

saying no, all files have to be

1:35:32

identical, have to have consistent, whatever's because

1:35:35

what you're doing is you're constraining all

1:35:37

of your engineers, all of your communicators

1:35:41

effectively in the

1:35:43

same way where you know

1:35:45

they're not going to be working

1:35:47

in the same way

1:35:49

on the same thing. Even

1:35:51

if it's the same person coming to

1:35:54

the same piece of code three, six,

1:35:56

nine months later, they

1:35:58

might have a different. and potentially

1:36:01

better way of expressing something. And

1:36:03

a lot of the times the

1:36:06

ability to express something elegantly

1:36:08

in code actually runs a

1:36:11

fall of even something I'm not gonna

1:36:13

argue against, which is automatic code formatting.

1:36:16

I'm all for automatic code formatting

1:36:19

for a very simple reason, because I'm sick

1:36:22

and tired of arguing, debating, or even

1:36:24

talking about it. That is the only

1:36:27

reason why I wanna have, a

1:36:30

code reformatter as part of my pipeline is

1:36:32

because I don't wanna ever have one of

1:36:34

those conversations again. That being said, I've

1:36:38

often been in the position where

1:36:40

the reformatted code just

1:36:43

does not express the solution

1:36:45

as elegantly as the code

1:36:48

I would have formatted in some other way,

1:36:50

because it runs a fall of that, whatever

1:36:54

rule the team put in place.

1:36:57

So even trivial rules like line length or

1:36:59

how many lines per minute, whatever it is

1:37:01

that you end up having, you're gonna have

1:37:03

some subset of those in every project. Even

1:37:07

those sometimes constrain your expressivity

1:37:09

as an engineer more than you

1:37:12

would like. Now, again, we're

1:37:14

talking trade-offs. The trade-off of having those

1:37:16

arguments about code formatting for the better

1:37:18

part of 30, 40

1:37:20

years of my life is exactly why

1:37:23

this trade-off is worthwhile. I will give

1:37:25

up a bit of expressivity so I

1:37:27

don't have to ever have those conversations

1:37:29

again, but that is why.

1:37:31

It's not because inherently the

1:37:34

consistency is a positive

1:37:37

or the expressivity is a positive.

1:37:39

It's always a trade-off. I

1:37:43

think we need to start

1:37:45

wrapping up. Yeah,

1:37:48

I think so. We didn't

1:37:50

even get to dunking on

1:37:52

code coverage and dependency injection. Yeah,

1:37:56

next time, next time. Yeah,

1:37:58

so Tomer, people wanna... see

1:38:00

what you're working on writing, speaking about these

1:38:03

days, where do they find your stuff? Well,

1:38:06

I'm running my own consulting company, so

1:38:09

that's Substrate, Substrate

1:38:11

Software Engineering, substrate.co.il

1:38:14

is the website. What

1:38:16

I'm working on in commercial

1:38:18

settings is not something I

1:38:20

can generally talk about, because it's customers'

1:38:23

stuff, not mine. That

1:38:25

being said, I have, as

1:38:29

always, there's something writing

1:38:31

or presentation-related down the

1:38:34

road. So

1:38:36

recently I gave a talk about

1:38:38

migrating to AWS Graviton, taking

1:38:40

a big production set of production

1:38:42

systems, actually, and moving them

1:38:45

over to ARM64. So

1:38:48

that was an AWS-hosted

1:38:50

event a few months ago.

1:38:54

What happens next is anyone's guess,

1:38:56

but I'm always ranting about something

1:38:58

or other on Twitter, at

1:39:01

TomerG. And if

1:39:04

you want to argue with me,

1:39:06

engage with me, talk

1:39:09

to me, or hire me, then you're more

1:39:11

than welcome to reach out. Just look up

1:39:13

my name, it's pretty internet-unique.

1:39:16

I would like to add that Tomer

1:39:19

has a whole bunch of talks which

1:39:21

are all styled around the title of

1:39:23

how shit works, and

1:39:26

how shit works a CPU,

1:39:28

how shit works time, how

1:39:31

shit works memory, whatever. And

1:39:34

you can find all of these

1:39:36

talks on YouTube, and I highly

1:39:38

recommend watching them. They're all irreverent

1:39:40

and all very highly educational and

1:39:42

informative. Awesome.

1:39:46

Highly irreverent is my middle name. I'm

1:39:51

getting there. Anyway, let's go ahead and get to

1:39:53

some picks. Dan, do you want to start us

1:39:55

off with picks? Sure. might

1:40:00

have noticed that this is my

1:40:02

return after a bit of hiatus.

1:40:04

I haven't participated in like four

1:40:07

or five episodes. Part of the reason was

1:40:09

that I was on vacation.

1:40:12

My wife and I, just the two of us,

1:40:14

went to Italy together and

1:40:17

toured all through South Italy. It

1:40:20

was awesome. So my first picks

1:40:23

would be first of all taking a vacation,

1:40:26

second taking a vacation with your

1:40:28

spouse and third

1:40:30

taking that vacation in Italy.

1:40:33

All of these would be my

1:40:36

picks. I would like to mention

1:40:38

two places in particular that we

1:40:40

visited and are like extremely unique

1:40:42

and really breathtaking and amazing. One

1:40:45

of them is this town

1:40:47

or city in Italy called

1:40:49

Matera. I don't know

1:40:52

if you've visited, it's like nothing

1:40:54

else I've ever seen. It's kind

1:40:56

of like this place where people

1:40:59

like lived in

1:41:01

caves and the rock and effectively built

1:41:03

their city over the caves that they

1:41:05

built in. And the living

1:41:09

conditions used to be terrible, which is

1:41:11

why this whole city was kind of

1:41:13

evacuated in the beginning

1:41:15

of the 20th century. But then

1:41:18

they realized that it really can

1:41:20

be turned into an amazing tourist

1:41:22

destination. So they've

1:41:24

renovated it and rebuilt it

1:41:26

and it's just gorgeous. And

1:41:29

we stayed there in a hotel

1:41:31

that was like itself like kind

1:41:33

of half a cave and it's

1:41:36

really amazing. It's like nothing I've ever

1:41:38

seen and I highly recommend visiting there.

1:41:41

And if you do and you go

1:41:44

there, stay at the Querrie Resort. It

1:41:46

was an amazing hotel, just 12 rooms

1:41:49

and it's really amazing. So

1:41:52

that would be one place that's

1:41:55

really worth mentioning. And another one

1:41:57

is an even smaller town called

1:42:00

almost a village, somewhere between a village and

1:42:02

a town called Ostuni. It's,

1:42:04

again, it's a really old

1:42:07

place that's been lived in

1:42:09

for millennia, but the

1:42:11

current city was built in the Middle

1:42:13

Ages. It's kind of like inside effectively.

1:42:15

It's almost like a fort. It's,

1:42:19

the old city is surrounded by

1:42:21

walls. It's on the

1:42:23

top of a hill with like

1:42:26

these winding streets, and they're all

1:42:28

cobbled with staircases and whatnot. And

1:42:32

it's also called,

1:42:34

the Italians

1:42:36

call it the White

1:42:41

Town, because

1:42:43

the walls

1:42:45

are painted

1:42:47

white, and the

1:42:49

city really shines in

1:42:51

the sun. It's an amazing sight.

1:42:54

I highly recommend staying there. And

1:42:57

yeah, so these two places especially, but

1:42:59

in general, just take a vacation with

1:43:01

your spouse and have a good time

1:43:04

and work on that relationship. Life

1:43:08

can be hectic, and managing your mental

1:43:10

health is more important today than ever

1:43:12

before. That's why Mindful Therapy Group's mission

1:43:14

is to take the pain out of

1:43:16

finding a therapist. Whether you need talk

1:43:18

therapy, psychological testing, even medication management, Mindful

1:43:20

has you covered. Our mental health providers

1:43:22

are here for you, with both in-person

1:43:24

and telehealth options to get you seen

1:43:26

in as little as 48 hours. Mindful

1:43:29

Therapy Group also accepts insurance. Join

1:43:31

us to start your journey to

1:43:33

a healthier and happier you. Visit

1:43:35

mindfultherapygroup.com to get started today. So

1:43:38

that would be my first pick. My

1:43:40

second pick is I'm

1:43:42

having an interesting time following

1:43:45

along this whole kerfuffle, or

1:43:47

well, it's way more than a kerfuffle now.

1:43:51

It's a drama, I guess, in

1:43:53

the WordPress community between

1:43:56

Met Mullenweg. I

1:44:00

always forget how he pronounces his name, and

1:44:04

WP Engine. I

1:44:06

think it's like the first example that I

1:44:08

can think of an entire

1:44:11

company and its user

1:44:13

base and its contributions and

1:44:15

whatever being ejected, forcefully

1:44:18

ejected out of a large open

1:44:21

source community. It's really

1:44:24

quite amazing what's going on there.

1:44:26

And you know, if you like

1:44:28

the drama, then follow along. And

1:44:33

those are my picks for today. So

1:44:36

I'm gonna pile on there because over the

1:44:38

weekend, they actually went after Advanced Custom Fields

1:44:41

as well, which is a plugin for WordPress

1:44:43

that's pretty popular. They

1:44:45

took it over, I think. It was- Yes. It was-

1:44:47

They took it off of their, basically

1:44:50

their app store, I can't remember, it was called

1:44:52

plugin directory, and they put their own in. And

1:44:56

the funny thing is, if I understand

1:44:58

correctly, their justification for

1:45:00

doing it was that it had

1:45:02

security issues. What they

1:45:04

didn't say is that those

1:45:06

security issues were not being

1:45:08

fixed by the original developers

1:45:10

because those developers were affiliated

1:45:12

with WP Engine and were

1:45:14

ejected off of the WordPress

1:45:16

community. So- Oh, I didn't follow

1:45:19

that. I didn't realize that was the case, that it

1:45:21

had a tie into the other issue. So

1:45:24

my qualm with this whole set

1:45:26

of shenanigans is

1:45:30

not being a WordPress user, I

1:45:32

don't have anything to do

1:45:34

with the community, but just reading

1:45:36

about this and assuming what I

1:45:38

read was even remotely accurate, it's

1:45:41

not just that the plugin

1:45:43

in question was taken off

1:45:47

because of a security issue, or even

1:45:49

because of something irrelevant like being affiliated

1:45:52

with a company, it's that

1:45:54

it was forked and

1:45:56

the fork was served. from

1:46:00

the whatever

1:46:02

software repository that

1:46:05

serves the whole community. So this isn't

1:46:07

just a staff. They took control of

1:46:09

it. They basically took

1:46:11

their project away. So it's

1:46:14

not just that, which is again, not

1:46:17

fully understanding the details or the companies

1:46:19

involved. It's what I'm thinking

1:46:21

about is from the perspective of a user.

1:46:24

Imagine you're using macOS

1:46:26

or Ubuntu or whatever system you

1:46:29

use, there's a product you got

1:46:31

off the respective app store for

1:46:33

that. It would

1:46:36

be, especially in a commercial setting, which is

1:46:38

easier to explain because the outrage is a

1:46:40

lot more kind of obvious, is

1:46:43

imagine I'm using a Norton

1:46:46

Commander modern clone for macOS called

1:46:48

Marta, which I highly recommend,

1:46:50

by the way. No, I'm

1:46:53

paying for it happily. Now,

1:46:55

imagine if I bought that

1:46:57

off of the Apple Mac

1:46:59

store and then a

1:47:02

couple of years later, Apple just

1:47:04

decided not just to yank

1:47:06

it off the app store with some made

1:47:09

up claim, but replace

1:47:12

it with Marti, their own

1:47:14

version of Marta that was

1:47:16

forked without my

1:47:18

knowledge, consent, or

1:47:22

ignoring the commercial and

1:47:24

human shenanigans behind the scene. That

1:47:27

is effectively

1:47:29

a betrayal of trust

1:47:32

of whomever is running that

1:47:34

software repository that

1:47:36

I haven't yet seen many

1:47:38

people decrying, but

1:47:41

I would have expected them to

1:47:44

have them being users, not WP

1:47:46

Engine actual WordPress users. I

1:47:48

would have expected to hear

1:47:50

a lot of outrage over this. Because

1:47:55

that's taking it one step further than

1:47:57

the usual open source versus code. commercial

1:48:00

drama that we're kind of used to seeing at

1:48:02

this point. And that drama

1:48:04

is explainable. You know, the

1:48:06

whole red thing, the elastic thing, you can,

1:48:09

you can see where it's coming from. This,

1:48:11

this is the same drama with someone abusing

1:48:15

their, you

1:48:17

know, authority in a way that is

1:48:20

probably legal. I wouldn't know,

1:48:22

but is incredibly harmful

1:48:24

to the community around the product. Yeah.

1:48:28

I was just going to say, I saw the advanced

1:48:30

custom fields piece of things kind of unfolding on Saturday,

1:48:32

I want to say. So

1:48:36

it's entirely possible that the community comes around and

1:48:38

does what you're saying, right? Cause it's Monday morning,

1:48:40

but I don't know. Maybe

1:48:43

they won't. Whether

1:48:45

they do or not, we'll tell

1:48:47

you a lot about open source governance in the

1:48:50

coming years, I think. That's,

1:48:53

that's where I'm interested is. Hey,

1:48:57

okay. So what does this mean for anyone else? And

1:49:00

not, not necessarily that I'm

1:49:03

in communities where I anticipate this from anybody

1:49:05

who leads any of those communities, but the fact that

1:49:07

it can happen, you

1:49:11

have to at least think about it. So

1:49:13

did you see the checkbox that they put

1:49:16

on WordPress.org? Yeah.

1:49:18

That if you want to log in, you

1:49:21

have to certify that you're not affiliated with the website. That

1:49:24

you're not affiliated with WP engine

1:49:26

or something like that. No way.

1:49:28

Yes. That had happened. And

1:49:30

then like you said, Tomer, it's, it's also

1:49:32

not whether or not it's legal. This is

1:49:34

so toxic to the community. They

1:49:37

basically ejected WP engine

1:49:39

out of the WordPress community in a way that I've not

1:49:44

seen done in any other

1:49:46

open source project, like very

1:49:49

abruptly and very violently. Now

1:49:51

it might be justified like

1:49:54

Tomer. I don't have sufficient

1:49:56

context, but the fact that

1:49:58

it can be done. is

1:50:01

I would have been a lot

1:50:03

more at ease with even with

1:50:05

this whole bizzare kerfuffle between two

1:50:08

companies that are ostensibly complementary in

1:50:10

the market. Again, as an outside

1:50:12

observer, I don't actually know the

1:50:14

details, but I would have been

1:50:16

a lot more at ease if the

1:50:20

plug-in in question had been

1:50:22

removed from the software repository

1:50:24

because it had whatever. Even

1:50:27

if you use that excuse of

1:50:29

it had unpatched security vulnerabilities, fine.

1:50:32

That's at least a valid

1:50:34

excuse, but it wasn't yanked. It was

1:50:37

replaced with a fork, which

1:50:39

is not okay under

1:50:41

any... This is basically,

1:50:43

I as a user gave permission

1:50:45

to the tool chain around this

1:50:48

repository to install a certain piece

1:50:50

of software, assuming

1:50:53

certain characteristics of

1:50:55

the people running the show, both the

1:50:57

repository and the people writing the plug-in

1:51:00

based on their reputation. Suddenly,

1:51:02

not only does that go

1:51:04

away, but my authorization

1:51:08

to the tool chain to

1:51:11

do that on my behalf

1:51:13

is effectively usurped to support

1:51:16

a different effort by different

1:51:18

people that may or may not

1:51:20

have the reputation

1:51:22

or characteristics that I want or

1:51:24

that I agree to. That to

1:51:27

me is the really new thing

1:51:29

about this whole drama because everything

1:51:31

else is just the usual. Someone

1:51:34

did something good open

1:51:37

source wise. It succeeded. They built a

1:51:40

company around it. Someone else built a

1:51:42

different company with a different business model

1:51:44

that you could discuss

1:51:46

whether or not they're leveraging off of

1:51:48

someone else's work, but the point is

1:51:50

it's open source. If you didn't want

1:51:52

someone to leverage off your work on

1:51:55

their terms, you should have licensed

1:51:57

it not openly. that's

1:52:01

on whomever released

1:52:04

the software in the first place. And

1:52:06

again, that's not discounting moral arguments. But

1:52:11

this is not, my issue with

1:52:13

what automatic did is not a

1:52:15

moral argument. It is something

1:52:17

that not being a lawyer, I could

1:52:19

never say is, but should

1:52:22

be in the vicinity of

1:52:26

actually, you know, bordering on

1:52:28

anti-counseling. Like

1:52:30

this is people

1:52:32

that have signed a U-LOG, that have

1:52:35

worked under some assumptions and you

1:52:38

yank the carpet and replace it

1:52:40

under their feet. That should not

1:52:42

ever. The answer by the way

1:52:44

is that if WP Engine wants

1:52:46

to continue working with quote unquote

1:52:48

WordPress, they should create

1:52:52

their own fork. And

1:52:55

they probably will, because there's a business there,

1:52:57

otherwise they wouldn't be in the situation to

1:52:59

begin with. Yeah, I will also put out

1:53:01

there that whatever the beef

1:53:03

was, I remember looking at

1:53:06

it and I didn't understand

1:53:08

how, because WP Engine has been around

1:53:10

for years, years

1:53:12

and years and years and years, right? And

1:53:14

so I didn't understand that

1:53:17

the situation had changed at all to

1:53:20

prompt this, right? It was just out

1:53:22

of the blue from what I could tell. We should

1:53:24

just do an episode on it and then just talk

1:53:27

about what the issues are for us. Yeah, assuming we

1:53:29

have sufficient information. Yeah. It

1:53:31

certainly has an impact on the web if

1:53:33

for no other reason that a third

1:53:36

of websites on the web are

1:53:38

still WordPress websites. Not by traffic,

1:53:41

just by counting domains. Yeah,

1:53:43

but the other thing is, is a lot of people

1:53:45

use WordPress on the back end of their JavaScript

1:53:48

apps. Yeah,

1:53:50

it's gonna have an interesting to

1:53:52

track effect on a set

1:53:54

of second order effects in the industry.

1:53:57

If you really wanna see something that most

1:53:59

everyone ignores. But that is coming and is

1:54:01

gonna affect the web is the whole kerfuffle

1:54:03

with the IO domain. Oh Yeah,

1:54:06

that's a funny one You

1:54:09

heard about that Chuck No,

1:54:11

I haven't but right so we

1:54:13

would get into it another time. Yeah,

1:54:15

okay Just say

1:54:17

this, you know the IO domain like, you

1:54:20

know Google dot IO and stuff like that.

1:54:22

It's going away. Yeah Okay

1:54:27

Very simple and good reasons, but it's

1:54:29

gonna have a heck of a yeah,

1:54:31

that's gonna affect things. Yeah for sure

1:54:34

Like I know businesses are built on

1:54:36

dot IO domains that yeah Yeah,

1:54:40

all right. So well, so that's coming. Yeah

1:54:42

fun I'm gonna jump

1:54:45

in with my picks So

1:54:47

the game that I've been playing lately with

1:54:50

my friends is risk legacy. I'm pretty sure

1:54:52

I picked this before board

1:54:54

game geek has a weight on it of

1:54:57

two point five nine, which means that it's

1:54:59

pretty approachable for Casual

1:55:02

gamers is a little more complicated

1:55:04

than like settlers of Catan But

1:55:07

you can play it and it's not terribly hard

1:55:09

to pick up if you've played risk before It's

1:55:12

mostly risk with some twists We'll

1:55:15

just put it that way So yeah,

1:55:18

so I'm enjoying that And

1:55:22

Then real quick just a couple of other picks

1:55:24

I have been reading lately What's

1:55:27

this called it's right here on my desk It's

1:55:32

Awaken the Giant Within by Tony Robbins.

1:55:35

It is awesome. I'm really liking that and

1:55:37

so I'm gonna pick that I'm

1:55:39

also gonna encourage people to go out and vote. I

1:55:42

recognize that I don't know how you vote and

1:55:44

many of you will vote different from how I

1:55:46

vote but Do

1:55:49

your homework figure out who these people are

1:55:51

and make the best decision you can And

1:55:55

yeah, those are my picks oh one other thing And

1:55:58

this is kind of a self-doubt plug,

1:56:01

but I am working on putting together

1:56:03

a bootcamp starting in

1:56:05

January that will show people how to

1:56:07

build AI agents. I'm

1:56:09

going to have examples in Ruby and JavaScript. And

1:56:11

so if you're interested in that, stay tuned

1:56:14

because I'm going to put the sales page up soon.

1:56:16

Tomer, what are your

1:56:18

picks? So I mean, beyond the

1:56:20

whole thing with the IO country,

1:56:23

country code top level domain going

1:56:25

away, which is its own thing.

1:56:27

One, I

1:56:32

guess I would say pick is retro,

1:56:35

retro computing is awesome. On

1:56:38

a previous visit to Germany a couple weeks

1:56:40

ago, I got a TI 1994 a eight

1:56:42

bit computer from

1:56:45

1978 to add to my question the

1:56:47

first computer that I owned. By

1:56:50

the way, it was it had a 16 bit GPU

1:56:53

or something like that. Or

1:56:57

something like that. But anyway, it's

1:56:59

a very early computer. It

1:57:02

gets added to my collection. This

1:57:04

collection will be the seed to

1:57:06

a full blown interactive computer museum

1:57:08

in the north of

1:57:11

Israel when I retire

1:57:13

and or the war ends, whichever

1:57:15

happens first. Which

1:57:19

brings me to my last pick, which is don't be in a

1:57:21

war. It's not good for you. As

1:57:26

a plug, I just finished the

1:57:29

first iteration of and hammering

1:57:34

on a Prometheus workshop for

1:57:36

developers. So if anyone's interested

1:57:38

in that, it

1:57:42

will probably show up both as a commercial

1:57:44

offering, but I'll probably be running it in

1:57:47

some conferences in the foreseeable future. So if

1:57:50

there's any interest in that ping me and we'll

1:57:52

see what we can make happen. We should talk

1:57:54

about that, Tom, because I've done some done

1:57:57

quite a bit of research on the internet.

1:57:59

So I think that's a really good question.

1:58:01

bit of Prometheus development relatively recently and even

1:58:04

gave a talk or two about it. So

1:58:06

I'm sorry. We

1:58:09

had an episode where about

1:58:12

Prometheus. Everyone that uses

1:58:14

Prometheus has an episode sooner or later.

1:58:16

Don't worry about it. All

1:58:21

right. Well, we'll go ahead and wrap it up here. Uh,

1:58:23

thanks for coming, Tomer. Sure. It's been

1:58:25

a pleasure. All

1:58:27

right. Uh, thanks for, thanks for opposing

1:58:30

some of my opinions. It's always better

1:58:32

when there's a, you know, some

1:58:34

back and forth. And until next time folks, Max

1:58:37

out.