Future of Coding - Myths & Mythconceptions by Mary Shaw

Episode Date: December 29, 2023

In the spirit of clearly communicating what you're signing up for, this podcast episode is nearly three hours long, and among other things it contains a discussion of a paper by author Mary Shaw titled Myths & Mythconceptions which takes as an organizing principle a collection of myths that are widely believed by programmers, largely unacknowledged, which shape our views on the nature of programming as an activity and the needs of programmers as people and the sort of work that we do as a sort of work, and where by acknowledging these myths the three of us (Mary Shaw primarily, and by extension Jimmy and I, those three people, that's it, no other people appear on this podcast) are able to more vividly grip the image of programming with our mind's eye (or somesuch) and conceive of a different formulation for programming, and in addition to these myths this paper also incudes a number of excellent lists that I take great pleasure in reading, beyond which I should also note that the paper does a job of explaining itself and that hopefully you'll find I've done a similar job, that's the spirit, please enjoy. Links $ patreon.com/futureofcoding — I've recently changed it so that there's only 1 instance of the INTERCAL tier available, so if you're interested in those perks you'd better hop on it quick before nobody else does! There's also a video, though I haven't watched it. Claude Shannon would have something to say about revealing information. Top 10 Hits of the End of the World is an album by Prince Rama. Listen to it as loudly as you can on Bandcamp, Spotify, or Apple Music. Val Town is the new startup by Future of Coding community founder Steve Krouse Ivan recently took a job at Ink & Switch on the "Ink" research track. Programmer Bums, or, rather, Computer Bums Limmy's Wa Retool MythBusters The Flop House's Final Judgements: Good-Bad, Bad-Bad, Kinda-Like CRDT Data Robust-First Computing is an approach championed by the hero Dave Ackley, and I have a well-informed hunch that you'll be hearing a lot more about it in future episodes. The T2 Tile Project is another Ackley joint that, perhaps, works as a wild example of what Mary Shaw means when she talks about an "execution ecosystem". Devine's talk at Strange Loop: An approach to computing and sustainability inspired from permaculture MUMPS (the medical thing, not to be confused with mumps the medical thing) is used by Epic (the software company, not to be confused with Epic the software company). The Glass Cannon podcast network. Lu's SPLASH talk Cellpond: Spatial Programming without Escape The Turing tarpit Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire by Erik Meijer, Maarten Fokkinga, Ross Paterson. Richard D. James is the same person as Richard P. (Peter) Gabriel, right? Similarly, see Neil Armstrong's work on Erlang (which is popular in telephony, right?). The Witness is not going to appear in our show notes. Jack Rusher. Jack Rusher? Jack Rusher! TrainJam Gary Bernhardt's talk Ideology Nobody remarked on these silly links last time, so this time I'm drawing more attention to them: Tode: Neopets • MySpace Berd: Angelfire • Orkut Bot: Geocities • Friendster https://futureofcoding.org/episodes/069Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

so ivan how much of this is your we don't talk about the thing that's changed why what changed so ivan always talks about the fact that like if we do something different we can't talk about it because talking about it makes it too obvious about what i'd prefer that we go as long as possible without letting anybody know i mean i i think it's going to be obvious because like my audio is so different. So right now I'm not at home. I am in a hotel in Kansas City. Why are you in a hotel in Kansas City? A horse show. A horse show. Okay. You're showing a horse? I am showing it to Kansas City. Whoa, you can't, you can't, this is PG. This is PG. You can't say you're showing a horse to kansas city what kind of horse are you showing jimmy a big one yes uh yeah so anyways i'm in kansas city

you know my wife janice is showing a horse here and the i will say though it is the weirdest venue for one fact. Okay, so you're always at these venues for horse shows. They're not glamorous. Yes, I am. Yes, I am always. I'm saying win one is at these horse shows. These venues are not glamorous. They're like county fairgrounds or state fairgrounds or whatever.

And a lot of times they're like these big concrete brutalist buildings that are dark and like warehousey. Horses love brutalism. Yeah, yeah, absolutely. The arenas are all nice, but then like the actual place where the horses are is not the nicest environment in the world because you have to fit lots and lots of horses from everywhere. And that's fine. It's right by a railroad track. That enough would be like, okay, this is kind of normal.

The weird thing is that it's multiple stories of horses what uh-huh wait what yes so like the usually it's just like one story but now there's like a ramp that goes up and then like above you think like you're in a car you know parking garage there are more horses up there and so you'll just be walking around and you hear a horse walking on the ceiling above you and neighing above you i don't know that i've ever been under a horse before exactly it feels very wrong like there should not be some uh a ton you know two thousand pound creature just like above me yeah even though it's through the concrete or whatever it just throws off everything because like when you're around horses you're you know you're paying attention to make sure you're not in the way of a horse yeah and now

all of a sudden it's flying it's flying hang on okay so that's why your audio setup's different this time yeah yeah so if i'm less echoey than uh you know no i i think actually i got a it's a pretty nice hotel room in downtown kansas city but the fact that it's nice means it's all hard surfaces. So it might be a bit more echoey. Yeah, a bit more echoey than normal, but otherwise we'll treat this as a normal episode, I think. Yeah, my setup's a little bit different too. Normally I don't really care too much about it, but I know that, Ivan, you do a lot,

so I've got to impress you. I've got to raise my standards for the future of coding. So what have you done this time that's especially different from how you normally record? I deleted my entire setup. Oh. And then I asked you for the template. That was my whole process from start to finish. But no, normally it has this, you know,

this whispery, relaxing stuff. Which I did hear you did an episode like that. I did do an episode like that. And thanks for throwing it to the Patreon. Dot com slash future of coding. Oh, yeah. The most recent bonus episode, if you are a Patreon subscriber,

is something I called Liminal Programming. And it is a recording of me talking in a quiet, gentle voice about visual programming. And it is narrowcast at one specific person, because they mentioned on Mastodon that they like listening to my voice as they fall asleep. And so i recorded an audio sleep aid for this one person and if you want to find out if you're that one person well subscribe to our patreon does the one person that this episode is targeted at do they subscribe to the patreon that would be telling the answer is no that's that's okay that would be like a gdpr yeah that would be a gdpr violation yes yeah fair enough is it a gdpr though since it's no ah oh god yeah you can only reveal information you can't reveal non-information i'm sure shannon would have something to say about this well yeah so that's what's uh that's what's different with me yep that makes sense yes yes this is so cursed i think it's uh the most important thing to to realize though about

this whole thing is that there's this big myth oh that this episode was just for one person but really like ivan just believes this but it's not really true. It's not objectively true. There's no way to prove it whatsoever. I think this episode was for everybody. But Ivan is just stuck in this myth that only some people care about liminal programming. And that kind of brings us so coincidentally into the topic of this episode. You're a magician, Jimmy. what a wonderful kind of magic you practice uh-huh this like beautiful segue about myths and misconceptions what does it mean to be a programming language anyhow no i'm breaking our overtalk rule no it's myths and myth conceptions i've been thinking of it as misconceptions this whole time oh my gosh it's

myths i i did too myth and myth concept i actually didn't read it that way you did read it that way i didn't mean to that was that was a freudian slip that worked um yeah myths and myth conceptions myth conceptions now i'm gonna speak with a myth this whole episode which is like a lisp but it's a myth so it's a oh what would it be it would be a a lism that's when they accepted m expressions into lisp that was actually good that was actually yes the unnamed person is unimpressed I'm doing the thing where I'm not saying the name of a thing there's a thing that I'm not acknowledging by refusing to name it

you mean like like Hest no not like Hest yeah either's fine either's fine anyway this is should we uh today we are talking about a paper by mary shaw called myths and myth conceptions what does it mean to be a programming language anyhow i'll start off with in the great tradition of talking about the first page of the text this one is is not fun yeah let's just skip right over

it i do not understand this first page at all it's supposed to be like an abstract yeah but like halfway through the abstract it just starts saying random sentences that's what it feels like to me like i i sat and tried to parse out the second paragraph of this and what the structure is supposed to be and i do not get it i don't know if it's a list i get it okay and that's why i want to bring it up because i had to just like skip over this thing in fact i'll go ahead and put out my biases here i struggled with this this paper i actually went and printed it out and highlighted it physically because every time i would keep trying to get through it i felt like i was making no progress and so i needed something that would show me that i was making progress oh my goodness okay i would add this was a very long paper yeah it was it was pretty long

it was like 40 pages which for us is long oh yeah i had the same trouble i didn't know how far i was through i was lost so i opened up the mini map on tl draw and uh i could see how far down i was and um that did help that wasn't a that wasn't a plug by the way that was not a plug okay but i'm gonna use my plug laugh whenever we talk talk about TL Draw, I'm going to do some plug laughing. Oh! For the audio listeners, here are all my pages. Let's see. Yes.

Those are some pages. And I'll share, you know, actually maybe this has spoilers in. But I could share the TL Draw room where I put my notes in. Yeah, I'll go start vandalizing it the way i vandalize your other tl draws you send me all right okay so i'm gonna read this second paragraph because i think it's a great intro summary to what this paper is about go to hell several persistent oh no no it builds up the previous i i made the i made the face even like i i was like okay i want to see how he's going to read the second paragraph when the first sentence

has reinforced this focus just like completely no no context this focus well unfortunately unfortunately that context is going to have to be emergent over the arc of the episode, because it's too late to go back now. Several persistent myths reinforce this focus. These myths express an idealized model of software and software development. They provide a lens for examining modern software and software development practice. Highly trained professionals are outnumbered by vernacular developers. That is a truth of modern software development not a myth yeah this is this is confusing as hell um thank you right okay hold on i i want to be so pedantic here because like this is what i was spending all my time doing

all right so first off this whole like refocus this focus it's like a bad focus of how we're not looking at software in its entirety and instead just looking at like mathematical stuff or something we can flesh that out more that's fine but it's like they provide a lens for examining modern software blah blah colon highly trained professionals are outnumbered by vernacular developers is that the lens yeah for which they yeah so is it the lens that highly trained professionals are outnumbered by vernacular developers i guess that's the lens because that's one of the myths no it's not the myth that's not the myth the myth is the opposite that's the truth highly trained oh are outnumbered by sorry yes that's the truth that's the truth that's the

truth it's not even the myth. But then like, and then writing new code is dominated by composition of ill-specified software and non-software components. So like these are all the truths. So then it just becomes

like a big list. Like every sentence from here on has no connection to the prior sentence. It's just statements. But what it is is each one of them is the summary statement of the

major points made by this paper yes and that's what's so confusing is like if they were put in a list format like especially this is you haven't read the paper and you don't realize like they don't say like we can summarize this as it just starts listing things and it's it would just i it took me so long to escape from this first page just because i i didn't know what that second paragraph was supposed to be doing for me i think the first paragraph is great which is sad that i've been skipped it and that you'll never get to hear it you'll never i skipped the whole page i'd like i didn't even i started at the beginning of the paper i usually don't read the abstract. It's spoilers. The second page is so much better.

Yeah, let's crush ahead to the second. And I think actually as far as summaries go, the conclusion I think is a great high-level overview of what the paper is about. I agree with that. So if we do a bad job of it, listener, then just go read the starting on page 36. You know what?

Just read page 36 to 38 and that's like that's a great you know you'll get the gist of the paper just from those pages i feel like we do have to give we do have to give some sort of introduction here like what is this paper about to ground the listener i'll crush that okay i'll do it perfectly. First try, no notes. You know what? Just before you do that. Sorry to interrupt. Sorry to interrupt. Page three, I think, is a much better introduction.

Okay. Because it is basically a list of the myths. That's what we're all here for, is the big myths and myth conceptions in programming. So, dear listener, I would recommend going to page three, reading that reading that then read page two then read the rest of it that's my advice anyway carry on please okay so here's my i'm not gonna cheat and actually read this i'm this is coming straight off the dome so this this paper i would i would propose using it as like a sorting function or like a, you know, like a bucketing function where if you read through this paper and you find yourself going, yes, of course,

yes, of course, I know this already. You are squarely in future of coding, you know, community, the heart, you know, you've been fully FOC pilled. You are in the right headspace for what we are and what we talk about and if you read this paper and you find yourself disagreeing with it where you say wait no that's not actually how it is it's this other way or you're saying that this thing is a myth but it's actually the truth or whatever or the thing you're proposing is like it has all these problems with it whatever you are not yet properly indoctrinated and need to,

A, go back and re-listen to all our episodes and Steve's episodes of this podcast, because that should convince you. But if not, then come into the Slack and start some arguments, and we'll see if we can straighten you out. Because reading this paper, I felt like I was a choir being preached to. Every point that it it made I found myself going yes of course of course of course of course of course I didn't get a lot of like eye-opening oh wow this is you know a new thing that I hadn't considered instead it was a whole bunch of like yeah that is a really juicy concise nice feeling way of I don't know why I put juicy in there, stating something that I intuitively feel and believe, but don't always have a one sentence tight way of explaining. And so this paper is

just full of these, like, you know, if you occasionally need to drop a bomb to shut down some Haskeller who's being all like, oh, formalisms are the most important, then memorize sentences from this paper because you can throw can throw those down at uh and like a smoke bomb and and win the argument so first a meta point you explain the paper by not explaining the paper no i explain what the paper does the effect of a paper is the the effect it has on the world not the source text whoa you'll know this paper if you already know all of the content in this paper yeah but second by by that i'm i'm not foc pilled i guess oh no we have to fix jimmy i expected based on like some of the trappings of this paper that it was going to be exactly how i've been

experienced it that it was i was the choir being preached to but i actually had to introduce new notation in my highlights which is our question mark oh in the same color highlight next to it and i have it in so many places because maybe i'm just being nitpicky maybe i'm just being pedantic but there are so many statements in here i just didn't understand i just didn't that just felt like there's some misunderstanding i'm having of what this paper's arguing for, because they just are so incongruent with everything else in the paper. I also had a question mark color this time, which I don't usually have. I did it in a few places, but there's also a bunch of places where I invented another color, which is for when i'm merely commenting and i think some of those were things i don't understand but didn't really want to admit to my highlighter you know what i mean

do you have a sentient highlighter you know someone's watching do you know it doesn't bode well that the very final sentence of the entire paper is in my pink, I don't know what this means, color. Uh-oh. And I read this like three times and I watched the video. There was a video? There's a video where she presents it. And so I read this, I skimmed it first.

