Future of Coding - Interpreting the Rule(s) of Code by Laurence Diver

Episode Date: July 3, 2023

The execution of code, by its very nature, creates the conditions of a "strong legalism" in which you must unquestioningly obey laws produced without your say, invisibly, with no chance for appeal. This is a wild idea; today's essay is packed with them. In drawing parallels between law and computing, it gives us a new skepticism about software and the effect it has on the world. It's also full of challenges and benchmarks and ideas for ways that code can be reimagined. The conclusion of the essay is flush with inspiration, and the references are stellar. So while it might not look it at first, this is one of the most powerful works of FoC we've read: Interpreting the Rule(s) of Code: Performance, Performativity, and Production by Laurence Diver, 2001. Next episode, we're having an open-ended discussion about end-user programming. The reading is Bonnie Nardi's 1993 classic, A Small Matter of Programming, with the referenced articles from the 1991 Scientific American special issue Communications, Computers and Networks as extra background. Links Nova is the new code editor from Panic. Ivan is using it now that his beloved Atom has hit end-of-life. Ira Glass spoke about The Gap Ivan's unicorn-puke GUI Jimmy tried recreating the grainy effect used by The Browser Company's Arc Chris Granger's Light Table was an early Kickstarter success. iA Presenter has a clichéd video teaser. Mimestream, a great native Mac client for Gmail, also made one of these. Ivan first saw this style of video over a decade ago with Sparrow — and at least this one has a narrative. Occasionally, someone does a playful tweak on the formula, like this video that keeps getting interrupted for Dark Noise. But in general, this format is worn out, and it was never great to begin with. Here's the classic Atom 1.0 announcement video Very Bad Wizards and If Books Could Kill are podcasts that talk through a work from beginning to end sprinkling in reflections as they go, rather than jumping around randomly or separating recap from reflection. Speech act has a philosophy corner within the philosophy corner. Elephant 2000 by Lisp creator John McCarthy, and Dynamicland, both make use of speech acts. On The Expressive Power of Programming Languages by Matthias Felleisen The Sapir-Whorf hypothesis Black, a reflective Scheme by Kenichi Asai. Hollow Knight is a great game for a 4-year old, and a 40-year old. It's just a great game. Maybe the greatest? Doom Eternal, not so much — but the inventive soundtrack absolutely slays. Local-first software Tony Gilroy's Andor and Terry Gilliam's Brazil. In hindsight, I'm surprised we made it all the way to the final minutes of the show before mentioning Brazil. Get in touch, ask us questions, DON'T send us the sound of your knuckles cracking: Ivan: Mastodon • Email Jimmy: Mastodon • Twitter Join the Future of Coding Slack https://futureofcoding.org/episodes/065Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Canada invaded the United States by riding ice all the way down into it, you know. Uh-huh. Like 10,000 years ago? Yeah, yeah, the original war between US and Canada where the icebenders attacked. So. It's time for James' philosophy. I have so many thoughts running through my head i i i know you know this uh i got laid off at shopify and so i've been doing like tons of interviews but also like so i don't have as much free time as i as i like in my head like you get laid off you just do whatever right yeah

you panic and stay up all night wondering what am i gonna do with my life exactly and like now you have to do interviews where like you kind of have to have that like happy persona right because like when you're interviewing like there's just a certain way you've got to do things, and yet inside you're like, I really need this job, and I want that job. So it's pretty crazy. But I have had some free time to do some coding, which has been really fun. I've been doing some compiler coding, some editor stuff. And I started thinking about this question of, what do I want a text editor to feel like and aesthetically look like?

I'm just very tired of, I don't know, every text editor looks the same. There's not a single difference. If you look at Atom VS Code, the only reason you'll know which is which is because they're using the default theme or something like that. Yeah, or the fonts are uglier in VS Code,

that kind of thing. Like the default text or something like that. Yeah, or the fonts are uglier in VS Code, that kind of thing. Like the default text rendering and buttons are very Microsoftian. Yeah, like I remember when I used TextMate and there was something very nice about that font rendering. But my problem is I can't design to save my life. It's something I've like practiced and tried to learn

and I can like critique a design. I can think about interactions. But when it's just come up with a feel, an aesthetic taste, I can't do it. It's very hard for me to think about how would I get a certain feeling across or what feeling would i want this visually to give me and so i you know try to do all the shortcuts that exist today like ask mid journey to generate one and the answer is mid journey has been fed the same text editor over and over again so even it can't imagine what a text editor a programming text editor would look like that is not just the same old thing. And so I'm curious, do you have thoughts on this?

You're a very like, I don't know. Aesthetically motivated. Yeah, yeah. Like I know you have thought about what you want it to feel like. And I know you also use Atom for reasons similar to this. So I had to stop using Atom because they end of lifed, and I wanted to get ahead of that. So, I know. You made the grimmest face, Jimmy.

Like, all the life drained out of your face. Like, oh my god, I'm so sorry. Are you okay? Yeah, I mean, I knew you really cared. Are you on VS Code now? I'm switching between VS Code and Nova. Okay. So I use VS Code a little bit when it has something that I really need,

and then I go back and I detox in Nova. Yeah, like the way that I would design something like a text editor is, like the really boring answer is whatever i came up with would also be crap but i would just keep iterating on it until i made it really bad and then i'd throw away that work and then start over again and keep iterating on it like i just like i solve this problem with like raw effort i don't have like a clear vision or anything like that either when i start out i just have that ira glass style feeling of the gap like this isn't good and i can recognize that it's not good but i'm just going to keep trying little things and trying little things and getting it to closer and closer until i find

something that's like like for instance i had to build a asset management tool recently was like it's for artists and so it had to be very gooey and I wanted to make it feel as much like a Mac app as I could even though it was an electron app and so I started by like okay I'm just going to measure all the colors in mac os and like measure all the distances between elements and try and like faithfully recreate the look of a native mac os app I got a certain way along with that and i was like yeah but i'm doing this in electron and i have css and mac os is kind of boring what if i started going a little wild with transparencies and what if i started using like gradients and filters and before long the whole thing turned into unicorn puke lots of rainbows

and sparkles and all this kind of stuff but it was like unicorn puke through the lens of the very professional dark mode looking safe mac os ui style and i think it actually looked pretty good okay but i got there not by going like ah i want to go for unicorn puke i got there by going like i want to make something that i know is a good foundation and then once that started to feel boring i just put little tweaks on it and little tweaks on it until it turned into something that's like actually this feels weird and different and i'm going to just lean into that yeah i think that's one of the problems I've actually had with design is I, I guess with code, I've learned very well, like, you know, you kind of put some stuff out there that's not great. And over time, you see what's not great about it,

and you start refining on it. And I guess, I don't know, maybe I've just not appreciated design as well as I should, or like, it still feels very magical to me in a way that, that coding doesn't. Right. It still feels like, like I talked to somebody, usually if I'm talking to somebody who's a designer, I'm talking to somebody who's a good designer,

who's done it for a very long time. And so like the things that they see and that they can produce quickly feel like an impossibility for me. Yeah. And I guess that's a good point of like continuing on with something even as you don't like it and think about what you don't like about it and just like slowly refine it and add more things. I don't know. There's something that makes sense about that. And there's something still in me that's like, but I want, I want my design now, you know? Do you know that Ira Glass quote about the gap?

I do know the Ira Glass quote. Yeah. Yeah. So like, I mean, I thought that was really interesting. Just like, you know, that our taste for things exceeds our ability to create them. And you have to like keep trying that's definitely where i'm at when it comes to design for sure like i don't think i'll ever be a great designer i'm sure there are people with aphantasia that become great designers and figure out how to work around it i do think is a little bit of uh it requires me to think very differently about design since i can't picture things. Which is why I do, when I do design,

I do try to take an iterative approach. I usually do it in code. I'm usually having something concrete to look at. I can't imagine otherwise. And I did have a little exercise of actually writing some shader code to try to recreate, so Arc, the web browser has like their like big gradients and then they can add like graininess to them and i just thought that would be a good thing to try to like figure out and recreate so i made that with like a big rainbow gradient and then started adding graininess to it so i could have a little texture and that was that was a fun

little like you know go dive into some shader code and try to learn how to do that and i did get that working it looked awful uh like it did not work as a text editor setup whatsoever because like when arc does it you know that's their like window and then the content is just your website and so like you're just seeing that at the edges whereas like yeah i don't want my like you know with my editor i'm trying to stay away like one design constraint i have is like you can't have one big text field that is like i i don't care what the solution is ultimately i've you know played around with an infinite canvas thing. I'll probably have something like that. But I also want, like, maybe like a more column based design with like code bubbles, but they're not going to be like stylized like bubbles or whatever.

But you know, snippets of code, but I don't want the one or two, you know, maybe three columns of big text panes. That is like my for sure no. no hmm it's great to have a guiding intuition like that like the sort of thing where you say well i don't know what i want but i do know what i don't want there's the weak version of that which is oh here's this thing that would be fine but i'm just going to choose not to take it on as a creative exercise or because I want to see what else is out there in the possibility space that sort of feels like where you're at with this. Then there's the strong version of it, which is like,

this is a holy war. I need an enemy. We must not just make an editor that doesn't have a big text area, but destroy all existing editors that have big text areas. And that vibe is one that I'm very amenable to. So I appreciate this as an incremental step towards holy war territory. Yeah, I can get on board with this holy war. Like, I know it sounds so silly, though. Like, I think that's the only problem I have with it. And it only sounds silly, though,

when you think of programming as non-interactive right and i i think that's really where all of this is coming from for me is you know what i've made i can actually do like interactive programming even in like a compiled language like rust you know i can't do it perfectly for all language i can't even do well i say i can do interactive programming i don't even have it so that i actually edit text in the editor right now i'm editing it separately but it's live reloading in my viewer so i'm like intentionally focused on like the live environment more than i'm focused on the editing of text and i'm slowly getting to the point where i'm going to edit text because i can like have lsp hooked up and have processes run and then go and pass data around and stuff like this but

yeah i i can the more i use an editor like vs code sublime text whatever it doesn't matter the details of them the less i enjoy using. Because there's always all this auxiliary stuff that I want to work with, whether it's I'm debugging. And like, you know, I think about when I'm working on a compiler, I'm debugging something. And there is, I'm in a breakpoint. And there's the state of the system as it currently is. And I can like poke at it a little bit on my debugger panel and see like, oh, there's that stack pointer. And then I can like poke at it a little bit on my debugger panel and see like, oh, there's that stack pointer. And then I could like go and write some incantations to like try to parse out what the stack is. And, you know, I can see this call like, but like, I just want to

be able to have like a default thing, I can go visualize all of that. And it's got to live over here, right on the right hand side over here is my visualizing all the state of the system. And if I want to dive into that, I can do it. And I just feel like all of these tools are possible technically. The thing that stops us from having them is the assumption of our text editor being a text pane. We can't integrate any of those things into our editor. They always have to external tools because how do you the the ui just has no affordances for that and so that is where like why and you could try to patch this up by having the left hand side is your text pane and the right hand side is your like visualization setup or whatever but like now they don't participate they're still two separate

systems you've really just split screened an app right like this is where i'm coming from for all of these things is i just find there's so much more i want to have in my editor but i also i also want other people to see this and this is where this question came from is about the aesthetics right is like i feel like there's something here but when i look at the demos i can create they feel very uncompelling because what you're looking at visually is not interesting and if you're i feel like if you're going to step away from the norm, making it look good will make people connect with it better. Yeah, could not agree more strongly with that. And so I guess that's why I'm thinking about this. I could go this very programmer-y aesthetic,

basically try to make it look like VS Code, but then throw in some other elements. But I feel like that's doing a disservice to the newness. And so that's what I'm trying to look for is like, what could I do that like is visually distinct, that causes people to take a second and look at it and want to pay attention to the details there. And every time I look at designs for inspiration, they just utilize graphics to like a level that I don't know makes sense for a text editor. And that is almost always their like aesthetic appeal is some illustration, some little detail. And I just don't know how to incorporate that into this or how to eliminate that and still get the feel that they're trying to do.

There's other approaches you can take to solving this. Like, I think a necessary condition to getting people to look at something is not just making the thing enticing to look at, but also framing it in an enticing way and if you can't go as far as you'd like on making it enticing to look at you can make up for that by coming up with a really interesting framing like i think that's part of what made light table take off is that it was the first time somebody put a future of coding you know before we had that term yeah project in the context of a crowdfunding campaign and that made it viral in a way that nowadays if you did something exactly like light table and put it up on kickstarter or whatever it just wouldn't make an impact if you're struggling with finding a way to make it look novel because that's that's like a that's a sort of a double whammy of a demand not only does this have to have the core functionality

and features and this like you know doing away with the text like the limitations of the of the text buffer as the outer framing so that you can have more stuff happening inside your editor not only like all that kind of technical and interface innovation but also innovation on the presentation where it's like and it doesn't look like anything else you've ever seen either you say oh yeah you're you're envious of designers being able to like really quickly put stuff together but it's like even most designers if you said put something together and it has to look unlike anything that i've ever seen before and be exciting that's yeah that's taller but yeah i don't know that it has to be completely novel in looks i just don't i want it maybe it's like only novel

as a text editor. Sure. Right? Yeah, totally. Like borrow aesthetics from somewhere else, but put it in a new context. If doing that for the product itself, for the editor itself is tricky, doing that for the presentation of the thing is something that I think is even easier to do because let's say you wanted the presentation to be something really sarcastic. Like it uses comedy or it uses laziness or it uses, you know, satire

or it does something where it's like, look at this terrible thing. Like you've come up with a framing that uses elements to entice people where you definitely wouldn't want those elements to be part of the design of the thing itself. Like you might not want the actual thing that you make to be cartoonish or to be bad or to be so bad it's good or to be ugly or anything like that. But when you present it, you can present it in that way because the presentation you have way more degrees of freedom you can do whatever you want so long as it entices people to take a slightly longer look at the actual

thing that you're making and so that might be easier is to come up with a like here's the aesthetic for how i'm going to pitch this thing right like it doesn't have to be just like thumping electronic soundtrack and like stark black visuals and like silhouette and like synth wave, that kind of thing. Like you can pick a different presentational aesthetic separately from whatever the thing actually is. I think that's really interesting. have to admit i think earlier on in my career i would have said something like you know why do you have to try to be all fancy and how do you present it like just give people the information it's a tool just show you using the tool show why it's useful and that's that's all you should have to do otherwise you're just trying to sell me something. But I don't know. After seeing, I think at the time, part of the reason I might have said that

