Future of Coding - Considered Harmful

Episode Date: September 29, 2023

Go To Statement Considered Harmful is a solid classic entry in the X Considered Harmful metafiction genre, authored by renowned computer scientist and idiosyncratic grump, Edsger Wybe Dijkstra. Surprisingly (given the impact it's had) this is a minuscule speck of a paper, lasting only 1-ish pages, and it even digresses several times from the main point. Fear not! Jimmy and I spend the entirety of these two podcast hours thoroughly analyzing the paper, wringing every last drop of insight from it, speaking directly to how programming ought to be reimagined from the molten venture capital core on up. Yes indeed, this is another episode in the fine tradition of Future of Coding where we stay faithfully close to the text, we leave the second-order implications alone, and there's nothing more than that. Nothing portended, nothing changed. Links => patreon.com/futureofcoding Hest, which Jimmy is convinced that I refuse to call by name, or even talk about. He's clearly mistaken — and yet, I feel his philosophical force on my hand even now. Conundrum considered harmful. "All Cretans are liars" doesn't have quite the ring of "dipping their breasts into the ripper", and is considered harmful. Dijkstra's The Humble Programmer considered harmful. Hoare's The Emperor's Old Clothes considered harmful. Letter O Considered Harmful considered harmful. “Considered Harmful” Essays Considered Harmful considered harmful! Scolds! James while John had had had had had had had had had had had a better effect on the teacher considered considered considered considered considered considered considered considered harmful. Proximity to Chomsky considered harmful. Interlisp, an early lisp featuring the ] super paren, considered harmful. The opening segment of the "I Want to Half-Believe" episode of Very Bad Wizards considered harmful. The Witness considered harmful to our show notes. Delimited Continuations considered harmful. Notation as a Tool of Thought by "Kenneth E. Iverson considered harmful." The Zen of Python considered a great honking idea. Chunky Bacon considered harmful. Copilot considered harmful. Charles Babbage's Bridgewater Treatises considered harmful. North & Whitehead's Principia Mathematica considered harmful. The Sailor's Chorus from Wagner's The Flying Dutchman considered harmful. PEP 8 considered harmful. There are dozens of us considered harmful. TC39 actually considered harmful. Bifunctors considered harmful. Chocolate Radiolab considered one of the only good radio shows, because it's pushing hard against the norms of its medium. UBI — consider it! Forking The Queen considered harmful. The Semantics of Graphical Languages, the paper about a visual formalism for visual programs, considered harmful. Music featured in this episode: Lemon Wagner Lu, Devine, William, Alex and Alex, Justin, Marcel, Peter, Matt, Blaine, Kevin, Nicki, Mae, Kate, Steve, Mitja, Philippa, Max, and everyone else who secretly said it like a swearword. Get in touch, ask questions, don't ask questions: Ivan: Mastodon • Email Jimmy: Mastodon • Twitter DM us in the FoC Slack Support the show on Patreon https://futureofcoding.org/episodes/067Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

I'm doing the thing that I do every time we have one of these wildly digressive nonsense opening conversations where I go, is any of this usable? I think it is. Is any of this, is there anything in here that I can salvage as like, yeah, this is exciting and interesting and relevant. And if it's not, you can just cut right here and get rid of all of that uninteresting, irrelevant conversation. And we just dive in to go to Considered Harmful. Let's.

I even said dive in. Yes, you did. I need to stop. i've stopped actually putting the little bit in the thing yeah yeah because i say it too much well and also because it's like if you can invoke it on command then that takes the power away from me then it's like jimmy knows that if uh when he does the splits the band has to hit a little stab i like playing with that because then i can make you not do the edits that you might want to do because i can try to like predict them like if i say like you might be tempted right there to put the like hest censored sound but you can't now because i just mentioned that you would

do it are you a cretin or are you a liar yeah all right uh it's considered harmful dykstra um uh-huh why are we doing considered harmful eggs eggs good dykstra you know so okay this is a paper that like maybe i have like kind of this original big list of papers that we could do and this did make my list but it kind of made it as a like anthology of all the dykstra things right because like dykstra doesn't write like big long papers. We got like the humble programmer and go to considered harmful Dykstra. I had one other one in here, I thought, but those are at least two.

I thought like, okay, this is good. And kind of like more like advice column sort of papers, right? Like there's the emperor's old clothes by C.A.R. Hoare as well, which is also like a Turing acceptance i think the humble programmer is as well i think it is useful to like look back at advice that people have given us the way they conceptualize usually when they're giving advice they're talking about the future

in some way they're giving they're conceptualizing how they see the programming space uh but go to consider harmful is a little different it's it's this very short paper right we're looking at like two columns here on one page and then like half a page of one call like half a column i don't know how to say this uh one page one column but it's half the column yeah if you didn't have all this formatting shenanigans it'd be like a page of text it's like a one pager yeah yeah it's it's pretty darn small in fact that i did learn the title was not even dykstra's title um it's like a note on go to or something like that was all he wrote it but the editor changed it to go to considered harmful it's good dykstra. Oh, which is, is interesting. And apparently the considered

harmful thing, uh, predates Dykstra, but it was, you know, popularized by this paper and the tech world, but you know, it's very, it's very constrained paper. It is just about a programming language feature. It's just about go to with some little Dykstra isms, you know, making fun of people every once in a while, which is like what he does. But I thought it would be fun to do this paper. One, it's a short paper, and we haven't done anything anywhere near this short. Two, like it kind of, you know,

lets us have our own opinions on what's harmful. And if any paper influenced the future of programming more than GoTo considered harmful, Dykstra, I'm not sure which paper it would be. Okay, back that up. So in what ways did GoToConsideredHarmful, which the actual, the full title thereof is? GoToStatementConsideredHarmful. Full title thereof is... Go-to statement considered harmful. Oh, I thought it had a longer... Oh, it's just go-to statement considered harmful.

I thought there was a longer title. In a way that sounds like a swear word. I can say it in the Dutch way. Yes. Het is gedijkstra. So, go-to expression, totally fine. Yeah, I was going to say, you could it's, you could just say statement considered harmful. I'd be perfectly happy with that paper.

A go-to expression has to return the value. So I actually have to jump ahead slightly. Uh-huh so the the the thesis for this episode of the podcast is that jimmy and i have our own lists of considered harmful that we're going to bring that's good dice girl and um one of mine i don't have them numbered but let's say it's number 36 is uh statements considered harmful dykstra that itself was a statement. I don't mean that meaning of statement. I mean a very specific meaning of statement. Yeah, that should have made my list.

I would agree with that one. But yeah, so go-to statement, considered harmful. Dykstra. You'll get all sorts of ones. I tried to look and see if there were any, like, really good ones we should throw in in this episode, other considered harmful essays. Dykstra. The letter O other considered harmful essays the letter o considered harmful was an obvious uh suggestion because it supersedes go to considered

harmful because you can't write go to if you don't have the letter o so you don't even need go to considered harmful so i thought that one was good it's obviously a satire of the considered harmful genre and then there's considered harmful, considered harmful. I just didn't like it. I want to be honest. It felt, I would agree almost potentially, even though we're doing this, with the statement considered harmful, essays considered harmful. But the way they defended it just felt very off to me. Very wrong.

Yeah, it's entirely possible that another one of my considered harmful is a rebuttal to the considered harmful considered harmful. Ed's got f***ing dystra. Okay, gotcha. Considered harmful, considered harmful, considered harmful. Ed's got f***ing dystra. Well, not quite so elegantly put. But yes, something to that effect yes okay that one is another one of the the hits of the considered harmful genre

it's good dice i'll just add in mine that was james well john had had had had had had had had had had a better effect on the teacher, considered harmful? Dykstra. Anything you do that brings you closer to Chomsky, considered harmful? Dykstra. Language considered harmful? Dykstra. Oh, actually, that would be a good one for me, because I'm often ragging on the use of the word language to describe things that should probably be called systems,

or maybe the word language, we need to take that back and have it be broader than, than people usually, what people usually mean when they use that word. Yeah, I've been reading a bunch of neo-American pragmatists on language and you would probably like some of that stuff. But I'm trying to read neo ones to get rid of all the bad stuff, like the instrumental version of truth and all that garbage um you like the version with lyrics the version of truth with lyrics yes i i actually do i'm not a big instrumental music fan i listen to it occasionally if i need to focus and want to cut out background noise but other than that it's just not my jam all right well as the jam boy of this show you uh you get to say what what jams are are most jammable uh-huh yeah i'm also not a jam fan you're not a fan of jam bands uh-huh yes that's definitely what i mean i like the occasional jam i really like fig jam i think fig jam is really good even though i'm not that big

of a fan of figs me neither yeah yeah but fig jam is tasty for some reason so go to consider time for man that hurts having so many stacks of tangent popped all at once it's just like such a such a strange feeling to like close so many parentheses all at once. That's gross. Anybody who would close so many parentheses all at once is using a terrible language. Uh-huh, yes. That lacks a go-to statement. Mm-hmm, yeah.

That's a way out of unbalanced parens. Just go to somewhere else in the program where the parens are balanced. You know early Lisps, you didn't have to close the parens. Oh, cool. Yeah, they just assumed that you could do the super paren. Hmm. What? Yeah, yeah.

Really? I can't remember which early lisp, but there's an early lisp that has a super closing paren, and it just closes all the parens above it. That's amazing. Yeah. That's very good. I like that.

No problems, no notes. Yeah, it's like HTML and not closing your tags. I was about to say, I am an advocate of don't close your HTML tags. That is the least surprising thing I've ever heard you say. I mean, I don't... That's just your vibe. I also, I don't open body. Like, my HTML of choice doesn't open body,

because as soon as you hit an HTML element that is not valid for the head, the parser will just assume, okay, we're in body now, so. Yeah, I can just imagine you, like, if I had to apply stereotypes to you, that would be one. Does not close HTML tags.

Just a picture of you, and that's various statements you, that would be one. Does not close HTML tags. Just a picture of you and various statements around, that would be one. I'll give you another HTML quick tip. Title that you put in your head to be like, this is the thing that shows up in my tab bar. Go into your style sheet and set display block, like title display block. And then you've got double duty. You've got something that sets the tab bar and shows up as the title of your page, two in one,

very efficient HTML writing right there. More hot HTML tips from this super Peren fan incoming. Considered harmful. Ivan's HTML advice. Adding that to the list. Yeah.

So I do want to cover the paper a little bit, not just jump into our considered harmful. Cool. I'll go make a coffee and you talk about this very short paper. I mean, okay. I said that I think it's probably one of the most influential papers on the future of programming and i think that's actually probably true maybe it was just a coincidence maybe this didn't have the influence but i mean it's a very well-known paper i think

it does right this is ultimately this paper is an argument for structured programming which is what every language since this paper came out has been. I don't actually know what year this paper is. 68. 68. It's at the bottom of the paper. Yep. 1968.

I mean, every language since then has been a structured programming language. And by this we mean has if statements and procedures or functions or things like this instead of go to as like kind of the main organizational structure i'm gonna say every good language that has come out since 1968 because there's you know malborge and brain yeah yeah yeah every every language that's intended to be higher level than like machine code and and is not a an s-o-lang yeah it's not a practical joke there's a reason s-o-langs like go to intercal though also did not have go to which you know i considered a reference to this paper for sure like the dimension of like it doesn't have it which is why we have to do it because anytime we do a work that references some other work, we have to eventually do the work that was referenced.

That's happened so much. Wow, we have a lot of works to do. Yeah, but we got a lot of episodes yet to come. Back us on Patreon to ensure the future of this podcast. Yes. Patreon.com slash future of coding. All right. So this is this argument, and we get a lot of, like, Dykstra-isms in this

because it's not just an argument. It's also making fun of people, which if you've read any Dykstra, that's what he does. Half of it is just him dunking on somebody, even if they're not directly named or, like, this person. It's just like, you know, like the paper starts out, which is like a note to the editor or whatever for a number of years i have been familiar with the observation

that the quality of programmers is a decreasing function of the density of go-to statements and the programs they produce burned anybody who uses go-tos the more go-tos you use the worse you are the worse you are and and he ultimately says that like he's convinced that you shouldn't have go-to's the more go-to's you use the worse you are the worse you are and and he ultimately says that like he's convinced that you shouldn't have go-to's in anything except for plain old machine code i think that's probably false uh but i could modify it a little bit to say anything that humans are supposed to write other than machine code because like i have intermediate representations of my compilers that use a go-to statement, because they should, because that's a good idea.

Was this before the time that intermediate representations would have been a thing? I mean, this is 68. I feel like there had to have been an intermediate representation in some lisp. I wonder if that's what, if you're thinking of high level versus machine code is kind of like the two ends yeah yeah i guess that's true they probably

did just compile straight from yeah they probably did like and i mean i think he still would have accepted that caveat yes exactly yep the rest of the argument is about how this becomes difficult to reason about. Oh, I have to put money in the swear jar? Oh yeah, right. The reason about swear jar. I almost forgot that that existed. It didn't have a little stinger sound effect, and so it hasn't been burned into my editor subconscious.

And I feel like there's some bits in here that either you're going to dislike or absolutely love uh oh i think i think you know well okay so there's some things that are just like so awkwardly worded that i don't even want to read them because i know i'm going to be like how do you do this like there's this whole remark about... Which one? I'll read it. I'll read it. Which one?

Okay, read it. My first remark. It is the second paragraph. Do you want me to read the whole second paragraph or just that sentence? That sentence goes on for most of the whole paragraph. Okay. Let's see if I can do this in one without laughing. Okay. My first remark is that

although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity. For it is this process that has to accomplish the desired effect. It is this process that in its dynamic behavior has to satisfy the desired specifications. Yet this process that in its dynamic behavior has to satisfy the desired specifications yet once the program has been made the making of the corresponding process

is delegated to the machine look at you got it in one perfect i retire undefeated that that is such a hard sentence or two i guess to parse okay you don't think so i i mean i just read it perfectly on my first try so yeah you read it perfectly but what does it mean i haven't explained it for us it's it's basically saying that there's a divide between when you are authoring the source text and then when the program executes and that in that divide there's going to be some interesting things to consider and that's what the next paragraph begins to explore and i actually quite quite like the next paragraph so see that's what i thought you would i think you would quite like this yeah this next sentence should i jump ahead to this next paragraph did you have more to say about this weird no no that's fine yeah i

think i just wanted to kind of get us into you know what his argument is okay cool so let's jump ahead um it's the literal next sentence let's jump ahead let's go to paragraph two i mean implicitly every sequential statement that executes in order is like an implicit go-to to the next statement after that. So it's one of those things where in some languages, some things are implicit and some languages they're explicit and generally. No, you have an explicit go-to in most languages. It's the semicolon operator. What about like an opening curly brace or uh or the the warm embrace of an opening paren with no super paren to come and shut down your part yeah yeah yeah um is there an opening super paren no because that doesn't make sense no it totally does because then it would be you

could put as many closing parens as you want and they would be balanced against the opening super paren but you would you couldn't have nested things why not because you wouldn't know how they nest well it's it's you would just assume like you'd you'd say like max int is my level of nesting and then every closing paren i get is decrementing the the level of nesting but where does the start of each of the levels of nesting i have plus i have super paren plus two three times five seven three nine minus four three two one in three end parentheses you want me to do this in my head you want me to write lisp in my head my My point is you can't. It's ambiguous.

There's no way to know. Okay, hold on a second. Hold on a second. Let's go into tldraw. This is going to be important. You're going to make this tangent on a point you know is wrong. All right. So it's going to be, let's say, plus one, two, and then we're going to close that.

And then it's going to be oh yeah because you don't have you don't have the ability to introduce any new function in that first position exactly as soon as you close okay right right right now i see what you're saying i had to look at it because okay okay okay my second remark you weren't just being obstinate for fun okay is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For this reason, we should do, as wise programmers aware of our limitations, our utmost to shorten the conceptual gap between the static program and the dynamic process to make the correspondence between the program spread out in text space and the process spread out in time as trivial as possible. And by extension, if you want me to write Lisp in my

head, you know, that's folly. We should write Lisp on paper so I can actually look at the, oh yeah, that's broken. Well, that's a static process of text, but yet this, I think, is a quite succinct little argument here for visual programming. Or at the very least, the design of good quality representations. Yeah. And that, you know, you need something to make up for the fact that, yeah, computer execution is a process in time. And that we need something that we can look at and react against in order to understand that evolving process just trying to do it in our heads is you know it's it's doable up to a certain limit and then you very quickly run into well i'm just visualizing

something and i have no way of knowing if i'm visualizing the right thing or not yeah or you're visualizing nothing because you're me. And it's always wrong because not nothing is happening. Is it actually nothing or is it just something nebulous? How does that describe? I can occasionally conjure up something nebulous with great effort but for the most and when i'm when i'm in a certain like lucid dream state i can actually visualize something but in general i do not have okay i do not have like any internal vision in my head i thought you were

gonna say world but i also can't recreate sounds other than my voice like if i think of like a trumpet playing it's me playing making trumpet noises not a trumpet in your voice yeah yeah yeah like i can't i can't actually hear reproduced sounds what and that includes like say like somebody's voice talking or singing or something like that? Yeah. I cannot imagine anyone's voice other than me doing an impression of somebody who's Morgan Freeman or something. Did you catch the most recent Very Bad Wizards, where they do a survey about things you can picture mentally? Yes, yes. And I went and did that little thing. And I am on the very far spectrum of can't,

like 99 percentile or something. Now I want to go do it, because I haven't done it. Yeah, Janice and I went and did that. It's a fun little survey for people who didn't listen to Very Very Well, which is a survey asking you a bunch of questions about your mental life. Do you have an internal monologue? How do you picture things? And it's kind of mental life. Do you have an internal monologue? How do you picture things? And it's kind of putting you on the spectrum

of how well you visualize things, how much you have an internal monologue. And it turns out that one of the hosts of Very Bad Wizards does not have an internal monologue when he thought he did the whole time. He misunderstood what people meant by an internal monologue, meaning they hear language in their head, not just they have thoughts, right? I do have an internal monologue meaning they hear language in their head not just they have thoughts right i do have an internal monologue um but i do not have any visual components whatsoever to my thoughts now i can't find the link to the thing to do the thing

yeah it takes a little bit of time i don't think we need to do it on the podcast here um you may not think that we need to this is very bad wizards uh copy like we're just gonna do every reading they do from now on that would be a hilarious podcast idea just find a popular podcast and make a like non-parody copy of it yeah yeah or just like do their topic every time yeah yeah yeah like we're the the very very bad wizards yes yes in some sense we're like a like a the witness review podcast in that every episode we end up reviewing the witness i've mentioned it a few times i'll i've i've put that on my i can't mention it list now uh okay wait where's that list it is the witness considered harmful dykstra

do you actually have a list no it's just in my head ah but you don't have anything in your head we just established that i have things in my head i don't have images i think this might be why you're opposed to the idea of thought stuff is that you don't have thought stuff is that other people have something that they appreciate as like this is a difference between my inner world and my outer world and you exist in a pure outer world like you're the most present in the moment i think i understand i think i understand correctly i don't think i'm wrong i have found that people will would make mistakes

in programs and i wouldn't understand how they were making the mistake they were making like it just didn't i couldn't you know recreate the process of like why do you think this is true when it's clearly false and i eventually realized it was a visual metaphor that they were like it would be like a concurrent process or something and they were visualizing a representation of the program and that visual metaphor was not quite accurate and so they were like concluding certain things based on using that heuristic and so like i was like oh and i've learned like when people are doing that i can figure it out and be like oh you're visualizing it this way aren't you and they're like yes and so this follows and i'm like yeah no that's that's not how it works right like here's the problem with that visual metaphor

but it took me so long to realize like oh this is where because usually i can like kind of you know see the flaws in reasoning but it was all on this metaphor of visualizing it so i do have i probably have different kinds of errors i get to by not being able to visualize things that other people have shortcuts for i think the biggest error is that you're still like you're building a text editor instead of building a visual programming environment. When really, of all the people who should be building a visual programming environment. Or am I doing both? Do you have a text cursor in your programming environment?

Then it is not visual programming. Not. I only have a plugin that happens to have text. In the actual code base proper, there is no notion of a text editor. So one of my widgets in my system has text. One of the generals in my army happens to commit abuses of human rights,

but that's one of my generals. It's not my army. My army doesn't commit abuses of human rights, but that's one of my generals. It's not my army. My army doesn't commit abuses of human rights. You would agree that any good visual programming language should be, or any, sorry, not good, any general purpose visual programming language should be able to express a text editor, right? Not the good ones.

Yeah, but any general purpose one should be able to. So I'm just building up to that. Eventually you'll build a whole thing out of, no,'m not but i still do think uh there's something good between text and graphics like i think you have to marry the two together and i do want to do that yeah yeah where the hell are we so we kind of stayed on topic ish uh you know visual programming we got right back to it right like if you want the it says that there should be this correspondence between text and the execution and it should be as trivial as possible the most trivial is they're identical um so i'm just

putting it out there that that would make sense but like then we get this like we go from these two kind of high level things and then we get this like i, we go from these two kind of high-level things, and then we get this, like, I don't know, this weird formalism in my mind. Nah, I dig it. It doesn't, on the first read, I was like, okay, where's this going to go? But I, you know, by the end of it, it's like, no, this makes sense. I dig this. I mean, it all makes sense.

It's like, how do you know where you are in a program is really all that is being asked here right and but the way it's being asked is just a little i don't know it's a little obtuse but i guess you need to do this especially at the time because like there's just a kind of a more formal attitude towards all of these things but the basic idea is like there needs to be some coordinate system of where we are in our program and the question is how much information do we need to situate ourselves in that program and know where we are yeah and also where does that information come from is it static information that you can tell just from the artifact of the source text or does it also depend on the execution of the program? Exactly.

And as soon as you add goto, I think one of the things I never appreciated about goto, not using languages that had them, is when you have a goto, the state of your variables is even a big question. Because there isn't this like lexical scope like i was like i always thought of go to as like and now i'm going to a new lexical scope it's just calling a function but without a return or something it's like no like you're going to

things and the state of your variables just are what they are and good luck and am I correct in understanding that a go-to, you are jumping to a specific place in the program based on the evaluation? Like you're specifying like go to this address, but the address is not a static address. It's a dynamic address. It could be either. Right. You can have a go-to label.

Yes. And label is just going to be a static address, but you could also have a go to this pointer yes exactly yeah my dog's asking to go out okay lemon break Thank you. She's outside laying down in the grass and then is going to ask to come back in. But if I try to make her come back in right now, then she's just going to keep going outside to lay down in the grass over and over again until i let her stay out so it's like a lose-lose situation that's okay i i don't mind the lemon breaks the lemon breaks they give me an opportunity to plug our patreon uh so yeah, this go-to makes, like, I think it makes every program harder to actually figure out, like, what's going on, right? Because you don't know the state of your variables.

In order to know what the behavior of your program is, you have to know its past execution. You have to know something about the dynamic properties of this thing. And so as you're reading code, you have to imagine all the possible ways you could have gotten to this point in order to really know what it's doing. And none of that information is local. Anybody anywhere could have done a go-to to your bit of code. And so you'll never really know

what is possible in your program and if you have something like a more structured system this if statement or whatever it becomes very easy and direct what is happening here yes you depend on some local variables or global variables that are referred here but the action is not at a distance right it's action that's

immediate right in your program yeah yeah and i mean it's a short paper right like it's i mean this is really about it right it's so we got i'll read two little statements here to kind of summarize i think what his points are the unbridled use of the go-to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress and then the go-to statement as it stands is just too primitive it is too much an invitation to make a mess of one's program. it's it's become a meme but it's a meme that uh like people accept the the truth of it or the or at least they accept it at at face value like i don't know that there's a a um like a contrarian you know movement out there that's saying actually go to is great let's bring it back

and even languages i guess like i said every language didn't have it but c was after this and it has a go-to statement but it's used so rarely all right it is you're not going to find many go-tos in standard c code uh i have seen them and they're you know very particular uses usually with comments on why they needed a go-to in this example i was looking at like the dtrace source code and that was one i found the one go-to i think in the d trace source code that was the process of debugging some really complicated thing and it was like this this is the best way to deal with this weird case here but you know it's a very non-standard practice that would be something that i I am in no way prepared to imagine, but it would be cool to hear somebody justify, like, here is a case where go-to is actually the most elegant thing, and here's why.

Because I haven't the foggiest. I mean, have you ever thrown an exception? Sure. They're just go-tos. Okay. They're a little bit more constrained. Yeah, no, they have a whole heap of semantics around them. Like, I don't think you can catch a go-to.

No, so what you're doing with a throw is you're saying, go to nearest catch statement. You're saying, stop the sequential execution of my program and go potentially in levels nested high that I have this catch statement. But the structure of catch statements is based on the stack that you had to build up in order to get to the point where the exception was thrown.

It's a dynamic process. It depends on how your code was run. I don't think so. I think it's as static as function calls. This is just sort of like an early return, but that it's like a super return, because you may not return just one level. You may return several levels.

No, you don't return at all. You don't return a value. Well, you return the exception. No, you throw the exception, right? There's a reason it's like throwing it out there. And if your code was called from different contexts, it will have different effects. But you're returning to the calling context when you do a throw.

Which calling context? Not the function that immediately called you not the function above them it it all depends on where in the stack of things an exception handler was registered you're returning to the nearest compatible exception handler yeah and so it's a dynamic property of how my code was called i have to know the history of the calling patterns to know where it was, where it's going to go. But that's no different than saying if I'm in some function, like before the exception was thrown, how I got to that function is a consequence of the dynamic process of the code's execution. Well, no. I know when I return that it is going to go to the immediate caller.

I might not know who the immediate caller is, but I know it's going to go to the immediate caller. And when I throw an exception, it's going to go to one of the higher stack frames. Or just break. But with go to, it could go to conceivably any place. It is more constrained. It is more constrained. But if you try to do the kind of analysis that somebody like Dykstra would want to do, there's a reason why like functional systems and things get rid of these is because they don't make pure functions, right?

Because you don't return something. And so like things get more complicated right because not only are you so like yes one you're returning to a random place but also the the caller of you all of the code underneath them underneath the call to you is not going to be run right so you have no guarantee that's why you have to have finally so that you could have nested scopes of these things so that you could run cleanup code in case somebody threw underneath you because now you won't do your cleanup. But that to me is no different than like you call some function and then you return a value from that function. And then after, you know, in the parent context, in the calling context, after you get that return value, you have some if that's like, if the value that I returned is, you know, the token representing an error, then do an early return. Oh, it's very different.

Imagine you have this, a bit of code, okay? So it's A equals some constant value, B equals a function call, right? C equals A plus B. And then I print out the result. I print out C. In a language without exceptions, you can look at that code, and let's assume it's typed, right, for a second. In a language without exceptions that's typed, you can look at that code, and let's assume it's typed, right, for a second. A language without exceptions is typed. You can know exactly what kind of result is going to happen. It's going to print some integer.

In a language with exceptions, you have no idea. Well, if it's typed, then the fact that the call can return an exception has to be part of the type. No. Otherwise, it's not a well-typed language. Most languages with exceptions don't all make a typed exception.

In fact, it's considered bad form to do so. Java does, but you can actually escape that, because you just declare your function also throws. What language are you thinking of with exceptions uh i'm thinking of a hypothetical language where the exceptions are actually well

done that's the problem is like well they're not exceptions you're thinking of return values you're thinking of result types you're thinking of algebraic data types that i'm thinking of like super returns super returns where it's like, this function may return normally or it may super return some more powerful returnable thing. Or it returns a result type that is either okay or error, right? That's the new style of doing this. Well, no, because it breaks the idea of a return only going up one level of the stack.

This is something where it's like, it will keep going up until it... Do you see the point that you can try to... Let's say maybe you have in your mind an engineered system around it. That's fine. Maybe there is some way of making it work.

But if you don't have that engineered system around it, you can see how adding exceptions without some other thing constraining them even more makes it so that they're a mini form of go-to totally yes yes and in fact they require one of your things they require statements exceptions throw is a statement yes i don't think i can quibble with that. That makes sense. Yeah. Yep.

So that's what all of these things are interrelated, right? And so there's a reason a lot of more modern languages are not having exceptions. Because the reason I know that they're basically go-tos is that's how you have to implement them. Mr. Compiler Engineer over here knows how to actually build these things behind the scenes.

They're difficult, right? Or you can implement them as delimited continuations. Delimited continuations are a great way to automatically do exception handling. You could see them as a better form of go-to, because you can go to a point of execution with the variables intact. We probably will never do a paper on delimited continuations because that will make awful radio. I really just can't imagine that it will be good.

If somebody has a paper, they're like, no, this is a very high-level delimited continuation paper that just talks about the benefits. Maybe, but doubtful. I think this is actually an interesting point which is that it's hard for us to do works that require a lot of visualization in order to appreciate the ideas and i think something like delimited continuations would be great if this were like a video essay or something like that where we could have like graphics on the screen and examples that we could refer to and because there's going to be a lot of context needed to kind of understand the examples that we would need to give yeah and yeah this is just not a

good format for that sort of thing as opposed opposed to looser ideas about, you know, what should happen in the culture or reflections on some work in terms of, you know, how does it make us feel that sort of thing? That's that's much more amenable to this format where not looking at something is actually a benefit if you're talking about feelings. Yeah, like notations as a tool for thought by my brain doesn't let me remember. That's weird citation. Put that in Bibtex. Is a great example of like a paper that would be an obvious choice for this podcast. In some ways, it's a seminal paper. It's, you know, about programming, blah, blah, blah.

But it's literally about notation. And like, we can't show that notation and so like what are we going to do just describe it every time that kind of like defeats the purpose so it's definitely one of those things where you can't just pick like all of the canonical papers and be like that works in this format which is a shame because the yeah it's a lot of the things that i'm most passionate about are the things that least lend themselves to this audio medium so that is our curse that is our burden as podcasters future of coding okay so we've gotten into like there are other forms

of go-to uh that are more constrained like exceptions which was i i think probably their goal like sometimes you want to exit out of a program and go to some other place in it but you want it to be more constrained than go-tos uh but i'm curious on the non-go-to topics like we got our lists of considered harmful it's good dice i asked like three times if i've been once to share them and he just ignored me every single time and never replied once. Definitely didn't say he didn't care. But he definitely didn't share his list. So I have no idea what's on Ivan's list. And I have no idea what's on Jimmy's list.

Mine are not. I don't know. I'll admit, I kind of struggled with this in some ways. Mostly because I think all my takes are boring. Yeah, me too. This is going to be so good. Right? This is going to be excellent content.

But at the same time, I realized every take I have, a lot of people disagree with it. And so maybe I just find it boring because I've had these takes for so long. Yeah. Well, let's try a couple of them and see how they go down i can start because my first one is very i actually have two that i would pair together but they're very similar to the arguments for go to considered harmful extra and i think they kind of go hand in hand which is dependency injection which people absolutely love uh dependency injectionency injection, considered harmful.

Dykstra. And I have kind of coupled with that interfaces in business apps, considered harmful. Doofus. Cool. This is good. So first, I think that the thing that you need to do is define dependency injection so that we know exactly what flavor of that you are thinking about so when you like have those dependencies and you inject them in that part yeah but i mean like is it just the

like oh hey this thing that i'm depending on is being passed into me so that i don't have to reach out and get it from you know import it from some other module or something. It's part of my, you know, initialization as you pass in the thing I need. Or is it the automation of that where it's like, oh, we look at what you're taking and then we figure out what to give you based on that. Aha. So this is part of why I put this one is like,

one, I don't think anyone actually ever has a clear definition of dependency injection. And everyone, people will be like, if you think dependency injection is bad, then you can't pass arguments to your function. And it's like, no, that's not what I meant. Like, yes, I understand that passing arguments, quote unquote, is injecting a dependency but like i think really what this gets down to is dependencies when you're talking about dependency injections are like non-value objects almost every time they're things that hold on to state they're a service that is provided and they're being passed in instead of being explicitly created in the place they're used so that you can change out functionality.

So why I say this is related to GoTo, that means you have no idea what your program actually does unless you know some history of the execution. This is some dependency that might do something at some point somewhere. And when you try to figure out what it's doing, you always have to be like, ah, what thing is this? Right? Does it go in right to my log system? Does it go and do this thing? Is this in the scope of my bug that I need to go pay attention to this because it can change these things. And at the point of your program, you never know what it's doing. And I think this is very related to interfaces and business apps, because almost always the reason people make interfaces is so they can

dependency inject, and then they end up making one implementation of that interface. And then every single time you have to be like, wait, there's only one implementation of that interface. So I know exactly what it's doing. But for some reason, it's on an interface boundary. And it's trying to deal with code that's written this way is just so incredibly frustrating to me and people will come up with cool uses of dependency injection and will tell me like dependency injection is great and like i get it of course there are uses of course there are cases where it's good just like there are cases where go to is good but it should be considered harmful thanks you should stop doing it and if i have to read code that's like that ever again i just like i've refactored code

out like that and it's just like for me personally because i know it'll never be approved and then i'm like ah this code is readable again it's so nice so you're you're more of a fan of just have no module boundaries just put everything on uh like in a single global namespace and uh inside your function if you need something you just reach out and grab it that's your that is uh well i don't think i don't see how namespaces are related to dependency action i can have i can namespace things i'm being facetious jimmy i know but if you just take off that word then i agree oh okay right like if you just say namespace things well and then if you need something just get them i'm like yeah i'm all for it right the only thing that i didn't like in that statement was namespaces. Okay. All right.

Or the suggestion that we remove namespaces. Oh, hold on. Yeah. I have a new one. All right. On my list. Namespaces. So you just reminded me. Considered.

No, no. Super good. Namespaces are a great honking idea. Namespaces rule. From the Zen of Python. Great honking idea. We should do more of them. Oh, okay.

Chunky bacon. The Zen of python is the best not considered harmful the zen of python dexter fantastic it's my favorite state like short little statement of how you ought to program i i haven't actually written any python um just because i refuse to use white space languages uh that's fine so in your terminal type in either python or python 3 whichever it's probably python 3 and then import space this oh cute so you get a little poem and this is kind of the guide of how they like to design things in python and the last line is namespaces are one honking great idea let's do more of those

I think I've actually read this before even if you don't like Python it's just great advice alright those are mine I will stand but I worked at a job so just to be clear I've written lots of dependency injection framework I even have in my little 100 lines or less repo I have a Java dependency injection

automagical figure out based on the type what things should be injected framework in 100 lines or less, which was really enlightening. It's like 30 lines or something, even in Java. I've written a lot of applications this way. I understand how to use it. I understand why you would use it.

I still hate it. It's awful. Don't do it. Considered harmful. Dextra! You heard it here. My starting one. Visual programming considered harmful you heard it here my uh my starting one uh visual programming considered harmful it's a wee bit dykstra this should come as no surprise to anybody who knows me and my

particular proclivities um that visual programming this is going to be real short jimmy's was was nice and substantial mine is very simple um i don't think there's been a single good visual programming system yet i think they are all terrible and i think that the problem with that is that it has led a lot of people to say visual programming is terrible and there has not been a single good one yet and the unfortunate consequence of that is that they say it as a way of discouraging people from trying to explore visual programming further. And that's a bad thing. I think, yeah, I think we should be exploring visual programming more because nobody's made a good one yet.

And so let's go make that good one. That's a weird, considered harmful take. Dykstra. Yeah. Visual programming considered harmful because it's so good. Dykstra. yeah visual programming considered harmful because it's so good it's extra well because it encourages people to look at how not good it is yet instead of looking at how good it could be you have to go let lemon in don't you yes i do yes you do i put her favorite treat on the ground for when she comes in because this is the time she gets

in so she was like she could see it and was you know very like oh wait but i have to get that now so so the uh i've got uh three more as follow-ups to this first one okay uh the second one is uh textual programming's enduring effectiveness considered harmful. In that if text programming weren't so good, visual programming might have more of a chance. And that, you know, text programming is so well established at this point and people are so comfortable with it and all the tools are so mature and we have wonderful things like Git that we can really rely on. And whenever somebody makes a visual programming system, they're like, oh, but how do you make it work with Git? And then turn around and the same person's like, Git is the most horrible, awful tool and I hate it. And it's bad and we should kill it as quickly as we can and get to something better.

So yeah, all of this maturity of textual programming, it's harmful because it's holding back the development of visual programming. I asked Ivan how weird his were going to be, and he said not. No. They're just very normal takes, but instead of agreeing with the premise of considered harmful, he just reinterprets it to mean something else well the premise of considered harmful is i've got something i want to complain about you're not actually saying don't do these things don't do textual programming don't do visual programming don't do textual programming only

do interpretive dance that's what i'm saying don't do it interpretive dance considered harmful is the next one i can see his screen now what i believed you even though that's not the next one you believed me unless i really guessed it right no you did not really guess it right i just got scared for a minute uh all right i have two more of these that i have to get through and then we can get back to the normal ones okay okay okay that's fine um the third one is co-pilot considered harmful that's a reasonable take.

Because it makes textual programming. Oh, but your reasoning is going to be silly. Because it makes textual programming more comfortable. It makes textual programming nicer and easier to do. And so it further will make it difficult for visual programming to gain an edge on textual programming. Hold on. I want to pause on that one for a second.

Okay, sure. Have you used Copilot? Yeah, for like 10 minutes. I've used everything on that one for a second. Okay, sure. Have you used Copilot? Yeah, for like 10 minutes. I've used everything for like 10 minutes. Okay, so I've used it like a lot. Like I've used it in my day job. I've used it in side projects. I've used it in interviews, blah, blah, blah.

And there are times where it is so nice, right? And there are times where it is the most frustrating thing on the planet, and I want it to go away. But I've realized like the frustration of it is all UX, right? Like it's, it's the way it's exposed. And it's the fact that like it overrides in VS code, it overrides like the real auto-complete like they're, they're on the same, they're exposed the same way. Right. So I do think it will be really nice when someone makes a better user experience for it but there's part of me that doesn't want to turn it off because like the

times where it's so nice outweigh the times where it's so incredibly frustrating and i hate writing boilerplate code even though i almost put on my list hate of boilerplate considered harmful extra because i do think boilerplate code is good to exist i just hate writing it wow and jimmy called mine weird what that's not weird hate of boilerplate considered harmful dykstra yeah that's not weird at all yeah that's not weird at all uh-huh not a little bit not weird like my oh visual programming good actually well your reason you're just taking like takes that are positive like visual programming is great textual programming is bad and both

making them considered harmful why not i can do it in a way that's consistent and my my fourth and final one on on this particular thread of exploration is that lack of diversity of thought considered harmful to ivan's brand in that all i do is talk about visual programming i got one for you all right yeah not talking about your side project on your podcast considered harmful extra hast is great i've worked on it uh not at all in about two years, other than thinking about it. But I'm still thinking about it a lot. Okay.

I do actually have that one listed down here. I think that's my weirdest one. Is not talking about your side project on your podcast considered harmful? Yep, it's considered harmful. Dykstra. I put a lot of thought. Every one of my considered harmful is substantial. I have a lot of other ones that are good.

They're not like little one-liners. Okay. I think this one just goes without saying, but of course, you know, the rest of everyone disagrees. Not everyone, but a lot of people. Agile, considered harmful. It's her Viva Dykstra. I think Agile is the worst thing that has happened to software development in a long time.

And I know all these people who are advocates of Agile, who came before Agile, will tell me I'm misunderstanding the history of all of it. I'm not saying what came before was good, right? I'm not saying that Agile wasn't better than what came before i'm saying agile has had absolutely horrible effects on the way we think about software it is this this meme that makes it so nobody can think in terms other than what the agile terms are right and so when you even try to criticize agile you can't even get the words out because people are like well you don't understand it or you're you've only seen bad agile or that's not

agile and so it's not the concrete thing that i'm talking about it is the meta way we talk about agile that is the harmful thing because we can never point to concrete things because they're all this vague general here's you know values we hold that like there's no way to show if you're holding that value or not it is such bad discourse and it stops us from being able to really talk about the problems in software because they always get couched in the bad agile terms that have defined the discourse forever. The further away I get from agile practices in the big A agile sense, the happier I am in my job. And the less I talk about agile practices, the better the practices end up being because

they're not confused by all these silly ways that people have broken up the world. There's some strain of programmer culture that steers people towards these sorts of terrible discourses. And the one I'm also thinking of is type discipline. That's on mine. Ah, great. Now, is it the discourse around types, specifically that? Static versus dynamic types considered harmful. So the fact that we're setting up this opposition at all is the considered harmful part.

I can kind of appreciate why it is that we have these sorts of debates where we say, oh, well, if you don't like visual programming, that's just because you haven't thought enough about how good visual programming could be. You're only looking at the existing examples of visual programming all of which are terrible there's a lot of like goal post moving there's a lot of uh no true scotsman there's a lot of like these sorts of dodges that just become the nature of conversation around these topics that keep us from engaging with the substantial, technically interesting, you know, grainy, detailed bits of the subject matter that should be the things that as programmers, as people who like to explore systems and understand how they

work, we should be compelled and inclined and attracted towards talking about that kind of stuff in a much more concrete, substantial way for whatever reason this sort of like dogmatic cultish mentality takes over so frequently and i don't i don't get it but i don't like it yeah i think this is a a real tough issue to try to convey to somebody because Because once you set up these oppositions of static versus dynamic type or agile versus waterfall or whatever, everything is put into those boxes and all of the statements you make

seem like you're arguing one side or the other. People will, whenever I have my anti-agile discourse, they'll be like, you're just arguing for agile and you don't realize it. And I'm like, no, like this isn't, I'm not saying the things that people do in agile are bad practices. I'm saying the whole way we've conceived the space is the wrong kind of way to conceive it. Right. And the basis on which we decide for these practices by looking at the Agile manifesto and seeing if they line up with these values or by looking at – by doing retrospectives to see how the team has been doing and if we want to – I think all of that framing of the discussion is the wrong kind of framing because it already presupposes a bunch of values that I don't personally hold. It feels systematized in a way that maybe is what attracts people to it, at least in this specific case where it's like there's a – like the culture is about encouraging something that maybe feels a bit like science or it feels like you get repeatability out of it or you get something that is dependable and that if you try and pull somebody away from looking at it just in terms of these same concepts that they like to lean on and say no don't just just lean into those concepts instead like try and unpack this a little bit and

think about in concrete terms what are we actually doing and why yeah it feels like it's at odds with that compulsion that we have to try and make things like to try and take human factors and make them mechanical you know that's another one of those strains i think the best like analogy i've been able to give for people because i do think this comes back to like some paradigm shift in commensurability i do think there's some stuff like that going on here but it's like the stack overflow question that I'm sure exists, which is like, how do you do inheritance in Haskell? And answering that question literally is the wrong answer to that question.

Clearly something has gone wrong conceptually here, but these are the kinds of questions when you start learning a new paradigm, programming paradigm, you start asking, how do I do blank in this language or whatever? And it's like, you don't, is the answer. And it's like, it's not that but I know

that tool and I need that tool and that's the kind of shift we need in concepts. So yeah, I think Agile has done more harm and if I have to say concretely in terms that people would understand instead of just this meta discourse, I think Agile has done more harm. And if I have to say concretely, in terms that people would understand instead of just this meta discourse,

I think we've given up the responsibility that we're supposed to have as programmers and made it part of this process or part of the system or part of product, which I also have on here. And that's the harm that's happened is we don't take the whole process of crafting software as a whole and instead try to break it into parts that it just can't be broken into.

That was a good one. What about you? I want to hear some. You said you had normal takes. Let's hear normal takes now. So this next one, this one could be interpreted as a joke, but it could also be interpreted as something kind of serious, and I'm interested to see where we go with this one.

This one is called The Elder Generation Considered Harmful. Extra. Oh, wow. Alan Kay, Ted Nelson, Bill Atkinson, Ivan Sutherland, Tim Berners-Lee, Ed Catmull, Susan Kerr, Vince Cerf, Leslie Lampert, Noam Chomsky, Tony Hoare, Lynn Conway, Elizabeth Feinler, Donald Newth, Ken Thompson, Bjorn Stroustrup, Gerald Sussman, and Charles Babbage. These people are our living memory of the time before computers and how computers came into being and why they are the way they are and what we could or should have done differently. I put together that list of names and in trying to put together that list of name found so many more people of that level of illustriousness who are now lost to the world and these people are still

here they still walk among us but only for so long and that i i as somebody who came up pre-internet and remember a life using a computer to do all sorts of things before the internet and then remember the advent of the internet and how they work that i can only imagine is so much more intense for anybody who was alive before computers as we know them were even a thing and who participated in making them into what they are and i don't know that this is like a thing that we can do anything about in the way that like go to considered harmful is like well just stop stop using go to thanks if these people who are alive now and won't be alive forever would just not die like if they just stick around and continue to help us appreciate why computers are what they are then that'd be great but that's not an option and it's it's so this is more of a lament than a you know hey stop doing that okay hold on now i'm confused on what's

considered harmful thanks you just said that you would love for them to stick around how are they considered harmful what's considered harmful is the fact that they are the elder generation and that means they won't be here for long not that they themselves are harmful it's like i'm not saying these are bad people okay hold on so what i've learned here is ivan did not want to say things are considered harmful so he made positive things be the things considered harmful by saying like the lack of the fact that we don't have more like healthy food considered harmful because it's so expensive to get at the grocery store that you should eat more of it but you don't yeah that's that is exactly what i did i was like oh wow look at this he's's going to be like, stop reading Alan Kay.

Don't listen to Ted Nelson. Like, we venerate these people too much or something like that. But, you know, you're like, the fact that we don't have more of them is the harmful. That's why they are harmful. No, a property that they possess is harmful. They possess the property of dying yes that's the harmful part yes i want these people who are our connection mortality considered harmful it's a fucking dystra yes that's i that's totally valid that's that's a reasonable considered harmful these are such weird ways of i was like i was like okay this will be fun but now i can see why you think it's a joke because

you don't don't know what considered harmful means that makes sense no no no no no no no using considered harmful to say the opposite of considered harmful considered harmful a property of this thing that i wish they didn't have but they do uh is harmful because it'd be better if they didn't have that property this checks out okay all right so because i can buy the take i see this is why i was i was confused because i can buy the take that that we rely too much on the takes of these pre-computer people. And that misinforms us on the world we have today, which is not a pre-computer age. And so when we're imagining the use cases that people have, when we're imagining what computers are for, they're not in the context of a computerized world. So I mean, I think one example

was like, you know, modeling being a focus of what computers do rather than entertainment. Right. And we know now that like, entertainment is a major component of this. And if we just ignore that, and are like, well, people shouldn't be spending all their time being entertained, that might be the wrong sort of approach. It be like okay how can we make that entertainment also fulfilling not addicting not you know whatever right like you can imagine refocusing our efforts so this is what i thought you were going to say is like these people have undue influence on our thoughts and maybe yes we should know our history yes we should think about it but maybe like aristotle might have had uh pre-newton right like aristotle considered harmful might have been a take because like his thought was so totalitarian in the minds of people that they couldn't imagine

something outside of it that take i might i might i might i don't know i might buy but people should stop dying the interesting thing is not also charles babbage being on the list it's like like that was like i knew oh no charles babbage and his big influence on free computing thought and how much i'd have you read charles babbage here here i was thinking that that one got by without you catching it okay i'm glad that you caught that have you read charles babbage uh i have not read charles babbage oh i will find some excerpts of charles babbage so the reason you object to charles babbage being on that list is because he's not as good oh no because i don't think uh i don't think you know what charles javavage actually wrote uh okay so he published a a series of treatises called the bridgewater treatises

that have titles like on the power wisdom and goodness of god as manifested in the adaptation of the external nature of moral and intellectual constitution of man. Right. This is not the right one. This is Thomas Chalmers. That's what they linked to from Wikipedia. Oh, this was the series he was a part of. Okay, my bad.

But it's still the kind of stuff. I'm thinking like Babbage of Analytical Engine fame. That Babbage. Yeah, yeah. That's him he he wrote like most of his writings were on uh on religion yeah kind of like uh like uh whitehead right was it north one of the two of them went like very kooky was it north was it north or whitehead i think it was whitehead what uh like the two authors of Principia Mathematica.

Yes, that's why I'm... Who are the two authors? I thought it was somebody, somebody North, and somebody, somebody Whitehead. It's Alfred North Whitehead. Oh my God, Bertrand Russell. There we go. Was it North or Whitehead?

North or Whitehead? I'm sorry. I know that didn't make for great radio, but it was too good for me to pass up. Yes, yes, yes. Okay, Bertrand Russell. There we go. For some reason,

Bertrand Russell, in my mind, is a playwright. All right, here you go. Here's Babbage. I finally found a good quote from the ninth Bridgewater treatise, not the other one, because that was not his.

It is more consistent with the attributes of the deity to look upon miracles, not as deviations from the laws assigned by the Almighty for the government of matter and mind, but as the exact fulfillment of a much more extensive laws than those that we supposed to exist. This is your new radio voice, Jimmy. This is how you have to read all quotes. This is a very good radio voice. That's the contradictions that have imagined can... They have imagined. Anyways, he wrote about theology, and I'm pretty sure the whole getting all this computation

was all in service of his understanding the universe so he could understand God. Yeah, whatever floats your boat. I just don't think anyone's influenced by Babbage in his writings. He's also in that list of people who are our living memory of the time before computers. Babbage, definitely number one, most read. Okay, so actually on considered harmful things, I'll throw out a bunch of random ones here that I don't think we need to talk about,

but I want to state as my opinions. All right, cool. Bring out your dad. ORMs considered harmful. Code styles considered harmful. Wait a sec. Code styles? What are code styles?

I'm not familiar with that term. Like, we have a style guide. You should follow it. Like prettier or whatever. I'm fine with automated tools that just go and format stuff, but like, hey, we can't merge your PR because you put two new lines instead of one and you oh this is where these things go now i have no problem saying like these are the conventions

of a coding community like pep8 or something like that but individual companies being like we always format things do things exactly this way and if you name something with is versus that and that kind of thing. It's good to teach junior developers to have reasonable code style when they don't indent their lines and stuff like that. If that's the level we're talking about, but if it's good engineers

who've been working for a while just disagreeing on some silly little stylistic thing, just let people do it differently who cares i might take the under on this one i think those discussions are just proxy wars over who's in charge yeah but that's hard considered harmful dystra um so this is anytime you say you want to go build something and people are like but why why are you going to go build that? That's really hard to build and X already exists. Why don't you use that instead?

I think that attitude. I put out on Twitter a while ago that I was building a text editor and someone was like, why? It's really hard to build a text editor. I was like, yeah, that's why I'm building one. Can I jump someone in mind? Because I have almost the same thing but with different words, which is DevX considered harmful. The notion that the choice that you make to do one thing or another Can I jump to one of mine? Because I have almost the same thing, but with different words, which is DevEx considered harmful. Dextra.

The notion that the choice that you make to do one thing or another should be driven at all reach for tools like React or Tailwind or Vite or other things that are things that they could probably build themselves from scratch and if they had built it themselves from scratch or had had engaged with things at a at a lower level instead of using some abstraction on an abstraction on an abstraction they would build a better product they would learn more in the process and they would have something that is probably more maintainable at the expense of maybe it not being so easy to hire new people and bring them in and get them going on the code base because it's in some form that isn't like a de facto industry standard. And it's these de facto industry standards

that are so much about developer ergonomics as opposed to making great products that I just find that harmful. That's an interesting takes on DevEx. I see it. I'm not disagreeing with it. But I think like, you know, maybe to, you know, play devil's advocate here, people would say, well, developer experience is just like, we should make developers lives easier and make it easier for them to implement things. And maybe people then take that as like, ah, well, I just got to be like that other system.

But that isn't in and of itself what DevEx is about. I'm curious, if we take maybe the original or true definite, are you still opposed to developer experience making something nice and ergonomic for developers? Or are you opposed to the industrializing of DevEx? I guess I'm opposed to the kind of the industrializing of dev x i guess i'm opposed to the wielding of dev x as a justification for making choices that are ultimately harmful to the product okay or that are ultimately harmful to the end user where it's like we're gonna build this thing in this way or we're going to choose

this technology and our primary motivation for choosing and i and i see this most reflected in the way that things are marketed to developers they are marketed as you know this makes this thing that you do so much more convenient and so much more comfortable and look at and and and you can think of any number of recent examples but the first time i saw this in a way that i think it was maybe the beginning of the the bad times was the original angular js it was this you know web development framework it was for making single page apps back before that term even existed. I think it was around the time that Angular came on the scene, you know, pre-react that we started to think about, oh, hey, a web page can behave more like an application. And the thing that Angular put front and center as the like, this is the reason you would choose

this framework is because with two-way data binding, you can put a period in a certain place when you access a property of some JavaScript from your HTML. You have some HTML attribute and you say, you know, my state dot value, and you get two-way data binding. And then you have, you know, if you put my state dot value in a text field and you put my state dot value is the text of a P tag. Hey, if you type in the html input your p tag updates automatically and you didn't have to write any code to do that you just you know glue some properties together and it was this like front and centering of it being so ergonomic coupled with the fact that if you actually learned angular js and actually invested in the framework it was this horrible cobbled together pile of

misfitting systems and complexity that did not scale at all. And that was incredibly miserable to use. But it was the beginning of how appealing can we make something look to developers being the thing that is front and center in the conversation. And I think DevX, yes, it means a lot of things, and it means some positive things, but it also is used as a shorthand for, hey, if this thing has good DevX. And it's familiar or convenient. So when I think of the start of the modern DevX movement, I think of Rails. Sure. When I think of the start of the modern DevEx movement, I think of Rails. Would you also lump that in in the same kind of category? Because what launched Rails was this build a blog engine

in 10 minutes or whatever? Yeah, build Twitter clone in five minutes, that whole thing. Yeah, so you consider that all part of the same kind of... I'm just curious to understand your thoughts here. I'd be happy to accept that as part of DevEx. There's a certain kind of JavaScript DevEx that I do feel like is distinctly JavaScript community. So I'm just curious if that's what you're reacting to, or even things like Rails trying to make developer convenience.

I mean, I would see this, I see this also in Swift and apple's platform apis and swift ui and that sort of thing like it doesn't just have to be javascript javascript certainly has a particularly nasty strain of this rails had a little bit of this also not in rails itself but in the gem ecosystem that grew up around rails where so much like devise and warden and uh all the different like simple form and factory girl back before they renamed and all these things were trying to advocate for build your rails sass service as a bunch of modules that you just plug together and i think that that insofar as it discourages people from engaging substantially

with like how do these things actually work in a fundamental way what are the concepts that they are building on it's it's like you have learned to work only in terms of interfaces that are designed by people who don't have a holistic view of the thing they're building gotcha my most recent one is tailwind i'm i've i do not like tailwind i think tailwind is a is a really nasty trade-off where it's like hey it will help you style a web page very quickly up front without having to learn css without having to engage with design as a like considered process you can just kind of like bash these little classes into your html until you get something that looks roughly the way little classes into your html until you get

something that looks roughly the way you like it to look and then what you are left with is this just miserable soup of html that i think is unmaintainable and is and is bad and if you had just slowed down a little bit and instead of racing ahead to try and build an mvp had slowed down and actually like designed a style sheet properly you would have a more maintainable nicer thing that you have built for yourself for the long run so i have one on here that's i think in some ways the opposite of what you're saying right now okay so i have not invented here considered harmful extra oh no that's my whole thing. Yes. Yeah, so, okay.

I want to caveat this one and say that in your personal life and personal projects, not invented here, I can also say with Ivan's idiom of not invented here or of considered harmful actually being considered good. Dykstra!

I'll say not invented here considered harmful because we don't have enough of it. Dijkstra! In your personal life. So like personal projects, I think not invented here is great. In the business world, I do think if you're, it depends on your context, but if you're on a team of people,

non-invented here stuff, like I want to recreate everything and I don't really have a good reason to do it other than I don't like the other things, it's usually awful to work with. Yes. And it makes everyone else's life miserable. You really should have a good reason to reinvent the wheel in your day job this is why i was like interested in you picking rails because rails is one of those like it's a good counter because i think rails is actually well architected and i think that it does allow you to engage with the things that it is abstracting in a useful way like it does lift you up a level but it allows you to be conscious of the level that you have been lifted

up from in a way that like i think a lot of people who use and i'm going to pick some more on tailwind a lot of people who use things that are meant to stop you from writing a style sheet those things are meant to save you from having to learn how to do css whereas i don't think rails is trying to save you from having to learn how like http works or how web security works or how databases work i think it is yeah that and that's why orm considered harmful is one of my things here and i think everybody's like yeah active record was probably the wrong way for rails to go active records definitely like i think one of the weak spots of rails i think i see where you're coming from i i do think i would i do think we have different

stances on not invented here because from everything I've heard, you have invented a lot of things for business applications, like your own module system and staying on CoffeeScript as a CoffeeScript dead-ender. Staying on CoffeeScript is not something I invented. There's dozens of us. Uh-huh. But you recreate a bunch of things because you're staying on coffee script only because coffee script makes it nicer to recreate those things than to use the awful inconsistent slow weird things that have actually been hacked into JavaScript over the last decade.

Like TC39 and the pressures that, in particular, people at Google have subjected them to. It's like there's negative externalities of it on the long-term future of the web that worry me. I getcha. So here's my next take that I almost didn't include because it's just like such a basic hipster uh take which is oh considered harmful fixture uh yeah i don't think i need to rehearse arguments against oh uh and i know that obviously there's a uh sizable portion of our audience that are like but small talk maybe but. But OO still considered harmful. It's good dice.

Wait a minute, wait a minute. Do you just want to drop OO considered harmful and move on? Do I really need to justify it? Like, okay, to me, this is one of those things where I'm not going to convince anybody. You're just like signaling to the audience that yeah you know that i wanted to remove it because it felt like i'm it felt like too boring or basic of a take and just like branding myself but it it's also something that i think like the what i didn't put on here is functional programming considered harmful but in ivan's sense of considered harmful is a good thing because we

don't have enough of functional programming thanks uh but John. But I didn't put anything about, like, I wouldn't put if we had a considered helpful or whatever. Functional programming considered helpful, even though I like it. I just think, oh, it makes us think about our programs in a way that I don't think is actually helpful to think about for like 99% of cases. I think thinking about our programs as a bunch of nouns, as a bunch of things interacting, is generally a limiting way of considering stuff. And it's a conceptual framework that asks questions that aren't about your problem and makes you go down these rabbit holes i would think the same of even though i think like i think you should learn it i think it's good to go learn i think it's important blah blah i would say the same in my opinion of

like the very functional programming big types sort of thing, like bifunctors, even though I might think it's interesting to go learn those. I don't know that they're really helpful for thinking about your program in a lot of ways, even though I do think monads were helpful for me. Like, I don't know. I think OO in particular has a bunch of just cruft that I don't think it's helpful to organize your programs around. i i wrote this also because i was working on some android code where like the android system web view you have to subclass the chrome client and the web client and then the web view and then you have to make them talk to each other somehow but indirectly because they can't talk directly

to each other and now i have some state in my ui and i need to propagate it over there but that means i need a subclass and it's just like i don't want to think about i and then you see like the react native abstraction around this and all this was just to high to change items in a menu i had to do like these crazy levels of object and then the react native abstraction is menu items equals array the end and they do all the weird nonsense i had to do for me um so yeah i just don't think it's worth it so the natural phrasing of this one would have been to preface this with the but in our culture it might be confusing so i just said office considered harmful so if i say the office like am i referring to a tv show i think office like the office people going to an office working on premises like i think that's bad yeah private versus public in a language i also think that whole distinction is

bad and languages should not have it. Everything should be public. I think we actually agree on that. Wow. Wow. Nice. Yeah. Hype considered harmful. Dykstra.

You might as well just say like falling off of a bicycle and scraping your knee considered harmful. Dykstra. I have two left. Black boxes considered harmful. Dykstra. Like like the recorders taking anything as a black box the the intentional stance of i will never look into how database is running things because that is too low level for me or that's just a given fact nothing i can do about it i i know this sounds like a silly thing but i think people practically consider all sorts of things black boxes all the time and it limits they do you you talk to people about um performance and they'll say well you really don't need to worry in most

cases about the performance of your code cpu wise because it's almost all io bound which is almost always wrong it's it's not io bound in any strict sense it's usually some other cpu over there doing things right or it's you didn't properly access that io or you didn't cache it or whatever right like it's it's almost io is very fast these days. And so like, we consider a lot of it, or we consider like, memory allocation being a black box, and we don't look into the memory allocator. There's just a lot of things that we take. Of course, if I said, oh, you're considering that a black box, you'd be like, oh, no, I'm not like, I shouldn't, or I know that's bad. But practically, we draw a boundary of, and I won't consider how that works because that's beyond my purview.

My incredulity here is only that, isn't this the same as when I said, hey, not understanding the things that are hiding behind these convenient abstractions that people- You said DevEx considered harmful yeah in that the problem with dev x is it tries to turn things into black boxes that ought not to be black boxings yeah that's just not the way i would put yeah so i didn't if that's all you meant that i agree yeah that that was pretty much what i meant cool though with the more glad i could phrase it better for you uh thank you yeah you do a good service here on the show we'll get to that all right last one for me uh is i think rules

are considered harmful okay all rules what kind of rules are we talking about name a rule it's harmful including the rule that rules are harmful i i think okay i think uh setting up rules as like these are these are the ways we do things we are i am making rules i am instituting them on high you must blank is nearly always of course there's like commonsensical rules like we won't introduce security, known security vulnerabilities in our software, things that don't need to be stated, right. But things that need to be stated, making rules is the wrong solution to the problem you're facing. So you might say, we're not testing enough, I'm going to make a rule that all PRs must add tests, or you must

never have test coverage go down. It's the wrong solution. It's the wrong way to solve the problem you're trying to solve. And so I think we as software engineers lean on rules so often as ways of getting the conduct we want. And we forget that it's really about people's thoughts, their desires their the hearts and minds uh which has forever been ruined uh but the hearts and minds of people right like that is really what we should be caring about because rules don't actually get you the behavior you want in the long run they just get you the results you're measuring and the you're almost always aiming at the wrong thing so if you ever see yourself like i just want to institute this rule that to me is a time to reflect and go what

what's the real problem here and how can i solve it at its root instead of mandating i'm uh yeah i'm in complete agreement about this and my way of like my little internal mental uh mnemonic device is that like um i think of rules and i don't i don't know that i call them rules but i think of this sort of bureaucracy as a kind of scar tissue it is something that is generated as the result of some trauma and instead of addressing the trauma you've just kind of scabbed over the issue. Yeah, that's a good way of putting it. Yeah, that kind of institutional scar tissue is, yeah, I think it's bad. That's it?

Those are yours? That's mine. Okay, great. Well, I'll bring up my dad. So I have video games considered harmful. That's a good dice, Chris. Did you just not understand this essay at all and my note for it is i waste a lot of time playing video games you're just listing all good things uh yeah that's it all those substantial things that are things that people probably

disagree with in our industry i am am just going to list chocolate considered harmful. Dykstra. Yeah. Cause I eat too much of it. It's bad for my tummy. Uh, so then I don't have enough of it. The next one that I've got,

this one's more substantial. This one's not, this one's not a joke one that is meant to rankle Jimmy. Oh, okay. I have to read this a certain way. It's kind of like you're at the office considered harmful. Um,

this one, if I don't read it right, it just won't make sense. All Things Considered Harmful. Dextra! All Things Considered, colon, harmful. The radio pro? The NPR radio show, All Things Considered, yeah, is harmful. Why didn't you say All Things Considered, Considered Harmful?

Dextra! I'm making the word considered do double duty uh all things considered harmful which is just my little my little opportunity to work into this episode once again the perennial theme that i think that podcasting as a medium is very different from radio as a medium and i think that there's a lot of podcasts out there that want to emulate radio. And I just want to take a moment and say, stop, don't do that. Podcasting allows you to do things in ways that are wildly and wonderfully different from what radio allowed. And that's due to technology, and that's due to economics, and that's due to the circumstances of production and access to the

means of distribution. And it's due to the expectations of the audience. And it's due to the circumstances of production and access to the means of distribution. And it's due to the expectations of the audience. And it's due to, you know, the fact that one of them is on demand and one of them is broadcast on a schedule. And one of them requires being created in a studio and the other one doesn't. And I think that if you have to try and emulate radio, you should try and emulate Radiolab. That if you're going to make a podcast and you want to do something that is NPR adjacent, then start with Radiolab and go from there. So, all things considered harmful.

You just wanted to make sure that you could have the reading of that, that everything is considered harmful. No, but that's a good reading. It's a very Jimmy reading of that. All things considered harmful. Yes. And that was...

Dykstra. Philosophy Corner. My next one, considered harmful scolds considered dreadfully uncool. Dykstra. And in reading this, I'll read that again so you can parse it. Can I repeat that? Yes. And I'll read it again after I set up what it is

In doing the reading Go to statement considered harmful And doing some background reading You of course encounter like we said at the top of the show The fact that a whole bunch of people Have made their own considered harmful And that one of them is Considered harmful considered harmful

A lot of ink has been spilled bemoaning the considered harmful snow clone genre dykstra whenever you make a considered harmful dykstra scolds come out of the woodwork to chastise you for calling something harmful for being incendiary or whatever and i just wanted to say that uh sometimes it is fun to be incendiary and to play with this format. And so I think if you're the kind of person out there who's saying, considered harmful, you are a scold. And thus, considered harmful scolds considered dreadfully uncool. So what you're saying is you want more people to give considered harmful takes.

Dykstra. Yes, yes, that I like considered harmful as a format. Dykstra! I mean, I do hope that we get some good considered harmful takes. Dykstra. In the Slack or on whatever social media platform of your choosing. I'd love to hear, you know, people disagreeing with us, but also like, I want to hear your own takes on what you consider harmful

yes, that would be great discourse I'm going to skip startups considered harmful you know what that argument is I thought about putting that on my list I did, I was like should I? do I really want to? the reason I didn't because i think it's a more complicated topic yeah like my my notes for that one go into like ubi and all

sorts of other wild tangents so yeah i would say it's like are they really because there are some startups i'm like i don't consider that harmful but it's the ecosystem it's the fact that startups are a necessity within the systems that we have that i consider harmful i would like there to be alternatives to startups that are ways that new ideas can enter the world startup monoculture yeah that's that's great i have uh Dykstra. Have you tried to read papers? They're boring. Papers are boring. I tried reading a paper by Dykstra and my teeth fell out. Books Considered Harmful.

Dykstra. I have too many of them to read and they keep multiplying. There you go, Jimmy. There's another one of my, actually, it's a good thing, but I'm saying it's harmful because it's too good. There are people out there in our extended community who do think books are harmful because you don't actually remember what you read in them. And so you spend all of this time reading them and if you ask somebody what you read, you cannot remember it all.

And so they're a bad medium for what they're supposed to be doing. I think that's interesting and I really disagree with it. But that's not my take. My take is that... You have too many of them, and you don't have enough time. I had to include that one in my bring out your dead round, because you're convinced that I don't understand what considered harmful means. I'm so shocked that Ivan took the considered harmful meme and turned it on its head.

Thanks, Tra! Or, like, you you know ripped it into several smaller pieces and it's kind of pushing those pieces around on the table like look this weird dead thing i found um all right my new one is allowing your queen to be forked considered harmful it's good dice track fork your queen allowing your queen to be forked so if you have a queen and then it's like now we have two queens because we forked this queen yeah see i do i i've been learning chess lately and i've been playing daily games and i just got a message saying that somebody so daily games meaning i play or at least one move a day so that's the time format format. And I just got a message that someone resigned

when I forked their queen. In this case, it wasn't really a fork. It was more complicated, but it was more fun to say forking queen. So basically what you do is, like, you move a knight, and now the knight is attacking both the king and the queen.

Oh. Right? And there's no way for you to defend the queen with how the setup is so they have to move the uh the king the king and then you take the the queen cool i'd never heard that term that's fun very relevant radio yeah this is this is good good good at playing chess is good i got three more a small a and a large, in that order. The small, not supporting us on Patreon, considered reasonable, but like, come on. Come on.

That's the small. The medium, compilers considered harmful. Dyke strike. Which is, I don't know why you, Jimmy, would want to work on compiler stuff when what we should actually be building is live systems that you modify from within. You can do that with a compiler. Yeah, yeah, yeah. And you need a compiler to do that.

So, Kent, of visual languages you're interested in. I do think this is actually a really interesting project because most of them that I've seen, there is a paper I know that's on a visual formalism for visual programs. It's on my list. I haven't looked into it but i do think it's interesting because one of the things they complain about is that for visual programming languages people will formalize it using like the lambda calculus or some other and they're like but that isn't itself visual and so we need a formalism that is visual which i like the premise of it seems really interesting um but one of the things of course they, that you don't incorporate is the time dimension that you're looking for.

They're looking at more node-wire visual programs. And so, yeah, I do think compiling your visual programs into something that's a nice, good executable is something we should have and could use and would be nice. And this is something where I know so little about it that in my explorations of visual programming i always get to this point where it's like okay how do how do i actually want to construct a set of semantics that are expressed in terms of some meaningful execution concepts and and have them be you know evaluated or what have you like that that work

i'm always just like i don't care about that part of it and so i i feel the compulsion to just uh oh i'm just going to pick some existing system and build on top of that but like you say that existing system will not have been built with the new possibilities that it being visual and temporal afford you. Yeah, I think that this is something that I do think if you go back to making HEST, we should actually try to collaborate on. Because I have some ideas, but I'm not going to build out the user interface part of it, because that's too much work for me. Yes.

So your take on compilers is,ivan's take on compilers considered harmful considered harmful thanks sure yeah because yeah uh yeah stop building the kind of compilers that are just for compiling static text languages and i agree on that start start making some more dynamic systems yes static systems Static systems considered harmful. Thanks. I'm all for. So this is my last one. This is a big one.

Okay. And it is Jimmy Miller considered harmful. Thanks. He works on making textual programming better, which, as we've established, is not a thing that we should be doing. He has positioned himself within the upper tier of technology influencers so in that way he is a threat he takes orders from a dog named lemon no less than on two occasions during the recording of this very podcast he left the recording of this influential technology podcast to go serve the needs of his dog lemon he seems almost disarmingly gentle and sweet he doesn't swear on podcasts and it is for this list of reasons that we must not trust him and consider him harmful

yeah see i asked ivan how goofy his list was and he said not uh i said it a little bit i said a couple of them were kind of weird uh-huh a little bit okay he said a couple of them were kind of weird. Uh-huh, a little bit. Okay, he said not at all. If he said not at all, then I would know that they were goofy, which is why he said a little bit. Well, some of them are a little bit goofy. Uh-huh, yeah, yeah. So that one was definitely a weird one and definitely not a large one.