And I was like, yeah, yeah, yeah, yeah. And then I watched the video and i was like wait hang on and then i read it again so i think i like ivan there is a lot in here where i'm like yeah that's obvious yeah but also like jimmy i have some things which make me go huh uh wait what what are you what are you saying here and like jimmy i also feel this is quite a long paper and ivan i would slightly disagree with what you said i don't think this is how you can drive home some of these points in one sentence this is how you can drive home some of these points in like 250 sentences like if you really really want to go deep or not deep just long you know what i mean anyway it sounds like i hate the paper i don't but i just uh you know

it was a battle and i feel good to be through the battle but yeah i do think there's some interesting things in here and i'll give a very succinct summary of what the structure of the paper is, which is Mary Shaw is proposing that there's these myths that people believe. It's unclear to me who those people are, but people believe, and they've messed up programming. And they're myths, not in just the sense that they're wrong, but that they really don't have any basis, and they structure the way we interact with programming. And so we need to overcome those myths.

And if we overcame them, we could change programming for the better. That's kind of the general structure here. And we can kind of get into those details. But that's something to have in mind is, I think, as the listener, you should be asking, are these myths? And what are the implications of them if they are?

One of the things that i do like that shaw does in this paper is speak to a really particular audience and so the audience she most often seems to speak to um or at least the the group of people for whom she says hey these myths are are probably going to have their most pernicious effects are programming language designers. So the people who are in an expert field where they're focused on building the tools that all software developers will do their work on top of, these people, because of these myths and the perpetuation of these myths, focus too narrowly or ignore certain types of programming activity or ignore certain people who do work that could be considered programming if you broaden

your horizons a little bit and in so doing fail to make the most positive impact with their work that they could if they had maybe not been deluded by these myths so i think i think that part like the focus on programming language designers that like really tight focus on audience is worth keeping in mind as we go through this because that's you know that's who these myths are meant to most directly target not you know folks like us who are yes we like to do our weird you know editor experiments and our spatial programming and our whatever i do which is not a thing um but uh it's not that group of people but it's the people who are like like um uh lou and i were at splash um just recently oh no i said your name uh hey hello it's me the seal is broken oh boy uh luke and i were at uh splash last week and that crowd like

that i think is the crowd that shaw has in mind for this paper is like the professional and academic programming language designers who are like putting forward you know here's the new approach that we're going to take to catamorphisms between abstract data types. This is a talk at Splash that I sat in on with something about catamorphisms and abstract data types. And I, brief aside, I sat in on this talk specifically because to me, I don't know any of what these words mean or any of the domain terminology. So I treated it as a 45 minute like abstract art piece. And it was incredible incredible it was like right at the verge of me being able to understand what they were talking about like i knew i knew i knew 75 of the words

they were using and it was it was uh that beautiful little space like right on the cusp of knowing what the heck anything was about so highly recommend that those people pull the wool off of their eyes with shaw's help i agree with that let's dive in let's dive in huge explosion you know i just want to quickly agree with that and say that me i might complain and you ivan complain hey we know all this already there's nothing new here but actually I think Mary Shaw has probably done the hard thing of writing it out in full or at least attempting to write it out in full and get the right people to hear it so yeah it's interesting to come at it from our point of view where all three of us are already making slightly

unusual programming things this is probably targeted at other people i wouldn't want to do it yeah um all right so so where do we want to be i have some i have some highlights just right off the top uh let's see. There's this bit that's about like what even is a myth that I kind of like right from the first page. And I'll just quote, A myth isn't simply a refutable claim.

In its purest form, it's a heroic narrative illuminating the human condition. It can establish a model for behavior and uphold social traditions. Myths have enduring appeal. People want to believe in them, notwithstanding contradictory evidence. This wish to believe elevates a myth from a simple, objectively testable statement

to a phenomenon whose appeal and persistence require interpretation. And that's by Carly Rae Jepsen, et al., 2009. Okay, I actually put this in pink which is i don't know exactly what this means and one of the things i don't know is like how does a myth compare to say just an abstraction so like when i talk about my computer doing things, it's not actually doing that. So like, when I say, you know, my computer, or my program changes the value, or it changes a text string, that's hugely abstracted, even though it's quite simple from what's actually going on, you know, I'm not going to say, first, it uses the move assembly instruction, and then it does this assembly instruction, and then it does this assembly instruction and then it does this

and that you know so that is kind of like a made-up story i tell myself because it's like it's useful but that's different to a myth i maybe it's like a sliding scale yeah yeah i think i think shaw does a good job kind of talking about maybe not quite answering your question on if that's a myth but we could even just say like let's assume it's a myth for a second. Let's say you have some statement about how your program works, and we want to consider it a myth, right? Shaw says a little bit later, the problem is not so much that myths are untrue as that they are incomplete. They should continue to guide us where they apply, but we should be acutely aware of the risk that they're blinding us to other possibilities.

And I think this really reinforces this point that you're making. Sometimes we talk at levels of abstraction that are good enough. They work for most of our cases, and then sometimes they don't. So maybe we think of variable assignment as happening, and usually it works perfectly fine with the simplified model we're talking about until concurrency comes in right and now that variable assignment was a myth right we acted as if it's atomic when it's really not or something yeah and so i think this is kind of the point that that this paper really makes is that these myths have some truth to them

they might be abstractions or as shaw puts it they're idealizations they hold an ideal conditions but reality is a bit messier right and so yeah i do think those abstractions can be considered myths as soon as they're leaky. If they're not leaky, they're not myths. There's a nice sort of unifying myth or mythos or whatever you want to say under which all the other myths could be captured, perhaps. And it's one that Shaw presents at the top of page three. She says, myths are stronger than tacit assumptions. They are embedded in our culture in a way that resists challenge. These myths arose in a bygone era, one that is even more idealized in memory than it was in reality.

An era with the belief that programming is the use of general purpose languages to create correct solutions to well-specified problems. Programming is the use of general purpose languages to create correct solutions to well-specified problems. That statement right there is going to get torn asunder. It is like four myths packed into one tight little sentence that Shaw is going to rip to pieces in the next section immediately following this one where she has a nice table of the different kinds of myths that we're going to dig into in more detail, but then also throughout the rest of the paper. So if you two are up for it, should we read through this table of what these myths are, this high level, like these are the myths? Or do you want to get to them as we go through the paper?

Because this is just sort of like an exploded table exploded table of contents so we could do it either way i want to know like right here right now all right which of these you think are real myths and which you know like what's truth and what's myth right now yeah let's have at it you know all right so i'll put out of the note that i'm i think we should read through this that's exactly what i think but i don't think we should read so this is a table with myth say myth myth mythos mythos i don't know how you should say mythos see mythos and then say pragmos i don't know what accent i'm doing i don't think we should read the say pragmos all right part we should just read the mythos the same mythos okay cool yeah i'm down for that let's just read the same myth so so the the pragmos is like reality

right like they're supposed to be the myth and then there's reality i don't think we should read the reality we should just read the myth all right and let let our listeners also think about which ones of these do they think are yeah are true myths yeah or reality yeah i mean the nice thing about this paper is that it does have this sense of structure from one myth to the next even if you get a bit lost in one of them then you get picked up very quickly by the next one ivan you've got to do some little myth introduction right you know like i do myth number one we could have done a top 10 myths that's exactly yeah yeah yeah top 10 myths of the end of the world yeah that's actually a really good album oh top 10 hits from the end of the world uh anyways it'll be in the show notes okay uh let's let's round robin jimmy since i'm

allowed to say your name as much as i want first myth programs are written by highly skilled professional programmers myth number two the code is the software. Software is simply the symbolic programmed text. And those two myths are followed by three purity myths. These three next myths together are called the purity myths. The first purity myth is the myth of mathematical tractability. Soundness of programming languages is essential. Correctness of programming languages is essential. Correctness of software is also essential. Thus, formal specifications are also essential.

And I think we should skip the last one. Okay, yeah, let's skip the last one. It'll be bonus for the listener if they decide that despite our best attempts this paper actually sounds appealing you can go and read it and find out what the last one is see that's the thing is like now you know despite our resistance this paper sounds appealing like this was linked so many times in slack yes so many people really enjoyed this paper i'm not saying i didn't i'm just saying i struggled with it just like like the Engelbart, right?

Engelbart is a great paper. Oh, I would much rather read this than the Engelbart. Yeah, yeah, yeah. I would rather read the Engelbart than this, but... I mean, I would. But I do think there's a lot in here. And if you're interested, you should read the paper. We wouldn't pick a paper if we didn't think it was worthwhile reading. Can I say at this point, a thing i really liked about this list of myths is the font the font and under the myth column it's very ye olde englishy

it sets the mood quite well let's see if that works out for them yeah no this actually i i you know i can't um this is a great opportunity. Welcome to the, let's talk about the design of the paper at the beginning of the paper club. I liked the design of this paper. Visually, it was very nice to read. It is not a gross two column photocopy of a PDF kind of thing. It's, you know, nicely illustrated. It's got these great prints of paintings and lithographs and that sort of thing i think these are lithographs some of them yeah the xkcd ones are definitely lithographs there's lots of xkcd sprinkled throughout here like four or five of them some of them were good some of some of them are some of the good xkcds even i mean it starts with apollo killing the python yeah whoa that classic xkcd post yes that's my favorite person yeah yeah when the reddit client killed the programming language all right so uh that brings us to the first section digging into a myth in detail, which is the myth of the professional programmer.

And this section introduces a new term that I quite like, vernacular software developer. So it sets up this dichotomy between professional software developers and vernacular software developers. And here's the quote that I'll read setting up that distinction. A professional software developer creates software as a principal occupation, usually for use by others, and has professional training in software development. A vernacular software developer, on the other hand, creates software in a specific context, has principal responsibility in that context, and has professional training, if any, in that context, rather than in software development. The software is a means to an end, not an end in itself. The alternative terms end-user and

end-user programming are pejorative. Non-professional is misleading. Many are professional, just add something else. I quite like that framing that end-user and end-user programming are pejorative. I also, I feel that way as well. And saying non-professional, yeah, that's like, you know, these are professional people. They're just professional in some non-software development domain. So Shaw is going to use the term vernacular software developer to refer to people who have to make software, but they're not making software for its own sake. They're making software to do something, and that's the something that is their area of expertise. Help me understand why end-user. I can understand why non-professional would seem

not respectful. Why is end-user programming pejorative? Well, I think that from what I've seen the term end-user programming used for is that whatever it originally meant, I think basically what it means nowadays is easy programming. Baby programming. Yeah, baby programming yeah baby programming

toy programming you know you can't do normal programming so you have to do end user programming i mean uh have you heard of this guy steve krauss not not a once never in my day he's uh said some interesting stuff about this recently he says that uh with his current uh valtown project he's trying to make it work well for was it end programmer programmers or something end programmer programming yeah which i think that was a term of art at least um i've seen steve hi steve uh credit jonathan edwards hi jonathan with uh with that term i think uh i think that's where that term may have originated but yeah this idea of like what if we took some of the nice qualities of end user programming that it's like by design approached very differently

from traditional programming but took that framing that approach to programming and made tools that were for real programmers like you know actual professional programmers i mean it's quite a funny phrase and programmer programming it kind of highlights that we're not actually using end user programming to mean end user programming you know it's it's almost like no it would be embarrassing to say end user programming you know it's it's almost like no it would be embarrassing to say end user programming you know this is not a toy thing this is real yeah yeah yeah that that captured definitely part of why i think end user programming is pejorative i'll throw out another another reason why end user and end user programming are pejorative and mostly focused on the first end user there's a a thread of thought

that says that the term user is a pejorative term um some people are some people do it on a linguistic um bent where they say oh user is like the term for somebody who uh who is addicted to heroin so we shouldn't we shouldn't use the term user because it implies like like that that term has some stink on it so uh we shouldn't apply that term to the people who yeah get the benefit from our software wow it's hard to get through that explanation without using the term use we shouldn't use the term use anyways well i i have seen this other uh i guess movement or idea of people not users yeah i'm on that i'm on that yeah yeah you're on that was that you no i'm on that bandwagon is that a intentional drug i'm on that yeah no i'm taking i'm taking people that's what i do as a podcaster is I take people. See, I'm in people ops.

Uh-huh. People. Have you not heard? This is the replacement for HR from Google, I'm pretty sure, is where the term originates. Instead of HR, it's people ops, which is just awful. I'm a PIPX designer. I do PIPX. People interface?

Yeah. And people experience. I have to admit, I don't see how end user versus vernacular feels any different. What have we changed in our conception of what these people need and what the solutions are going to be

that's different if we use the term end user versus vernacular vernacular is cool but i think it's really just trying to say oh and because normal programming's you know it's latin it's the it's the non-normal thing here's another one it keeps the framing focused on the relationship uh mediated by the software. So the professional software developer authors the software and the end user uses the software. And because we are looking at the software right now and the process of creating the software, we may intuitively elevate the software developer to a higher status in our minds and the end user is a lower status whereas what this is trying to

say here is no the people who are using the software and who are in fact writing the software in their domain specific area where they are this expert in this other context like those people are deserving of our utmost respect and our attention and so by labeling them end user it's sort of diminishing them in a way that could be avoided if we picked a a more respectful term i buy that a lot more i agree i i think um you know end user programming is also is almost a slightly dirty word yeah um and it's a messy definition and i think she's just sort of said i don't want to deal with that um i'm gonna specify the uh the this language i'm using which is more positive more respectful i personally would have gone less respectful to the professional software developers i maybe i would have just called those massive nerds and then the vernacular ones just normal people this reminds me of some like much older papers which talked about like programmer bums and

program have you ever heard of this no i've heard of priests high priests you gotta read this paper about programmer bums okay and it was it was about like the early culture of programming and how it became and I highlighted this word mystique in this paragraph. What did she say? Shaw says, part of the reward for this effort, referring to professional software development, is an associated mystique about having mastered the special knowledge. And there's this culture of thinking that programmers are people who just sit away. No one understands them. They don't talk to other people. They're programmer bums. They just code and then produce correct, perfect software that doesn't have to deal with a fuzzy world. It's right or it's wrong. And so I would have just

called them, yeah, massive nerd programmer bums, bums maybe then again she's not trying to appeal to me she's trying to appeal to these professional software developers so credit to shaw for finding something that is respectful to everyone yeah yeah yeah she's trying to appeal to the people who are making programming languages typically for professional software developers to convince them that these people ought to be making tools for vernacular software developers as well and um it's already come up once in this episode that um shaw loves her lists um like the the abstract had this big list of sentences that seemed disconnected, but that in hindsight makes sense.