was because I saw a lot of tools that were presented that way, and they were so novel to me. They were so interesting to me because I was so motivated on getting something, learning everything I could. But after seeing in programming tools like produced and a video kind of tutorial produced in the same way I get it right like there's there's got to be something to bring me in and make me want to watch it and like care about that presentation not because like

the tool isn't good or like you can't present the facts about it or like i'm only into shiny objects just because like i only have so much time there's so many of these like how am i gonna pick yeah i i get that and i i think that's an interesting idea i'll say this out loud because i think you were hinting at it but i don't know whether or not you wanted to be explicit about it i want to be explicit about it i think there is a phase that programmers go through where they see dressing something up with fashion or design as a kind of inauthenticity maybe it's part of the phase where they're going through some kind of like anti-establishment, you know, hacker spirit sort of independent streak and looking at something that is presented in a glossy way makes it feel corporate and they reject that. And I think that some people do that very earnestly and with great amounts of principle and some people do it it because it's kind of a cool thing to do at a certain point in your life. I also went through a phase where I rejected things like that and am no longer in that phase.

I'm in a different phase now. that doing something like a like a um not even glossy but just a thoughtful presentation where the presentation has character is that it is an opportunity for you to signal effort and i think that that signaling of effort is the thing that separates like wheat from chaff that separates like somebody's weekend hobby project that is, you know, they're still not really thinking about it separately from light table where it's like, we want to raise a hundred thousand dollars and do this seriously and turn this into a real thing that you can really use. There's a need to signal to somebody how serious you are about this thing. And if you are just doing it as a hobby, then you don't need to put this kind of effort

into the presentation but if it is something where it's like i actually want people to use this and take it seriously doing something like like when adam launched they had like this really nicely produced sci-fi sort of jetsons-esque like 60s vision of the future flying cars style teaser video for a freaking text editor and it was delightful and it made a huge splash and it signaled this is a very serious project because look at how much money we just just spent on this video to like promote it we wouldn't have spent that kind of money on this video if this is just like a little you know one person on the team hacking away at it it's like no this is a serious project from github that has their institutional support behind it and so to whatever extent you want to make that promise to people to say this is a serious project that i'm i'm really committed to like you don't

have to just bake that into the design of the product itself and the visual design in particular. But you can bake that into the here's how I'm, you know, how you talk about it side to make up for if you don't have the skill to come up with a with a novel and interesting look. That's I mean, that I think that makes a lot of sense. And it's definitely something I'm now going to think about. So I wanted to get an aesthetic out of this. But now I've learned I'm, I'm even thinking in the wrong place. Yeah, well, the the aesthetic can be like, oh, it's not enough to be a graphic designer for the for the UI, I need to go and be a filmmaker. Yeah, exactly. And, and I like this. see like i know i'll just i actually will throw in

one thing like you talk about you know whether it's a hobby or a serious project and i do think there's a lot that is signaled in those things but for me i'm more interested in this because i do think it's a hobby project i don't i don't imagine myself starting a company around this editor or whatever, but I want to get better at the things I'm not good at. And so I'm good at giving an in-person presentation, right? I can go up and give a talk and, you know, do those sorts of things. I'm getting better at podcasting thanks to you and having these conversations with you, right? Like there's still all the aspects i

don't know like the audio editing that you do an amazing job at but like that kind of presentation like how would i make videos and social media like all of that stuff like that to me is just a skill and i want to learn it and i find it interesting to try to take my programming hobby projects and add some extra things in there like that so even if i don't even show it to anybody practicing it i find actually really really fun really enjoyable i'll give you a good creative prompt in the same way that you've got the creative prompt of like i don't want it to be a text buffer okay um like a single big text window with maybe some splits i want it to be anything but that, which I've also got some thoughts on.

We should probably return to that at some point. But a similar creative prompt I can give you for how to do a video or something to introduce your product or your project or your hobby or whatever. Calling it product feels weird. I've been corp-pilled. I don't know.

If people want to pay me money, I just got laid off. I'm down with people paying me money, so we'll call it a product. This is your job now, Jimmy. I'm going to refer you, Jimmy, and any listeners who might be listening to this to go check out ia.net slash presenter. These are the people who made IA writer, which is one of my favorite

text editors for the Mac. It's like a super minimal Markdown editor. They made a new app that is called IA presenter. And it's like a you know, what if you could build a slide deck using markdown and so it's just like another markdown editor with some features for adding graphics and it generates layouts and that kind of thing and so it's their new their new product and they have two videos at least at the time of recording when i load the page the the video at the top of the page is just like a bunch of quotes from early feedback from users of the beta and if you scroll down to the bottom of the page bottom ish they have another video that's like your more typical sort of done in after effects lots of 3d camera movements looking at a ui lots of you know big typography with colors and

elements sliding around and and the sort of thing where it's like oh what if we took the the window that the app lives in and like pull the elements out into 3d and kind of rotated the camera around them a lot of that kind of slick presentational stuff with um motion graphics aplenty and like a pumping soundtrack and i would say anything but that because this style of presentation is so tired at this point i remember there was a mail app called sparrow about a decade ago that was the first time i saw an indie shop do a video like this and it blew my socks off and in the time since then i've seen video after video after video that looks like this mimestream just launched they have a video like this. MimeStream just launched. They have a video like this as well. MimeStream, great email client for Mac. Yeah, this style of video

is so tired at this point. It's effective, maybe, but it feels like a really default sort of thing, like a really template, sort of paint by numbers kind of thing. And if the goal is attract interest in a way that gets people to more substantially engage with the thing you're making anything but this anything but this style of video it seems like though if the goal is like investor tech media all of those things, this does seem like the style you might want to go for.

Yes, except I definitely see way more stories whenever somebody does a clever buck of this trend. Yeah, that's true. But who's done this for programming tools? Who has the money to do this for programming tools uh who has the money to do this for programming tools it's just the big you know like your microsoft but their their their stuff is almost always uh it's so interesting because like the microsoft's marketing content the ui they show in the advertisement is nothing at all like the actual product it's so fake they're not

like they i just watched something from build where i was like is that the mac os cursor demoing all these windows features it's like it's so faked up that they're not even using like the windows mouse cursor to show people interacting with these features of windows and at the bottom of the screen and in big letters it says like it said something like basically this is all fake the real thing's gonna look different i can't remember exactly what it said it was one of those like you know disclaimers yeah yeah conceptual design only and you know things like that yeah so but i don't know there is something i know that i i get where you're coming from because i think you're right that if you do something other than that it will probably be more interesting but as somebody who can't even

imagine making that now there's this like extra level of like not only do i have to make something good i have to come up with something that doesn't follow the formula and since i'm so new to like i can count on one hand i can count on zero hands the number of presentations like that i've made that feels a little bit like a tall order so here's the cheat right uh-huh do the thing where you start by parroting something pick something that is like if i tried really hard i could make something that is a tenth as good as this okay um pick one of those things and start like trying to do it because you'll learn a whole bunch of like how do they do that kind of a thing or how how do you even get yeah of high quality image of a user interface that is rotated at a weird angle like it's in 3D space? How do you

even do that? Where do you start? How do you get it when you zoom super far in, you're not seeing individual pixels from a screenshot or whatever? You're not seeing JPEG artifacting or whatever. You see like a crisp version of the UI. How do you see interface elements animating that kind of thing whatever it is that you want to pick pick like one of those kind of things and do your your bad version of it but as you're going you'll be surrounded by all these artistic tools and you might start thinking well what if instead of doing it purely in this way i did it in a way where it's like i get 10 seconds into the video and it's not very good and then the video kind of pauses and then there's a voiceover of me saying like i tried to do a really good video

of this and it sucks and that's just because i'm not a very good animator but you know what i am is i'm a very good programmer and so here let's actually look at the and like go meta and i have seen people do that to great effect there was a uh uh an app for ios called dark noise which is just like a you you you know you listen to white noise to fall asleep kind of app or like raindrops or whatever those kind of sounds and early in the pandemic they did this it's developed by one person and i think they did this video by themselves anyways and they did this video where it was like this like slow motion like kubrickian 2001 sort of 3d like zooming and rotating on an iphone like floating in space kind of like really epic looking shot and they got about five seconds into it and um and i can't remember what the hook was they had to like interrupt this really epic sequence with something really anticlimactic and they did that a couple of times where they're

bouncing back and forth between being really intense and then like really humorously like disappointing and that video did tremendous numbers because it was subverting the expectations and it was done in a in a cheeky kind of humorous way that fit with what this one guy could pull off on his own with a copy of after effects in a couple of afternoons so gotcha yeah no i like it i i think that's an interesting idea even if the end video didn't do that going in and starting with that and then thinking about how to subvert it yeah i i do feel like why do i make this same mistake you know we this is just the same mistake i talked about before where like i think i have to come up with the idea from the beginning instead of iterating on it right and it is just so interesting to i we i've learned this a million times in so many other different avenues but something that

feels magical to me i always end up forgetting like i can just start make something crappy and make it better over time so i mean it's obvious and i but i even do this with like programming things it's what kept me from from learning compilers for so long as i thought how in the world am i gonna produce all these passes that do all these optimizations that like and i don't understand machine code and like and then it's like oh no i just dive in i do one little thing and then like i start understanding all the other ones and i'm forced myself to understand them same thing with graphic programming like i never thought i could build a text editor because I thought doing graphics that are not on the web is impossible.

I have the same thing every time we read a paper where I start reading the paper and I go, this makes no goddamn sense. I'm so confused. Why aren't they just like, why don't they just say what they're talking about? Why do they keep talking around it in this circuitous academic sort of highfalutin way uh-huh where are they going what are they trying to say i'm so confused and then i get to the end it just like clicks and then i'm like oh okay i get it why did it take getting to the end of this for it to all click together? But like all the worry that I had when I was halfway through or three quarters of the way through thinking, I have no idea what this is even about.

Just for some reason, it goes from pure confusion to total understanding in this weirdly magical feeling way. And then I spend a day or however long mulling over it. And then I come back like a day or two or whatever later and start rereading it again. And from the start reading it, it's like, this makes perfect sense. All the arguments are really clear.

I totally understand what they're saying. Why the hell didn't I get that the first time reading it that now reading it, knowing what they're talking about and knowing the point they're building towards i can actually see the structure of their argument and i have no idea what it is about the the paper the essay as a format that you know so frequently does this to me uh and it's not all of them like the the um not richard d james what's his name rpg uh richard p gabriel right there we go yep peter gabriel uh his papers did not have that

effect on me his papers i could actually follow from the start and i could understand what points he was building towards and it was more about like you know he'd set the argument up in a way that i could follow and hook into and then what followed was elaborations on that argument and fleshing it out and filling it in whereas this this essay that we read for for today i was so completely lost and all of my notes going through it the first time are like well these things that they're raising as problems they're not giving any examples they're not really explaining how or why their problems they're just talking about them as if i'd already know that their problems and assume that they're problematic and let's let's justify

why they're problematic but not actually set it up as like is this even a bad thing and it sounds like they're speaking about some boogeyman that you know some specter looming over society that they never established and so it's like well i can understand their arguments if that specter is the thing they're concerned about but they never even mentioned it and then i get to the end and it's like oh yeah okay they were actually talking about this specter looming over society they mentioned it in like one sentence in the intro and then never again and i took that sentence as a like offhand sort of you know well this could happen and then the whole rest of the essay is like predicated on no that's the thing that we're actually worried about happening and

it just it didn't stick the first time i read it um but i got to the end and it was like it all clicked into place and it was like holy crap yeah it's a really you know compelling point well made um all my fears alleviated so that it's just it's strange how that happens but that's a that's a familiar feeling at this point yeah i think i i don't think this is necessarily the case uh in in your instance of reading this paper which i will go ahead i like to mention what paper it is. Yeah, let's talk about what it is. Because I, like people, you know, you have all this intro, this segue,

and then you just never mention it. People are like, it's in the title, but I can't remember now. But wait a second. If we don't say what it is, we're going to hold the listener in this state of not knowing what we're talking about.

And we're going to have this whole, and then at the end it will, okay no no never mind so go ahead interpreting the rules of code performance performativity and production and rules it has an apostrophe s or s in parentheses or parentheses uh so interpreting the rules of code colon performance performativity and production very academic classic today academic title with the colon i only just got the joke why the s really why the parentheses oh my goodness yeah the rule of code like rule isn't like rule of law yeah yeah so this is actually a legal paper and i i was thinking it's like oh singular or plural like the one rule or many rules no it's like the rule is in like the ruler uh-huh the

ruling class that sort of thing yeah see there's some cleverness right at the beginning yeah uh this is in the mit computational law report so like this was published in in 2021 it's by lawrence diver like this is very outside of what we've been doing yeah on this podcast we don't have any paper that i feel like is similar at all it's very recent it's not in the canon of of you know what you would think of as computer science papers it's one that i chose that i really like and i totally get where you're coming from on this feeling of like is this making points that i care about and i do think where you're coming from on this feeling of like is this making points that i care about and i do think some of that comes from i do think like when i read papers maybe

this wasn't the case for you but when i read papers that are a little outside my wheelhouse i do have a little bit of like am i gonna be smart enough to get this paper do i have enough background in order to get this paper and it's easier to project it on the paper itself than your own lack of like background knowledge of where the author's coming from oh i got plenty of that too don't worry but um yeah we'll get we'll get there yeah and so uh you know i do think that some of that is like this feeling of unease, like, am I going to not get it? And so when you get to the end and you did get it, you can now read the paper again without any of that unease. Yeah. Or the question of like, is this a response to something that I would know if I was in the milieu, but because I'm not, I don't know what this is talking about. Or I don't have a strong't know what this is talking about. Or I don't have as strong a sense of what this is talking about.

I might have a hunch or an inkling, but I don't have a certainty. And I will say, going into this, I wasn't sure if it would – like going into this, I was like, oh, Jimmy suggested this paper. He said, you know, it was beautiful, which – Yep. I stand by. That speaks to me when Jimmy says that about something. And I went into it thinking, okay, this is going to be interesting. And I got about halfway through and I was like, I don't know that this is really all that relevant.