I love lists too. I love lists. I also love lists. I highlighted a whole bunch of lists. Here's one. Vernacular developers are typically not trained nor interested in being trained to use traditional general purpose programming languages,

nor do they necessarily share the cultural knowledge of the software domain or its engineering sensibilities about system integrity, maintenance, backup, and the like. Instead, they use spreadsheets, databases, scripts, web authoring tools, constraint systems, graphic composition tools, macros, and so on. Instead of writing sequences of programming language statements, they write sets of related formulas, develop macros and scripts with follow-me examples, formulate sets of interdependent constraints, connect objects in diagrams, and develop user interfaces and websites with graphical tools. So there's your high level sort of like, these are the kinds of activities that vernacular software developers do.

And what I find interesting in that list is that these examples are all ways that they use the affordances that we've offered them. Like we as software developers, we as the builders of these tools like spreadsheets database scripts web authoring tools constraint systems graphic composition tools those are all like things that i've seen people do phd theses about and and give presentations and write papers and make cool prototypes and all that kind of stuff just to like get one of these things you know one increment better or like get it on the table get it out there into the world in some way or another and like as a personal example like constraint systems i recently joined ink and switch as a researcher on the ink track i don't think i've mentioned that here so oh congratulations

thank you thank you um that's that's the only big change that has happened recently around these parts. And so part of what we're working on involves constraint systems for vernacular software development. And I won't give more detail than that. But this really resonated with me because it's like, yeah, clocked, right? Here I am as an author of tools for quote-unquote non-professional software developers and i'm using exactly one of these things and so it's it's interesting to me to think about how would we make this list bigger how would we put more things in here how would we take the things that are in here and make them richer? How would we turn actual professional software development tools

like C++ or Rust or Postgres or whatever and turn those into things that feel more like constraint systems or graphic composition tools? I think there's just a lot of fun stuff you could play with in this little space that Shaw has carved out. Yeah, and I think with this section, we get not only this picture of vernacular programmers, but the fact that they vastly outnumber

the professional programmer. This professional programmer myth that a lot of people are spending their time doing these things that, by most good definitions of programming, Shaw would say are programming. You don't have to be using a traditional language to actually be programming. And so we have this whole group of people who are

doing tons of programming, most of the time not using a traditional language, a traditional programming language, and yet they don't get any support. They have to spend all of their times in these tools that weren't really designed for the tasks they're trying to accomplish. I have a buddy who's an environmental scientist who is now learning traditional programming. I think I've mentioned him before. And the reason is, is like, spreadsheets just stop being useful for the kinds of things he was doing. He got to a certain scale, and he talked about his workarounds of crazy, intricate, like, oh, well, I make spreadsheets for all of these different things, and I have gigabytes of data that I'm trying to process through spreadsheets.

And his only answer was even to go get a master's degree or something and go learn data science stuff. And that is the kind of thing that this paper really wants to point out that that isn't the way this has to be. The reason these people have found themselves in this position is not because they're unsophisticated, because they lack knowledge or anything. It's because the tools they've been given don't support the rich things they are capable of,

the rich ways in which they can think about computation. And I love this. There's an example. It talks about researchers where we had this well-known bug that had happened all because of a difference in how files are ordered on file systems between operating systems.

I think this is a great example where people had built all these tools for scientific computing that depended on things like order matters. And for some reason, the systems we've built don't even help you guarantee those kinds of constraints. And so yeah, I'll buy, I'll say I'll buy that vernacular might be a better term. I still think end user programming is not that bad, but that's okay. I'm curious, though, do people believe this myth? There's two ways of saying a myth is wrong. That it's not true. I think it probably is true that people who vernacular programmers outnumber programmers.

Yeah. But is it really the case that this myth is believed by a lot of people? Do a lot of people think that programs are written by professional programmers and that that's why they're building all of these formal tools? I just don't buy that. That's true. That's... Oh, you've convinced me. You've convinced me.

I don't think that, I don't see how this idea, even in its subconscious form, is what is making people not build these tools for vernacular programmers. I don't think it's that people think, oh yeah, there's just so many more programmers, or that this is what programming means. I think there's other reasons why people aren't building these things,

and I think it's around incentives. I think it's around how academia is. I think it's around what can get published, etc. That's why I'm saying this paper, paper i think makes a lot of good points i just don't understand what the argument is here for this myth i see what you mean maybe it's the well everyone knows that there are plenty of vernacular software developers out there. It's just no one cares about them. Yeah, or the kinds of people who care about them are the kinds of people who self-select into CHI slash HCI,

like human-computer interaction stuff, or who self-select into working on spreadsheets, which at this point are pretty heavily productized more than the domain of academia though you get a little bit of overlap there with things like state charts state charts still feel like an active area of academic research that are to me related to spreadsheets like in my mind but even then like state charts seem to be something where the ink has not yet dried on whether those are tools for serious professional, you know, the Jonathan blows of the world. The people who take themselves so seriously as a programmer that like garbage collection is something they like snort at.

Or if it's a tool for the people who are not even aware of what garbage collection is right so where where that technology ends up going tbd but the fact that we can kind of clearly see oh yeah there's the people in the world who don't garbage collect and there's the people in the world who like just assume that all programming has garbage collection in it because all the tools they use are you know that far away from the metal and that you you sort of specialize into you know working at somewhere higher up or lower down in that stack like it feels like the thing that's missing here is maybe cross-pollination between those camps like maybe the the people who spend a lot of time working on like machine instructions or compilers or that sort of thing that the jimmy millers of the world and the people who spend their time working on abstract

graphical constraint based rule system things the uh the uh ivan wilson's of the world ivan wilson well how do how do we portman tow our names uh luvin the luvins of the world i like that that's good the luvins of the world i ship it yeah yeah yeah and then we'll need to figure out okay when jimmy and i are in the same camp on something and not lou that would be the the jivins the jivins what and then when jimmy and lou are in a camp what is what is that that's the limmies the loomy the loomies limmy limmy what there once was a limmy from what i don't know it sounds like a limmy rick oh oh dear okay all right so the the thing jimmy was saying i do see that there is a a self-selection if not like institutional slash incentive driven

motivation for people to specialize in a way where they're focusing on vernacular developers versus professional developers i do see that happen i meet people and they say yeah i do this and that and that and that and i say have you thought about this other category of people who could benefit from that skill and they say no like the catamorphism talk that i sat in on as an abstract performance piece right one of the people in the audience had a question at the end of the talk where they were like have you thought about this other interesting way to use this idea that you presented and the person giving the talk who was like very like stern suit and tie academic like you know devout professional like i don't want to say joyless but um this person who's like who's like deep in it they were like no i've never thought about that

and i don't see why you would it's like they have so square peg in square hold themselves that considering applications of their ideas outside of the main domain that they've selected into is like it's a foreign idea and an unappealing one at that and so i think that is that is the audience of you know programming language designers that shaw is targeting is those people who are like you know i only work on incremental improvements to see compilation you know in this one particular way that sort of. I want to give one more angle on this same thing, and maybe I'm pigeonholing too much on this myth, but I also think you can look at this from a totally different angle

that vernacular programmers have had a lot of resources poured into their work. It's just that all of that work has been captured by commercial entities. Think about all of these. There's all sorts of ETL processes. There's all sorts of tools out there where you can spend tens of thousands,

hundreds of thousands of dollars to have your point-and-click ETL process. There's Microsoft who's put Copilot into everything now. There's been tons of work poured into how to make Excel do everything that you want it to do. I happen to work at a company that builds things that lets random people customize all of their help desk software. I am working on something where the new track that we're working on is actually called ProCode. It's supposed to be professional coders working on this stuff now. And the way that this has been seen

is that everyone who's been building out these systems beforehand were non-professionals. And yet, there's millions of lines of code written in these systems for non-professional programmers. If you actually look at it, I talk to people all the time who work with these tools that are specifically designed for vernacular programmers that are not geared towards software engineers.

Their way they're sold is, hey, you don't have to go borrow those programmers over there. The software engineers over there, you can do it yourself. Retool is a startup that's in this. I don't know that it's really the case that they haven't had much thought to put into these things. It hasn't been really, people are ignoring it.

It's just that their needs are very different from what academics explore because most of the people who are doing this work don't have the freedom to choose the tools that they want. This is the negative part that I'm saying. This is the incentive of why it is, is they're stuck with these commercial tools that their company imposed on them rather than having the freedom to explore these kinds of things. So I agree with the goal. We need to make vernacular programming better. We need to make with the goal. We need to make

vernacular programming better. We need to make it more expressive. We need to let people do more of these things. But I just wonder, is it really that we need more academic research poured into it? Or is that we need to change some incentives and structures where people have more freedom

to choose these tools? I guess this is the thing that I just found. I just found i just found this section unsatisfying and i know it's not a standalone section i know we get more into stuff as we continue on but i just want to put these thoughts out there of like are these the right myths for us to be focused on if we want the goal that shaw wants i want that goal i don't know that this is the path busting these myths myth buster style is the path to get there and you're saying you would choose a different set of myths yeah yeah i i did not make a list of my myths oh i wrote down three myths whoa coming in with the

homework i i mean like you know this is all i care about now this is my whole world well they're three myths yeah no oh no i don't think we should do them now oh okay so so jimmy and i have until the end of the episode to come up with some myths be entertaining conversationalists and to come up with our own lists of uh myths at the same time okay so my first one is i mean i might add another one i've been convinced by jimmy casting is the dominant new wilson is an incredible human being that's a myth that's not a myth listening to their toad pond podcast should be required as part of the elementary school curriculum that's not a myth that's true that's true well see ivan's just

doing that thing where he inverts the meanings of things like considered harmful dikester and then oh yeah it's a callback yes it is uh-huh by the way can i well i feel like we should give this first myth like an official seal. Oh, yeah, yeah, yeah. Does this get the, that is a valid myth and worthy or? Mythbuster style would be busted, is it proven? And then plausible. And Flophouse style would be, is it a good bad myth, a bad bad myth, or a myth we kind of liked?

Wait, what? I'm not well read enough to do myths chat oh that's okay i think this is plausible yeah i think this is a a myth i kind of liked plausible maybe if we nitpick there's some things but let's not do that you know i'm i'm all i'm all for this myth and just uh to to further counter jimmy in 20 seconds shaw includes a couple of examples of uh things that vernacular software developers do that could use uh some help from the tools and and and work of professional programming language designers. So for example, there's a character named Frida who has to take a spreadsheet that comes from her company, you know, high up in her company that's about preparing some annual report or whatever,

and she has to customize it to her department. And so each year the company sends down the new spreadsheet with the new format or whatever and she has to look at the new company spreadsheet last year's company spreadsheet and her modified department specific version of the company spreadsheet from last year and try and like you know crdt those by hand together into the new format spreadsheet just for her department so like trying to figure out all the deltas that have happened and put them together and that's that's the sort of thing where hey i've referred to this as her manually crdting them together

uh because crdts are good at that kind of thing right like and and git is well terrible but something git ask might be good at this kind of thing and so yeah wouldn't it be great if if uh if we could you know put crdts somewhere where frida could benefit from them and frida is not just a character frida is a real person yeah there's like a stick figure drawing and everything she's real to me well it says frida is a real person interviewed for that study so this was a real example yes and there's an actual stick figure drawing right there that i'm looking at with a circle and some lines and it's real to me i don't know why you're denying me the reality of this person jim but our numbers real well no no

i don't know is the sentence frida's a real person interviewed for that study, is that real? It's in the example. Like, it's part of the example. It's not outside the example. I can't. Myth number two. Myth number two.

Myth number two. The code is the software myth. The code is the software myth. Historically, program was pretty much synonymous with software. The mindset was that software systems are big programs constructed by compiling together smaller program modules, which are written in the same programming language and interact through precedence calls. Procedure calls. Oh no, I got it wrong all right

i'll do it i will do all readings i will do them flawlessly this is it's quite quite long words in there you know yeah oh i i uh people on the on the grade school schoolyard called me data because i liked to use big long words and i still like to use big long words procedure calls there i think okay great uh data was incidental debugging involved direct interaction with the schoolyard kids maintenance was a necessary evil driven by being beaten up every day at lunchtime documentation was missing or viewed as stinky. The behavior of the program depended only on explicitly taking the children outside and shaking your fist at them sternly.

Libraries in the underlying operating system, which changed only with explicit detention of the programmer. Lou has in their highlighting a color. Oh, it's spying. That is reserved for Ivan will have something to say about this and i scrolled through their pdf that they shared with me to find hey wait a sec there's a section here that is highlighted as ivan will have something to say with this so lou what what what do i have to say about this highlight that you've got well there is a clear distinction between a program and a system

right so like a program is maybe like a something you run something goes in something goes out or something goes in lots of things come out whatever a system is well actually it says a software system is a composition of programs and other resources including possibly databases that provide a computational service. It is created by software developers using some kind of software development environment. It differs from a program in scale, in scope, and in the developer's responsibility to the users of the system. And I know in the past, you have mentioned about the difference between a programming language and a programming system and i think there's some parallels here and i think i think there's this acknowledgement when

you refer to a system or when we talk about a system there's this acknowledgement of this system is not just a thing that exists in a vacuum in like a hypothetical world. No, this programming language or this tool or this application exists in the real world. And there are some fuzzy edges where this touches and affects the real world and vice versa. So maybe it has to cooperate well with other programming systems or programs. Maybe it has to work well with like real people using it maybe it has some data sort of embedded in that might change over time because our world changes for for me this also relates to robust first computing right all right heck yeah so time to actly on this episode is one hour 40 minutes all right but this is literally what dave actly talks about with this concept of robust first computing where

when we make a program it's not just a program it's a system we can say that it's in some ways comparable to a living system where over time it, it might need to react to changes, it might break and it might need to repair certain parts of itself. And I think this is basically saying the same thing. When we make a program, it's usually part of a system. Mary Shaw mentions like documentation or like what platform it's running on yeah I'm all for that there's sort of when you code something and you put it out there you don't just forget it it's part of the a bigger changing world there's a wild thing that she says at the bottom of this section that I highlighted specifically and I'll work down to it so this the thing that Lou had

highlighted saying oh ivan might have some thoughts about this it's part of a little sidebar and so the sidebar makes three points or it introduces definitions for three terms and the first definition is a program which is an executable definition of a calculation that accepts variable inputs she goes on to say a little more about it the software system which lou has wonderfully about, which is this composition of programs and other resources, data, etc., etc. And this third one is a software development ecosystem is a comprehensive software development environment. So we're talking about the development of the software, not the actual running of the software system or the program that you built, but this is the ecosystem of developing software. It includes tools, languages,

libraries, interface standards, and other resources that support software developers. The software system may run in an equally rich execution ecosystem. I love that term. Oh my goodness. Execution ecosystem as opposed to development ecosystem. That is extremely my jam. That is like, I'm the jam boy for this idea. Is that there is an ecosystem in which you develop the software and a separate ecosystem in which you develop the software and a separate ecosystem in which you execute the software.

And that is something that I don't spend a lot of time thinking about, except in maybe a very narrow way where I think about like, oh, how portable is this binary? Is it, you know, the kind of thing that is fat or universal and I can run it on some other architecture? Or is it, you know, cross-platform? Will the same binary run on windows and on mac os and on linux or you know is it compiled just for for one of those platforms and you know is the source code written in a language that is portable so you can compile it on you know unix or compile it it on Windows or what have you. And then, you know, it runs on that platform it's compiled for. That's, to me, a very narrow way of thinking about this execution ecosystem, where I think a bigger way of thinking about execution ecosystem is like starting to ask questions about like, what does it even mean to execute code? And so that like Ackley, you know, example, like Dave Ackley's, the things that he builds execute in a very special kind of environment where it's like, oh, yeah, this this thing that I made executes in an environment that is this large tiled grid of, you know, subdivided screens that is spread out over the wall in this building, you know,

it involves a definition of hardware in a way that is, you know, you need to define it quite, quite, um, in quite a lot of detail because it's so different from how we normally conceive of a, you know, a computer. We might think of, you know, a desktop or a laptop or a phone or something like that. Dave's over here thinking like yeah i want my my software to be able to run like as an organism and so i need to create like a like an actual ecosystem for it to run inside of and what would happen if you like cut your computer in half while it was running can you build your software so that it just keeps running even though you've just like cut it in half

that sort of thing so i think it goes even further even further yeah what you've described is this t2 tile project it's like a indefinitely scalable computer architecture that uses a whole like completely different set of priorities to our current computers. But that is work done by Dave's organization, which is, I think, just Dave, basically. But he's a good guy, so he does a lot. Dave counts as three people, right? Anyway, it's from the Living Computation Foundation, which presents a different way of thinking about code,

which I think really is relevant here. Because there's this concept of we ship code in so many different ways, in so many more places than is currently assumed. So when I say we ship code, that's often referring to pushing some code from your development environment into production but actually we're shipping code every time we make something run in our development environment we're shipping code when we put an example on a doc site that code is being run by

sometimes a computer sometimes someone's just reading it, and that code is like having an effect. It's like a very different way of thinking about it. But I think the important thing is that there's this acknowledgement of the larger ecosystem around something. And, you know, if we are only focusing on making one program run well in one specific constrained environment, that's not so useful as thinking about the whole ecosystem. Yeah, I think this is something that Shaw is definitely absolutely right about the reality here, that software is more than just a singular program text. I think anyone who's been working in,

especially if you've been in a big company, but in general, I think modern software engineering outside of compilers, this is just the reality you're faced with constantly. You realize that you can't make a change to this API because of code that exists not even at your company depends on the fact that that field is there. And that is nowhere.

There is no text that you have access to that tells you that. It's this kind of implicit behavioral specification. There's all of this data that you have to migrate. There's all these users who use your system in some weird way. The constraints on what your code can do depend on all of these other factors. And so you realize my software that I'm doing is not just this code I'm writing here. It's the concurrency mechanisms. It's that database.

It's Kafka. It's blah, blah, blah. I think this is just a reality that's really faced. And I do think there's an argument to be made that a lot of academia ignores this reality. Now, there are some great works that I do think try to do this, where there's systems trying to let you program at a higher level of abstraction, think about concurrency as a first-class entity, which is something that Shaw points out here.

Modern languages don't let us do, let us express this, but they are a little on the fringe. They aren't kind of the mainstream thing. And there's a bunch of things interested in like the formal semantics of a single language rather than thinking, how do we deal with this massive system that we're confronting? How do we, I think Jonathan Edwards has really interesting things along these lines. Like I said, a little on the fringe. I think Jonathan Edwards would be fine with me saying that. Where it's like, how do we do data migration? How do we handle schema change over time? How could we have something that lets us really think about program evolution?

That, I think, starts getting at these systems and how they evolve across time. So I think this one, I mean, when we're talking about the reality, I think there's no question. Software is not just a program, and it hasn't been for a long time. I think it hasn't been probably since the ibm 360 at least like

you know it's been it's been a much more complicated thing for a while and shaw recognizes that this section though is pretty chunky like we got yeah we got a lot here so we got this kind of first section of like the code is the software myth what kind of introduces some of these concepts and then we get a split where shaw says this myth plays out differently for vernacular programmers and professional software developers and i i kind of got this like professional software developers i do think there's some weird things in here uh but i'm just going to skip them and ignore them because i don't need to nitpick stuff i think this is is is spot on i mean We can comment on the professional one

if there's things that you all want to pick out. I think you mentioned, like, when you talked about layers, Shaw mentions the sheer number of layers that professional software developers have to deal with when adding something to the ecosystem. They're not just adding it to avoid. There's two good lists in the section talking about how the code is software myth manifests when looking at professional

software developers. One of them is that modern software is made up not just of code in a single programming language, but also of code in multiple languages, supporting technologies, large data sets, synchronization for distributed execution, interface policies, scripts, real-time data feeds, dynamically selected components, automatic unannounced updates, and so on, much of which is not addressed by mainstream programming languages. And then there's another list, which is the elements that are incorporated in the software may come from ad hoc, untrusted, unstable third party sources. They are under specified and may change their behavior without notice.

So she does do a little bit of discussion about the sort of the question of like a secure software supply chain, wanting bill of materials for software. That comes up in this section if you're familiar with those themes. Another list, software developers must scrutinize configuration parameters, wrangle APIs, set up data and communication protocols, manage the third-party bits, including the vagaries of unannounced changes, and generally worry about which bits not under their control are going to go awry next. Love these lists. Shaw, great at list writing. Make me very happy.

You're so good at reading lists. Thank you. You didn't have to put the word list at the end of that sentence. But there's the next section, which I think we have more interesting things to say perhaps which is it's so we looked at how this myth that the code is the software affects professional software developers now we get to look at the vastly more numerous vernacular programmers mostly use tools other than general purpose programming languages. So the myth that the code is the software breaks down

with vernacular programmers because they're not writing code. They're doing other stuff as part of their programming. And so if you are convinced that the code is the software, therefore, you know, we only need to focus on code related concerns. Well, you're wrong if you care about vernacular programmers because they're not writing code in general-purpose languages. They use a variety of tools and notations, including spreadsheets, scripting, data schemas, markups, domain-specific languages, visual web development tools, and scientific libraries.

Many of the tools don't represent the software as a static symbolic text. Software development may involve progressive tailoring of a system, collection of formulas and constraints and spreadsheets or CAD systems, or visual programming. So we are way outside the realm of the text code is the software. Now the software is something wildly different. It might even be visual programming. Thoughts on this section i will just put in a note that i do now have my list of myths so oh nice and they're they're real

not weird things that ivan wants to list out uh so i do actually now have it now that we've gone through uh ivan you you read enough lists i read enough lists that jimmy had covered a zone out and come up with some goods um so i i think this is interesting lists considered harmful dykstra i think it's weird the way that this myth is breaking down between professional and vernacular because you know for professional it was supposed to be oh, there's so many more things other than the code. And vernacular, it seems like it's like, well, the program isn't the code. And I guess I don't see why there needs to be a difference here,

because some of what vernacular programmers do is code. Spreadsheet formulas is code. Yeah. I think there's just like definitively a classic, you know, functional programming language. It's just put inside of a cell instead of in a text file. But I think I just don't see why this needed to be that different, because I think what professionals do that's not code is very similar to what vernacular programmers do that's not code. Really, I see the distinction as just which kinds of tools that they're using. Generally, professional programmers don't like a lot of the

tools that vernacular programmers use. Yeah. And whether they like them or not is a different question. But they are using these things, and programmers often, even if they could get benefit out of using those tools, there's kind of this cultural, no, I would not use that tool. And there's sometimes good reasons. Maybe they're proprietary, maybe they're whatever, but they're often just not using those tools. Why I was a little confused on this difference,

I think even Shaw points it out here. It's claimed that there's kind of this maybe a difference in working and how people work. And I'll read kind of, I'll try to read and see if I can not fail at reading because I'm not as good at reading as Ivan is.

Lists? Oh, just in... Sorry, reading lists. Lists, yeah, lists. Reading lists, yeah. Yeah, yeah, yeah yeah yeah reading lists Ivan's awful at reading anything other than a list it's usually just me doing my Ivan impression that's why the radio voice was added in so you wouldn't notice that it was me doing an Ivan No. Yeah, absolutely. No. No. So this is on page 234 colon 12. I don't actually know why.

Page 12. Yeah, yeah, but why is it 234 colon 12? Any idea? Because this was published as part of a longer journal, and so it's page 12 of this article within the longer journal. There were 234 articles? Yeah. this article within the longer journal. There were 234 articles? Yeah, it's the ACM Programming Language Volume 4, Hopple, Article 234.

Article 234, not in that... Sorry, it's not that there were 234 pages, it's that this is Article 234 in this. Procedures of the ACM Programming Language. I wonder if that's across all volumes or that volume. Anyways. I don't know. All right, so. It is especially important for these tools to support programmers

who are developing the software as a way of understanding their problems. So this is about vernacular programmers. So they're trying to understand their problems or the ramifications of their decisions. People who are using software to work towards a specification rather than from one. Programming in this exploratory mode involves getting feedback on whether initial ideas accurately capture the intention, then refining and extending the results to achieve a satisfactory program by progressive approximations while refining their understanding of their real

intention. So the idea here is this is like, you know, you're continuously developing what is the problem that I'm trying to work through. I don't really have a specification. I'm not really sure where I'm going, but I need to get feedback and see, is this the correct direction? Is this fruitful? And Shaw adds that this is talked about as a conversation and that many professional programmers work this way, but it's especially prevalent in vernacular programmers. I don't buy that this is any distinction here. I think that there are... I have not thought of a single instance where what I'm

doing and programming is not working through in a conversation with the code, with the system, what kind of problem I'm working on, what solution will work. I'm almost never working from a specification, even when I'm talking about like a compiler, like, you know, I'm almost never working from a specification even when I'm talking about a compiler. I'm looking on YJIT for Ruby. Yes, there is a specification in some sense. It's what CRuby does. And yet it was still this conversation back and forth. Will this optimization work?

Will I be able to implement it in this certain way? I just think this is how programming is yeah and it might be that this the reason that she's introducing this idea here is just because she needed to introduce it at some point and it just naturally flows here and not that she means to say that this doesn't apply to professional developers equally as much there's a weird sort of like uh yeah no we can't let vernacular developers have something that professional developers also deserve to have which is exploratory programming yeah the biggest thing that pops out to me from this section is kind of what jimmy mentioned earlier about all these examples of vernacular programming.

They sound like closed products or systems. So like one of the examples is like a geometric tool for, I guess, constructing diagrams for a variety of reasons, architecture, mechanical engineering, mapping. And I can think of some of these tools that I've seen. They're often something you pay a subscription for. The things you make in them are stuck inside them. You can't take them out and put them into another mapping tool or whatever.

You're stuck there. And Figma is like this. You know, I would say Figma is a form of generating CSSss and other stuff like i've copy pasted css from figma and and i'll do it again you know i like figma has been like a very high level way of generating css for me at times in my life um but like, did you see Devine's talk at Strangeloop? Yeah, it was great. Yeah, it was super good. Devine mentioned how some of these systems like Figma trap you, you know, they trap these vernacular software developers. You don't get good at designing maps or architecture or diagrams you get good at figma

and this is what i worry about when i see this difference that shaw mentions all of the professional software developer examples with with things that were very customizable things that they could be in control of things that they could take stuff out of all of these vernacular software developer examples seem like products seem like sass products that's a great thing to capture because shaw gives a ton of examples of things that vernacular developers are missing out on that professional software developers have, like programming language design principles such as precise syntax, abstractions, encapsulation, scope, and clear denotations. But you're bang on that there's like a whole other outside the text of

the code, outside thinking of the code as the thing, but looking at the broader ecosystem, differences between the way that programming tools are offered and the substrate that we get to build on top of and the materiality of the things we build versus what vernacular developers have as their material and their substrate and their environment. The software development ecosystem and the execution ecosystem differences Differences here are quite interesting. I think, though, the reason that these vernacular programs lack these things like precise syntax abstractions, encapsulation scope, and clear denotations are because they're built by industry. I think this closed source nature of these, this proprietary nature of these systems

is why we have a lack of these things. Because the way we develop software in industry is not conducive to these kinds of problems. If you look at, I'll use Salesforce. I've never written in Salesforce's programming language, whatever it's called. I have no idea, but I know they have their own. And I know there are people who have to code in it.

And from everything I've heard, it's not great. Another one that you could give example is like Mumps. Mumps was a medical software programming language, right? It was for databases. That's an awful name for a medical software. Yeah, why did they call it mumps? Or no, I think it wasn't medical originally. It was just databases, but the medical community took it up, right?

No way. Yeah, yeah. So mumps is used by Epic, which is like the largest electronic medical records system in the United States. Wait, not Epic Games? Yes, not Epic Games. Not that Epic. the other Epic. Okay.

And it's a crazy language from everything I've heard. I've seen a bunch of the code, but I've never had to write it myself. And it doesn't follow a lot of these things. I mean, you could even look at earlier JavaScript that was produced as a marketing effort, and it was forced in these timelines, and it didn't have clear semantics as good as it could have,

it didn't have lexical scope, et cetera. This is what happens is that we push these things out the door based on marketing efforts, based on what features our users are clamoring for right now, trying to solve the immediate problem, and then people get stuck with them, and backwards compatibility means you can't fix these kinds of abstractions and so they're these half-baked solutions over and over again so i i just think this i think lou you're absolutely right like all the examples in here like we see like autocad we see like google something or other microsoft something or other like it's or other. Like, it's always this proprietary software.