And I came out the other side going, this is 100%. This is extremely on point. This is like very FOC. This is, I feel sniped by this paper. Like this, this is right in my wheelhouse. This is definitely like putting a different spin on a whole bunch of thoughts that I've got coming into this. And I think it's really interesting. So if you are listening to this and going, never heard of this paper, don't have an interest in rule of law or legality or all the stuff we're about to talk about, know that coming out the other side, this is directly, at least in my humble opinion,

this is directly applicable to all of the like, how do we think about what it means to program a computer and the interfaces that that affords and the relationship that we have with the software we're building and how we might change programming in interesting ways. I think this is like straight down the middle. Yeah, I never thought when I found this article, I can't remember exactly how, but I never thought when I started reading it that it would actually offer some insights,

to be completely honest. I've read a few papers that are non-programmers, non-computer scientists talking about programming in some way. And often they do feel like they just kind of miss the mark like they might have something interesting to say and they might kind of you springboard off of computation to say those things which i like totally get and i think is completely valid but who they're speaking to is not me right like i'm not the audience but also like i didn't get something out of it even though i wasn't their audience i was

and i was hoping for and maybe that's too tall of an order to ask right like they're writing for a totally different audience as this paper is but i think there's something really interesting here but i also think one of the reasons i wanted to choose this paper is i think there is something lacking in the boldness of the suggestions i think the suggestions at the end they set up this really interesting problem there's something really motivating about the whole thing and then the suggestions kind of fall flat yeah and i do think that's because of a lack of maybe it's maybe it was just like they want to make practical reasonable you know suggestions maybe that's the context they're in but also it feels like there's so many weirder programming things that we could like

inject into this yeah and like give it a little bit more of that spice of future of coding there may be not as steeped in the sort of plurality of approaches that are available if you're a like a somebody who's actually studied computer science and knows about logic programming and concatenative programming and all of these different ways of approaching what it even means to program a computer. You know, Church Thurling. Thurl Ravencroft, noted computer scientist. Yeah, the Church Thurling thesis.

If you know about all of these many different flavors that are available, there's definitely other ways to proceed from this paper to interesting directions. Software code is built on rules, and the way it enforces them is analogous in certain ways to the philosophical notion of legalism, under which citizens are expected to follow legal rules without thinking too much. This is how we start. We're talking about software code is built on rules, and the way it enforces them is similar to legalism. And so I admit, this podcast is going to be a little hard to get everyone in the same mode here it's okay i played the jimmy's philosophy corner stinger right at the start of the episode like right at the very very beginning so we're all good from here on out uh so yeah the next sentence i think is a sentence I can imagine you might have gone, why did I agree to read this paper?

Which sentence? The ontological characteristics of code, its opacity, immutability, immediacy, pervasiveness, private production, and quote, rulishness, amplifies its legalistic nature far beyond what could ever be imposed in the legal domain. This, I think this is one of those papers I've already mentioned that like, there's going to be a lot of words in here. There's going to be a lot of background that we got to do. So like, we've already seen a couple like legalism, ontological, I'll throw out like performativity, legality, ex-ante, ex-post, rulishness, like the vocabulary here is decidedly different

from the kinds of texts we've been reading, the kinds of texts you'd expect, because it is a legal text. And yet, like once you, I do think this paper does a good job of introducing them in the body of the text right the abstract kind of like assumes a little bit more upfront information but it does do a good job of describing them and putting out those what these words mean for somebody who's not a legal

person because i didn't know the difference between legalism and legality or any of these sorts of things in the legal world uncritical deference to rule following is sometimes characterized on the rubric of legalism. In its strongest form, legalism becomes an ideology according to which not only should rules be followed, but they should not be questioned or even interpreted beyond their apparent meaning. So legalism is this mindless rule following. There are laws being established and people should just follow them. It doesn't matter the legitimacy of the laws. It doesn't matter what they actually say. It's the fact

that there are laws means you ought to follow them. That is legalism. And what this paper is setting out to do is to show us that code itself has a legalism that goes far beyond what you can actually get in law. If it's used in a society, if it's used for laws, or if it's used even in corporations, it enforces its own execution in a way that laws cannot. Legalism admits of degrees, however. In its strong, more ideological variant, citizens are expected to act like automatons, minimally interpreting the rules and following them as handed down. There's little in the way of interpretive flexibility and the respect for individual autonomy that this implies. What is normative under weak legalism, i.e. asking citizens to

follow a rule, becomes simply a command, something to be followed mindlessly. Law is solipsistic, sealed off from the social world it serves. It is, quote, self-contained and autogenerative. Enfranchised citizens have a political role, but once the outputs of the dirty business of politics have been converted into legislation, they take on the character of scientific data to be processed by the institutions and vocabulary of the legal scientist. We're getting this sort of spectrum, right? Of like, there's rules, there's laws, there's those sorts of things, but how you actually follow them and how you actually operate under these laws and these rules, there's degrees of strictness there. There's the soft version where there's the rules, but everybody kind of understands that they're just sort of like rough guidelines and you're just supposed to kind of follow them if you feel like it.

And they're there to kind of help, have things like maybe a court as an opportunity to go and plead a case if you feel like oh hey i was told i was breaking this law but i wasn't actually breaking this law and then there's the stronger more ideological dogmatic version the strong legalism which is the law is treated as this immutable, detached, almost surreal sort of thing that is above society, that is not to be questioned, that is not to be disagreed with. And you're not supposed to think about where it came from, how it got here, you know, any of that. You're just supposed to do what it says automatically. And that's the stronger legalism. And it's setting written and out there and you're going to run it, you have no opportunity to question it or to counter it or to disagree with it.

It just runs and you are, it's not even that you are expected to be a mindless automaton. You have no choice but to be a mindless automaton when you are subject to the running code. Yeah, and there's a good couple sentences here that contrast this strong legalism and legality. Strong legalism contrasts with conceptions of legality that acknowledge the importance of rules and legal certainty, but view these only as elements of a functioning legal system rather than its whole.

The more reflexive perspective seeks to respect individual autonomy within a framework of democratically legitimated rules that apply to both citizens and the sovereign rule giver. So here we have these laws. They're very important for structuring our society, but they're just one element. There's the court system. There's the questions of, are these rules legitimate? There's interpreting the rules. And this is going to become a very important theme, is that the way law is interpreted and the way programs are interpreted, there's some parallels and there's some weirdness here there's something

a bit more complicated about interpretation of code and what exactly that means in a way that we have already established for law and just to just to zoom out one step in case this isn't already clear what this essay is going to do is it's going to set up an analogy between the law and code and specifically the execution of code versus the execution of the law it's going to say that these two things are similar but different let's look at their similarities let's look at their differences and it's doing this for two reasons this this what i'm saying right now is the thing that i was missing when i first read through it didn't actually state this up front. So service to the reader slash listener.

It's going to make this analogy between code and law. It's going to do it just because it's interesting to do in its own right. And there's some cool things there in the world who say, hey, we could probably gain some efficiency or some effectiveness if we took some of this fuzzy business of structuring laws and replaced them with software systems that we could encode that law within. And that might help us do certain things. Let make law computational let's use computer tools to help either with the production or enforcement or you know adjudication or whatever of the law and this paper is going to say that's a dangerous idea and to figure that out we're going to have to go on a

little bit of an exploration of the space but the the specter here is people out there in the world saying, let's computerize law. Let's take law and enshrine it within code for whatever motivations they might have to do that. I mean, yeah, you can see this, I think, in its more extreme forms in people who are crypto maximalists. Yeah, sure. Yeah, right. Think about the way in which contracts on the blockchain are supposed to work. The idea is there is a clear unequivocal contract now that is running on the blockchain, right? It's immutable.

It's deterministic. It will execute and it will enforce these rules of the contract between two parties. Let's just say, keep it simple, two parties. And what we saw when we started having contracts actually hold like very big dollar values on the blockchain was those blockchain contracts had bugs. But the question of a bug here doesn't actually really make sense. The whole point of the contract was it supposed to be completely unambiguous. What the contract says is the contract. How it is computed is the contract.

And so the bug allowed people to steal money out of these contracts. But aren't they just following the contract's terms? Isn't that just allowable in the contracts terms? And so I just think this is an important thing to think about as a frame for this discussion. If you take the extreme view of all of society ran by contracts on the blockchain, which is something some people really advocate for, what would that look like and how would it be different from the way laws function today? This parallel between code and law is not the part of this essay that to me seems super relevant to the future of coding.

So if you are hearing us talk about that and wondering, well, what does that have to do with anything? It's not that framing that is interesting. To me, it's the things that surface as it explores this comparison that make this really interesting. So hang on for that if you're wondering what this has to do with anything. Yeah, if you think that this is going to be a politics discussion, that is not the goal. We have to set up the framing here about this legal system, etc. But like, I, I don't intend to be talking about politics the whole time, right? Like, what we're going to be talking about is code and the complications that the legal context brings up in relation to how we think about programs. And that's what I find really interesting. Yeah, like these ideas of, you know, look at it as similar and different to the law, look at legalism, look at legality,

look at rulishness. They give us a very interesting perspective from which to look at code as text and code as performance in the execution. And I don't mean performance in the like speed sense i mean performance is in the like theatrical or the like having an effect on the world kind of sense the other thing that i wanted to say here is you know yes there's this um jimmy brought up like the you know the crypto maximalist sort of version of of this idea of contracts and law and turning

them into code and it also, the essay broadens the scope a little bit here in one of the early sections where it says, the problems of code's legalism arises not just in systems to which legal operations have been delegated, although it will have particular salience in that context, but it's equally important wherever code is employed as a means of ordering human affairs. Just as we ought not to accept the ideology of legalism in the practice of law, so too should we resist its manifestations in other normative contexts. And we'll talk about what normative means in a sec. Be it the rules of conduct in a social setting, such as a club or law, legalism, normativity, which is like the setting of norms.

But this all applies to any context where something that human beings want to do, either in a social way or I'd even broaden it beyond that, just anything that human beings want to do. Like we're used to, as human beings, you know, any kind of human practice or custom, it's going to turn things that used to be soft hard. Yeah, I want to give an example here. Just, you know, the smart thermostat, right? Yeah. I learned that my local city power or whatever, you know, it's up in America. It's a private institution, right? it's not actually owned by the government so there's a private corporation but they're the ones who have

the power uh provide electricity to my home they will give me a discount on a nest thermostat and then like a re and like a discount on my bill on top of that if i buy it through them which i found found interesting and i was i was interested in like okay well you know do they just really think like the nest thermostat is that much better that like it saves them money on operations and saves power no their nest thermostat lets them control my heat and cool air now i don't know to what level. I don't know, you know, if it's overrideable. I don't know any of those things, because I didn't end up doing this. But they actually have a way of looking at it and changing the settings. And so you can imagine, and maybe in this case, they, you know, it's very minor, and it's overrideable. But you can imagine this causing problems. Like today, I set my AC down

very low compared to what I would normally do because I need to have it turned off for the duration of this episode, and it's going to be very warm. And so I try to make it cooler so then it doesn't get crazy hot by the end of this recording. And this might be something that, of course, I shouldn't make a habit of or whatever, but I also wouldn't want that enforced on me through the thermometer deciding it. I couldn't. Even if it wasn't like the corporation actually can reach in and do things in real time, maybe they put a cap on how low you can set it built into the software, and now I'm not allowed to make those sorts of changes. And this is the kind of thing that we're talking about, that it doesn't have to just be law. It can be about the design or an autonomous vehicle that won't let you speed, right?

We can imagine the same kinds of things. And this will, you know, we'll get there in a bit, but this is a great example, so I want to bring it up a little early. The energy company that would be remote controlling your temperature or setting limits on it, they don't have the context that you have. You have the context to know, I'm going to be not running my AC for a couple of hours while I record a podcast. Let me pre-run my AC a little bit so I can pre-cool the space, and then I'm going to turn the AC off and let the space gradually warm up on its own so that it stays quiet. And that lack of context is just a really key thing. And that's one of these things that when we start enshrining things in code, we deprive the later running of that code of context and if you take

context sensitivity away it removes some of the agency from from the human in in you know the human in the loop i know that that term means something specific i should be careful with my use of technical terms here because we've got a whole bunch we've got like so let's just before we keep going we've we've thrown a bunch of terms out already i think uh we should like normative what do you want to say for like definitional stuff about the word normative i mean so normative really is it sounds fancier than it is it's like referring to the norms of society, right? It's a, it's something that has a, an evaluation. So like normative claims are saying something's good or bad. Right. And then there's also the norms of society, the things we as a society

have decided are the way things ought to be. Right. So when we talk about the norms of a certain club, they might not be, the club might not actually have them enshrined in the code of conduct, but they might just be things that people generally practice. And if you don't do them, people will look at you weird and judge you for it. And this is useful in the context of law and this stuff of legalism and legality and that sort of thing, because the stronger versions of legalism, legality and that sort of thing because the stronger versions of legalism where it's like you must all follow the rules automatically without question some people might prefer that because it takes things that are about norms and normativity which would be hey there's these rules and everybody should know like what

the rules are and should follow them but it places the responsibility to do that more on the individual under strong legalism it takes that sort of personal responsibility away and and finds ways to make it more in like automatically enforced and so weak legalism like leans on normativity, like, yeah, it's the social norm to, I don't know, not spit in the street or something like that. And it's just kind of like, you're supposed to know that, right? Like it's left a little bit more up to the individual. We're under strong legalism, it would be like, we have CCTV cameras that do, you know, computer vision to detect when people spit on the street, and serve them with a summons or something like that when we detect it. There's a more rigidly enforced version as opposed to just trusting that people will do the right thing. So normative approaches would like – let you have more sort of self-authority and non-normative ones in the direction of strong

legalism would be like, no, we're going to force you to do that. Yeah. Let's say, for example, we all generally agree, you know, of course there's exceptions, et cetera, that you shouldn't have, you probably shouldn't just walk around with a ton of profanity like printed on your body or on your clothing or whatever, right? And of course, we're not saying in our context, like, it should be legally, you should go to jail if you have profanity. But we would kind of generally consider it a norm going to a playground where children are, and you just have like a big sign that's just like as much profanity as you possibly could, people would say, ah, you shouldn't do that, right? Is there

technically anything illegal about it? Well, it depends on where you are, but in a lot of places, no. Public displays of profanity are not illegal. This is not a legal question. It is a normative question. It's a norms question, right? But I do think the word normative is a little bit complicated because there are norms and then there's also like normative judgments, which are just saying, you saying whether something is good or bad, right? And so I might say it would be bad to do that. And that's a very different statement from saying it is illegal, right? And if, so if you think a society ought to be governed by strong legalism, you would want to replace those norms with laws and say, here is how we

are going to structure our society. But I think the really interesting thing about this essay is that it points out that we can inadvertently do this. We can accidentally replace things that were once norms, that were once up to interpretation, that were once subjective, with things that enforce something we never intended to enforce through computers. And it's not because programmers are all these people who just want to enforce rules on everybody else.

It's that computers are much better at straightforward rules than they are at taking into account context. In fact, the essay goes stronger. They can't take into account any context unless it was designed into them from the beginning. And this is where I think the essay gets so interesting and why I called this out, is it gives us a way of looking at our code and the way of reconsidering a design for how code ought to be that isn't just a subjective fuzzy feeling that I personally have about code, but instead has a very clear aim for how code ought to be in order for it to function well in society. And I think that's a really interesting, different take on the future of coding. How can we make code so that it wouldn't tend towards this legalism? How can we understand what practices can we have? How can we change the design of code

so that instead of tending towards mindless rule following, it could be democratically legitimate? It could be flexible. I think that that's the interesting frame here i'm not sure whether you're jumping ahead or not because that's like conclusion of the paper kind of yeah i think i think we have to get the conclusion out you want to you want to go straight ahead to that okay i just like as i'm like sitting here i think the essay this is always a problem we have yeah essays i do think work better when the conclusion is built to. I don't know that conversations do. This is why I like listening to other shows like, say, Very Bad Wizards.

It's because they do the similar kind of thing where it's like, or I just started listening to a new one called If Books Could Kill, where they're reviewing some text or something like that and i'm always listening to see like how much are they going through the thing linearly and just kind of following the shape of the thing and then at the end delivering their own reflections versus how much are they mixing the reflections in versus how much do they just up end the structure of the text itself and just go in whatever order they want or start with a conclusion and that kind of thing? And what I have found is at least in the ones that I've listened to, they tend to stick with the structure of the thing and follow it linearly through.

And then at the end, by the time they get to the end, their personal conclusions are mostly just like pulling together a couple of threads that have been present throughout the conversation all along. And that, you know, in sort of reflecting on each section of the thing as they go through it in order, they can kind of surface some of their own little, you know, oh, here's the thing it's building towards, but I feel differently about this. Or I feel like, you know, here's a further place you could take it. I guess for me, it depends on what your goal is with these conversations, right? I will say, I think a lot of people, podcasts that I've seen that are trying to do that, I don't think Very Bad Wizards does that. They're usually pretty intermixing all of their personal feelings on a text and random asides and things like that.

But I guess it's, do you want to be faithful to the text or do you want to talk use the text to talk about something here's my concern about not being faithful to the text okay it's that for people who aren't familiar with it if we don't do a good job of laying out what it's talking about in like even if not in order than at least in a kind of a complete picture they won't have a hook for all of our reflections on it and i worry that because we are familiar with the whole shape of the thing if we don't go through it at least sort of in order, or at least have like some summary that nails all the major points that we've prepared to kind of bang through, we'll very likely leave some aspects of the, or some major points or some themes out of our discussion that, you know, we both have as context, but that the listener doesn't.

I see where you're coming from i i do find it interesting though in light of our earlier thing about you not understanding this text until you got to the end and so but when i just jumped to the end to try to give our listener that context you it feels off you jumped to the not not the end of this paper necessarily but the extrapolation from it where it's like let's consider what alternatives there are before we've even set up the alternative to what okay because we've explored like here's legalism here's the the kind of the you know the rigidity of this ideology and we are hinting that programming has that rigidity, but we haven't actually talked about what it is in programming

that creates that rigidity. We haven't talked about like code execution versus source text. We haven't set those things up. And so if we're going to start talking about like, what are some alternative ways? Like what are some explorations of code systems that don't have these properties it would be good i think first to look at how code systems do have those properties that's what i was worried we were missing oh i mean i i wanted to go there i just wanted i still feel like we've been in the the weeds here. Usually we're in some technical weeds.

And I worry that if you don't see that this is really about questioning what programming is, how it ought to be, how can we... Having a project... I guess I see this paper actually more akin to Licklider's vision of what should programming be in the future. In the 60s, asking these questions about how computers should be more than what programming should be, which makes sense in the context. What should computers do?

To me, this is following in that vein, but the way in which it goes about doing that is decidedly different, right? It is a very particular argument. It does have very particular points that I do think we need to have, but I guess I just wanted to make sure we see this bigger picture and we don't get lost in just the details

because I think that's one of the most interesting bits about this. Yeah, I'm not worried that we're gonna not catch that on the back side okay we're definitely going there okay good good yeah so i had something that like right when you started branching off to the let's look at uh ideas for programming language stuff i had something that followed right after what you were saying that i think sets up this relationship between the legal stuff and the code stuff and it's a it's a passage to read if you're cool with that perfect

uh so this is from section two two section two two i'm not suggesting that designers and the programmers of code necessarily harbor a legalistic ideology, however, what matters more is that code, by its very nature, tends towards the embodiment of strong legalism, and that this is the case regardless of the intent of the programmer, however vicious or virtuous that may be. The ontological features of code very easily facilitate the strongest of legalisms, under which the ideological ought of strong legalism, as in, you must follow this rule without thinking too much, becomes the technological is of code, as in, you have no choice but to follow this rule, or indeed, the very nature of your action is

constituted by it from the outset such that there's no possibility to act otherwise. What was normative becomes simply descriptive. This on its own should be sufficient cause for concern, but when it's combined with and amplified by the other characteristics of code, the picture becomes starker. The sheer speed of execution collapses any opportunity for deliberation, an effect that is in turn amplified by code's relative immutability at execution time, which prevents the possibility of the rules it imposes at both the back-end infrastructure and the front-end interface levels, the sheer amount of it operating around us, and of course, its production by private enterprise for profit, the simultaneous parallels and contrasts with legalism become clearer. clearer that paragraph to me is where it at least most coherently makes the argument for or at least like lays it out lays out the pieces of what it is about code that makes it legalistic it's the combination of like the intent of the programmer is removed from the picture. The way that the code is executed removes opportunity for participation on the part of the person who's executing it. And that if the code has been built in this way that there are actions that you would like to take but that the system hasn't been designed to support them you don't have any opportunity for appeal and so an example of this that i've got is i i live in the country i live in the woods i have a weird mailing address my mailing address is basically like the name of the route that the mail delivery person takes so my my mailing address is rr2 clive alberta t0c0y0 canada self-doxing

and the rr2 like rural route 2 like like there's multiple rural routes that the mail delivery person takes and my my address is just rural route 2 rural route 2 is this huge winding path through the countryside it's not a region of the world and so when when i have to enter my address for one some systems will accept rr2 all as one word. Some systems will accept RR space two, but not RR two all as one word. And if I don't type it in the way that the system expects, it refuses to accept it. And it says you don't have a valid address. Some systems won't accept this kind of address at all because it's not a street address. I have no number that begins the address or no specific, you know, this house number or whatever.

Some people use a mailing address as a way to determine your location, and this address doesn't work for that. And so here is a system that predates computation where the computerization of address, you know, systems for mailing or for physical location often don't expect the kind of address that I have. And so they frequently tell me that my real address as it's printed on my government documentation is not a real address. And I have no opportunity when encountering these systems, like if I'm trying to book airline tickets or something like that and they balk at my address, I have no opportunity

for appeal. I have no opportunity to talk to the human who's acting out this algorithm and say, hey, so you know this is a real address. I am forced to either conform with the coded system however I can. So I learned after a lot of trial and error, oh, sometimes if I put a space in between the RR and the 2, that will trick whatever formatting thing into accepting it. Or sometimes I just can't proceed to use whatever system it is. I can't order from this store. I can't buy this airline ticket through this website. Yeah, I think that really gets at this contrast here because this is very different from the way in which you would have to deal with this in a human or a legal context, right? In this case, the medium is that computer. It has these certain rules programmed into it, what it will and won't accept. Whereas dealing with a person, dealing with a legal system,

you could appeal to the person's external knowledge, right? That program knows nothing about rural Canada. It knows nothing about these external systems. And if you tried to explain to it, hey, but I live out in the middle of nowhere, and this is the route, and all the things you just said, what would it even mean for that program to accommodate those sorts of things, right? And if it can, let's say there's a program out there that could, it could only do this because somebody thought beforehand to add that affordance to it, to be able to accommodate appeals about addresses, where no such thing has to be the case in our legal system, right? We don't have to put in an explicit rule that like oh well

if the address is weird then somebody could appeal it like you can just talk to people and they can have you utilize that knowledge from outside the system and so i think this is really what this text gets at like right after what you just read, is that the difference between the way programs enforce their rules and the way legal institutions do is legal institutions are almost all what they call ex post. They're after the fact. So let's say you put in your address into – like let's just make up a scenario here right i want to keep this address one because i like it let's say you put into your address and you signed on some contract and the company thought like you gave them a fake address and like that's a breach of contract and now they're like suing you or something right well if you go to a court, you're going to be able to, after this problem has happened, say, here is my explanation.

Here is why this address is valid. You can provide documentation. And so the only way those people can do anything, get money back from you, force that contract to be null and void, whatever, would be going to this court system after the fact. Now imagine instead of going to a court system, they were able to sue you through a computer system, and they said, this address is invalid. The computer system would just look at it, say, yes, it's invalid. And now you would be forced to pay them in this made-up scenario that I have, right? And so once code is out in the world, and once it's running and it's constituting these systems, it is the thing that lets you book the airline, it is the thing that lets you order from that store,

nothing can be done about it. This is why it inadvertently creates this legalism. Because it's not immutable in the sense of no one could go patch that, right? You can submit a bug report and go get them to maybe fix their system, right? Very unlikely that an airline is going to go change their system to accept your address just from you doing a bug report. But at the point of you interacting with it, there's no way you can change it. It's immutable from your perspective in a way that a human being would not be. Section 2.3 lays out in more specific detail a couple of different permutations of how this happens. So the first one is mind mindless execution the second one is hard

edges and the third one is limited ontology this mindless execution one is the one that to me is the most interesting um i bet we'll come back and talk about limited ontology because we haven't had an ontological discussion yet um but this mindless execution it's the idea that um the code that is written is going to execute um with kind of two sides to it there's kind of like two sides to this coin of how code executes one of them is that it is going to execute only when all of the conditions needed to execute it are met so if you don't exactly satisfy all the conditions that are needed to run the code, it doesn't run at all. It's very all or nothing in that way. And then the other side of that is it's going to run whenever all those conditions are met, no matter what objections you might have to its running that you know as soon as you meet all

those conditions it's going to do exactly what it was programmed to do to the letter even if there's extenuating circumstances even if there's some some reason that it should not execute or shouldn't execute in exactly the way that it was written it It's not sensitive to context. And that, those two things create a kind of an inflexibility that is like a real pure legalism. Like it's that mindless automaton. And this is something we haven't talked about yet,

but there's a kind of a sort of a stack of mappings sort of between the legal side and the code side that I kind of pieced together as we are – as I was reading through the paper where it's like in this analogy, like the programmer of the system is kind that are going to be of interest in a minute. The code that the programmer writes is like the law that the legislative body creates. These are, you know, those are the rules. And the programmer, legislature, both of those are people, right? That's an important, I think, thing to be aware of. This isn't an idea that's really explored in this essay, but it's one that I found interesting. It's like programmer and legislature, both are people.

Code, which is law, you know, there's the mapping. Both of those are texts. The execution of the code is equivalent to, in my read of it, civil society. So this is the environment where those laws, those rules have their effect. The rules of code have their effect when that code is executed, wherever it's running, which is later on. It's that ex post, that term, ex ante, the thing before, ex post, the thing after. So the execution of code is ex post and civil society where those rules are applied, you know, also ex post. There's a difference, an interesting difference here where the execution of code is mechanical in its nature or it's happening on a machine. And civil society, I don't think of as a machine. I think of it as something different than a machine.

And then finally, the person who is running the software, the person who is interacting with the running software is equivalent to whichever citizen is down to the very personal level of an individual person who is running some program or who is trying to type their address into some web form which is the same as like some individual person who's like trying to cross the street and you know subject to all the laws that govern how you're allowed to do that say and so that that that mapping between those two things is important because we need to be conscious of another detail that's in here, I think, which is that legalism versus legality, it touches on this of a little bit of maybe libertarian philosophy because, you know, there's a section here that talks about cyber libertarianism. But it suggests this idea that the internet and cyberspace and computer code and, you know, the blockchain and all of these things suggest that there's a freedom that the internet has. the internet is is sometimes seen as this lawless place it's seen as this place where you know there's no presiding country that's governing the internet it's sort of this you know this second world with its second set of laws and norms and that sort of thing and the laws of the internet historically are technical in nature.

And some people see this as a cyber libertarian utopia where it's like you can do whatever you want. You're free to do whatever kind of thing you want on the internet. On the internet, nobody knows you're a dog. You can escape the tyranny of lawfulness of the real world and go and be free to build whatever kind of business or venture or

community or what have you on the internet and this paper does an interesting thing where it it counters that point quite directly and points out that the opposite of legality the opposite of what we have in our you know in our countries and our civil societies with laws from legislatures is not this sort of anarchic free world where anybody can do anything, this kind of cyber libertarian paradise. And I know I'm doing a disservice by comparing anarchy and libertarianism but it's not that absence of rules because the internet is created through code and because the online world and if you imagine one of the one of the references that it sneaks in a in a footnote is the metaverse right if you think about these other worlds that we're creating in this virtual space because they're built from code, the role of the person and the role of the society is more constrained because the nature of the code is more constraining.

And so all of that, I wanted to like wrap all of that up into when we're comparing law and we're comparing code, it's important to think about which of these things are people, like which for all of these different roles in the process, which ones are people, which ones are texts, which ones are systems, right? Execution of code is a system.

Civil society is not really a system. And I think there's an interesting difference to explore there. Under what circumstances somebody subject to these rules and are the people who are subject to the rules the same people as the ones who are creating those rules that's that's the other the rule of law aspect the sort of gets back to libertarian philosophy this is not a politics