Yeah, one even involves Twitter, right? That's not possible now. Yeah, yeah. Like, these are the kinds of things where I really think, and if we think that it's, like, academia not doing its thing academia has supplied people with the means of of knowing how to apply these things i think personally they haven't applied them themselves because it's industry that's building these tools for vernacular programmers and industry has ignored academia i just think this is a deeper problem here than just researchers not focusing on these

things. It's even if they did, how do we get it into the hands of these vernacular programmers? So again, this isn't me like saying Mary Shaw's wrong, this paper's wrong. This is just saying, I think it takes one step further down the line. Yeah, our interpretation of the audience as being academic people who are programming language designers is too narrow. We also need to include industry people who are programming language designers or programming tool designers for these vernacular programmers. That's the thing that kept confusing me as I got to this point in the paper, is the industry people don't believe these myths. They never have.

They don't think that mathematical tractability is so important. They don't think that the software is the code. They don't think that software professional developers outnumber vernacular because they're the ones building all the software for all these people and they know how much is out there. So that's what's so confusing. It's targeted at the audience that isn't – that's what I'm confused about. I disagree in this one section where Shaw actually makes the split.

In this section, that myth that the code is the software, I think that does apply to industry people making vernacular programming tools because and it's they may like fall ass backwards into it but the thing that the ill that they bring upon the world is that they see their product as the whole universe and they build a tool like lou was saying that is proprietary and is closed and that way of looking at the world is like the writest large version of writest largest version of of this idea that the code is the software that it's like this thing is the only thing that we need to think about it's the be all end all it is the complete picture and you oughtn't not to look outside that and look at, you know, the databases and the runtime environment and the other tools and the get and the different kinds of activities separate from creating these very bespoke purpose specific tools in whatever proprietary thing you're using or the creation of those environments themselves there's like a myopia here and i think that that totally plays in this in this the code is the software framing

i see what you're saying jimmy i really do however i think the main message that shaw is trying to get across is that these vernacular programming tools are worthy of more attention and care and a bit of love and so i think that message is useful whether it's received by like the academics or the industry folks it's basically saying look these tools are like serious programming tools they're not just little drawing tools or they're not just little spreadsheet tools there's this like comparison is it that shows us look how different these things look and she's drawing a line between them and saying we need to treat both of them with a lot of scrutiny and a lot of effort and care so maybe there's someone in the industry who's who's reading shaw's paper and got this far and and that landed home but i think it's a bit uh harsh to say that you know mary mary shaw should be

reaching those industry people instead of the academic people i think ivan you were saying earlier about how she knows her audience like this is targeted at a very specific group of people working in programming i think it would be slightly unfair to say well she's not targeting this other audience you know she maybe she will next year you know or maybe i hope there's like a mary shaw equivalent in industry trying to drive those messages home in another way i you know like it's like if you brought an apple then i wouldn't complain that it's not a banana you know who the mary shaw is that's trying to reach industry it's us baby we're the we're the ones we're the ones who are bringing this message to the masses no wonder it's not going well so the next section i want to comment on this photo

oh it's yes me too yeah because i i didn't understand this photo when i first read it until a recent episode of a dnd podcast where why this photo would be included was explained uh so this was a pathfinder uh glass cannon podcast they talked about this not this photo but it happens to help me understand it so ivan do you know why this photo of a unicorn it's the maiden and the unicorn a unicorn resting its head on this young woman uh do you know why this is included here no jimmy i don't i also don't apparently it was believed that if you want to catch a unicorn there was a ritual you can perform you place a virgin out in a field and let them sit there quietly for a long period of time and then a unicorn would come and rest their head so this is purity myths so this is a

myth around the purity that would bring this unicorn that's what this picture is illustrating here is this myth oh my god uh that's i had no idea that's um that's a very art history ass direction for our show to go but that's why this picture was included yeah and that's why this painting was made that's what it's illustrating is this myth of how how you can find a unicorn you know a very strange medieval myth so we have the the first image in the paper is Apollo killing the Python. I think that's self-explanatory. It's like these myths. Let's kill these myths, right?

Mythical creatures, right? Giant Python. The second picture is Pandora opening the vessel and letting out all the, you know, the evils. That's the myth of the professional programmer, which makes perfect sense because programmers release evils into the world like you know following in the great tradition of mark andreessen the third image is vulcan forging the thunderbolts of jupiter and that's accompanying the code is the software myth which makes sense because you know software development ecosystem these tools these uh things that we have to forge that we release upon the world like thunderbolts the programming language purity

myths the maiden and the unicorn i think i want to be the unicorn this time that's how i'm going to be uh jimmy you can be the i want to be the virgin oh you want to be the virgin lou okay i was going to say jimmy should be the virgin and lou you can be uh the the bubbling brook in the background you can be the oh yeah yeah no i'll be that please yeah bubble bubble yeah yeah jimmy's at a horse show so i think i preferred it when i didn't know the reason behind this yeah the the abstract interpretation is um is more my jam knowing that there's like oh if i had actually gone and taken art history and listened to dungeons and dragons historical podcasts yeah i mean you can see the kind of the the maiden is painted in a way that you would paint mary right there is not there isn't the

blue that you would expect from like mary but it's very symbolic of mary here right so the programming language purity myths i've highlighted the entire first paragraph. I'm going to read it because I love this. Beautiful. Mainstream traditional programming language research focuses on purity, symbolic notations with precise specifications and well defined semantics that support provably correct solutions to well-specified problems. This has given rise to a pair of related myths that mathematical tractability of programming languages and the correctness of software are essential. And these two myths invoke a third supporting myth that specifications can and should be

precise, complete, preferably formal, and available at the beginning of the programming effort. Yeah, I hate these. I hate these so much. It's so bad. This is like 100% my jam that I cover myself with and let the bugs of righteousness bite me. This is awful. Mathematical tractability, go away. Correctness, go away. Specifications away specifications hate them don't want them next section i guess okay i i want to point out a tension here this is not me disagreeing at all but i do want to point out a tension here between this myth and the last one which was we talked about how vernacular programmers need things like precise syntax and abstraction and

etc and all of these things that that were pointed out so precise syntax abstractions encapsulation scope and clear denotations these are all mathematical tractable things and so i guess what i'm curious about is, I think the specification one is just kind of obvious. I don't think anyone outside of academia, at least, really believes in specifications. At least not upfront specifications created separately from the act of programming. Yeah, yeah.

People might think we need to be a little bit more, a little less loosey-goosey. But no one's like, hey, we should formally specify every single program we write in industry. But I think that there's this mathematical tractability. I think we have to walk this very fine line. It's very easy to say math equals esoteric or catamorphisms or category theory.

But even having precise syntax esoteric or catamorphisms or category theory. But even having precise syntax and understanding all of those properties, this is mathematical tractability. And it's the things that make us be able to deliver software that gives us the kind of, I think Mary Shaw calls it fitness for a purpose, rather than correctness. That's what lets us do this this is the mathematical tractability.

We have to have some of this. And so I'm just curious to see how do we see this line between mathematical tractability and like we have to have some of it. Who has to have that though? like whose whose problem is that right like is the problem of mathematical tractability the problem of the programming language researcher or is it the problem of the programmer and i think the objection that i have and that maybe shaw has is that a lot of programming language developers love these mathematically, you know, the soundness and provability kind of capabilities and try to offer them in the work that they make in the programming languages that they design and their theorem provers and all that sort of thing and say,

oh, the problem with C++ is that it has undefined behavior and therefore we need to be more rigorous in defining c++ or level up the ability to make formal claims about the c++ systems that we build right that we need that kind of like cock level soundness and uncertainty in our code and i think that that's the the part that i object to i'm all for let's have these you know formal properties let's do this reasoning let's you know have this elegance but like keep it over there like go do it in your ivory tower don't make me have to write software with that that stuff i want to be over here with like drag and dropping like graphical gooey widgets and and having them snap together satisfyingly

because you did all the soundness stuff needed to make that snapping work so that it does what I want it to do but I don't want to have to like prove to my programming environment that I'm doing exactly what I mean to be doing Andrew okay can I can I can I yes please sorry um please yes one of the most frequently said comments about some of the things that i make is people say is this turing complete or like i'm not sure if this is turing complete or it appears to be turing complete and and it is like what appears in my YouTube comments on Twitter on Mastodon and more recently it has been uh part of the feedback I got when I submitted uh to Splash the person who reviewed it and actually the feedback was extremely useful but one of the points of feedback was this appears to be true and complete, but I'm not

entirely sure. Which is why in the actual presentation itself, I put a little jokey section where I just proved that it was true and complete and then carried on without saying anything about it. Because I always feel like it's really not the point. The point is Shaw's thing. Is it, what does she say? Does it have the fitness required? Yeah. Is it fit for purpose? Yeah. So the main thing for me is, is it fit for purpose? And I've come up with this new concept where instead of looking at true incompleteness,

which I don't find very useful, I ask, can I do the things in it that I want to do? And I have a new name for it called luring completeness. Do you get it? It's like loo, but it's like, and the thing is, it's a really hard thing to measure and to prove. And it changes. And it's fuzzy. And you know, maybe luring completeness isn't what's important to you. Maybe Jimmy ring completeness is what's important to you. Or maybe it's our vernacular programmer ring completeness is important to you. But I think that's a far more useful thing to focus on. The thing is, turing completeness is easy to hit, but there's something appealing about it. You know, it's this myth that it's really important.

And it's this myth that we need to check this box. But like it's the Turing, what's it called? The Turing tar pit that you can get stuck on focusing on it. It doesn't matter. That's just one very small extreme example. I wonder about, are these other examples of mathematical tractability are they useful or are they just as pointless as true incompleteness i do want to just highlight something though that you you lou said in your q a asked by some anonymous person in the audience

was it ivan yes yes, it was Ivan. Ivan asked, and I really found this interesting, Ivan said something to the effect of, when you're exploring these features in CellPond, is it the user interface that's giving you all these ideas of what you can do, or is it the VM? There's definitely a leading question where Ivan assumed the answer was going to be the user interface.

You answered, no, it was the VM. The VM was more capable than that user interface. I guess in my mind I see this as that two sides. You've built this tool that's very interesting for vernacular programmers, in my mind. But also, it was the VM, this mathematically tractable side of it, that produced all of these ideas. I'm curious how you see that tension, because the stuff you're working on is mathematically tractable and sophisticated.

And that's where you're getting all of these ideas. I don't know. This is a tension that I'm just curious how we resolve. Yeah. Basically, this relates to this specification section as well. It might surprise you to hear that I actually think this general concept of specification is really important because it's really about design. So Shaw says that there's this myth that specifications can and should be precise, complete, formal, and I agree with her on that.

I think that they don't need to be like that. But I would say that it is important in programming to have something planned and designed ahead of time. That specification, I'm going to call it a specification, might be written down or it might be in someone's head. But there is a specification that you're working to. And in another Q&A, I did say I mentioned the cell pond spec, the specification. And I mentioned how i actually deviated from it for performance reasons so yeah you're right so i'm working from this vm i'm

working from this specification but this specification is not built and designed to meet mathematical tractability it is built and designed to meet something very fuzzy, which is luring completeness. And I think that's the main difference here. Like, there is only one person that could answer, is this luring completeness or not? And it's me. I like it. I like just because something is fuzzy and hard to measure doesn't mean it can't be designed towards. And I think that's what a lot of people who work in academia and tech academia, who probably enjoy being able to prove things to other people. Some things are really hard to prove, but it doesn't mean they're not worth working towards.

I come from a world of teaching where I have really mixed feelings towards assessment. We put kids through so many tests that are pointless and don't help them. But then we also do lots of really helpful assessment, like in the moment, just having a conversation with a child, checking their understanding, allowing them to give feedback to you. That's a really fuzzy fuzzy question and it goes really wrong when governments and departments for education i've got some i've got some some uh deep-rooted feelings here anyway some institutional trauma yeah the new future of education podcast yeah art history and our education no but it goes really wrong when they try to turn these fuzzy concepts into mathematically tractable measurable statistics

and and i i see this disconnect we're trying to make programs systems for the real fuzzy world mathematical tractability doesn't help with the real fuzzy world maybe it helps with some stepping stone along the way but the end goal the target is something fuzzy and i think that's that's what this vm was designed for this rhymes very nicely with our episode about uh legalism when we looked at lawrence divers the rules yeah of code is that what it was called whatever one that was the yeah the interpreting the rules of code uh interpreting the rule of code parentheses on the s there's something later on in this paper that made me think of that too which is where shaw mentions about health systems yeah maybe we'll get to that later maybe

if there's time who knows yeah but say we're like uh we're like halfway through oh we're fine we're fine we're fine we're fine we're more than halfway through the myths though i know we're probably gonna skip the last myth yeah we are yeah yeah ai no you're not saying it i'm cutting that out that's fine you can cut it out all you want i'll just keep scattering it throughout make your editing job harder that's fine i've done worse uh yeah so so there's uh there's a there's a passage in here that i actually want to call out as like this is the one part of the paper where i have a bone to pick with mary shaw can i guess can i guess yeah you can guess it's on page 17 uh yeah it is the like third paragraph that's on the page uh yeah

yeah yeah yeah yeah i i also have this is triple question mark territory for me and three colors of highlighting yeah this is nasty so let's i'll build up to it because i guess we're going to rip this one up um so it's under a section titled the myth of mathematical tractability favors mathematical elegance over expressiveness or domain specific power and she begins the section. Traditional programming language research emphasizes generality, soundness, completeness, richness, abstraction mechanisms, elegance, and so on. Love this. The researchers have deep expertise in different programming models, procedural,

functional, logic, data flow, object-oriented, and the formalisms that support reasoning about the programs. They design languages intended for use by professional software developers who are adept at generalization, modeling, abstraction, and symbolic reasoning. Using these languages requires programming expertise and, in many cases, mathematical sophistication and maturity. Love all this. No notes, no problems so far. All good. Double thumbs up. Agree on all points. Love that there's like four lists in this one paragraph. Super good. Very good. And she continues. But how widespread is that mathematical proficiency? According to the Stack

Overflow 2020 Survey of Professional Programmers, referenced Stack Overflow 2020, only three quarters have earned a college degree, and fewer than two-thirds of those received an undergraduate degree in computer science or mathematics. So fewer than half have college education that would suggest any proficiency in formal systems, even assuming that proficiency persists into their careers and is at a high enough level to handle type theory and category theory. Even more concerning, over 15% of the professional developers didn't think that college education is even needed to be a developer. In other words, there's significant dissonance between the level of formal proficiency expected by programming language researchers and that attained by developers.