podcast jimmy said we're not going to talk about politics that that is about as deep into it as i want to go but i wanted to point out that like that's another dimension along which this paper looks yeah the point about this like cyber libertarian thing i think is very interesting regardless of your political view on it that code is what constitutes this place is the way that it's put here right that code is what makes the cyberspace what it is. And as we get more increasingly commercial code, you can think of the metaverse made by meta, right? What you are free to do is just what that commercial entity has decided is possible in that space.

Whereas in reality, we have all sorts of things we can and can't do, and they're only enforced through someone attempting to enforce them. Code does not need that person attempting to enforce anything. And that's where this mindless execution comes in, is not only is it execution like somebody can enforce something without a person being involved. But also there's a disconnect between the intentions we put in the code and what the code really does. I almost never intend to write a, an infinite loop that's going to lock up my computer, but I often do it, right? And it's because the, the meaning of that code in some sense is complicated. There's the meaning I intended, and then there's what's going to actually happen. And when we have a legal system, we can attend to that meaning and decide how to execute

afterwards. So we as citizens can decide not to follow the law because we think that even if we believe that that's how it was written, because we believe the law is illegitimate, we can protest that i don't want to follow the the exact letter of this code that i'm running i want to do something a little bit different and that's where it's going to point to interesting relations to the future of coding yeah so we got this mindless execution we got hard edges which i do think kind of kind of play in with each other, because you talked about the conditions being such that you have to exactly meet these conditions. And that is what this hard edges is

about, is if the rules are not met, the code will never execute, regardless of any other consideration. So the address is not valid. You can't book this flight. This is a hard edge. There's no softness to this. And any, I love this passage here about, well, you might think this isn't really the case. There's often times where like, maybe I put in my address and it's like, I've gotten the thing. So my address is not as complicated as yours, but it used to be a duplex uh on this same lot and so they think i need an apartment number for my official address and so often i'll put in my real address and they'll say is it apartment a or apartment b

like you need an apartment number that this is not a valid address and some of them will let me say use my address anyways some of them will force me to put an apartment and i just put one and i happen to know that the mailman's going to ignore it like i rely on that ambiguity and so but i love this point that we might think oh no there is ambiguity here there are these fuzziness allowed, but the way this is put is, any apparent ambiguity is illusory, since it has been consciously designed and is made manifest at the level of human interpretation, but it does not and cannot exist within the internal calculus or logic of the machine. By contrast, all human understanding is predicated on the interpretation of the potentially ambiguous, which requires a pre-existing horizon of tacit knowledge that necessarily fills out the limited depth of the communicated text.

I think this is really interesting that all ambiguity we put into our programs is intentional ambiguity. And of course, it's real. I understand this like apparent ambiguity is illusory. I think that's an interesting way of phrasing it. I think you can also say that the ambiguity is real. There are programs that can be non-deterministic, that can run in different ways, even though underneath they're following from these rules, there's kind of this way. And yet, there's a strong contrast between that kind of ambiguity and the ways in which humans have ambiguity. The ways in which we attend to it, the ways in which we think about it, the ways in which even if we weren't planning on it, we can stop and ask for clarification on that ambiguity before continuing on. There's no mechanisms that we have in our programs that allow us to do these kinds of things.

It's around this point in the essay that I started really asking two kinds of questions and in the end the essay um did satisfy my my sort of what about ism that i'm about to bring up um and in in two two ways one way that i was sort of wondering well like how is all of this questioning about you know all of these aspects that must be designed in intentionally if they are to be there at all in the code system. So if you want ambiguity, it has to be consciously designed. It started, you know, at this point in the essay, it started bringing up matters of the design of systems. And so I started wondering, like, how is this different from something like a double A battery or a government form or a garden, you know, any of these things that are part of the

built world? Code is, you know, a built thing built by humans. It's subject to engineering dilemmas and it's subject to, you know, the math on which it rests and physics and that sort of thing and we are we're wielding that we're weaving it into whatever permutation we want and i have all these questions at this point in the in the essay about aren't all of these problems that it's talking about some of this rigidity some of this you know you're forced to use it in a certain way that's kind of true of a lot of things that we've built how is code special and i think it's worth you know me kind of saying here's how to resolve that tension you know it's like if i am holding a double a battery there's the expectation

that that will fit into certain electronic devices that accept AA batteries and that will work when it is charged and et cetera, et cetera. It will not work for a AAA battery unless I take some wire and, you know, splice it in and the voltage is right and what have you. But the AA battery, I can also, you know, if I was really intent on doing it, I could use it to smash a window or i could use it to mash a potato or there's like a certain flexibility afforded by the the real world and i was reminded immediately upon thinking about this of dynamic land like that's dynamic land's whole steez is if you put the programming in the real world you get this automatic you know all the laws of physics. It's like import physics from real world, right? You get that for free. You get all the malleability of the physical space and physical matter and all the tools we have for working with it, scissors also, the thing that this essay is really speaking to,

without all of the automatic limitations that come from doing something in the code environment where the only things that are allowed are the things you explicitly allow. Reality, you know, you could say the same thing about reality that the only things that are allowed in reality are the things that are explicitly allowed by physics, but that's a huge set of things in terms of the human experience in terms of what it means to be a human being in the world like physics and society allow for a

great great many things and a great deal of flexibility within those things and so code is not um maybe not categorically different from other things in the built world, other things that are designed, but it is definitely different by a great degree, at least in this respect, in terms of, you know, hard edges and the limitations that are automatic unless you intentionally release those limitations. Yeah. and I love the point that's made here, which is even for software that is flexible, its flexibility is defined in an inflexible way. You think like Emacs.

Emacs is a very flexible piece of software. When you want it to do certain things, it's very easy in the system to do that if you're trying to change the kinds of things it meant for you to change, right? So, and it's, of course, it's not that you, nobody could ever change it to do anything you want, you know, if you have, if you could recompile it and go do, of course you can do anything you want with it, but the point is, at the point of execution at the compiled artifact, there's only so much you can achieve. And it's because it's designed to be flexible in that certain way. And so already here, we see this

transition in this essay from just talking about these problems to what hinting at here in 2.3.2, like what is going to end up being the solution is to start looking at the program before its execution. That if we want to have these problems solved, looking at code when it's executing in society is not going to be good enough. We have to look at the underlying source of the program. We have to look at how it's produced. We have to look at the underlying source of the program. We have to look at how it's produced. We have to look at those things because in order to design these things properly, we have to get it before it actually is out there in the world causing the problems

it might cause. And that actually, that thing you just described is also what's covered under 2.3.3 limited ontology right if its designers anticipate only responses a b and c to conditions x y or z these are all that the code can ever react to yeah it code doesn't care about your intentions code will not execute unless certain conditions are met, but then also code can't expand itself beyond its bounds. If it was made with these ideas in mind, that's all it can do. For example, we as people might be wondering whether we should take a certain action, and we can decide, oh, well, I need more information. I'm going to go down the street and investigate something.

I'm going to take a picture of something and study it closely or whatever. Code doesn't have that kind of flexibility. If it's going to take an action, it's already built into the fact whether it's going to take that action or not. It can't all of a sudden change its mind and decide, now I need new conditions. That's just not in the nature of a running executable program. So I think this move from the text,

from looking at the execution of the program in society to looking at the text of the program brings up a question that I do think is actually really important for us to consider, which they put as, who is the interpreter? And I think with code, it becomes a little complicated because we use that word interpreter to mean the thing doing the execution, right? But we also use it to mean the person interpreting the bit of code, right? And so I think this is the move we're going to move towards. Instead of looking at

the interpreter, meaning the program that runs the code, we're going to start looking at how should we as people interpret the source text? How should we understand the meaning there? How can we think about the effects it's going to have in the world? And I think this is kind of this turn that we get in the paper as we're moving here is moving away from thinking about the machine as interpreter and thinking about humans as this interpretation. There's one other term that is relevant in this context that we're probably going to use, and so I just want to define it right now,

which is performance or performative. Just to be clear, when we talk about performance or performativity, we're talking about the effect that the code has on the world, not like how quickly does it run. So the interpreter is the person looking at the source code and the performance is the effect of running that source code on the world yeah and so what we actually get at is what does code mean and there's this notion that code means what it does. The meaning of code is just how it runs. You'll see this idea of meaning and that it's somehow simple

and that we can really determine it being pretty common in computer science. Now, a lot of people won't say it's how it runs. They'll instead say it's the formal specification of how it ought to run, right? Like that's the meaning of a program. And I think what we really should care about as future of coding people, as programmers in general, is that the meaning here is way more complicated than just the effects that it has in the world, just the way it runs. That there are all sorts of things

that maybe won't ever happen. Our program won't ever run that way because the conditions aren't met that are part of the meaning of our code or these things that might not have been our intentions that are in the code. This is what I loved about this essay is this switch right here, where we go from what is the legal context, how does it relate to programs, to what is a program? How should we understand them? For some, the meaning of code lies only in this performative role. But this can only be true if we in effect delegate interpretation of the text to the compiler, while at the same time limiting the interpretive role of humans to the observable effects of the code's executions. While those effects are indeed where computational legalism can be witnessed, they are not where it will or can be challenged. The documentary purpose of code

can give us insight into what effects are likely to be before they are let loose in the world. The salient difference for computational legalism between interpreter, human or compiler slash CPU, and the object of interpretation, text or effects, thus lies in the temporality of the interpretive practice and its documentary role. Prior to execution, the interpreter of the code is a human. The essay starts making the point that there's kind of two sides to a program. There's the side that is facing the human who's writing the code, and there's the side that's facing the compiler or the machine that is executing it and the side that faces the human can be designed it is a designed artifact and

that we're going to have a lot of questions about how should we be designing the human facing side of our programming languages in light of all of these concerns we have about legalism and then there's the the side that is executed by the machine and there's kind of like i mentioned you know there's a phase that people go through where they see you know corporate marketed uh programming tools as being inauthentic i think there's a phase that people go through where they see like the truth of the program is in what it says to the machine, how the machine executes it. You talked about this a moment ago, Jimmy. But this separation of the nature of the program, the same source text can be very, can mean

very different things to the person reading it versus the computer reading it. But there can be a wide gulf between these two things. It's really interesting. We're going to see some examples of that in a minute. But then there's another gulf that it sets up here or that it's been setting up all along where there is a temporal gulf between when the program is written and when the program is run that's the bit jimmy read um the salient difference for computational legalism between the interpreter and the object of interpretation the object of interpretation is the the text of the code or the effects that it has on the world lies in the temporality of the interpretive practice that the text of the code

prior to execution is documentary. It's documentation. It's meant for a human interpreter. And then the actual execution happens later on. It happens well after the fact. So we've got these two gulfs. We've got this temporal gulp, gulp, temporal gulp, it's a big gulp, temporal gulp between when the code is written and when it's run. And we've got this meaning gulf between what the code means to, what the code text means to the programmer and what the code text means to the machine. And to kind of tie this into other things we've discussed, I think this is kind of what Naur was pointing out

in programming as theory building. He contrasts this view that programming is really just the creation of a programming text or the running artifact. And he wants to say, no, it's about us building up this certain kind of knowledge. And that really, I think the point of this essay is we often only attend to the effects, the running code. We don't think about the kinds of knowledge we have, the intentions we put into this. How could we better design these

things? How could we better build a theory that achieved these goals of different effects at the end, right? I think this moving towards the text, moving towards the creation of it is moving us towards that building of a theory. There's a lot of culture, programming culture out there that is about how to wield code in its form as documentation of programmers intent that's like you know practices around commenting practices around project structure things like mvc things like testing like the way that you're supposed to use testing or testing versus types and that whole debate things like the book code complete which is a great way to start a campfire. There's a lot of culture around how text code should be used as a handle that the programmer holds onto. essay points towards eventually and where i'm most interested in following this essay's vector is that we ought to reconsider how we even create programming languages in light of these gulfs and

the legalism that ends up resulting at the end and that it's not sufficient to say hey we should be adding comments and we should be adding you to say hey we should be adding comments and we should be adding you know tests and we should be keeping architecture decision records and that we should be pairing or all of these kind of things that the very nature of the programming language itself and the very nature of compiling or machine interpreting the code or the very way that the code is eventually executed as being a black box that the person subject to the running code doesn't have any way to interact with. We've got to really rip down to the foundations

to start solving some of these problems with with code's strong legalism yeah and i think this next section 3.2 here i don't think we need to go into all the details of the fancy words and stuff that are used in it but this is we can i was trying to spare you so this this section is called code as speech act and like this is the jim Jimmy's philosophy corner of Jimmy's philosophy corners. Like this is. Yes. So that's why I was trying to spare you. I didn't want to,

you know, per locutionary, locutionary, illocutionary. There's all these fancy terms in here from Austin that even like philosophers think are very confusing terms to be completely honest with you. Like, no, that's easy. I got, I got this all right oh okay so a speech act is when you say something that is meant to have some kind of an effect in the world like please pass the salt

that's a speech act i'm using speech and jimmy you can correct me when i'm done oh yeah that's fine go i'm using speech to effect some change that I want, you know, to have happen in the world. And there's the perlocutionary, locutionary, and illocutionary are just all about how and when does that effect happen. One of them means it will happen immediately when i say the thing so the canonical example is i now pronounce you husband and husband or wife and wife or wife and husband or whatever i now pronounce you you know spouse and spouse that pronouncement as part of a marriage ceremony

has an immediate effect there's another kind of speech act which has a delayed effect where it's like i'm gonna say this now i'm gonna make the speech act now and it's gonna have an effect later on like you know you need to go to the dawn's house and tidy up some business stuff with cement shoes in the river of the other mob guy see yeah very new yorker of me um uh that is like a hey you need to go do this thing has a delayed effect and then there's the other kind of speech act which uh doesn't have an effect i can't remember what the third one is yeah it's like this is a speech act. Maybe something like saying I love you.

That might count. I can't remember a good example of it. The ones that don't have it. Just like saying like the cat is on the mat. That is just a true or false statement. Right. You just stating a fact. There's nothing that happens from stating a fact.

Yeah. And I know that you're uncomfortable about getting too weedsy in this, Jimmy, but this is like super relevant to programming as far as I'm concerned, because if we're thinking about how do you even redesign programming, I think it's good to think about, hey, programming is all about making statements. Here's an interesting framework for thinking about making statements. Yeah, I think this is really interesting, in my opinion, thinking about code as a speech act. So the idea behind speech act is, you know, I do think you did a great job describing it. I'm just underscoring what you said. Like, it creates an effect in the world just by its utterance, right? If you, like the most canonical example is, and God said, let there be light. And there was, right? Like this is by

speaking, you are making something happen. And so the pronouncing somebody married, promising to do something is another pretty canonical example because you've now made it true that you like have a commitment to do so right but there's also all of these things about like the conditions that must hold right if somebody if i just go around the street yelling i now pronounce you and pronounce people it's not a legitimate instance of the speech act. We're not, these people haven't agreed. I'm not an officiant. There's all sorts of things that have to happen in the world. And when we write code, we are actually setting up these things that will happen. We are performing speech acts, right? Maybe we're not speaking it out loud. That's not the point, right? We are writing code in a text that will one day run and make something happen.

And the question is, that I think is really important here is like, okay, what will happen under what conditions will it happen? And these are all things that we might not immediately think about. We might have effects in the world through our act of coding that we don't foresee. And we know we are going to. There's all sorts of things we do that we don't foresee in code. And we have to ask, as code plays a bigger role in society. What do we as programmers have is this kind of obligation to think about this performativity,

this fact that our code will have practical effects in the world. And I want to put out two things that I've already in programming just to like draw connections here. I already explored some of this. So first, Elephant 2000 by John McCarthy is of Lisp, the creator of Lisp.

He wrote a paper about a programming language that is SpeechX, that has SpeechX as like a first-class thing in it, but also DynamicLand, to bring that back up. DynamicLand is SpeechX, the programming language, right? There's wish and claim as these two keywords. And so to claim something is true, well, if the certain conditions are met,

you have now made it true because I am claiming that it is and I have the right to claim it. And wishing is an interesting one because you might think wishing is not a speech act. Like what does wishing do in the world? Well, nothing unless you have a genie. If you have a genie there and you make a wish, you make it come true.

And so I like to think of dynamic land, real talk, OS as the genie that fulfills your wishes, right? And so it makes these wishes come true. And so it makes your wishes a speech act. I just find that connection wonderful. I absolutely love it. And so if code is a speech act, if our code has effects in the world, if there's this latent performativity that once we ship it, it's just going to happen.

We can't look only after the code is already shipped. We have to think about this beforehand. And in the context of this essay, the question is, how do we make this, our code, legitimate in the social world that we live in? How do we make sure that it isn't going to have this strong legalistic effect? I think that is a question that is, it's complicated. I don't, I don't, like, I don't know that there's an answer given here.

In fact, I think the answers that are given here are, I know we're not quite there. Like there's a lot left in this paper to get there, but I think it's important to like take a moment and think about what would that even mean? Like beyond documentation and testing, what would that look like? I think it's a hard question to answer.

I've got some real easy answers to it like that's why i was saying this is this paper is like right down the middle for me i felt sniped by it as it's like okay i could easily project onto it some of my like here's how i want programming to be different here's what i'm you know interested in exploring kind of ideas. They felt very nicely aligned with some of the issues surfaced in this essay. So before we – I'm curious. We have a lot – before you were saying you want to like walk through this essay kind of more in order. How are you feeling about this? Yeah.

I wanted to make sure we like set up the the argument and really export it i think we've mostly done that now like like there's a lot of filling in the details that it does um but uh like previously when you were when i was like no no don't jump ahead it like, cause we hadn't even broad stroked the whole thing. Yes. Yeah. I think, you know, there's a lot about like the difference between speech acts and code and the speech acts in legal context, right? Which are probably very salient for the audience who, you know, this paper is intended for

like judges can determine certain things of speech acts whereas code there's no human involved it's back to this mindless execution there's a lot of talk about kind of like uh code as document looking at like comments looking at literate programs looking at these kinds of things but i do actually i do actually want to maybe stop in on a little bit of that section here, this 3.3 code as a document. I just liked this contrast of how we can interpret texts. There's two ways we can try to interpret our programs. And I think this is actually just a very good practice practically but the first is uh what they call the the hermeneutics of faith this is to take the text

at face value uh ivan is wincing at that no i'm laughing because it's like i didn't want i didn't make any notes in this section because i didn't want to have to read all of these terms because i'd probably mispronounce them or do a bad job of explaining them so i'm like i'm just delighted that it's like oh yeah that was this section jimmy's going here i didn't have to bring us here so if if you know if jimmy messes up any of this stuff great i'm i'm not gonna look stupid in front of however many thousand people are gonna hear me sound stupid so hermeneutics is just how you interpret a text it's just the the process by which you go about it so the hermeneutics of faith the text is taken at face value and the meaning

that the author apparently intends is accepted as such so we just look at like what did people say in this text we're gonna assume that they're being honest, good people. We're going to assume there's a single author. And then there's the hermeneutics of suspicion, where you're willing to suspect that there's something underneath the text going on, that there's power struggles, there's conflicts, and there's interests that are hidden in the text, that it might not be in the plain spoken words. How many times have you left a comment that really you wanted to say

the person who built that system over there did an awful job, I hate it, and this code is to patch up their bad hacks and bad bugs, et cetera, but you don't say that, right? You kind of make the language a little bit more flowery, like for business reasons, it was decided that this, or it's important to note that this system will produce these things.

When you read that comment as a programmer, you can read it just as it is, or you can see the underlying words that were not said. The intention of why is this person being overly polite and technical here when this comment is really, I did a dirty, ugly hack, right? And sometimes we are just like, ugly hack, right? Like we'll just say it directly.

But there's always these underlying things about the way in which the code is actually created. And the point of this, I don't think we need to go into all of the details here, but the point is that we actually have to, if we're going to make our code legitimate, we can't merely look at what we, what the code is intended to do. We can't merely look at what the code is intended to do. We can't merely look at what the code purports to do. We have to think about these underlying facts and the interests behind the code and what the context it's going to be deployed in. And we have to really be rigorous thinking about

how we interpret our code. And I don't think as programmers we have a practice around this, and this is something I wish we would create and make a culture of. It's the only reason I wanted to pull it out. Cool. The only reason I wanted to pull it out is because I taught Astrid, my four-year-old, in circumstances where one might say, well, what are you going to do?

I taught her to say say hermeneutics really yeah so uh so occasionally she'll just like i'll be you know putting her in her car seat and she'll be like where's the milk and i'm like oh i forgot it back in the coffee shop and she's ludics she has no idea what it means of course but you know fun you can have when you have a four-year-old but she knows the context and since meaning is used according to wittgenstein she knows what it means definitely yeah there you go that's how i'll end the philosophy section there well well hold on a minute well wait a minute wait a minute jimmy does not end the philosophy section editor i ends the philosophy oh well there's not a end of jimmy's philosophy corner so there's no little and that was jimmy's philosophy corner there is as of the Intercal episode, the Intercal episode has an ending

Philosophy Corner theme. It has a version of it where the fact that it's actually just a variation of the Let's Dive In theme is more apparent, A. B, the ending version now has Lou singing along with it. And C, just because of the shape

of the conversation it had, the thing you said immediately after the ending in the last one was, prove me wrong. And so that's going to be part of it from now on. That's going to be the ending. I guess I didn't notice that as the end of my philosophy class. Yeah, you'll get used to it. Yep, got it.

Prove me wrong. I loved that argument. That was the best part of that paper. Yes, that was great. What a good paper. Yes. So we get to section 3.4, which I think is like now we have definitively crossed over from we are thinking about law and how things work

to generally. Let's think about programming. Let's think about the future of coding and so for me i'm we can talk about what this system sets up but i think this is where we should really start reflecting on some of our thoughts on here now right off the top right off the bat ah there are these terms. Oh, crap. We skipped over the part with brain fog.

I was hoping to get you to. Two times this episode, I had the opportunity to bait you into getting beeped, and you didn't do it. One of them was like, what if you held up a sign with a bunch of profanity? And I was like, come on, Jimmy, give us an example. Say. I thought about it. Say. Jimmy, please. Please. up a sign with a bunch of profanity and i was like come on jimmy give us an example say i thought about it say jimmy please please oh wow i had a i had a uh uh halfway between a friend and a girlfriend when i was uh in in uh art college and uh she listened to a band and their band shirt was just the word huge letters and so she was somebody who walked around with profanity in huge gothic sans serif on a shirt just all day every day

i know that word is uh less uh negative in certain cultures like australia yeah uh but at least the united states i think i don't think there's a word you could use that would be considered more profane. Exactly. Yeah. It's the best. Yep. But no,

I actually thought in that profanity, me talking about profanity, Jimmy's profanity corner. I intentionally didn't say it just to make, cause I knew you wanted me to, I knew you wanted to have the beat because you didn't believe me that that was the first time you had to censor me, and it was. Yeah, yeah, yeah.

Damn you. Yeah, so we skip over the section with brain fog, which is just like there's a section here where it shows Python, JavaScript, and brain fog to make the point that the computer will execute all of these different languages with equivalent duty. But to the human programmer, they read very differently. They serve a different documentary function. And it refers to this as the bidirectionality of the text. That in the direction of the machine compiler, it means one thing. And then the direction of the human reader and writer of the source text, it means something different. It calls that bidirectionality.

So if we talk about bidirectionality, that's the specific meaning in the context of this paper essay. So yeah, section 3.4, producing the code rules. And this section rules. This section has – so it has a couple of terms that it uses that we need to introduce. One of them is the programmer of the programmer or the P-O-P. The POP. Which is the POP, which is basically the way of – that this essay distinguishes between the programmers who are creating the programming language that you use and then the programmers who use that language to write whatever application they want. And the essay is mostly focused on the consequences of building some software within an existing programming language and how that creates legalism but it identifies as a as one root cause that ought to be explored the work of the pops the work of the programmers of the programmers because

the people who are creating these languages are creating a program and it has all the legalism problems of that we've been talking about all along so when you use a programming language you are already stuck inside a legalistic domain and your choices your agency is already restricted you are already an automaton you are already mindlessly following the path that has been laid out by whoever created your programming language. And in a sense, you have been programmed by this environment. So that's why they call these people who make programming language the programmer of the programmer. If you're writing some software in a language, you have been programmed by whoever created that language to operate in a certain way.

Yeah, and this actually ties into the same kind of rule following that we see in the legalism divide. Because what is considered valid in your programming language is not up to you. It is just constituted by the compiler the interpreter the lent or linter whatever right like that is what decides there is this predefined grammar and even if you think like oh well it's lisp and i can write my own like there's still limitations on what you're able to do there and even even if you want to go extend it, you have to, before you extend it, write in that grammar to then go extend it, right? There's always going to be this kind of restriction

that you can't get out of. As opposed to natural language, where the speakers of the language, not some third party rule imposer, are the people who change the language over time. We can all start using something that is not considered grammatically correct and make it grammatically correct. That is not how users of programming languages get to operate.

It is only the creators, the maintainers, that actually get to decide what is and isn't valid. We can coin our own words. We can change the rules of grammar. And we can do that extremely locally. And we can do that globally. We can do that long after the fact. We can do that immediately. We can do this in so many different ways that that

natural language is ultimately malleable and it is um i was going to make a point but it was a really dumb point so i stopped myself and it's not that these things are neutral either i think that's an important point is like people like like to be like, ah, well, programming languages, it doesn't really matter which ones you use. They're just, you know, tools or whatever. But like, that is just clearly not true in the sense of the programming language designers have a normative claim they're trying to put out there. They believe that there is a better way to program. They want to cause you to program in that way. They want to enable you, yes, but they also want to shepherd you, to force you, to make it so that if you're using their language, there are certain things you can and can't do. There are certain ways you can and can't think.

They are not just, oh, I've made a tool and it happens to be useful. I can't think of a single programming language that is just that, right? Every language has a viewpoint and is trying to accomplish certain things. There's so many pearls of wisdom and anecdotes and examples. They just like, my cup overfloweth with these so for instance you know easy things should be easy and hard things should be possible right that is a a normative framework imposed by um a tool right a tool that that subscribes to that viewpoint and that and that tries to fulfill that it's doing it in a normative way. Another example, a lot of people will point to Turing completeness as a way of saying that any language that is Turing complete

and that is meaningfully nice to use, like pick your favorite Lisp or whatever, it's like if there's some capability that is absent in this programming language, you can make that yourself it is you know the language if it's extensible and if you can you know build your own system within it or something like racket where it's like make your own dsls or whatever right it it has this facade of flexibility or it has this air of malleability to it that may make one feel like they are escaping the legalistic nature of it, that because they can extend it to whatever means they want, because it's Turing complete, you can achieve whatever ends you want. The issue that I see when I see people lean on Turing completeness as the way of saying I can have whatever I want is that Turing completeness is relevant only to the machine interpreter relative to the compiler. It is looking at that side of the bidirectional

relationship, the human facing side of the bidirectional relationship. Turing completeness is not very important. It's not meaningfully interesting. What is much more meaningfully interesting are questions like, is this a text language or a visual language, right? I wanted to bring this up earlier and now we've got an opportunity. that you're putting on yourself, Jimmy, to make a system that is not just a big text buffer, that anything but that is, I think, valuable because you can make a big text buffer inside something else. Like it's comparatively easy to make a big text buffer inside an infinite canvas or you know a 3d spatial vr interface or whatever or or on a sheet of paper on a you know a tangible interface or whatever it is big text buffers are easy to

plop down in some spot somewhere right they're rectangular and there are so many tools available for making that easy to do the same cannot be said of the reverse you can't have a text buffer and easily within it create a drawing canvas right that is much harder to do spaces that give you a drawing canvas usually give you a way to put text buffers inside them spaces that give you a text buffer don't usually give you a way to put a freeform drawing canvas inside it one where the objects that are present um you know can can interact with each other in a meaningful way right like your caret positioning code is not going to enter usefully into the drawing canvas and do stuff there whereas your drag and drop drawing

tools could enter into the text canvas and manipulate stuff in there in a useful way so there's like when you look at this from the side of the text of the source code that is facing the human user, there's a lot of stuff there that deserves attention where a lot of our culture around – a lot of our culture that might give one objection to this notion of legalism is only looking at the relationship between the source code and the machine, not between the source code and the human author. I love that distinction. That actually like crystallized something for me. Like you talking about why the Turing completeness being wrong is about the directionality. There's a paper by Matthias