Holy f***! I cannot get mad enough at this paragraph. It conflates so many nasty things that are awful, that I hate. I don't know if she's trying to make a point here that I missed and took the wrong point away from it but what i think she's trying to say is that it's and i'll you know what i'll put some weasel words in there to even help her case it's very likely that if you are going to use the sorts of mathematical tractable fancy features in advanced programming tools for professional software developers like type systems and category theory that it's important that you have a background in formal mathematics

and you attain that background through formal education i think that's her point i think that point sucks i think that point is awful i think that point is just. I think that point is just... I have the same gut reaction here. I think I figured out an interpretation that saves this section for me, because I tried to. And here's the interpretation that makes it not as bad, right? Let's start with the assumption here

that programming language researchers assume everyone using their programming languages have very sophisticated mathematical background which is already objectionable but sure i'll grant you that yeah but let's say all these researchers really think everyone has this complicated mathematical background. And now Mary Shaw is looking for evidence that suggests that is the case. And the best evidence we can get is formal education. Is that the only way you can get the necessary background? No. But how do we measure it otherwise? Okay, look at these surveys. It looks like people, even the people who are formally educated probably don't have the sophistication expected that's like the the weaseliest way i can interpret this section

but yeah there's i i'll get rid of the weasel things and just say there's so many conflations here of like that a formal education is the only way to obtain this that you need that sort of formal background in order to use things like type theory and category theory like that researchers expect this i it just this section just confused me and it felt unnecessary for the argument as well like i just don't see how it undergirds anything here and i admit that there's just a bias because i have no formal education i do appreciate the different reasons the two of you get annoyed ivan is just objecting to like you know i guess this elitist idea that's slipping in here and jimmy is just annoyed because the argument doesn't need it you know yeah that so wait among other things i agree with that

framing of jimmy's objection i disagree with that framing of my objection my objection here's a sentence here's a sentence that a human being wrote all right here's a half of a sentence okay even assuming this proficiency persists into their careers and is at a high enough level to handle type theory and category theory suggests a world in which people go to college or university and they study whatever they study and that is like inflating their balloon of knowledge and then when they leave that that you know realm of study and enter the world that that balloon gradually deflates throughout the course of their career as whatever knowledge that they picked up

you know is lost to the to the falling sands of of memory time and that that's it that that's the whole model for how it works to learn something like the mathematics that you'd need in order to be able to work with type theory and category theory like yeah that that that hurts like that's awful that that that's not a a straw person argument that is not a what's the gender neutral of straw woman oh you know i uh i'm to have a niece slash nephew-in-law soon, right? Oh, whoa, yeah. So, I looked up what the gender neutral term for, like, uncle and auntie. Uh-huh.

And they're just so bad. What are they? I don't want to be a pibbling. That's what I'm saying. That's what I was going to mention, pibbling. Pibbling? Pibbling? pibbling pibbling pibbling pibbling parent sibling oh i like that so much but you know what like the gender neutral term for nephew and niece is nibbling i like that too that's great doesn't no, it sounds like a disease, you know? We've got the piddlings.

So, I think it's actually strawribbling? Stribbling? Just change it to scarecrow. I think, just for the clarification of doubt. A scarecrow is a straw person. Yeah. Just for any listeners at home, I am non-binary. That's why I'm joking about it. Yeah. that's that's the context needed carry on i'm i'm binary but i'm also joking about it that

well because you know we're good friends you know that's how it works that's how it works you learned it here anyway oh can i put in a can i say something that would be like a that would literally boost the demographic of your audience please okay i'm just gonna say this phrase and then some people will get this joke a very small number okay heat from fire fire from heat that's it thank you lou i appreciate that yeah like this this this balloon of knowledge idea just hurts so much because it ignores all of the learning that you can do outside of a formal institution, which feels like something that Mary should be cognizant of and arguing for given all the other stuff going on in this paper baffles me that suddenly we get into this sort of you know academic supremacy mindset it implies that going through formal education is actually a way of accreting knowledge not just accreting like a credential um which i think for most people it is ah come on

even i like formal education is a way of accruing knowledge. There's no question. Is it the only way? No. Is it knowledge that you'd accrete better and faster than alternative ways that you could accrete knowledge outside of a formal institution? I don't agree. I think it's one, person relative. There are people who really, formal education really jives with them. Sure. And that is something they really enjoy and that's the way they learn, right? Yeah. And then two, there's kinds of things that are not propositional knowledge but like tacit knowledge that you gain in academia that are hard to gain elsewhere.

Certain forms of writing writing certain forms of review like certain practices around proofs or whatever right like i think that there's even though i am i have none i don't think we should completely diss on the formal education all right well i'll save dissing on formal education for the next time that perennial theme comes up uh because you know gotta keep powder dry i think it's one of many ways and here it's listed out as like the only way but in my head canon this this clumsy paragraph isn't there so i don't think we need to worry about it cool i expect uh every every paper we do from now on we're gonna get the the loo cut yeah yeah in my head canon this isn't there

and neither is i mean in your head canon the last myth isn't there either right so right yeah so what you're saying is we don't need that for luring completeness yeah basically do i want it yes or no no i don't want that paragraph it's clumsy it's not alluring so it does not does not make it into the alluring completeness absolutely not yes uh there's another um there's a little example on this page about um somebody asking in a github request the i think maybe one of the authors of f sharp or one of the people, one of the maintainers to add a feature and their reply, which I loved is adding type level programming of any kind can lead to communities where the most empowered programmers are those with deep expertise in certain kinds of highly abstract mathematics, e.g. category theory.

Programmers uninterested in this kind of thing are disempowered. I don't want F-sharp to be the kind of language where the most empowered person in the Discord chat is the category theorist. That resonates with me because I have had people argue against visual programming for the same reason, saying like, I don't want to have to have artistic skill

to be a capable programmer. And so by creating a system where you require like artistic ability in order to do the programming work it's it's going to be exclusionary towards that kind of person like i've legitimately seen that opposition come up and i love it because it's like you know you are getting close to a deep realization thank you a programmer for raising that objection um yeah i i love this thought that it's like yes there's different ways that people can express themselves and have computers do something as a response to that i think that's

a lean into it kind of a thing not a lean out of it kind of thing which is my way of saying type level great add it in put all the types just i think. Which is my way of saying type level, great, add it in. Put all the types. I think, though, this is an innovation of TypeScript. TypeScript has type level systems. You can do a lot of very advanced type systems work in TypeScript, and yet

what we don't see is that category theorist being the one empowered. We see a lot of users being empowered. So I think this was actually a user interface issue and an education issue and a framing issue rather than just the fact of type level programming. And so that to me is what TypeScript really overcame, which I think is fascinating.

So I'm hoping that visual programming will also let me, who has no artistic ability, be... You just got to overcome that, right? Let me do something cool, even though my art is awful. That would be very interesting to me, where it's like, oh yeah, there's a hierarchy of people who are able to make good use of visual programming, like true visual programming.

I'm not talking Scratch, Max MSP stuff. I mean like the one where you're doing drawing as the programming activity where there's like, you know, some people with basic like stick figure level art skill are able to do some work. But then as you have more and more artistic proficiency, there's like a kind of expression that you can make that is like meaningful to the computer that people without artistic capability are unable to express to the computer that's the like that's wild i love that thought so this goes on to like dsls here after we uh after we dis on people without formal education uh we uh dis on programs that are not domain specific

uh i don't know i don't know where this like this section i agree with the thrust of this section but i was confused on the setup of it yeah well like dsls are often ad hoc and so they lack a sort of formal rigor that maybe some other programming systems have but dsls are are wonderfully useful for obvious reasons especially if you're a vernacular programmer i think there's just an appeal here to say hey can we get i don't know what the appeal here is actually you know what yeah yeah it's this like this is where i don't like the tension is is here because like what what this what this section is saying is like mathematical tractability bad right to oversimplify but dsls have not been giving the loving care and attention that is regularly lavished on general purpose languages.

What is that loving care and attention? It's mathematical tractability. Yeah. I'm just so confused. We talked about the problem is mathematical tractability. That's all these language designers care about. That's the time and attention and care they're putting into their languages. And we don't do that for DSLs.

But what tools is the researcher supposed to use other than these tools they've been using for general purpose programs, which is their math? Maybe we need to cut mathematical tractability in half. Maybe we've glommed too much onto that term. Like you said hey in the previous section talking about uh you know the design of denotations and abstractions and all that kind of stuff that's the mathematical tractability maybe that's the mistake we're making is that shaw

does not consider that stuff to be the mathematical tractability part because like here's a quote right the sheer volume of software development based on notations and tools other than traditional general-purpose programming languages cries out for care and attention. So DSLs are crying out for care and attention. those, you know, ivory tower experts, from opportunities to trade generality for power in a language while maintaining the formal rigor now largely reserved for general purpose languages. So that myth of mathematical tractability is about like, hey, we only want to apply our effort to domains where we can like write formal proofs about what this software is doing. So any efforts that we make like you know coming up with better notations or coming up with a like an elegant way to have concurrency at the

programming language level rather than you know as some weird ad hoc layered on top you know collection of nonsense like any any nice properties that we might want to imbue a language with should not be reserved for the languages in which in in which we can make like strong formal statements strong mathematical statements we should also be doing that work in these ad hockey dsls where we can't make these big formal statements. They deserve just as much power and expressivity as the general purpose formal languages. I'm confused. I think what you just said at that last sentence

made me even more confused. Awesome. But I'm going to ignore that one for a second. How are mathematical tractability and formal rigor different? Because Shaw says here that we need to trade the generality for power in a language while maintaining the formal rigor now largely reserved for general purpose languages so the way i take the statement is stop focusing on general purposeness that's what the generality for power in a language right

don't have make it generally applicable to everything focus focus on their domain, but imbue it with formal rigor, aka mathematical tractability. I don't see how formal rigor is not mathematical tractability. I think those terms seem a bit vague to me. And this is what I found reading through it was, wait, what bits are good and we should do and what bits are not good and i know what i think like i could i could say like from my own opinion that mathematical tractability can be a blocker it can make you too focused on like the internal workings or implementation of a system instead of the actual like human fuzzy facing design and i think i want to keep taking it back to this concept of system versus a program because you can prove the

mathematical tractability of a program but it it might be that you can't actually prove certain things about a system and and it's not like should we do more mathematical tractability proofing or whatever it might be actually the thing we're trying to make which is a system not a program we can't even do it even if we wanted however i would say that i think it is a bit confused um or at least i got confused when I was reading it like maybe that's a maybe that's a me problem I don't know but like there's this one paragraph in particular which I highlighted in red because I don't like it where where should I you know with respect Shaw states and and I've I've been reading this and i'm struggling to find a point to start reading

a quote because it's like a lot of you know referring to previous things yeah yeah yeah as we as we have stated um but it's on page 20 and basically she says proponents of the former referring to uh i believe like mathematically tractable programs, general purpose programs. For example, value minimality of the language base for its mathematical properties, while proponents of the latter, referring to systems for vernacular programmers where you're not caring so much about the mathematical tractability of something. Well, for example, value richness of the constructs available as part of the language. Okay, so I have a huge disagreement there, because Shaw is stating that domain-specific languages are away or tend away from minimalism.

And they're better if they're more complicated and more rich, and they provide like a bigger breadth of options. But I don't think that's necessarily true. I don't really see a supporting statement here behind that. I think sometimes the best domain-specific tool is just the thing that does that one thing that someone wants to do.

Like that's the whole point of being domain specific it's honing in on less so i feel tangled up with some of these points i don't fully understand but i think that like the core message of mathematical tractability is less relevant to fuzzy real world systems that i agree with and i think that's in my head canon that's what i'm taking out i think all of this could be cleared up and i understand why it's not there all of this could be cleared up if we could just point at some of the people who are believing the myths right like i know that why it's not yeah but i'm just i i continue to be confused on who it is that's believing the myths and i would love

somebody who just like accepts these right like if we can find somebody who'd like just like we'll say you know a well-known researcher who'd be like these aren't myths these are facts right and and maybe that exists if we and we could just point at them and say that's the kind of person i'm thinking of then i i think this would all be clear because like when i read that section about minimality and language base and its mathematical properties versus richness of the constructs, richness of the constructs available as part of the language, I think Ruby. Ruby is a language that's all about the richness of the constructs. It is not a minimal language in any way, shape, or form. It is about piling in a lot of stuff, right?

And that stuff is useful. It's good. It lets you express things in lots of different ways. And then a minimal mathematical base, I maybe think of a Haskell, but minimal, kind of hard. But like the core of Haskell, right? Like the core of Haskell, or maybe like the core of haskell right like the core of haskell or maybe like the core of some scheme right like i these are the kinds of things that i think of as having this minimal base for its mathematical properties but then who are we talking about because those are

both language designers valuing different things like i i just i i wish we could just point to somebody because there's so much in here that I feel is right. So much in here that I think is the point of this paper. I do think we are overly obsessed with mathematics. I do think we don't pay attention to the vernacular programmer enough. We focus on mathematics to our peril where we stop actually solving real issues that people are having. That core of the myth is so true.

There's a reason we don't cover a lot of... I can't just open up any computer science journal and pick an article out of there, and we do it on the podcast. Yeah, or we'd be talking about catamorphisms of abstract data types, right? It would be really hard, although there is a paper on catamorphisms, so we totally could do. As an abstract art piece,'m 100 there uh yeah it's called uh functional programming with bananas lenses envelopes and barbed wire oh that sounds like scala uh i i knew i could at least get you

with this is uh eric meyer is the first author listed here and that goes through recursion schemes which catamorphism is uh yeah right yes yes so yeah yeah anyways but there's so many things that are just overly mathematicized that it becomes very hard for not just vernacular programmers to be involved but industry programmers to be involved and i think that that's a real valid critique it's just when we get into the weeds here, I know that there's a way, there's an interpretive lens to make sense of all of the things that are being said here. And if I try to take the right lens, I end up agreeing with them. But then I start questioning again, as if we've switched frames and taking different lenses here. And I think that's the problem with the volume of this paper.

It's so large and has so many different approaches that you get confused between which approach is being taken at a given moment. You know, this is a solvable problem. We could literally speak to Mary Shaw and ask her to name and shame, you know? Yeah. Richard D. James did it in the incommensurability album that was like that was good it was like brocca and cook versus whoever the lisper person one richard d james yeah affix twin yeah like you're trying to you're trying to get okay you're trying to confuse them with somebody else i didn't know that that was a person in Apex Twin.