Felicin on the expressive power of programming languages. And what it's trying to argue is like, there's a bunch of programming languages that are Turing complete, and we want to call some more expressive than others. And how can we like rigorously define that? And the way he does it is very clever. It's about whether a program halts or not. They don't need to get into details, but it never sat right with me. And you finally like crystallized for me why. And it's because to me, expressiveness is about the human facing part. And he goes and redefines expressiveness to be the computer facing part. right? And so I love that, and I think that it's really important that we pay attention to that distinction.

Yes, we can compute anything we want to compute in these languages, but that doesn't change the way we interact with them. It doesn't change the way that we are forced into their system, right? We have to think about that aspect, the human facing aspect. And I think that is gotten, like people don't pay attention enough to it. People often think of computer science as not actually dealing with that part and just dealing with the computation, the computer facing part. So to tie these things kind of back around, section 341 introduces some terms

that I'm not going to try and pronounce. There are lots of terms in this paper. I think they're Latin. I'm not familiar with pronunciation rules for Latin, so I'm not going to try. But it makes the point that uh like we mentioned earlier you know natural language is evolving and it can be evolved by the people who speak it if i want to make up a new word i can if i want to change

grammar i can and so long as the people i'm speaking to are able to understand my meaning or to the extent that I want them to, that's fine and that's totally effective. And I'm like prescriptivism versus descriptivism I think has been largely settled in favor of descriptivism. But the – yeah, language, human language, malleable. Computer language, programming languages are not malleable in that way there's no input to the programming language from those who speak it if you want to you know change something about c++ and be like hey we're not using c++ we're using some you know slightly different variant of c++ where it's like you know we're we have these extra features right like we have like a like an embedded dsl or something like that right like we have um

jsx inside our c++ you have to go ahead and build a system that supports that and then that system like we got this with javascript right coffee script probably the worst programming language at this point you know just gonna just gonna call it coffee script probably we should just get everybody to stop writing coffee script um it did have an effective role in changing the javascript standard right but the things that coffee script did like the arrow syntax for functions and the way that it makes certain braces optional and implicit returns and statement semantics and all the other, you know, terrible, awful things that it did that, you know, don't deserve to be in JavaScript. JavaScript adopted some of those things, but it did them in a different way than CoffeeScript did them. And so you end up with this case where some of the things that were nice in CoffeeScript, now my jumping back and forth between liking and sarcastically disliking has become a thorn in my side because I can't sincerely talk about CoffeeScript as being a good thing if I just set it up as a bad thing.

Damn it. Some of the things that were nice about CoffeeScript are not nice in JavaScript, even though JavaScript added those things in reaction to CoffeeScript. And so there's a case where it's like, yeah, we got to go speak this dialect of JavaScript for a while, this transpiled alternate language that is, what if JavaScript but nice to read and write? And then when the JavaScript standards bodies incorporated that, they did it badly. And it's the like standards body right that's the thing that programming languages have that laws have that natural language doesn't have natural language doesn't have a standards body it has a dictionary it has like a collection of linguists and of you know people who in an academic capacity or in a professional capacity

have some role in the the way that language is propagated and the way that it is recognized but their role in it is purely reactionary it's purely like when the dictionary adds a word it's to capture the fact that that word is now in popular usage. When the New York Times changes their style guide or when the AP changes their style guide to allow some new usage, that is catching up with the culture at large, what individual people are doing. It's recognizing the new evolutions of natural language. Standards bodies do that, but they do that with a different kind of a role

where it's like this thing that used to not be permitted, so you had to go outside the standard to do it. You had to go use a different language. You had to go use a different tool. You had to build your own tool. You had to build your own DSL. You had to build your own module system or your own preprocessor, your own transpiler you had to go do that they're now saying okay you know we're recognizing that a lot

of people like to nest their css rules inside one another they've been using sass and less to do it now let's add that to the css standard but we're going to do it in the way that we decide is the right way to do it and that works with backwards compatibility and that satisfies our technical goals and they end up with syntax that sucks and that looks bad and that doesn't feel good and so it's it's not like we all as individuals get to participate in the evolution of the standard beyond just like serving as an example that they can reference when deciding that they want to add some new feature yeah Yeah, and I think what's interesting here is what it might sound like we're ultimately arguing for

is to somehow get rid of all of that and replace programs with something that would be like natural language. But that's not what the paper argues for. What the paper's trying to say is these are the facts about how programs work, this is how programming is and that means that these the programmers of programmers have an outsized influence in the the habits of mind that these people have and this is a point that like alan k has made i i know a number of of

people have said that you know the sapper wharf hypothesis has even come up on in a previous episode i can't remember which one there's this big impact and so what this paper does is sets up a new project you could have which is that there might be a lot of different ways you could build a programming language build the tooling around it but they want to focus on whichever one, whichever way you could mitigate the computational legalism in the system. How could you design a programming language, a tool set, culture, everything that is what creates code to minimize and mitigate the problems of computational legalism? And I think that is a fascinating research project.

I think it not only, like, of course, it has this kind of directness in its aim of, like, affecting society in some way, which I really like. I think sometimes we kind of ignore that aspect when we're thinking about future of coding things. But it also doesn't give the in. Like, it doesn't give the constraints that are going to, like, well, it's got to be visual, or it's got to be this.

It kind of gives you what your goal you're aiming at, and you can test it against. Are you actually mitigating this computational legalism. And I think this is where when people look at future of coding endeavors and they say, well, maybe shouldn't we just be looking at what people are building, what companies are being created, what are people making? That's the future of coding, the things they're making right there. That's what I find so unsatisfying. I find what is most interesting to me thinking about the future of coding is not what people in this community, is how can we mitigate these things? And maybe that's not your project. It doesn't have to be everyone's project, but it seems like a worthwhile one and one that I don't think is talked about at all in the popular programming world. Not only is this useful as a project that one can take on but it's also useful as one of the many

rubrics to have handy when evaluating the work that you're doing or evaluating the brainstorming that you're doing along with things like is the interface nice are the graphics tight does the syntax feel right when you are thinking about an idea for a you know a new way of programming you're thinking about the performance characteristics you're thinking about you know how do i express the grammar is this building on top of an existing thing is it like hosted the way closure is hosted that kind of thing there's all these different dynamics that you can think about and this offers a new one to me new to me at least this is a new and interesting rubric a new and interesting framework to look at the work that you're doing whether or not you are

directly attacking this problem area that question of is the thing that i'm building going to do a better job of honoring the autonomy and the independence of the people who are going to work within this system so if you're building a new programming tool that's both the programmers who are going to use it but also the end users of the software that's going to be built in your programming system like to what extent is their human flexibility and their need for context sensitivity and their need for for them to have a role in not just whether or not the code runs but how it runs and what happens if it doesn't do what they want you can pull that need for empathy all the way back to the design of the programming language itself you can pull that all the way back to the questions both of how does this programming

language face the programmers who use it but also how does it face the machine and consider both sides of that? Yeah, I think this is just a fascinating frame to me and one that if we took it seriously, I do think we would make something quite a bit different. So this is where like my kind of talked up front, like the suggestions that we get for maybe how to accomplish this feel a little lackluster. So we have some stuff about agile versus waterfall, where agile might be a better way of mitigating computational legalism, is the suggestion because it allows for tolerance of mistakes and new knowledge.

Um, so this is in three, four, three, uh, second paragraph. Crote as be, crote as be collage code as break a lodge.

Yeah. It gets into Heidegger here. Yeah. Yeah. And so the idea is like that about Agile, of course, is going to strike me negatively. Because I guess the reality of what Agile actually is versus the pie-in-the-sky version. I think, in fact, the structures you get in Agile often reinforce the kind of legalism that we're worried about here, right? It's this kind of social structures that value conformity, value not questioning, because not hitting your iteration becomes a major problem, right? Not getting that sprint done is going to be an issue. And the

iteration actually doesn't happen at the level of the thoughtful programmer. Now, I'm not saying Waterfall is better, whatever. I'm just saying I think Agile is the exact wrong kind of structure. I think if we're going to accomplish some of these goals, there's a question of like very practical things, which I think this is kind of trying to be more practical suggestions. And then the things that I think are more interesting, like the super speculative ones that can maybe point us in a direction of practicality later. So when I was reading this, immediately my thought goes to, I don't know if you're familiar with the programming language black. Yes. Yeah. The scheme where you can have a

like sort of meta levels stacked on top of one another yeah yes so so this is a lisp that you're able to as your code is running you can go down into the interpreter and change the interpreter of the running code but you can also go down to the interpreter's interpreter and change it, and you can continue to do this infinitely, right? And so there's this infinite stack of interpreters that you're able to change. And I find this as just a fascinating, even if it's just an analogy, and we don't expect end users to be able to do this, I find this as a really interesting way of looking at a programming language that it becomes hard to say that it doesn't prevent these things. And maybe it doesn't, right? And

of course, it's not practical. And you're not going to put that in your car. And you're not going to like the airline system that you're doing, is it going to let you go down into the Lisp interpreter and reinterpret the code code but there's something really interesting about the suggestion of it that it it really does get at this idea that what we think of as immutable in this legalistic the way code executes can be subverted we could offer something different you know we're not going to let me reinterpret the code but we could right and like what would a society look like if every bit of code you were able to drop down into that infinite stack of interpreters and reinterpret it now yes again silly suggestion i just like it as a idea to clarify something i actually don't think it's a silly suggestion. Okay. Like, when I have been hinting that it's like this, you know, this lines up a lot with my views about what the future programming entails, that's pretty much the big one.

Like, so I have this in my, I can't remember what the name of it is, but I have this programming project that I'm working on. And one of the ideas that is really central to this project is this idea that I'm calling participatory execution because I don't know the proper name for it. It's probably got some name that's, you know, from the 70s or whatever. Or it probably has like five different names depending on which exact shade. You know, if I went – spent a year on C2 in the the wiki i'd probably find a bunch of things that are about this but i call it participatory execution and the idea is that whenever the code is running it is running in an environment where you can you know open up the hood and look at what it is doing and that like like yes this this black uh lisp that lets you pop down to the interpreter of the code and the interpreter of the interpreter offers that but there's a there's a sort of a specific thing that i'm taking on in my view of what something means to be a system with participatory execution and that is that you have to design the execution environment

around this you know participation of the end user as like the utmost concern it is the most important thing is to think about what would the experience of opening the hood to go and look at the code that you're running feel like and this essay touches on this a couple of times in interesting ways like for instance in talking about natural language it compares the meanings of some english words or statements in code with how the lay person might interpret them so for instance something like print you know a print statement is worded in such a way that a lay person probably would understand what is meant by that statement and uh it's it's kind of easy to hop into an understanding of that it's not a big ask of a lay person. Whereas a lot of code is not

approachable to a lay person. A lot of code is written in a way that even if it is using common words, regardless of language, even if it is using, you know, math formula or algorithms or things that are, you know, maybe familiar in some context, the way that it's put together in the code as a text that is facing the person, the documentary role of the source text, it's not designed by the programmer of the programmer to be approachable to a lay person. And not only is it not exposed at runtime in the execution environment but were it to be exposed that wouldn't benefit the person who's being subject to the code exactly you don't solve the legalism just by giving them the source code open source is not a solution to this legalistic

problem you can't just show somebody your source code and say, there, now you can see the laws that you are subject to, right? It's like being able to see the code is not good enough. And so this idea of participatory execution is what if you designed a programming such that participation of the end user of any program built in this system is the most important thing. That's the most important concern is come up with an environment where somebody could go from not having any programming experience, not knowing how it is that code is structured and how it's built and the tools that are used and all the cultural practices and and find some way to hold their hand and walk them in to that environment of code and of you know the rules and the statements and the semantics and all of that and so that is why i talk a lot about like borrowing from video games because video games sometimes do a fantastic job of this and i have a you know i have a four-year-old right so i

am very comfortable with like ah jumping up and down in a hollow knight is something that she can really get her head around but something like picking up a twin stick playstation controller and going into doom eternal and like you know being able to look around there's no hope of that because there's a certain amount of like physical literacy there's a certain amount like muscle memory and hand-eye coordination and all of that that you need to be able to look around in a 3d you know first person shooter or whatever to manipulate the camera and your character's position at the same time and so there are some games that take it upon themselves to introduce novice game players to those systems and to how that works or they'll do things like there's a there's a kirby game that came out recently where

it's a third person game and your character's walking around and you can hit an attack button and you swing a little attack kind of sword or whatever and you can hit a little enemy and the way they programmed it is if from the perspective you are looking it looks like your character hit the enemy then that counts as a hit even if the spatial relationship of those two characters is such that they missed so it's kind of like you know when you're filming a movie or a tv show or something like that and one actor punches the other actor, you do the thing where the fist goes like behind the other person's face. So you're not actually punching them and the other person has to react as though they were punched but it like it misses. And they have to sell it but they don't actually hit each other because that would be unsafe. It's the same kind of thing.

You don't actually have to hit the enemy in this game. If you look as though it hit the enemy, then that counts, because that takes some of the pressure off a novice player to understand all the spatial relationships in this 3D world and how to mediate them

with this kind of foreign-feeling controller when you're first learning how to do it. And so a participatory programming system would be a programming system designed with similar concerns in mind somebody who has no experience with code what kind of an environment could you drop them into where they would be welcomed in and would feel like here's a good place to start learning what it means for a program to exist and to do what it does and this is a a very aesthetic concern in my humble opinion this has a ton to do with the presentation of it and a lot less to do with like the the technical dynamics

of it and it's something that i've i've thought a lot about and i could go on and on and on about but that's that's something that i immediately thought of is as a solution to the legalism as a solution to the problem of the person being subject to the code not having any opportunity for a say the first step is they need to be in the environment where they can actually see what this code is doing. And then once they're there and you have like helped them grow the initial seed of an understanding of what it is, then you can start to introduce, okay, here's how to actually have a say in the process. Here's how to actually participate in it. There's the first half, which is like you need to be literate. And. There's the first half, which is like, you need to be literate. And then there's the second half, which is you can now write.

Yeah, I do really like that. I'm glad you've made my what I found as a silly suggestion a less, I think it was still, in my mind, the way I was suggesting it silly, the way you've now made it, you've taken it and turned it into something serious and interesting. And, and I think that there's like, when I think about that vision, there's something of course, utopian about it, you've taken it and turned it into something serious and interesting. And I think that there's, like, when I think about that vision, there's something, of course, utopian about it. There's something, you know, people might call it out impractical, right? Because, like, do you really think the airline's going to let you participate in the execution of whether you get a ticket or not? But even if it doesn't work in all cases, there are ways in which I do think this could actually apply. And one of the things I like that DynamicLand is doing is it's not just a focus on the technology, but also a focus on the social way in which we engage with that technology.