Yeah, no, Peter Gabriel and Richard D. James, great computer science recording artists. Who also was the shepherd in this writing. That's what listed as the shepherd of this. Of this Shaw paper, what? Yeah, yeah, it's a very topical. Yes, yes, right. You're talking about Peter Gabriel. gabriel uh-huh yeah yeah

yeah so okay i think we should wrap up this this section here even though there's a lot more about correctness and specification i'm not sure that unless you really have some thrust that we can go to and not get lost in the weeds here this is a a long section. All right. Can I, I said my piece about specification. That's gone. But correctness. Yeah. This is a hundred percent robust first computing. And Dave Ackley is listening to this right now

and saying, no, it's not. But, okay. But this section is talking about correctness and kind of an over emphasis and over focus on correctness and correctness can mean multiple things it can mean like correctness of a specification completeness of a specification but it can also be about needing computers to be correct. And there's a section called good enough is often good enough. And it sort of maps out different kinds of computer program. On one end of the scale, the two dimensional scale, we have things like finding a restaurant, appointment scheduling, it doesn't matter so much if the computer gets those things wrong

but obviously it matters a bit but not as much as the other end which is things like nuclear safety devices self-driving cars medical implants and it's very important that those things are correct and sure highlights the point the good point that not everything needs to be 100 correct things can be slightly wrong they just need to be good enough because you know we're working in a in a world where there is this element of fuzziness you know computers like people like any other part of this big system we're in can be wrong in In robust first computing there's also this concept that computers up until now have been focusing too hard on correctness and also efficiency and that just doesn't reflect the fuzzy boundaries to our world and And yeah, I see that same point here, this incompatibility with

completely 100% of the time a computer being right is not compatible with the rest of the world. But what I don't see here in this chapter is this concept of robustness, because maybe because it's a very sort of specialist or niche area the thing is i care less about whether a medical implant in me is correct or not and that might sound weird all right but imagine this you have a medical implant inside you that's regulating your your body in some way i want to tell you that no computer is always correct. It's just not possible. No computer is always correct. They have bugs in them. They have other things that go wrong with them. Hardware failures, whatever. So let's just say that 99.999999% of the time, it's correct.

But what about that time it's wrong? And in robust first computing, the idea is that those times that you're wrong, you're not that wrong, right? For me, that's more important than maximizing correctness. For certain things, where safety is involved or security is involved, I'd much rather something is mostly correct than correct as much as possible. So I think Shaw is right to pull out this issue of hyper focus on correctness but i'm not sure what the sort of solution is or the replacement do we just need to get better at it for some things or how do we get better at it for some things and how how do we let go of these other things there's a um an interesting contrast between that robust first worldview where the emphasis is on not minimizing the likelihood of error, but making error states survivable, which kind of rhymes with neil armstrong's work on erlang and the view espoused by a lot of functional programmers where you want illegal states to be irrepresentable you want to make sure that

if the code compiles then it's going to run perfectly and that the latter view is sort of assuming that the environment in which the software is going to run is fully predictable and fully controllable. It's like, okay, if we know everything about the circumstances in which this program is going to be run, then we can make some hard guarantees about the way that the program is going to work at compile time. And they really lean into that in a way that I think is kind of cool but the robust first says well we don't know what the runtime environment is going to be like somebody might come along and cut my cpu in half if my cpu were built to be a robust first computer it would be able to survive

being physically cut in half and just carry on perhaps a little bit more slowly or perhaps you know needing a little bit of time to recover but it could you know carry on regardless that's not going to be a catastrophic failure condition whereas if i took some haskell program that's running on some chip and i cut the chip in half i don't think anybody in haskell land is worried about that happening the way that dave is worried about that happening so So I think this like example of like the T2 tile, which you're referring to, which can, you know, literally be cut in half and carry on working is an extreme example. And it's quite a fun example. So I think it's often what people think of when they think of robust first computing, because it's like, you know, it's on Dave's YouTube channel, and it looks very cool and

impressive. But really, robust-versus-computing is like a lot more boring than that. And I mean that like in a positive way. Like, don't worry, it's more boring than that. So for me personally, my legal name is different with different places. So like my doctor is one thing, my hospital is the other thing. So things go really badly when my doctor requests that i have an appointment at the hospital or vice versa so what happens is they're not used to people having two different names on two different systems which which i didn't want

to happen i tried to avoid it but what happens often is that the computer crashes because they've said that no our type system is correct it says that these two name values should be the same right and it was an oversight right they didn't think that people could have different names in these two different places but the way they decided to deal with that was not robust first they decided we're going to crash out because then we'll find the bug quickly and maybe we'll fix it well they haven't the robust first thing to do would be to handle that and to say like how are we going to recover from this error state that we're in so i think there's a kind of like a straw person with the robust first stuff that people think it's just about making a really

cool computer and it is you know that's part of like getting people to discover it just how local first is to other stuff but anyway like um so you know at the end of the day it's it's just kind of a mentality and a measure of software how robust first is your hospital booking form right are you gonna deal with these dodgy names and this is like a very common thing where names that are not expected make programs crash sometimes i can't put my name in because it's two characters long but anyway i'm not saying that like you know everything needs to be robust but it would be helpful to have it as one of these measures when we talk about correctness let's also talk about robustness because they're completely different things and and very compatible things too as somebody who has not read or watched any actly so uh i'll just say

thank you at least for kind of you know getting some context here i think this is definitely something we should cover yeah in the future you know probably you know next weekend uh uh even though i'm getting the gist of it probably the listener who's not familiar also might be a little lost on some of this because it's not something we've you know really explored here i will say just because i'm sure some people right now are screaming at the the podcast as you do uh that you got to remember when we're talking about correctness here we're talking about this myth of correctness this mythical version of correctness because if we talk about like maybe a more robust definition of correctness it would include all of the things that we're talking about with robust first software it would

include like how do we how do we remain correct in these strange circumstances blah blah i know robust first clearly has some other stuff going on with it than just that but i'm sure there's somebody saying you're just not understanding correctness criteria you can define all of those things we're talking about this this siren song of correctness as shaw puts it that this idea that we can be absolutely correct and not have to think about the purposes we just have to think about these mathematical properties right it's kind of a scarecrow version of correctness um correctness as it manifests as opposed to the ideals of correctness that we would like to yes uphold via robustness and via you know whatever other things harry lang yeah what have you so we we haven't rated this myth right well we're not done

this myth yeah there's there's a list there's a list oh no you're gonna read the list i'm gonna read the list you're so good at it so software correctness is intrinsically problematic because of many types of uncertainty i love i love this i knew it was gonna be this one yeah it's the big list and it's also it's the biggest one it's the biggest list but it's also the list that makes me happiest to think about um because for every one of these think about like what is the future of coding ask outsider perversion of what we know of as programming when you refract it through this warpy lens. Even if individual modules can be formally verified, they execute in an unverified software environment. Even if the compiler and operating system were correct, it's not practical to verify the rest of the software stack,

nor are the specifications of all the layers such that a given program's interaction with them can be formally verified. Simply identifying which versions of which software elements affect the behavior of a system can be challenging. Hence, the current interest in the software bill of materials, which we could actually do an episode on that at some point, and the software supply chain and that sort of thing. I think there's some super FOC relevance there. Understanding of software's requirements may co-evolve with software development, which precludes a firm fixed specification. That's, you know, waterfall is bad, right? Don't do that. Do the programming where you discover what it is that you're going to be building through building it. That's a perennial theme in this paper, and I think we're all fond of that.

Much software is now provided in the cloud. Current practice updates it continually and without notice. There's your local first thread. Software embedded in physical systems is subject to the uncertainties arising from the physical systems. Like your CPU could get cut in half. Yeah, that's like the flashy example, but I also love it because it's also a very common theme in science fiction, you know, that overlaps with programming and how we think about it. Solutions to societal problems are hard. These problems do not lend themselves to even forming consensus on the problem definitions, let alone definitions of success. They're called

wicked problems. That one, right? Perennial theme of the show, the legalism rule of code episode, all about that. The whole idea that, you know, programmers keep trying to solve social problems with technical solutions. And finally, acquiring specifications has cost. So it makes the most sense to get the specifications relevant to the task rather than trying to be complete. I love this list. I think this is a great list it's full of provocative challenges to the worldview that you can like define here's what the correct software will do open shot easy straightforward example that programmers can do on their own in advance of going and writing some some code of course shaw then goes on to say yeah the thing we want is not a correctness specification.

We just want some criteria for fitness for purpose, whether the software is good enough. And that depends on things like the consequences of something going wrong and the likelihood that a problem will be detected and corrected before anything goes seriously wrong. Closes the loop on all the stuff that we have said in this section so far. No notes. I agree with you. i agree with you i agree with you oh are we gonna blow right past to the we'll leave this as an exercise for the for the reader who wants to go and read this paper there's actually a lot of good stuff in this paper even though we're kind called SynthWell. It's a program that generates generative music. And it's a really nice example where Richard splits themselves into

two people and the two people have to collaborate on this problem. It's very nice. Yeah, I got very confused by that by that you know especially because who is that the the person in the previous example that there was a stick figure frida yeah frida yeah the real person i was really looking forward to a uh you know richard and dick are both real people and it's the same person you know yeah this was very metaphorical, this section. Well, you have to know that Richard P. Gabriel, there, I said their stage name, is actually a real person and I believe a friend of Mary Shaw. And also wrote some papers that we have previously covered on this show. So, like, this P stands for Peter. Peter Gabriel is like a hero of our program.

Yeah. So, I knew that. p stands for peter peter gabriel is like a it's like a hero of our of our program yeah so so i knew that however i didn't know if like uh you know it's like jacqueline hyde where richard p gabriel transforms every night you know into into dick but um no it was an enjoyable section highly recommend yeah recommend reading the paper just for that section um oh i have so much green in this section. Oh, and then we get to skip the following section because it's the one about the fall of Icarus. So we're going to just ignore that.

We'll have no discussion of waxed wings on this program. And that brings us to the conclusion. Which is the best part of this paper? Yeah, the conclusion whips. Honestly, this was the thing where I got to this section and I started going back and being like, wait, that's what that section was saying. I think this could have been at the beginning.

Yes, should have been at the beginning. Yeah, we had a summary at the beginning and I think had it been this summary it might have helped every section along and it might have helped focus it i think that that this this paper could have used some editing and in my opinion on to focus in on some of these arguments and just make them a little sharper because there's so much packed in here, you get lost in the weeds. And I think that's kind of what we did. We got a little lost in the weeds.

But this brings us back to breaking down each of these myths and the way in which the myth distracts us. And I love this phrasing, that the myth distracts us from doing certain things. I will not try to read them because I know I will fail at reading them. But we get each of these myths in turn. And the one that I particularly liked, though, is this idea of the professional programmer. Why was this professional programmer myth brought up? I will read this one, I guess.

The myth distracts programming language designers from opportunities to improve software overall by bringing programming language design expertise to the notations and development processes that support the needs of vernacular programmers. I think that this professional programmer myth here, I will, once we, a little bit of spoilers, once we get to my list of myths, I want to twist this one. But I think this is really important. I do think that we are not using the tools that we have as programming language designers, which I just count people in the future of coding community, whether you're doing that or not, I bet you you are, in some small part,

being a programming language designer. Or you're thinking about it. Right. I think even the APIs we build, the software we build, oftentimes we're building these kind of implicit languages in part of it. I think there are ways we can build that expertise and broaden it.

I think that it is a very generably applicable tool that can be used, whether that's in visual programming systems, whether that's in constraint systems, whether that's in whatever, right? Even more traditional systems. I think these are things that are just not more widely used. And I love this phrasing of the myth distracts us. I think this is a key

that i wish the paper focused on in a little tighter fashion there's a um a wonderful list and i'm not going to read this whole list i'm going to say we're all going to take turns reading bullets from this list oh nice which is the the list of suggestions that Mary has for things that we could do when background and mindset of our intended users, hide the complexity and higher mathematics, for example, with domain-specific abstractions. The advent of low-code environments suggests a niche in software development that presents an opportunity for providing better languages to a wide audience. Support exploratory programming that seeks understanding as well as programming to satisfy specifications.

Bring the power of programming language design to scripting, markup, graphical, mashup, and other domain-specific languages and tools. Bow, bow, bow, bow, bow, air horns. Whoa, yes, this one. Very good. Okay, but what does, like, bring the power? It's kind of fun, but also, like, that's, that's, what does that mean?

What makes you go air horns? Expressive power. Like, a lot of, you know, no-code, low-code tools are, like, extremely limited in what you can do with them. And general-purpose programming languages are extremely unlimited. And I think that there is a beautiful

fusion that you could have between those two things. I interpret this a little bit differently because they also say domain-specific languages, which are not supposed to have the expressive power. So... I disagree with that framing. I know that that's probably the definition, but I think it's a bad definition.

Okay. Well, I'll just say another interpretation. Cause I also liked this. I think there's another way of interpreting it that I think is positive, which is that oftentimes these tools have these very ill defined edges to them. Right. I think of a lot of these commercial tools where you can do that except for it's kind of hacky and kind of bad

and there's these weird, why does it work that way? Well, because we released seven different versions and we never fixed the crunchy edges of this. To me, the power of programming language design is that we've figured out over a lot of years how to have a cohesive design right we learned from the mistake of javascript how to do some scope and stuff like that we learned from the mistake of python how to do packages we've learned how to from the mistake

of pearl how to not make every random paint splot a valid program. We've learned how to fix some of these issues. And so I think that to me is like, a lot of these tools haven't learned these lessons. And I continue to repeat these problems that past programming languages had because we haven't applied some of the latest research and ideas here. That's what I took out of this.

100%, completely agree. And just to sneak it in here my definition of domain specific language is basically like a language where the kind of expression that it encourages you to do matches the kind of domain problem that you're trying to solve and bonus where it has like a good ass standard library for the kind of thing you're doing so if i'm doing like computer graphics for a video game, and I want to do some like generative graphics for the game, I don't want to have to go write that in C++ or maybe Lua. I want like a domain specific language that's good for generative graphics within the, you know, polygon tool set or whatever

it is that I'm using. It doesn't have to be limited expressive power or limited capability it just has to be like no this is an environment that is like focused on a domain other than the creation of software that's my personal definition of domain specific language would elm meet your criteria yes not not in the ultimate way yes that you want yes like elm would be a dome yes domainspecific language in your thing because it's focused on web apps. Interactive websites, yes, exactly. Elm is a domain-specific language for making interactive web apps.

Even though Elm is also a general-purpose language in its general expressive capability. Java is a domain-specific language for creating massive employment in IT. So the next example is, Enrich type systems to elevate noisy or probabilistic data to first-class status in the language and to capture provenance of data from different sources. Make provisions for contingent results that may change after the next time a machine learning model is

retrained. Support contracts about behavior of data as part of the type system. We didn't get into that part of the paper, but there's a part where Shaw explores this. But I love all these ideas. I love this idea of like, enrich the nature of data that can be talked about in your type system like that that probabilistic data in the type system like i need that uh for what i am working on right now at ink and switch like that would be very helpful to have is you know if typescript could let me talk a little more expressively about probabilistic data that would be awesome yeah providence i think is one that i have really wanted. I worked on a medical recommendation system where we did a bunch of rules

and stuff and made recommendations on prescription renewals or whatever. And one of the things we had to do in this kind of ad hoc manner is track provenance. Because we needed to know, why did this recommendation happen? What rule made it so that we get this result, and why didn't this one fire, and et cetera? And that was one of the most complicated parts of the system, and you could easily get it wrong. And having something that

can track these things, not just for security things, but also for understanding my program and which systems talk to what, I think, fantastic. Love that idea. Last one, Lou. I gave this one two ticks, actually. So this is a good one.

Explore ways to determine how good, by whatever measure, software needs to be for a given application, as well as how good a piece of software actually is, so that it's possible to evaluate good enough in context. And this good enough thing came from the correctness section. It's saying, how correct does this particular piece of software need to be? Or like, how consistently correct does it need to be? I love this idea. I am at a loss for what this means.

And that might be the best. To me, that actually is like the best thought right like i love the idea of exploring different ways of determining how it's quote unquote good by whatever measure right i love that because i think this is something that we ignore we tend to act as if we have a defined notion of good and everyone else agrees with our notion of good and that's what determines it and we never explore these sorts of things so i and maybe i quibble with uh measure but like it's by whatever measure uh like it's not really about measuring and assigning a number right it's like by whatever means um Yeah. So I love this. Yeah. I have no idea how you go about

this, but I love it. I mean, I've definitely like been in design conversations or seen conversations or seen rationales out there where there's too much of an emphasis on trying to get that 100% solution. Oh my God. I'm not fricking referencing jonathan blow am i no yeah we never do that here that's forbidden not under my name not on my name he's the witness is not going to be in the show notes this episode i blocked him on twitter man anyway yeah no no but there's the what am i saying sometimes you just need a 90 solution sometimes a slow program is better than no program sometimes a program that crashes if you do things to it the wrong way is fine sometimes a program where you have to run it a couple of times before it has

its effect is fine sometimes a program that doesn't do the thing you need it to do in terms of like the effect it has on the world is okay if it does something else that is like valuable like shows you oh this was not the right approach to solving the problem right like the evaluation of the program can happen in so many different ways if you make it context-aware. And it's only when you try and divorce evaluation from context that things go wrong. See also previous discussion about assessment in education, which government instituted, every child in the country gets a numerical score that determines their future. That is so divorced of context that it's awful. So I want to read these next two sentences right after this list,

because I think it kind of resolves the conflict that I was having with this mathematical tractability. And I think it really just puts in a way that I think I just wholeheartedly agree with. I don't think I could quibble with this kind of conclusion here. This is like Shaw's conclusion of what needs to be done now. Above all, the programming language research community should make these improvements in a way that exploits the power of the formalism while still supporting the background, mindset, and workflow of the intended beneficiaries of these improvements. Capabilities grounded in formal mathematics have great power, say, mythos,

but making them effective, say, pragmos, requires packaging them and presenting them in a way that provide the power without the obligations for users to master the formalism. I think that's spot on. I think that is fantastic. I think this is the power of programming language. You take something that was a specific problem that someone had to understand all of the details of, and you solve it in this general way without them having to know all of this. Think memory management and garbage collection. This is something where there's so many complicated properties that have to hold for garbage collection to happen. You have to really think about all of these details, but as a programmer, you don't need to know all of those details. And even the things you might need to know, like, oh, I allocate and i'm allocating too much and like the older gen like some things you end up learning it's still not all the details you look at how the

jvm does garbage collection and how it does thread safety and all of that there's so much that goes into this and i i do think this is the power of a language-based solution in the broader sense of language-based where this is the the medium in which we write rather than specific solutions to specific problems trying to tackle this broad generality and paying attention to that audience and not making them learn all of those details i love this i think this was this is the thrust of this article that I am just 100% behind. So maybe I am FOC-pilled, despite all my quibbles. I agree. I think the thing I like about that statement and this conclusion is that it's clear that Shaw is trying to bring out the best

of both kinds of programming world out there. I have a lot of respect for her trying to be a bridge between two things which sometimes seem quite separate, like in that section where vernacular programming and professional programming were compared. There's a lot of difference with strengths and weaknesses, and she makes the case for combining them together. There's another section of this conclusion that I really like. The programming language myths arise, I think, from a deep-rooted need for certainty. Indeed, it is possible to find certainty within a formal system. The world, however, is uncertain, messy, non-deterministic, robust first, ambiguous, human, it does not lend itself to the precision

required for formal definitions, non-binary, and that prevents the certainties within our formal systems from being translated with confidence to the world. We should certainly continue to aspire to precision and completeness, but we should also provide support for practical software that runs in a context of inherent uncertainty. And that is robustness. That's robustness. I think now is the time, unless Ivan has something in this conclusion. No. All right. No, nothing to add.

Now is the time where we have to list our myths. Yeah, sure. Our replacement lists. I haven't thought of any myths. Well, you have 30 seconds. I'm only capable of speaking the truth okay okay well then then this is your let me tell you how to do this myth i am only capable of speaking lies oh dear oh no you just have to like flip your myth ivan say this is not true and then speak the truth you know what i mean i'm very bad at doing

that i only understand things correctly and and uh yes anyways maybe maybe after the two of you do yours i'll have thought of something okay here's my first myth okay long papers are good I may have written this immediately after reading this paper like three times so there may be some emotions caught up and tangled up there but and I say this directed to the ink and switch employee on the zoom call

called out long papers are fine but i think we've in this specific paper we i think we would have all appreciated yeah like a bit of editing it sounds so anal to say right you know like i really love this paper but i i love it so much that i want those key points to shine even more you know yeah i think some of these things could have been appendices sorry did you say appendices appendices appendices but this isn't it pembis isn't that the like the gender neutral pembis was that what it was wait yes a pimp a pimple pibbling pibbling there was pibbling but wasn't there pimbus wasn't wait

no not mumps listen no you can cut that cut that part out but long papers are not not good not always good myth two, making a programming language is something only an elite few can do. I like that myth. I think making programming languages is something that, for some reason, is seen to be this insanely difficult thing. I would say that it is difficult, but it's only as difficult as most other programming tasks. Completely agree. I don't know if it's the Dragon Book or something. It's got this weird status.

And myth number three, the tech world isn't completely morally bankrupt. Wow. That came out of left field there getting them all in on the first episode lou this is great it just needs repeating you know yeah it's repeating uh moving on yeah yep i'm sure that won't be a perennial theme yeah i think that would we need to find some good stuff on that for sure. Yeah. I don't know of any good papers on the moral bankruptcy.

Oh, don't worry. We'll get there when we get to my myths. Oh, boy. You have myths now? I have myths now. And those were your three, right? You had three myths? Yeah, I had three myths.

Okay, okay. I have one myth, which is vernacular programmers and professional programmers are significantly different from each other. That's my myth. Hmm. Okay. Hmm. You think they have more in common than what keeps them apart? Recast this whole paper and just talk about both professional and vernacular programmers and the needs that we all have collectively,

all kinds of programmers. It works just as well. I think that this division between professional and vernacular programmers needing different things is what has made this problem where vernacular programmers are given all these proprietary things and they don't have the general power and etc but it's also made the problem where professional programmers get like

ultra nerdy tools or not well designed and not paying attention to the graphical design the visual design of things like i think all of these this division is to me a myth i don't think that we're actually that different and i think that focusing on the needs of one versus the other is causing some of this problem myth busted i like that i've actually just added that to my list too so i can't steal his list this is just four items it is well it is wait what it's lose three in my one yeah yeah yeah was that your full list jimmy you have one more don't you no no it's just one that was it uh-huh okay well mine yeah these are gonna sound familiar my first one oh my god i think lou said this my first one is that papers are good papers are good papers are good right that's kind of what you said lou except you added some extra words in there that aren't necessary i did yeah i said long yeah exactly um

it's true yeah i i don't actually like papers as a medium yeah i agree we should have more books no no well so i actually had papers are good and i put underneath that considering saying it instead reading is good somebody who shall remain nameless in our slack was saying that they read 300 books a year and like 50 papers a week or something like that jack russia say the name three times and they'll appear on the show again. Jack Rusher. Jack Rusher. Jack Rusher.

Who dares speak my name? Oh, Lou. Wow. Nice to see you and Ivan and Jimmy. Ah, looks like you're recording a podcast well you know I've got no time to stay in chat I have to get back to my reading I had a wonderful conversation uh very short conversation with Jack on on our train ride train jam where he was like what have you been reading? And I'm like, I don't read fiction. And I made the mistake of putting the word fiction in that sentence.

Yeah, I think that there are so many other ways that we can be communicating these subtle, nuanced, delicate, beautiful ideas to each other. And I'm very interested in exploring all the ones that don't involve reading. Stay tuned. Hopefully, if I have my druthers, I won't have my name on another Ink and Switch essay. That is another also one of those like perennial themes of the show. I think we've made this public, but I'm very interested in finding works that we can do that aren't papers. And I would love to look for some non-paper things for us to talk about. So my uh one that i'm stealing is i want to denormalize sharing scrappy fiddles so yeah so so uh so uh what was normalized sharing scrappy fiddles that's the myth um oh yeah and the thing i want to say there's no context for that for the

listeners they're gonna go what is that what is that so everybody who's listening to this should follow lou on mastodon um because lou has been recently doing this tremendous work where they say normalize sharing scrappy fiddles and then accompany that with a post of some thing that is a scrappy fiddle meeting a song or a little video demonstrating something some kind of work that is like rough and unpolished and unfinished and and the sort of thing that you'd normally be timid about sharing because you know oh it's just a little throwaway thing that's not worth sharing and lou if i'm not mischaracterizing you you've been saying no share those things it is good to share them yes it's morally wrong not to share them and i'm going to come in and say that it is uh it is harmful to

share them because and i think this you know i'm being a little bit glib here um i think it is actually good to share these kind of things and i struggle a lot with sharing scrappy fiddles because i care too much about the attention economy and how limited everybody's attention spans are and how we should you know save our the attention that we generate for the things where it really matters and that we should only be putting things out into the world that are very deeply considered i say on a rambly digressiveressive podcast. So that's myth number two. Can I counter your myth? One sentence? Yeah, you can counter my myth. Yes, please.

I think it's more about being anti-gatekeeping. And sharing doesn't have to be online. It could be with someone who you're sitting next to, or that you live with with it doesn't need to be taking someone's attention away i think in music making and in the world of programming there are a lot of elite clubs and people try to dissuade uh you know newbies so i guess my myth about like only an elite few can do programming language work i don't think that's true and know, when you post up some little bit of music you make online, sometimes you get some slightly negative feedback, which can be slightly shocking for newbies. And, but you know, that's, that's the whole point of the normalized sharing scrappy fiddles movement is to try to, uh, I guess, bring these things to the forefront and have a bit of

fun with it. Yeah. I think if nothing else else if it helps people learn how to give good positive feedback that's a that's a great value that we can do it's like hey you sometimes don't need to tell other people what they should be doing differently if they're sharing a little precious idea out there you don't need to say your idea was not done properly here's the proper way to do ideas um do you have another myth i have two more i'll keep them quick the third one is uh that programming is a job and the fourth one is uh so i can deal uh by that i mean that like yeah you you're down with that jimmy yeah i'm done with that um i think uh that like programming is a thing i was tempted to say or that like programming is a thing that people do um that's the myth that one i'm less i'm not so sure about that one yeah

uh so the the thought would be that programming like if if programmers were good at their job then they would make programming go away like it would no longer exist uh because we'd all just turn ourselves into vernacular programmers the fact that there are people out there who are like no i like programming for programming sake those people are bad and we should not be listening to their podcasts so very pointed do you know any of those yeah yeah very pointed accusation there yeah yes and the fourth one is that um i never do this kind of stuff that's the fourth myth what follow lou on uh mastodon it's uh they are at toad pond follow them on youtube at toad pond follow jimmy on mastodon uh j H. Miller. Follow Jimmy on Twitter, because Jimmy's still on Twitter for some reason.

I haven't posted on either for a very long time, so I need to think of what I want to do with social media. Follow me on Mastodon, at SpiralGanglian, or go to my website, Ivanish.ca. Back us on Patreon, because we've got a lot of mouths to feed on this show now um please my loo their microphone it's so it's fine it's so it's so fine um it's fine okay the light in their room actually no actually the light is broken i'm glad you noticed yeah yeah yes i

didn't notice but oh well it's broken you were complaining about it yeah it's really dark in here yeah yes uh support us on on patreon uh to get to get the bonus content that you crave if you're the one person who we recorded liminal programming for back us on on patreon and uh and then find out if you are in fact that person there i did the thing that i don't do and then uh i guess we should end it the way that the paper ends things which is our myths should inspire us but they should not hold us captive okay but i actually don't know what that means like like uh i guess i guess maybe it's because i'm not held captive by these things perhaps yeah i think you're held captive by the myths that you don't recognize as being myths that's the trick oh my god if mary shaw has done

her job somebody out there didn't realize they were held captive by one of these myths and now knowing that it's a myth they're freed so really that's the lists that we should have come up with or like what are the what are the things you don't even realize are myths reminds me of gary bernhardt's ideology talk that's a good talk which is about very much the same sort of topic i like that at the end he says closure is good because i like closure and i like that at the end of that talk, he's like, yeah, closure is good. But yeah, the idea here is that like myths aren't bad inherently. It's just when we don't realize that they are myths and everyone froze for me. Oh,

cool. Cause my hotel internet probably cut out. Oh, and you froze for me. Yeah. You just froze for me, but we got the the final word yeah there you are perfect timing he's back are we back you're back hello hello

hello yep you all froze for me one two two perfect uh i'm gonna hit stop uh you should both hit stop to save me from one two three