And I think the way you're suggesting this is a similar kind of suggestion, right? That there's certain expectations we have about computation that have made it more individualistic. They've made it specialized. They've made it so it's not a general purpose thing. And dynamic land wants to make it more social. And what I see you doing as well is making it less mystical, less specialized, more of an expectation that you are able to do these things. So I think about when I've been at getting checked out at a register even, but like, you know, legal documents or whatever, you'll often have, and I often make the joke where

like the person's struggling with the computer and I'll just be like, technology, huh? And everyone's like, yeah, I hate this thing. And then they'll explain what's going on because oftentimes you can see they're sitting there frustrated. And they'll explain the problem they're having. But you could imagine how someone actually could, because they're a trusted employee and there could be certain checks, they could actually get around that problem that they're a trusted employee and there could be certain checks, they could actually get around that problem that they're having

by doing the things that you're suggesting. And sometimes I have to suggest it to them, right? Because I understand, because I'm a programmer, how their system is working. At least I can make assumptions and I'll say, huh, why don't you try this? And now we get around the problem and everything works out. But why shouldn't that be just a skill everyone has? Why shouldn't our software

think about those things? And that would be a great way to mitigate this legalistic way that the software operates. I like it. I think beyond letting end users have a choice. I do think that there's things we could do to make our software designed to be less legalistic. And I think, I will say, some of those things are just to decide not to give software certain jobs it shouldn't have. So I interviewed at a company, absolutely loved the manager, not recently, this was a few years ago, absolutely loved the hiring manager. It was great. He told me about their system, all the technical details, the problems they were having, the ways they were trying to tackle it. Honestly, best introduction interview I've had to a company ever, where he's

trying to sell me on it by not like painting it as you know a perfect utopian vision of what it's going to be like to program but like all the crap like half it's written in a camel and then closure and it's like okay um I gotcha but then we got to talk about what the business actually does because their website was very corporatey speak and you can never actually figure out what it was and it's improve employee retention that's what they do using machine learning so i'm thinking like maybe they identify when people are disconnected and they like actually give like positive reinforcement or you know whatever or like find bonuses that they should be giving people who are good workers. I'm like wondering what it is. Well, it turns out it's used for hospitals and fast food restaurants. These are their two main customers.

And it's a personality quiz that they take when they're being hired. And they use that personality quiz to decide, using a machine learning algorithm if this person will leave the job sooner or stay longer and they had all sorts of research on that it wasn't biased on gender and race and a bunch of other things but i'm i told him i was like i can't do that like i think that that is the and in fact the problem that they were having was that people who were the hiring managers did not like their software because they would find a good candidate that the software would say was going to leave and they weren't

allowed to hire them and this to me is this like very strong legalism of the software and and it's like a software engineering mindset even of like well we can determine this by looking at statistics and look i predict it so well even if they're right that those people would leave that job sooner rather than later i think this is the wrong way for our software to be that's a like a level of attacking the problem that is at the cultural level not even at the like how do we design the software and there's certainly a role that how we design the software can play in that but things like the this is possibly you know fake i don't know but the story that was going around a little while ago about a teacher who fed a bunch of class essays to ChatGPT and asked ChatGPT if it had written those essays. Like, hey, ChatGPT, I'm a teacher.

I'm going to paste you some essays and you tell me if my students wrote them or if you wrote them. And ChatGPT came back and said it wrote them. And so the teacher went back to the students and was like, hey, you have all, you know, used ChatGBT to fake these assignments. You're all getting a zero. Your only way out of this is you now have to write a new assignment and that is going to be what determines your grade.

But I'm going to feed that assignment to GBT and if it says that Chat GBT wrote this assignment, you're getting a zero and you're, you know, possibly up for expulsion on that kind of thing. Like we're going to like take this very seriously, totally ignoring the fact, assuming this is true,

if this isn't fake, that, you know, chat GBT is not in the position to be able to answer that question truthfully and honestly and reliably. That is not within its purview. This is a misapplication of that tool. to be able to answer that question truthfully and honestly and reliably. That is not within its purview. This is a misapplication of that tool. And OpenAI have done some things to try and dissuade people from using the tool in that way.

The culture around that tool definitely does not dissuade people from using the tool in that way. The culture among programmers, among people who are technically literateate there's definitely an awareness of that sort of thing but among the general population like my parents who came to me and said hey we're really interested in using gpt to write arts grants like write applications for arts grants because my parents are both working artists and they you know have been hearing the buzz from their networks of artists about using gpt to like apply for grants and how it's a it's a helpful tool and i had to be like very clear with them that it's like this is a tool that's going to produce bullshit we call it hallucination that's the term that we use in the in the technical sphere is is we think of what it

does is hallucination with the negative connotation that that presents. And so if you want to use it as a way of coming up with a, you know, going from a blank page to a to something that's obviously wrong, but that serves as a better starting point than a blank page, great. But if you want to use it as a way to like, validate the work that you're doing, or come up with something that is a finished product or better than you feel like you could do on your own that's a misapplication of this tool and the tool itself is not going to guide you to avoid those bad usages yeah like this is one part of it is yeah the design of these tools um like software eating the world, to borrow that horrible person's ism.

The, you know, the malleability and the flexibility and the universal applicability of software is tremendous. But I think we're still, you know, despite the last decade of increasing scrutiny of the role of social media and of, you know, even like local first, right? I wanted to bring up local first. Local first, that whole movement, like take your data out of cloud servers and have your data on your own machine first and foremostly. And the cloud can be a useful thing to facilitate the exchange of data between people, but you should have and own the data on your machine. You should be able to use it offline. You should be able to have your own backup copies of things you should the the data that you create should be your possession not the possession of google or whoever it is that's you know aws or whoever is the cloud infrastructure sitting underneath the the text editor or whatever that you're using

there's there's the societal question of how do we convince society at large, no, please don't enshrine our laws in code systems that don't allow ambiguity. Please don't force all students at this university to install proctoring software that spies on them and does gaze tracking and that sort of thing you know please don't use these automated systems to like constrain what it means to be a human being and and intermediate within our personal relationships and become the the interface through which we live our lives right i hated this um at the beginning of the paper, it makes this terrible pun. Like, this is so dumb, but it's so true at the same time.

Code is deterministic in this important and limited sense. So while one should not overstate the extent to which code rules currently predetermine behavior in the offline world, the risk is that as we transition into the on life this risk becomes ever greater on life is a terrible pun like offline on life like our life on the internet and this is where it like uh this is around the time where it's invoking the idea of the metaverse right but like yeah as we become increasingly you know living our lives mediated by technology, I think we really do need to fight to maintain the imperfection of humanity. I think that this also gets at something that I think is just kind of broader in the, so, you know, of course we have society, but we also have like programmer culture, programming culture. And your example of using ChatGPT for art grants, I think, is very instructive,

because I think everyone probably would agree. You can use it as a tool, but it's going to hallucinate, it's going to do these things. But if I suggested, let's start a company that will figure out if we should give a grant, and it's going to almost fully automate this process, almost nobody is going to, as a programmer, is going to really think much about that. They're not going to be like, that's a crazy idea.

How can you decide if these grants are useful? They would be like, oh, yeah, we could probably do some statistics. We can do some machine learning. Look at grant proposals and outcomes. And do you have a good data set? These are the kinds of questions that are going to come about and i think i think this like this essay one of the reasons i like this focus on legalism is i actually think in the programming world we often just like it like there is at least a subculture that really wants everything to operate legalistically,

wants everything to have non-ambiguity, and believes very strongly that things will be better. And if you go to programmers and you say, we have this problem, almost always the solution is going to be to impose a rule, to have a, a, a lenter go check something to make it restrict something in some way. And suggestions otherwise are often met with maybe like, I don't want to like, you know, I don't want to make a straw man here, but they're often met with derision. Like they're often met with like, oh, why wouldn't you impose that rule? Do you really not think that's a good rule, right?

Like, are you just saying people should be able to write code however they want and we don't wanna impose these structures? And I think that this gets at the problem we have in our culture where we see how effective rules are in programs, how effective this mindless execution can be, how much you can accomplish with it, and project it onto everything. And so there's something that, this is something that I think, you know, the programmers of programmers are not just the people who make programming languages are not just the people who make the IDEs, but also the people in businesses who get to make the rules about what is allowed, about code standards, about all of these things.

And the effect that as you become more senior you can have on people below you on what they are allowed to do is also something that we have to think about. And so while I don't like the Agile suggestion, I do think processes and all of these sorts of things are things we have to think about if we're going to mitigate this legalism. Because I think it ends up being a major part of our culture and it makes people not at all skeptical about legalistic solutions. In some ways, I think this essay almost feels negative, right? And even like how we're exploring it, like I think it ends very positively,

but you can see it as like, you might read this as like, code is just bad for society and it just creates this legalism and we should just get rid of, you know, you could see it read this way, even though I don't think the essay does that. And so I love this quote. This is in section four, the second paragraph, and it's, nothing in code is a given. And so the legalism of code is not an inevitability, even if its ontological characteristics and the culture I love that optimism. I love somebody willing to put something that almost seems unachievable out there as a goal. And I think this is a better vision of the future of coding than I have seen in a lot of contemporary things.

There's a reason we often go back to older papers, because they often have a bolder vision of what could be. And that's what I love here, is I do think this is a bold vision. Even if the suggestions don't quite go to that level of boldness, I think we as a community could help achieve that bold vision. You know, when I was talking about my so-called participatory execution idea and this notion that like it's not enough just for the end user to have access to the source code. They need to have access to the running code as it runs and the opportunity to go interact with that code as it is running and learn about what it's doing and also make changes like as it is running and and you sort of um suggested that that might be impractical like to to you know the airline won't allow you to do that and i didn't counter at the time but i'll counter now that like that is not not as big a ask as it may seem to be when you compare it to other societal level issues that

we need to currently address and i know i'm doing a bit of a you know a bit of a rhetorical play here but if you compare the need for something like say climate change or the need for something like, say, climate change, or the need for something like, you know, arguably alternative systems of governance and economics that might be a little bit more equitable, given current contexts, we're not getting political on this show, but I'll just use some weasel words to kind of dance around some issues. Put in your favorite issue here that you think requires a lot to tackle whatever societal level issue you want to be concerned with those are problems that started off with a small handful of maybe cranks maybe easily derided people saying, hey, here are some societal level issues that we're going to have to deal with sooner or later. And those issues, as they got, as they went unaddressed, the number of people affected by them increased, the number of people aware of them increased, the number of people talking about them increased, and it had this

sort of steamrolling, you know, snowball rolling down a hill, getting bigger and bigger as it goes sort of effect where now we are starting to see policy level changes happen that are targeted at addressing climate change. We're seeing the very nature of what it means to transport yourself within a city changing like what's happening in Paris. We're seeing changes to the entirety of the automotive industry as it moves to battery electric vehicles we're seeing all sorts of societal level change happen each of those changes is a little microscopic thing on its own but they are all intended to solve an issue in aggregate and they're all intended to be their own small part of a big project and i think when it comes to the future of code it sort of by essence will follow a similar path where there will be some things about how we program that a handful of small

cranky individual people will pick up on first as significant problems with the way things currently work. And that as time goes on, the number of people impacted by those problems will increase. And it may spill out of wonkish programmer-centric circles into spheres of the public at large. And I see certain things like the way data is stored and the way data lives on cloud servers is currently kind of at that stage like we're seeing governments start to legislate like hey facebook just got a billion dollar fine because they're storing data of europeans on us servers after being told numerous times that they're not supposed to do that anymore and we're starting to see more cultural awareness of like the data that companies have about you is sort of like an extension of

your persona or of your being but it is not your property it's like a part of your virtual body that you don't see or have or or can really grasp but it is valuable to you and to people out there in the world and i think that the further we go some of these things there's going to be more awareness and more literacy about them and i think what's interesting about this legalism essay is that it suggests one that I hadn't really seen before from this perspective. And I hadn't really put these words to it. But I've definitely felt this. Like I felt what this essay is talking about forever. And other people feel this too, right? Like the recent not as bad as it perhaps could have been, better than it had any right to be, Star Wars series called Andor has a little subplot in it where, without spoiling circumstances fall on deaf ears because they're up against a very, living under a system of rules that you have no say in is a really present thing in our lives.

And the extent to which code will intensify that I think will also intensify the pushback against it. And so I think if this gives us an opportunity to come up with some solutions that are interesting, like to say, hey, maybe execution is something that people ought to be an active participant in, in whatever sense that that means, whether that just means in the local first sense, where it's like, I get to participate in the execution of my text editor by saying the data lives here on my local machine not on a cloud server even if i want syncing and live collaboration or in the more extreme sense of no code runs unless i can open the hood and there are user serviceable parts because maybe not every person on the planet will be their own mechanic or their own tinker but there will be tinkers and there will be mechanics and they will not be

the people who are doing the programming of those things. The programmers of those products, there'll be rogue programmers out in the world. There'll be maintenance programmers who take off the shelf software and, and help you adjust it to your own need. I think that that is not out of the sphere of possibility. I think that is like very much something that um is achievable and is already it's it's something that people are already very conscious of and

they're already talking about and they're already already finding lots of different ways to do that and different permutations of it and that we'll see this reflected in various things various new developments like we've got shortcuts from apple right it's a really locked down system but it's a heck of a lot more permissive and a lot more malleable and flexible and open to the end user than not having shortcuts and so they may see it as like a pressure relief to keep people happy in an environment where there's not true programming on the device, but it is definitely an acknowledgement of that pressure. And I think that's worth not just dismissing out of hand

as too far-fetched to be possible. I see it as like any increment in that direction is a positive development. Yeah. I'll just end. I think I don't have any better thoughts than that on the issue. I'll just say I would recommend I think this paper of all the papers, there's a lot in here that we didn't get to talk about. There's a lot of great footnotes to a bunch

of works. I think there's actually a lot of work that I've started diving into in this computational legal setup that seems to really have a lot in common with what we're looking to do in future of coding. Like I think, I think this is a rich set of literature that I just recommend people go read. This paper is, yeah, written a little differently. It's a little bit more academic. There's a bunch of words in here here but it also exposed you to a lot of ideas and i i just recommend people going and checking it out and that was prove me wrong