07/26/2019

Ivan Reese guest hosts.

I’ve been intimidated by Jack Rusher from the first blush. I mean, he’s wearing a high-collared fur coat and black sunglasses in his Twitter pic, and his bio includes “Bell Labs Researcher”. So when tasked with choosing a subject for my first interview, I immediately reached out to him, leaning in to my nervousness. His reply included the detail that he’s “generally hostile to the form” of podcasting. Terrifying.

When we talked, it was about Lisp — several flavours of Scheme and Racket, Common Lisp, Lisp machines, Black, Clojure, parens of all stripes. It was also about aesthetics, and graphic design, the relative ignorance of typical programming tools to the capability of the visual cortex, and how to better tap it. This podcast’s streak of discussions about Coq, miniKanren, TLA+, and Alloy continues, with the addition of QuickCheck and the like. Jack presents his work on a literate editor for Clojure called Maria.cloud, an environment that makes a number of unusual and interesting choices both in the design and implementation, reaching for an ideal blend of features that afford both instant beginner enthusiasm and unrestricted expert use. We pay our respects to the phenomenal red carpet that video games roll out to new players, inviting them in to the model and mechanics of the game with an apparent ease and apt ability that should be the envy of programming toolsmiths like us. The show ends with Jack sharing an excellent collection of plugs, ranging from academic papers by the relatively obscure Stéphane Conversy, to the aesthetically-lush programming tools pouring out of Hundredrabbits’s Devine Lu Linvega.

I am no longer terrified of Jack’s persona. Rather, I am now humbled by his towering expertise and the wildly varied accomplishments of his career, and it was a thrill to get to tour them in this interview. Best quote of the show: “A kind of grotesque capitulation to sameness.” Damn, Jack!

Jack Rusher is our esteemed guest. He is on Twitter, Instagram, and SoundCloud. Applied Science is his consultancy, and Maria.cloud is their beautifully designed literate Clojure editor.

Ivan Reese hosts. He’s on Twitter, works on educational media, is making a visual programming tool, and plays 100 instruments — badly. He started life with HyperCard and now loves Max/MSP.

Repl.it is our Sponsor. Email jobs@repl.it if you’d like to work on the future of coding.

Complex Event Processing is a bit of technology Jack helped commercialize.

ClojureVerse is where a discussion of Luna led to the Visual Programming Codex, based on the History of Lisp Parens by Shaun Lebron.

QuickCheck, miniKanren, Datalog, Black Scheme, and Oleg Kiselyov are touched on. Out of the Tar Pit has its mandatory mention, and then Chez Scheme saves the day.

Maru is a Project by Ian Piumarta. Maru is a symbolic expression evaluator that can compile its own implementation language. Maru is no longer maintained. Atilla Lendvai made an attempt to get the project rolling, but stopped as well.

Scheme Bricks and Media Molecule’s Dreams are interesting touchstones on the road to future visual programming languages. Ivan has an affinity for Pure Data and Max/MSP and vvvv.

When talking about tools for beginners versus experts, Rich Hickey’s Design, Composition, and Performance is invoked — and poor Shostakovich.

Jack’s main is Maria.cloud, named in honour of Maria Montessori. SICP gets a nod. Maria has proven useful at Clojure Bridge. Matt Hubert [Twitter] created the Cells abstraction that Maria was eventually built atop — it’s similar to ObservableHQ.

Video games like Steel Battalion, The Witness, and Dead Space have strong opinions about how much, or how little, visual interface to expose to the player. Complex 3D tools like Maya and 3D Studio Max are GUI inspirations for Ivan, where Jack and Matt prefer simplicity, so much so that Matt wrote When I Sit Down At My Editor, I Feel Relaxed. Dave Liepmann is the third leg of the stool in Applied Science, Jack’s consultancy.

Maria originally had a deployment feature like Glitch. There’s a great talk about Maria by the Applied Science trio, containing a mini-talk called Maria for experts by Jack.

Pharo is an inspiring modern Smalltalk.

Fructure is a wildly cool new structured editor, and its designer Andrew Blinn is fantastic on Twitter.

Extempore and Temporal Recursion by Andrew Sorensen offer some interesting foundations for future visual programming tools.

Sonic Pi and Overtone are lovely audio tools by Sam Aaron, widely praised and deservedly so, and everyone should back Sam’s Patreon.

A visual perception account of programming languages: finding the natural science in the art and Unifying Textual and Visual: A Theoretical Account of the Visual Perception of Programming Languages are obscure but beautiful papers by Stéphane Conversy.

Aesthetic Programming is one of Ivan’s favourites, and the author Paul Fishwick just so happened to teach Jack’s graphics programming class at Uni.

Orca is a mind-bending textual-visual-musical hybrid programming tool by Hundredrabbits, who are Devine Lu Linvega and Rekka Bell. Notwithstanding that they live on a sailboat(!), they do an amazing job of presenting their work and everyone in our community should take stock of how they accomplish that.

Ableton Push and Ableton Live are practically state-issued music tools in Berlin. (Not to mention — Ivan edited this podcast in Live, natch.)

thi.ng and @thi.ng/umbrella are Jurassic-scale libraries by Karsten Schmidt, who wrote blog posts about Clojure’s Reducers in TypeScript.

Finally, Nextjournal are doing great work with their multi-lingual online scientific notebook environment.

Transcript sponsored by repl.it

Corrections to this transcript are much appreciated!

Steve: Hello and welcome to the Future of Coding. This is Steve Krouse. Today in this episode, we are going to switch things up a bit. I was at dinner with Aidan Cunniffe and Dev Doshi a couple of months ago, and they had this wacky suggestion that I bring on a guest interviewer to take some of this podcast work off my plate, and at the same time scale it up so that there could be more conversations from different perspectives showcased on this same RSS podcast feed. I thought it was a great idea. One person immediately came to mind who would be a wonderful guest interviewer. Hello and welcome to the Future of Coding. This is Steve Krouse. Today in this episode, we are going to switch things up a bit. I was at dinner with Aidan Cunniffe and Dev Doshi a couple of months ago, and they had this wacky suggestion that I bring on a guest interviewer to take some of this podcast work off my plate, and at the same time scale it up so that there could be more conversations from different perspectives showcased on this same RSS podcast feed. I thought it was a great idea. One person immediately came to mind who would be a wonderful guest interviewer.

Steve: Ivan Reese has been a listener of this podcast and part of the Future of Coding community I think since the beginning, at least that's how it feels to me. I can't remember how we originally got connected, but it's always felt like he's been there as a staunch supporter of these efforts. He's always been a really positive and encouraging voice and someone that I can always count on for sharp feedback and a thoughtful perspective.

Steve: I have somehow come to really trust his taste on things. It's kind of a subtle thing I can't put my figure on, but I find that his aesthetic is very similar to my own, which makes him a perfect person to be a guest interviewer on this podcast. I have somehow come to really trust his taste on things. It's kind of a subtle thing I can't put my figure on, but I find that his aesthetic is very similar to my own, which makes him a perfect person to be a guest interviewer on this podcast.

Steve: You actually have heard from Ivan before, you just didn't realize it. If you've enjoyed the increased audio quality in the past couple of episodes of the podcast, you have Ivan to thank. He's been in the background helping me with choosing the right microphone and getting it set up correctly. Sometimes when I set it up incorrectly, he'll help me salvage the audio quality and get the best sound that's possible given how I screwed things up. It's been a real labor of love on his part. Thanks, Ivan, for that. So without any further ado, Ivan Reese: You actually have heard from Ivan before, you just didn't realize it. If you've enjoyed the increased audio quality in the past couple of episodes of the podcast, you have Ivan to thank. He's been in the background helping me with choosing the right microphone and getting it set up correctly. Sometimes when I set it up incorrectly, he'll help me salvage the audio quality and get the best sound that's possible given how I screwed things up. It's been a real labor of love on his part. Thanks, Ivan, for that. So without any further ado, Ivan Reese:

Ivan: It's going to be really tough to live up to that glowing introduction that Steve gave me, but I will do my best. My name is It's going to be really tough to live up to that glowing introduction that Steve gave me, but I will do my best. My name is Ivan Reese and I'm really excited to be on the podcast interviewing Jack Rusher . Before we get to the interview, I will give you a whistle-stop tour of my programming career just so you know what sort of perspective I'll be bringing to the interview.

Ivan: When I was about five years old, I started making silly interactive animations and games in When I was about five years old, I started making silly interactive animations and games in HyperCard to annoy my sister, and I've been making silly interactive animations and games ever since.

Ivan: I work for insufferably about it. I work for a little education media company . I was hired originally as a 3D animator there, though my role quickly expanded to include programming. I now make all of the frameworks and tools for the other artist-programmers in the company. My current project is a visual programming language for building interactive animations. If you follow me on Twitter , you know that I tweetabout it.

Ivan: Outside of programming, my main hobby is music. A curious tidbit: I have a collection of over 100 different instruments all of which I Outside of programming, my main hobby is music. A curious tidbit: I have a collection of over 100 different instruments all of which I play very badly . Having a hobby as a musician and being a programmer means that I've had a lot of fun exploring the intersection of those two things. Max/MSP was probably my introduction to visual programming and I still have a very soft spot in my heart for it.

Ivan: So enough about me. Let me introduce So enough about me. Let me introduce Jack Rusher , our guest on the show today. Jack is a programmer living in Berlin that I know via the Clojure community, though his interests in Lisp go way beyond that.

Ivan: Jack has a fascinating history of projects that we talk about. Then we head fearlessly off into the weeds talking about logic programming, model checking, towers of abstractions, the history and future of visual programming languages, the aesthetics of programming tools, the principles of visual design that underlie all of our programming tools (whether we realize it or not), his consultancy in Berlin called Jack has a fascinating history of projects that we talk about. Then we head fearlessly off into the weeds talking about logic programming, model checking, towers of abstractions, the history and future of visual programming languages, the aesthetics of programming tools, the principles of visual design that underlie all of our programming tools (whether we realize it or not), his consultancy in Berlin called Applied Science , and the programming environment that they built — a literate editor for teaching Clojure to new programmers called Maria

Ivan: Just before we get into the interview, I have a message to bring you from our sponsor, Just before we get into the interview, I have a message to bring you from our sponsor, Repl.it . They sponsor the transcript of the show which you can find at https://futureofcoding.org/episode/041

Ivan: Repl.it is an online REPL for over 30 different languages. It started out as a code playground but now scales up to a full development environment where you can do everything from deploying web servers to training ML models, all driven by the REPL. They are a small startup in San Francisco but they reach millions of programmers, students, and teachers. They're looking for hackers interested in the future of coding and making software tools more accessible and enjoyable. Email jobs@repl.it if you're interested in learning more.

Ivan: Hi Jack. I'm interested in your background as a programmer, especially in your Twitter bio. You kind of teased that you had a past life as a kernel hacker at Bell Labs. Hi Jack. I'm interested in your background as a programmer, especially in your Twitter bio. You kind of teased that you had a past life as a kernel hacker at Bell Labs.

Jack: Those are actually two separate entries. When I got started with programming... Well, I started programming in the '70s on little microcomputers, 8-bit microcomputers. When I went to university, I immediately was launched in the world of VMS and Unix, specifically BSD Unix running on ridiculous refrigerator sized machines like a Gould PowerNode 9000, which is a museum piece these days, as are all the machines I was using then. Those are actually two separate entries. When I got started with programming... Well, I started programming in the '70s on little microcomputers, 8-bit microcomputers. When I went to university, I immediately was launched in the world of VMS and Unix, specifically BSD Unix running on ridiculous refrigerator sized machines like a Gould PowerNode 9000, which is a museum piece these days, as are all the machines I was using then.

Ivan: What did that entail? What did that entail?

Jack: Well, in the beginning, the problem was that the software we were running our machines with was not particularly reliable, so we had to fix it. A great many Unix users in the mid-80s were also fixing not only userland utilities but kernel things. I went a little deeper than most, and did a lot of work particularly in file systems, virtual memory, and the scheduler in several different flavors of Unix, especially BSD variants. Ultimately in my professional life, I wrote a few different very small Unix-like operating systems that were used in embedded systems. Well, in the beginning, the problem was that the software we were running our machines with was not particularly reliable, so we had to fix it. A great many Unix users in the mid-80s were also fixing not only userland utilities but kernel things. I went a little deeper than most, and did a lot of work particularly in file systems, virtual memory, and the scheduler in several different flavors of Unix, especially BSD variants. Ultimately in my professional life, I wrote a few different very small Unix-like operating systems that were used in embedded systems.

Ivan: That's such a far cry from the programming experience that I think most people have today, where they're working on top of such a gigantic stack of abstractions that actually going down to that level is something that people do more like a spelunking expedition, rather than something that's necessary to keep the wheels turning. That's such a far cry from the programming experience that I think most people have today, where they're working on top of such a gigantic stack of abstractions that actually going down to that level is something that people do more like a spelunking expedition, rather than something that's necessary to keep the wheels turning.

Jack: Mostly hobbyists for fun these days, yeah. My GitHub even has a tiny bootloader for starting your own operating system project on x86 compatible machines that I used in a class that I taught around 2010 in New York. Mostly hobbyists for fun these days, yeah. My GitHub even has a tiny bootloader for starting your own operating system project on x86 compatible machines that I used in a class that I taught around 2010 in New York.

Ivan: Yeah, so in some sense, you're still kind of doing that to this day. Yeah, so in some sense, you're still kind of doing that to this day.

Jack: Yeah, although my professional work at the moment is at the absolutely opposite end of the tower of abstractions. Yeah, although my professional work at the moment is at the absolutely opposite end of the tower of abstractions.

Ivan: Yeah. I'm hoping we'll get into that a little bit as the conversation goes on. So that's the kernel hacking part — what's the Bell Labs part? Yeah. I'm hoping we'll get into that a little bit as the conversation goes on. So that's the kernel hacking part — what's the Bell Labs part?

Jack: For a while I was at the Labs, and our team was working on a thing that was a... The technology is called streaming databases and is sort of taking the conventional idea of a database, which is that you have a big pile of data that already exists and you ask questions about it in the form of queries and it delivers you answers based on that preexisting data... In the streaming database context, you do not yet have the data, but you do know what your question will be. You make a query in advance, and then as the data comes in, you're given something like a materialized view, or perhaps a trigger on some sort of alert or whatever, based on your query. For a while I was at the Labs, and our team was working on a thing that was a... The technology is called streaming databases and is sort of taking the conventional idea of a database, which is that you have a big pile of data that already exists and you ask questions about it in the form of queries and it delivers you answers based on that preexisting data... In the streaming database context, you do not yet have the data, but you do know what your question will be. You make a query in advance, and then as the data comes in, you're given something like a materialized view, or perhaps a trigger on some sort of alert or whatever, based on your query.

Jack: In our use case, because it was AT&T, it had to do with data networking. We built a system for monitoring data traffic at a very, very large scale — because, AT&T — that would run on commodity hardware and would respond to SQL-like queries. The trick here was that we used our own modified NetBSD kernel for these machines. Then we wrote some code that would take these queries and do a complexity analysis, and take the least complicated parts and compile those into a firmware update that we would hot-flash onto the network card so that it could do a lot of the upfront processing; and then a kernel module that would do some things in kernel; and then a userspace portion that could often be scripted in Perl — because by that time there wasn't that much data left, because we had already pruned it in these faster layers further down the hardware stack. In our use case, because it was AT&T, it had to do with data networking. We built a system for monitoring data traffic at a very, very large scale — because, AT&T — that would run on commodity hardware and would respond to SQL-like queries. The trick here was that we used our own modified NetBSD kernel for these machines. Then we wrote some code that would take these queries and do a complexity analysis, and take the least complicated parts and compile those into a firmware update that we would hot-flash onto the network card so that it could do a lot of the upfront processing; and then a kernel module that would do some things in kernel; and then a userspace portion that could often be scripted in Perl — because by that time there wasn't that much data left, because we had already pruned it in these faster layers further down the hardware stack.

Ivan: What era about were you working on that? What era about were you working on that?

Jack: That would be not quite 20 years ago. That would be not quite 20 years ago.

Ivan: Oh, okay. Well in advance of the move to NoSQL databases where you have to do that similar sort of... planning out all of your queries upfront, and then kind of baking that into the data as it comes in, rather than the SQL-style collecting all the data and then querying it after the fact. Oh, okay. Well in advance of the move to NoSQL databases where you have to do that similar sort of... planning out all of your queries upfront, and then kind of baking that into the data as it comes in, rather than the SQL-style collecting all the data and then querying it after the fact.

Jack: Yeah. This is the first time that I had dealt with that particular situation in that way. But a few years later, around 2005 or 2006, I did a startup where we built a thing that kicked off the discipline called Yeah. This is the first time that I had dealt with that particular situation in that way. But a few years later, around 2005 or 2006, I did a startup where we built a thing that kicked off the discipline called complex event processing — or rather, the commercial phase of the discipline called complex event processing, which was the same sort of idea but applied to various industrial sectors. We were a company called Aleri, which is eventually purchased by Sybase, and the product is still sold by SAP today.

Jack: It ended up being used for all sorts of things. It was a dataflow system actually, so this is a thing that has some crossover with, I think, a general interest of the listeners of this podcast, because it had a programming mechanism that could be done through a sort of boxes-and-wires kind of approach, through a visual programming environment, or through a code approach, or through a hybrid approach where the boxes were written in a programming language of our own creation and then wired together in the visual environment. It ended up being used for all sorts of things. It was a dataflow system actually, so this is a thing that has some crossover with, I think, a general interest of the listeners of this podcast, because it had a programming mechanism that could be done through a sort of boxes-and-wires kind of approach, through a visual programming environment, or through a code approach, or through a hybrid approach where the boxes were written in a programming language of our own creation and then wired together in the visual environment.

Jack: At one stage, this was used to handle (I think I can tell this without violating any contracts that we signed at the time) about a third of all foreign currency transactions in pound sterling, most of the anti-fraud activity for a couple of very large credit card companies (who will remain nameless), and so on and so on. It ended up being quite effective as a system for detecting patterns in data on arrival and allowing very nimble reactions to those things. At one stage, this was used to handle (I think I can tell this without violating any contracts that we signed at the time) about a third of all foreign currency transactions in pound sterling, most of the anti-fraud activity for a couple of very large credit card companies (who will remain nameless), and so on and so on. It ended up being quite effective as a system for detecting patterns in data on arrival and allowing very nimble reactions to those things.

Ivan: What was the name of that technology? What was the name of that technology?

Jack: The product is the Aleri Streaming Engine— The product is the Aleri Streaming Engine—

Ivan: I was more thinking the generic term, the complex event processing— I was more thinking the generic term, the complex event processing—

Jack: Oh, Oh, complex event processing ! It's a terrible name. We did not coin the name. It comes from the research community and it just makes it all so much scarier than it is.

Ivan: I don't imagine — beyond the fact that anything to do with flowing information from one place to another is either continuous or discrete, and when it's discrete we like to call it an event, so in that sense — there's probably no relation to the event streams we have in web programming these days. Or event sourcing, rather. Is there some relation there? I don't imagine — beyond the fact that anything to do with flowing information from one place to another is either continuous or discrete, and when it's discrete we like to call it an event, so in that sense — there's probably no relation to the event streams we have in web programming these days. Or event sourcing, rather. Is there some relation there?

Jack: Well, in the sense that if you have discrete events arriving and you route them through some sort of dataflow architecture, then you have something that's very like reactive programming. In our case, my two primary colleagues — who are really, really excellent designers, programmers and so on — who were working on this with me, one of them was one of the coauthors of the original adding-an-object-system-to-ML paper, and thus kicked off OCaml. He was the primary designer of the language and wrote the little VM. Well, in the sense that if you have discrete events arriving and you route them through some sort of dataflow architecture, then you have something that's very like reactive programming. In our case, my two primary colleagues — who are really, really excellent designers, programmers and so on — who were working on this with me, one of them was one of the coauthors of the original adding-an-object-system-to-ML paper, and thus kicked off OCaml. He was the primary designer of the language and wrote the little VM.

Jack: We had these little language runtimes with arena allocators that would blow away any storage that was allocated in the course of the thing so that the user wouldn't have to worry about storage allocation and so on, and with a great deal of hand optimization to the little VM. They ran really, really well. So more expert users could write these little programs in these boxes, and less... shall we say... less-expert users could then wire them together very easily, and you would have different people doing different sorts of tasks at the customer installations. We had these little language runtimes with arena allocators that would blow away any storage that was allocated in the course of the thing so that the user wouldn't have to worry about storage allocation and so on, and with a great deal of hand optimization to the little VM. They ran really, really well. So more expert users could write these little programs in these boxes, and less... shall we say... less-expert users could then wire them together very easily, and you would have different people doing different sorts of tasks at the customer installations.

Ivan: Cool. When you were describing the different ways that you could program this system, was I correct in understanding that there were three different levels? You could write traditional code; you could write little pieces of traditional code and then wire it together with some sort of visual language; and then... was there also entirely a visual language, or am I misunderstanding? Cool. When you were describing the different ways that you could program this system, was I correct in understanding that there were three different levels? You could write traditional code; you could write little pieces of traditional code and then wire it together with some sort of visual language; and then... was there also entirely a visual language, or am I misunderstanding?

Jack: Yeah. There was an entire visual language. In fact, that's how we started because we had believed... Or actually, it was my fault. I had believed initially that, that would be the primary way that our users would like to interface with the system. In retrospect, I feel I was wrong about that and I should have built an interface that looked more like spreadsheet. The more like Excel it would have looked, the more appropriate it would have been to the users may ended up having. I just didn't know what verticals we would end up being successful in. In finance, everybody loves a spreadsheet. Yeah. There was an entire visual language. In fact, that's how we started because we had believed... Or actually, it was my fault. I had believed initially that, that would be the primary way that our users would like to interface with the system. In retrospect, I feel I was wrong about that and I should have built an interface that looked more like spreadsheet. The more like Excel it would have looked, the more appropriate it would have been to the users may ended up having. I just didn't know what verticals we would end up being successful in. In finance, everybody loves a spreadsheet.

Jack: With age, and experience in user interface design (of which I did not have that much at the time) I've come to realize that pre-post image table views would have been an excellent way to show people how to do this kind of thing. With age, and experience in user interface design (of which I did not have that much at the time) I've come to realize that pre-post image table views would have been an excellent way to show people how to do this kind of thing.

Ivan: Interesting. Just for anybody who's not familiar with that term (and I might be one of those people, though I'm imagining what I think it is): pre-post image, is that where you have one half of the view is, "Here's the data coming in," and then in the center you have, "Here's the transformation we're applying," and then on the other side you have "Here's the processed result?" Interesting. Just for anybody who's not familiar with that term (and I might be one of those people, though I'm imagining what I think it is): pre-post image, is that where you have one half of the view is, "Here's the data coming in," and then in the center you have, "Here's the transformation we're applying," and then on the other side you have "Here's the processed result?"

Jack: Yeah, that's exactly it. Yeah, that's exactly it.

Ivan: Okay. Cool. Okay. Cool.

Jack: That would have been the much better way to do it. That would have been the much better way to do it.

Ivan: Right. Yeah. It's curious how, as people who are fond of visual programming in all of its different forms, we keep struggling to do something that is an order of magnitude more effective than what VisiCalc seemingly came up with right out of the gate. It's kind of frustrating how they hit upon something so seemingly fundamentally powerful very, very early on. Yet with all of our playing around with different ways of visualizing what the computer is doing, it's hard to beat just plainly showing data, and making that data and the different intermediate forms that it takes along the way very, very visible. That's hard to top. Right. Yeah. It's curious how, as people who are fond of visual programming in all of its different forms, we keep struggling to do something that is an order of magnitude more effective than what VisiCalc seemingly came up with right out of the gate. It's kind of frustrating how they hit upon something so seemingly fundamentally powerful very, very early on. Yet with all of our playing around with different ways of visualizing what the computer is doing, it's hard to beat just plainly showing data, and making that data and the different intermediate forms that it takes along the way very, very visible. That's hard to top.

Jack: Yeah, it's extremely powerful. Anything that taps into our evolutionary heritage I think is very strong, and that's been known at least since people like Minsky and Papert were trying to teach children with physical, mechanical turtles and things. Bringing in our intuitions — our physical intuition — is one of the strongest ways to give us a jumpstart on learning a new domain. Yeah, it's extremely powerful. Anything that taps into our evolutionary heritage I think is very strong, and that's been known at least since people like Minsky and Papert were trying to teach children with physical, mechanical turtles and things. Bringing in our intuitions — our physical intuition — is one of the strongest ways to give us a jumpstart on learning a new domain.

Ivan: Yeah, and those physical intuitions — I'm assuming you're referring to things like spatial reasoning, and something like a grid. A grid is a very knowable thing that we find in real life. Bringing that kind of a structure as a way of dealing with hierarchy, or as a way of dealing with relationships, it leverages a lot of what we bring to the computer. Yeah, and those physical intuitions — I'm assuming you're referring to things like spatial reasoning, and something like a grid. A grid is a very knowable thing that we find in real life. Bringing that kind of a structure as a way of dealing with hierarchy, or as a way of dealing with relationships, it leverages a lot of what we bring to the computer.

Jack: Absolutely. If we push past that, if we look into other disciplines and what they've learned, one discipline that's done very well is various graphic design disciplines that have determined what axes there are really — and data visualization for that matter — have determined what axes there are really on which you can vary your presentation in order to recruit the user's visual cortex to do most of the work before their higher facilities begin to try to figure out what's happening. Absolutely. If we push past that, if we look into other disciplines and what they've learned, one discipline that's done very well is various graphic design disciplines that have determined what axes there are really — and data visualization for that matter — have determined what axes there are really on which you can vary your presentation in order to recruit the user's visual cortex to do most of the work before their higher facilities begin to try to figure out what's happening.

Jack: You have things like relative contrast, relative size, grouping by position in space, all of these different things. I think in programming actually, we make shamefully little use of most of these ways of conveying information to our users. In this case, users being the programmers who are using our programming tools because the tools are themselves, as you are well aware, interfaces. You have things like relative contrast, relative size, grouping by position in space, all of these different things. I think in programming actually, we make shamefully little use of most of these ways of conveying information to our users. In this case, users being the programmers who are using our programming tools because the tools are themselves, as you are well aware, interfaces.

Ivan: Yeah. Like those fundamental design principles. You pick up any first-year college Design textbook and you won't be able to get very far into it before you encounter the fundamental building blocks of pretty much any image that is meant to convey some sort of meaning, before you get into the deeper things that are based on cultural heritage. You move through, like you said, spacing, grouping, variation in intensity and hue. What they don't even touch on — and I think something that we grossly overlook in computing — is also that there are those same fundamental building blocks available in motion. Yeah. Like those fundamental design principles. You pick up any first-year college Design textbook and you won't be able to get very far into it before you encounter the fundamental building blocks of pretty much any image that is meant to convey some sort of meaning, before you get into the deeper things that are based on cultural heritage. You move through, like you said, spacing, grouping, variation in intensity and hue. What they don't even touch on — and I think something that we grossly overlook in computing — is also that there are those same fundamental building blocks available in motion.

Jack: Absolutely. Yeah. Absolutely. Yeah.

Ivan: Yeah. Entry-level design — it's not for pencil animators. So they're not learning about easing and temporal repetition and anticipation and those sorts of principles as well. For me personally, looking at a lot of the programming interfaces we have, not only are they built with a willful or accidental ignorance of design principles, but there's also this entire other domain that can be explored and leveraged to convey meaning to the programmer that's just not even been touched on. Yeah. Entry-level design — it's not for pencil animators. So they're not learning about easing and temporal repetition and anticipation and those sorts of principles as well. For me personally, looking at a lot of the programming interfaces we have, not only are they built with a willful or accidental ignorance of design principles, but there's also this entire other domain that can be explored and leveraged to convey meaning to the programmer that's just not even been touched on.

Jack: Yeah. Absolutely. It is a bit of a tragedy really that the editing environment continues to be... people to continue to write new editors for programming languages that offer you a grid of fixed-width type. Yeah. Absolutely. It is a bit of a tragedy really that the editing environment continues to be... people to continue to write new editors for programming languages that offer you a grid of fixed-width type.

Ivan: Yeah. Yeah.

Jack: It's just that's it. The paradigm is monospaced type and — oh! — we'll maybe add some color for the syntax highlighting. It's just that's it. The paradigm is monospaced type and — oh! — we'll maybe add some color for the syntax highlighting.

Ivan: Yeah. That's I think what excites me so much about the community of this podcast is... so many people here are looking at different ways of getting us from that fixed grid of colored text to something, and this something is as yet undetermined. Yeah. That's I think what excites me so much about the community of this podcast is... so many people here are looking at different ways of getting us from that fixed grid of colored text to, and thisis as yet undetermined.

Ivan: It's kind of neat to see all these pieces — from the design fundamentals, or motion, or aspects of culture — being put together in different combinations to see which of them resonates most strongly with what human beings bring to the programming experience. It feels like it's unfamiliar territory, and yet we've been exploring this very territory since the 1960s, if not a lot earlier depending on how you want to frame it. It's kind of neat to see all these pieces — from the design fundamentals, or motion, or aspects of culture — being put together in different combinations to see which of them resonates most strongly with what human beings bring to the programming experience. It feels like it's unfamiliar territory, and yet we've been exploring this very territory since the 1960s, if not a lot earlier depending on how you want to frame it.

Jack: Hmm. Hmm.

Ivan: You have a remarkably sharp sense of aesthetics. That's something that I've noticed. From your profile picture on Twitter, to the way that you use your hobbies in programming and elsewhere and tie them together to make generative art, to being a musician, your website. Everything that I've seen you do that requires you making your presence known on the Internet is rooted in what I feel is a very strong sense of taste and cohesive sense of aesthetics. You have a remarkably sharp sense of aesthetics. That's something that I've noticed. From your profile picture on Twitter, to the way that you use your hobbies in programming and elsewhere and tie them together to make generative art, to being a musician, your website. Everything that I've seen you do that requires you making your presence known on the Internet is rooted in what I feel is a very strong sense of taste and cohesive sense of aesthetics.

Ivan: That's why I wanted to interview you on this show, because I feel like that permeates everything you do. I imagine that it does, and so I'm curious to see, when it comes to the choices that you make in programming or your affinity for certain technologies, how do you see your own sense of aesthetics guiding those choices? That's why I wanted to interview you on this show, because I feel like that permeates everything you do. I imagine that it does, and so I'm curious to see, when it comes to the choices that you make in programming or your affinity for certain technologies, how do you see your own sense of aesthetics guiding those choices?

Jack: First, I have to say thank you. Then I would say I have multiple backgrounds. I originally was educated in physics and shifted to theoretical computer science because I was seduced by certain early/mid-century findings in that discipline, and then spent a long career doing engineering with software and even a bit of hardware. When I'm doing my own programming, there is a strong pragmatic perspective for me where I will use whatever tool I feel is the one that is going to help me achieve the objective well. First, I have to say thank you. Then I would say I have multiple backgrounds. I originally was educated in physics and shifted to theoretical computer science because I was seduced by certain early/mid-century findings in that discipline, and then spent a long career doing engineering with software and even a bit of hardware. When I'm doing my own programming, there is a strong pragmatic perspective for me where I will use whatever tool I feel is the one that is going to help me achieve the objective well.

Jack: On the other hand, like everyone, I am inflicted with my own set of aesthetics that drive me toward certain things. I really, really like Scheme for example, and the closer a language is to Scheme generally the more I like it. This is one thing. On the other hand, like everyone, I am inflicted with my own set of aesthetics that drive me toward certain things. I really, really like Scheme for example, and the closer a language is to Scheme generally the more I like it. This is one thing.

Jack: I believe that it is always better if you can to tell the computer what to do, rather than explain to it the minutia of how to do it. I find that more elegant and more pleasant, and also faster and more practical in most cases. I believe that it is always better if you can to tell the computer what to do, rather than explain to it the minutia of how to do it. I find that more elegant and more pleasant, and also faster and more practical in most cases.

Ivan: Is that faster in a performance sense or faster in just— Is that faster in a performance sense or faster in just—

Jack: In a human effort extent. Yeah. In a human effort extent. Yeah.

Ivan: Scheme specifically? Or Lisp as a family? Or Racket? Scheme specifically? Or Lisp as a family? Or Racket?

Jack: Well, I've had a very enjoyable program experiences in Scheme, and in Racket, and in Common Lisp, and in some Lisp-like dialects of my own construction over the years. Yeah, generally I do enjoy parentheses I would say. But beyond that, of the group of them I feel like Scheme hit upon a distilled and crystalline vision that I respect a great deal. Well, I've had a very enjoyable program experiences in Scheme, and in Racket, and in Common Lisp, and in some Lisp-like dialects of my own construction over the years. Yeah, generally I do enjoy parentheses I would say. But beyond that, of the group of them I feel like Scheme hit upon a distilled and crystalline vision that I respect a great deal.

Jack: When I would use Common Lisp in the past, it was primarily because it had usually made available, at some stage some kind of very nice environment for programming. If you have listeners, for example, which I doubt with your community that you do have any listeners who aren't familiar with Common Lisp's environments — they are typically extremely humane, in the sense that if you have an error you can pause and fix the thing that broke and continue from where the error occurred, and things like this that are almost unknown in most other programming environments. So this is very, very attractive. When I would use Common Lisp in the past, it was primarily because it had usually made available, at some stage some kind of very nice environment for programming. If you have listeners, for example, which I doubt with your community that you do have any listeners who aren't familiar with Common Lisp's environments — they are typically extremely humane, in the sense that if you have an error you can pause and fix the thing that broke and continue from where the error occurred, and things like this that are almost unknown in most other programming environments. So this is very, very attractive.

Jack: But Common Lisp, the language, it's a mixed bag. There's some very nice things about it, and it also has a lot of cruft, and it doesn't have the kind of crystalline purity that Scheme does. But Common Lisp, the language, it's a mixed bag. There's some very nice things about it, and it also has a lot of cruft, and it doesn't have the kind of crystalline purity that Scheme does.

Ivan: I think the first place we ran into each other was on the I think the first place we ran into each other was on the ClojureVerse Forum . That was in a thread about the Luna language/environment that had just been announced where they're creating a very Haskell-like pure functional language and also creating a very nice sort of node-and-line based visual programming environment. They're two representations of the same underlying model.

Ivan: We were looking at that environment and talking about the various merits, and projects that had tried this in the past, and some people started saying, "Hey, we should collect all of these projects We were looking at that environment and talking about the various merits, and projects that had tried this in the past, and some people started saying, "Hey, we should collect all of these projects into one place ."

Ivan: You suggested that somebody pull on the model of You suggested that somebody pull on the model of Shaun Lebron 's History of Lisp Parens , which is this wonderful GitHub repo he made reviewing some of those beautiful environments that have been made for Lisp throughout history, and looking at not just the design of them and the choices that they've made but how they sort of—

Ivan: I feel like they were reflections of the era in which they were created, in the way that everything that is created is a reflection of its time... There was this this period through the '70s and maybe in the early '80s where it feels like the spectrum was wider. There were wilder ideas being tried, despite the fact that computing power was so much more limited back then. That the freedom to do whatever you wanted — that we have now — wasn't there back then. I feel like they were reflections of the era in which they were created, in the way that everything that is created is a reflection of its time... There was this this period through the '70s and maybe in the early '80s where it feels like the spectrum was wider. There were wilder ideas being tried, despite the fact that computing power was so much more limited back then. That the freedom to do whatever you wanted — that we have now — wasn't there back then.

Ivan: So, the scope of human ambition was curtailed by the very, very restrictive ability of the computers at the time. I feel like we haven't expanded the scope and breadth of our imagination for editing tools in lockstep with the advancement of computing power since then. I'm wondering if you also feel like the range of exploration has — if not narrowed, then at least — stayed within a known bounds. How do you see our programming culture moving forward, compared to how the technology that we built that culture on top of is moving? So, the scope of human ambition was curtailed by the very, very restrictive ability of the computers at the time. I feel like we haven't expanded the scope and breadth of our imagination for editing tools in lockstep with the advancement of computing power since then. I'm wondering if you also feel like the range of exploration has — if not narrowed, then at least — stayed within a known bounds. How do you see our programming culture moving forward, compared to how the technology that we built that culture on top of is moving?

Jack: I think one of the things that happened historically was that the machines that had the nicer programming environments were extremely expensive machines that essentially existed in the future relative to what people could afford at the time. I think one of the things that happened historically was that the machines that had the nicer programming environments were extremely expensive machines that essentially existed in the future relative to what people could afford at the time.

Jack: What I mean by that is, for instance, the Lisp machine — which I had the pleasure to use a few times back in the day — was remarkable, and contained features that nothing else had. But at the same time, even back then it was a bit clunky running on — by clunky, I mean a bit slow in terms of direct response to user input — running on $80,000 worth of hardware. What I mean by that is, for instance, the Lisp machine — which I had the pleasure to use a few times back in the day — was remarkable, and contained features that nothing else had. But at the same time, even back then it was a bit clunky running on — by clunky, I mean a bit slow in terms of direct response to user input — running on $80,000 worth of hardware.

Jack: What naturally happened was cheaper, much worse workstations showed up with much worse tools and experiences available on them, but which cost such a tiny fraction of what those machines cost that it reset our expectations to what was possible on an 8088 with very little memory. That's essentially where we have stood since then, and we have professionalized the culture around the lower expectations of that lesser hardware. What naturally happened was cheaper, much worse workstations showed up with much worse tools and experiences available on them, but which cost such a tiny fraction of what those machines cost that it reset our expectations to what was possible on an 8088 with very little memory. That's essentially where we have stood since then, and we have professionalized the culture around the lower expectations of that lesser hardware.

Jack: Now, when we go back in time and we look at the papers from the '70s and early '80s in, for instance, the Lisp community, we find over and over again gems that were really interesting ideas that were just impractical on the hardware that most people could actually afford at the time. Now, when we go back in time and we look at the papers from the '70s and early '80s in, for instance, the Lisp community, we find over and over again gems that were really interesting ideas that were just impractical on the hardware that most people could actually afford at the time.

Jack: As you have pointed out just now, the hardware that you have in your phone today is far better than the hardware that one had on an extremely expensive machine in the '70s. If you're writing an environment for a modern laptop, you can do anything, which means that we are ripe for a revisiting and a rethinking of how we do these things. As you have pointed out just now, the hardware that you have in your phone today is far better than the hardware that one had on an extremely expensive machine in the '70s. If you're writing an environment for a modern laptop, you can do anything, which means that we are ripe for a revisiting and a rethinking of how we do these things.

Jack: Even, not only coming up with new ideas, but even performing some anthropology on the history of our own discipline and sort of cherry picking some of the great ideas that we had to leave behind because our hardware was so bad. Even, not only coming up with new ideas, but even performing some anthropology on the history of our own discipline and sort of cherry picking some of the great ideas that we had to leave behind because our hardware was so bad.

Ivan: Alan Kay had this wonderful description: to invent the computing of the future, you can buy hardware that takes you 10 years into the future, and then you can imagine another 10 years after that. I can't remember his exact quote but it was, basically, you can put yourself 30 years into the future and work in that space if you are adequately well-funded and adequately imaginative. That ties that together, what you've said about it where... these researchers coming up with all this material were almost leaving a breadcrumb trail for people today. Alan Kay had this wonderful description: to invent the computing of the future, you can buy hardware that takes you 10 years into the future, and then you can imagine another 10 years after that. I can't remember his exact quote but it was, basically, you can put yourself 30 years into the future and work in that space if you are adequately well-funded and adequately imaginative. That ties that together, what you've said about it where... these researchers coming up with all this material were almost leaving a breadcrumb trail for people today.

Ivan: Did you ever end up trying Luna? Did you ever end up trying Luna?

Jack: I think I was unable to download it when I went to try it, and then I didn't go back. But I do very much like what they're doing. One of the things that I think isn't talked about enough, when people talk about languages with a strong upfront type discipline like Haskell, is that everyone focuses on this as a way to avoid making certain kinds of mistakes. But they don't really talk so much about how effective it is as a user interface paradigm, because the more the machine knows about what's possible, the better sorts of completion and filter it can give you moment-to-moment while you're editing your code. I think I was unable to download it when I went to try it, and then I didn't go back. But I do very much like what they're doing. One of the things that I think isn't talked about enough, when people talk about languages with a strong upfront type discipline like Haskell, is that everyone focuses on this as a way to avoid making certain kinds of mistakes. But they don't really talk so much about how effective it is as a user interface paradigm, because the more the machine knows about what's possible, the better sorts of completion and filter it can give you moment-to-moment while you're editing your code.

Ivan: This is something where I think Steve — the normal host of this podcast who I am swooping in beneath — he and I really differ in this regard, in that he is very strongly of the ML-family, strongly typed persuasion and I am very dynamically of the dynamically typed, Lisp-y persuasion. I don't believe that there's anything fundamental about types and category theory that you require in order to create very rich tooling. Though I feel like it does... there is some cohesion there. It is very nice to have that certainty about the mathematical underpinnings of your language in order to build tooling around it. I feel sort of like there's this impression that dynamic typing leads to a very difficult foundation to build tools on top of. Though our history with Lisp would suggest otherwise. This is something where I think Steve — the normal host of this podcast who I am swooping in beneath — he and I really differ in this regard, in that he is very strongly of the ML-family, strongly typed persuasion and I am very dynamically of the dynamically typed, Lisp-y persuasion. I don't believe that there's anything fundamental about types and category theory that youin order to create very rich tooling. Though I feel like it does... there is some cohesion there. It is very nice to have that certainty about the mathematical underpinnings of your language in order to build tooling around it. I feel sort of like there's this impression that dynamic typing leads to a very difficult foundation to build tools on top of. Though our history with Lisp would suggest otherwise.

Jack: Not only Lisp, either. I mean Smalltalk is tremendously dynamic and to this day has the best developer tools that any system can really offer. It's a ridiculous argument that you can't make good tools on top of dynamic languages. Not only Lisp, either. I mean Smalltalk is tremendously dynamic and to this day has the best developer tools that any system can really offer. It's a ridiculous argument that you can't make good tools on top of dynamic languages.

Jack: What I would say is that a language that has built-in a way for you to tell the environment to restrict the possibilities of a certain call site, for example, does give you the ability then to have a user interface that doesn't provide you completions that don't make any sense, for example. What I would say is that a language that has built-in a way for you to tell the environment to restrict the possibilities of a certain call site, for example, does give you the ability then to have a user interface that doesn't provide you completions that don't make any sense, for example.

Ivan: Sure. Though there's no strict requirement that that be done with types. Something like specifications or contracts would work just as well. Yeah. Sure. Though there's no strict requirement that that be done with types. Something like specifications or contracts would work just as well. Yeah.

Jack: Oh, absolutely, absolutely. Yeah. To me, those are really fungible in terms of a way to communicate to the machine what range of possibilities they are for this call site. Anyway you can do that can work for this purpose. Oh, absolutely, absolutely. Yeah. To me, those are really fungible in terms of a way to communicate to the machine what range of possibilities they are for this call site. Anyway you can do that can work for this purpose.

Jack: Of course, for me — as I mentioned before my love of Scheme — I very much fall on the "Don't make me write all the types upfront" family of programming. Because for me, with the kind of very rich REPL-attached-to-editor kind of editing that I typically do in the dynamic languages I use, it is extremely seldom that I encounter a bug that occurred because of a bad type signature. Of course, for me — as I mentioned before my love of Scheme — I very much fall on the "Don't make me write all the types upfront" family of programming. Because for me, with the kind of very rich REPL-attached-to-editor kind of editing that I typically do in the dynamic languages I use, it is extremely seldom that I encounter a bug that occurred because of a bad type signature.

Jack: Those things are worked out while I'm writing the code, while I'm testing the code, while I'm evaluating the forms. I very quickly have the shape of the code the way I want it to be, and then everything is fine. I don't typically have the kinds of problems that Haskellers tell me that I would not have if I were using Haskell (which I have, in fact, used in anger in the past — and I respect Haskell a great deal, but it's not my favorite moment-to-moment programming experience). Those things are worked out while I'm writing the code, while I'm testing the code, while I'm evaluating the forms. I very quickly have the shape of the code the way I want it to be, and then everything is fine. I don't typically have the kinds of problems that Haskellers tell me that I would not have if I were using Haskell (which I have, in fact, used in anger in the past — and I respect Haskell a great deal, but it's not my favorite moment-to-moment programming experience).

Ivan: Yeah. The whole static-dynamic debate, it just rages on and on and on and on. I feel like it's fundamental to computation in the way that, like, we have lambda calculus, and Turing machines, and combinator calculi, and Pi-calculus, all these different fundamental models of computation. Is the static-dynamic split something that you feel like we're going to have forever and ever? Or do you feel like, in the culture, we will eventually tip one way or the other and stay there forever? Is there some kind of harmony between them we might arrive at? How do you feel about that split? Yeah. The whole static-dynamic debate, it just rages on and on and on and on. I feel like it's fundamental to computation in the way that, like, we have lambda calculus, and Turing machines, and combinator calculi, and Pi-calculus, all these different fundamental models of computation. Is the static-dynamic split something that you feel like we're going to have forever and ever? Or do you feel like, in the culture, we will eventually tip one way or the other and stay there forever? Is there some kind of harmony between them we might arrive at? How do you feel about that split?

Jack: Well, I mean the area between the two extremes that I find most interesting is in progressive typing. Obviously, the Racket community, I think, is at the forefront of this particular approach. I do like it actually because I find that early on — and different people approach programming in different ways, but for me, if I'm encountering a new problem domain in the early phase — I tend to want to go very fast and try many different things to explore the space in an environment that helps me. Well, I mean the area between the two extremes that I find most interesting is in progressive typing. Obviously, the Racket community, I think, is at the forefront of this particular approach. I do like it actually because I find that early on — and different people approach programming in different ways, but for me, if I'm encountering a new problem domain in the early phase — I tend to want to go very fast and try many different things to explore the space in an environment that helps me.

Jack: I want to evaluate lots of little forms and capture what they've produced, and their typing will exist, obviously — like if you have a vector of vectors, that's a thing and it has type. But I don't want to have to tell it that I want a vector of vectors when I'm taking apart this piece of data that's coming in off the wire in a nonce fashion from inside of Emacs just to see what kind of data I'm receiving, and so on. I want to evaluate lots of little forms and capture what they've produced, and their typing will exist, obviously — like if you have a vector of vectors, that's a thing and it has type. But I don't want to have to tell it that I want a vector of vectors when I'm taking apart this piece of data that's coming in off the wire in a nonce fashion from inside of Emacs just to see what kind of data I'm receiving, and so on.

Jack: There's definitely a wide base of exploratory programming and live coding that I want to do in an extremely forgiving, extremely dynamic language. On the other hand, once something is sort of hammered-down and you are pretty sure that your need to change it is small but the cost of error is high, or alternatively — and this is something again that I feel is not talked about enough with regards to types — you need it to go very fast, then going through and providing type hints so that your compiler can do more work and produce better code becomes more valuable. There's definitely a wide base of exploratory programming and live coding that I want to do in an extremely forgiving, extremely dynamic language. On the other hand, once something is sort of hammered-down and you are pretty sure that your need to change it is small but the cost of error is high, or alternatively — and this is something again that I feel is not talked about enough with regards to types — you need it to go very fast, then going through and providing type hints so that your compiler can do more work and produce better code becomes more valuable.

Jack: All of that said, most of the claims for static typing in terms of avoiding errors, I find, at least in my programming life, I have gotten more mileage out of from model checkers — you know, theorem provers. All of that said, most of the claims for static typing in terms of avoiding errors, I find, at least in my programming life, I have gotten more mileage out of from model checkers — you know, theorem provers.

Jack: For example, if one is writing a complex protocol, this is a situation where the types can't save you but a model checker can. These are the kinds of situations in which I run into walls where, "Oops, I didn't think of that, and now a very expensive mistake has happened." Where that is much less common, at least in my programming life, as a result of not having inserted type hint somewhere. For example, if one is writing a complex protocol, this is a situation where the types can't save you but a model checker can. These are the kinds of situations in which I run into walls where, "Oops, I didn't think of that, and now a very expensive mistake has happened." Where that is much less common, at least in my programming life, as a result of not having inserted type hint somewhere.

Ivan: Have you ever seen an environment that — because I'm used to seeing tools like TLA+ or Alloy as sort of separate from the actual language where the development work is being done — have you ever seen an environment that pulled those things together? Other than maybe Have you ever seen an environment that — because I'm used to seeing tools like TLA+ or Alloy as sort of separate from the actual language where the development work is being done — have you ever seen an environment that pulled those things together? Other than maybe QuickCheck , or something like that.

Jack: The closest thing, really, is when you have your model checker embedded in the same language you're doing your domain programming in. So for instance Coq, for an OCaml programmer for example, feels very native relative to other ways that you might go about doing it. The closest thing, really, is when you have your model checker embedded in the same language you're doing your domain programming in. So for instance Coq, for an OCaml programmer for example, feels very native relative to other ways that you might go about doing it.

Ivan: Is there a relationship between the sort of model checking that you've done and something that you might do with Is there a relationship between the sort of model checking that you've done and something that you might do with miniKanren

Jack: There is obviously a strong relationship between theorem provers and logic programming environments. You can, in a similar way, factor out the possibility of certain kinds of errors and so on using... Yes, obviously. You can construct a type system in a logic programming environment if you so choose. So obviously they have equivalent expressive power. There is obviously a strong relationship between theorem provers and logic programming environments. You can, in a similar way, factor out the possibility of certain kinds of errors and so on using... Yes, obviously. You can construct a type system in a logic programming environment if you so choose. So obviously they have equivalent expressive power.

Ivan: My curiosity there is that something like miniKanren is... it's a tool that you'll reach for usually when you need to do that sort of logic programming as part of solving your domain problem. Whereas I feel like model checking is something you reach for not to reach a solution in the domain, but to reach a solution in the domain one abstraction away — the programming domain — where you're trying to figure out if the system that you're constructing to solve the domain problem has the properties that you want to imbue it with. My curiosity there is that something like miniKanren is... it's a tool that you'll reach for usually when you need to do that sort of logic programming as part of solving your domain problem. Whereas I feel like model checking is something you reach for not to reach a solution in the domain, but to reach a solution in the domain one abstraction away — the programming domain — where you're trying to figure out if the system that you're constructing to solve the domain problem has the properties that you want to imbue it with.

Ivan: I'm sort of wondering aloud if there might be some kind of potential direction there for future tools to go, where they have the facilities of logic programming — like a Prolog or I'm sort of wondering aloud if there might be some kind of potential direction there for future tools to go, where they have the facilities of logic programming — like a Prolog or Datalog , miniKanren, or some sort of constraint solver — that you could use at the level of your domain problem if you need to, or you could also use it at a macro level, or... Is it Black Scheme where you have a tower of interpreters that you build? Is that the one?

Jack: Yeah, it's the one. Yeah. Yeah, it's the one. Yeah.

Ivan: Yeah. If there's something like that. Or like a Yeah. If there's something like that. Or like a dependent typed kind of environment, where the same tools that you can use at one level you can use at another level up. I don't know that I've ever seen anything like that.

Jack: I don't think... made quite so uniform, so it feels like one experience. But there are many situations where you find logic programming embedded in another programming language. That is typically how I personally prefer to use logic programming. So rather than turning to Prolog, for example, I would prefer to use miniKanren from Scheme, or, you know — I don't think... made quite so uniform, so it feels like one experience. But there are many situations where you find logic programming embedded in another programming language. That is typically how I personally prefer to use logic programming. So rather than turning to Prolog, for example, I would prefer to use miniKanren from Scheme, or, you know — Oleg has some very nice work on embedded logic programming within ML dialects, especially OCaml and so on — because I find that's actually a much nicer way to program.

Jack: What you really want when you are solving problems is an ability to move along a kind of continuum from very declarative things, where you're at the far edge and you're essentially writing logic programs, down to extremely imperative things, where you're explaining to the computer exactly how the bytes must go in the record that you're, you know. What you really want when you are solving problems is an ability to move along a kind of continuum from very declarative things, where you're at the far edge and you're essentially writing logic programs, down to extremely imperative things, where you're explaining to the computer exactly how the bytes must go in the record that you're, you know.

Jack: For example, if I'm doing graphics programming, it can be very frustrating if I have to marshal a new data structure and return it out of everyone of my functions, because the buffers that I'm moving around then are going to cross these different memory boundaries, there's going to be a lot of allocation and deallocation happening, and I'm going to have terrible performance. For example, if I'm doing graphics programming, it can be very frustrating if I have to marshal a new data structure and return it out of everyone of my functions, because the buffers that I'm moving around then are going to cross these different memory boundaries, there's going to be a lot of allocation and deallocation happening, and I'm going to have terrible performance.

Jack: In those situations, I need to be able — if I want to write that kind of code — to drop down to a layer at which I'm just slamming bytes into a byte array. But it's not how I prefer to write most programs, right? So, optimally, ideally, I want to be able to slide back and forth along that continuum as needed, staying as far towards the declarative side as I possibly can and only dipping down into the rest as needed. In those situations, I need to be able — if I want to write that kind of code — to drop down to a layer at which I'm just slamming bytes into a byte array. But it's not how I prefer to write most programs, right? So, optimally, ideally, I want to be able to slide back and forth along that continuum as needed, staying as far towards the declarative side as I possibly can and only dipping down into the rest as needed.

Ivan: That's an idea that to me most immediately calls to mind the other, other FRP — the Functional Relational Programming idea introduced at the end of the That's an idea that to me most immediately calls to mind the other, other FRP — the Functional Relational Programming idea introduced at the end of the Out of the Tar Pit paper, where they have a programming language/environment that's split into three separate pieces that each fit together — where you have one piece that is expressing relationships between entities in the system, and then another piece that is low-level, very imperative code that does performance sensitive work with the data that has those relationships, and I can't, off the top of my head, recall what the third piece of it was.

Jack: I seem to remember it was a pretty bland functional layer, wasn't it? I seem to remember it was a pretty bland functional layer, wasn't it?

Ivan: Yeah, something like that. Yeah. Yeah, something like that. Yeah.

Jack: That's exactly what I'm talking about here... is the same thing, of course. That's exactly what I'm talking about here... is the same thing, of course.

Ivan: Well, my question is... I believe there was only ever a toy implementation of that idea brought into existence. I'm wondering what environments you've seen that do a very good job of spanning all the way from that highly declarative end of the spectrum — the logic programming end of the spectrum — all the way down to very precise control over what's in my buffers, what's being swizzled, that sort of thing. Well, my question is... I believe there was only ever a toy implementation of that idea brought into existence. I'm wondering what environments you've seen that do a very good job of spanning all the way from that highly declarative end of the spectrum — the logic programming end of the spectrum — all the way down to very precise control over what's in my buffers, what's being swizzled, that sort of thing.

Jack: The way that I prefer to deal with those situations is, rather than trying to make a single monolithic programming language that can do all of these things, I prefer to work in a programmable programming language that will allow me to build DSLs at these various levels of abstraction that can all work together. The way that I prefer to deal with those situations is, rather than trying to make a single monolithic programming language that can do all of these things, I prefer to work in a programmable programming language that will allow me to build DSLs at these various levels of abstraction that can all work together.

Jack: For example, a good, fast Scheme implementation like For example, a good, fast Scheme implementation like Chez Scheme with something like miniKanren to work more towards the declarative side and the ability to actually allocate a bunch of bytes and set them in a tight loop — can get the work done.

Jack: Historically, probably the environment that I found that's most agreeable for this is some of the better Common Lisp implementations because you can drill down to finding out exactly what code is being written for you by the compiler based on the code that you have written, and give type hints and do all the things you need to do at the bottom level, but you can back off and build a tower of abstractions that is as tall as you wish it to be. Historically, probably the environment that I found that's most agreeable for this is some of the better Common Lisp implementations because you can drill down to finding out exactly what code is being written for you by the compiler based on the code that you have written, and give type hints and do all the things you need to do at the bottom level, but you can back off and build a tower of abstractions that is as tall as you wish it to be.

Ivan: As soon as you said that, I had the thought, "Oh, of course, that's the ultimate smart-alecky answer to give on this podcast," which — I think there's a lot of the listenership who have the idea in mind that what we need is a giant comprehensive solution that spans from one end of the planet to the other — no, of course, it's Lisp! It's composition. It's small pieces that you can build your own abstractions out of. Yup. That's great. As soon as you said that, I had the thought, "Oh, of course, that's the ultimate smart-alecky answer to give on this podcast," which — I think there's a lot of the listenership who have the idea in mind that what we need is a giant comprehensive solution that spans from one end of the planet to the other — no, of course, it's Lisp! It's composition. It's small pieces that you can build your own abstractions out of. Yup. That's great.

Jack: That's certainly my preference. I would say that there are other people who have been at this even longer than my ancient gray-bearded self, who prefer some of those layers to not look like Lisp. For example, this is how Alan Kay's team generally approaches any new thing, is they build a tower of languages where each language has different syntax and features relative to the language beneath it. That's certainly my preference. I would say that there are other people who have been at this even longer than my ancient gray-bearded self, who prefer some of those layers to not look like Lisp. For example, this is how Alan Kay's team generally approaches any new thing, is they build a tower of languages where each language has different syntax and features relative to the language beneath it.

Jack: For example, you go look at [Maru](https://www.piumarta.com/software/maru/), a very low level Lisp-like language that is used to bootstrap most of these experiments. You'll see that on top of it eventually they end up building something unsurprisingly resembling Smalltalk. Often on top of that maybe some other DSLs that are even more specialized. For example, you go look at [Maru](https://www.piumarta.com/software/maru/), a very low level Lisp-like language that is used to bootstrap most of these experiments. You'll see that on top of it eventually they end up building something unsurprisingly resembling Smalltalk. Often on top of that maybe some other DSLs that are even more specialized.

Jack: The idea of course here is that if you can build a tower of DSLs and write all of the parts of your system in a language that is very agreeable for that task, that you don't need to write nearly as much code because you don't spend as much time in the awkward part of your programming language. The idea of course here is that if you can build a tower of DSLs and write all of the parts of your system in a language that is very agreeable for that task, that you don't need to write nearly as much code because you don't spend as much time in the awkward part of your programming language.

Ivan: So, I'm going to throw a curveball at you. (Hopefully it's a curveball.) Where have you seen, or what would you like to see, for building such towers of abstractions in a visual paradigm? So, I'm going to throw a curveball at you. (Hopefully it's a curveball.) Where have you seen, or what would you like to see, for building such towers of abstractions in a visual paradigm?

Ivan: I know you mentioned Alan Kay, and that you end up with something at the very top that looks kind of like Smalltalk. But if you're interested in having a visual experience that goes all the way from one end to the other — and you are interested in tying together those principles from graphic design and animation, and using them to get more information to and from the programmer and the computer then you'd get from just the grid of colored characters — what do you think that would look like? Or what would you want that to look like? I know you mentioned Alan Kay, and that you end up with something at the very top that looks kind of like Smalltalk. But if you're interested in having a visual experience that goes all the way from one end to the other — and you are interested in tying together those principles from graphic design and animation, and using them to get more information to and from the programmer and the computer then you'd get from just the grid of colored characters — what do you think that would look like? Or what would you want that to look like?

Jack: Well, I would start by saying that one of the differences I have with Alan Kay on this is that I do prefer very uniform syntax at all layers. Whereas he prefers the syntax to vary more by layer for aesthetic reasons of his own. Well, I would start by saying that one of the differences I have with Alan Kay on this is that I do prefer very uniform syntax at all layers. Whereas he prefers the syntax to vary more by layer for aesthetic reasons of his own.

Jack: For me, I would want something that I could express well in a visual environment that translates across all of these domains. If I were building such a thing myself, I would maybe build it on top of Chez Scheme, but build an interface that looks something like For me, I would want something that I could express well in a visual environment that translates across all of these domains. If I were building such a thing myself, I would maybe build it on top of Chez Scheme, but build an interface that looks something like Scheme Bricks or Scheme blocks, which I think is actually a kind of nice, aesthetically pleasing variation on, say, the scratch idea of blocky things plugged together kind of programming, but again with a very uniform syntax that makes it visually quite easy to see what's happening at all the different layers.

Ivan: In that sense, you would gravitate towards a visual language that is still rooted in written language rather than rooted in the language of visual arts. In that sense, you would gravitate towards a visual language that is still rooted in written language rather than rooted in the language of visual arts.

Jack: Well, I don't think those are actually different worlds. If we study graphic design, most of it is about type. For example, I don't think that in such an environment, I would want everything to be represented by small blocks of monospaced type. We can still use vertical and horizontal alignment of elements and have them, based on what's syntactic structure they're describing, look different from each other. Well, I don't think those are actually different worlds. If we study graphic design, most of it is about type. For example, I don't think that in such an environment, I would want everything to be represented by small blocks of monospaced type. We can still use vertical and horizontal alignment of elements and have them, based on what's syntactic structure they're describing, look different from each other.

Jack: When we look at other human-scale notations for complex things, for instance traditional mathematical notation (which admittedly has many problems of its own) there are things like writing a for loop as a capital sigma with the beginning and the end at the bottom and the top and so on. When we look at other human-scale notations for complex things, for instance traditional mathematical notation (which admittedly has many problems of its own) there are things like writing a for loop as a capital sigma with the beginning and the end at the bottom and the top and so on.

Jack: I don't see any reason why when we build, say, a map over some domain in our language that it can have a visual representation that looks like that's what it's doing. The uniformity in the sense of making everything into a little box like Scheme Bricks, that would be a starting point to bootstrap the idea, but ultimately I would like to have really beautiful typography. I would like to use all of the different things that our visual cortex can to make things more obvious to the end user as they're programming. I don't see any reason why when we build, say, a map over some domain in our language that it can have a visual representation that looks like that's what it's doing. The uniformity in the sense of making everything into a little box like Scheme Bricks, that would be a starting point to bootstrap the idea, but ultimately I would like to have really beautiful typography. I would like to use all of the different things that our visual cortex can to make things more obvious to the end user as they're programming.

Ivan: Yeah, this is something where I feel like there's a lot of unexplored territory yet. Yeah, this is something where I feel like there's a lot of unexplored territory yet.

Jack: Oh! So much. Oh! So much.

Ivan: Especially as we have new projects like Media Molecule's new game Especially as we have new projects like Media Molecule's new game Dreams that just came out, and VR in general as a kind of a, I would say, new frontier (that's kind of a tired term, but), it's a space that — because it is a new modality of interacting with the computer, of doing input and output — it's encouraging people to be very creative in how exactly they translate ideas from the mouse-keyboard-screen world to the VR goggles and controllers-in-your-hands world. I'm seeing a lot of very interesting ideas that are...

Ivan: My big hobbyhorse is making execution visible. As in whatever you're doing in any language, whether it's visual or textual, the more you can do to make the programmer participatory in the execution of their program the better, in just providing their visibility into how it executes and their ability to debug things. We see some of that with Elm's time travel debugging where you can roll backwards and forward. I feel like that's a direction that we could go much, much further. My big hobbyhorse is making execution visible. As in whatever you're doing in any language, whether it's visual or textual, the more you can do to make the programmer participatory in the execution of their program the better, in just providing their visibility into how it executes and their ability to debug things. We see some of that with Elm's time travel debugging where you can roll backwards and forward. I feel like that's a direction that we could go much, much further.

Ivan: What I'm curious about is: for the block languages, what does the future for block languages hold? I'm not necessarily asking you, I'm just putting this out there as a rhetorical kind of thing. I often wonder: to take block languages and to make them have more of the principles of graphic design and to make them leverage more human modalities and human ability, will it just be a matter of moving away from what Scratch has, where it's intended for children and it's kept very simple. But at the same time the regularity that it has is a benefit to all human beings, not just children. Would it be moving away from that for the sake of more expressivity? Or would it be something where... What I'm curious about is: for the block languages, what does the future for block languages hold? I'm not necessarily asking you, I'm just putting this out there as a rhetorical kind of thing. I often wonder: to take block languages and to make them have more of the principles of graphic design and to make them leverage more human modalities and human ability, will it just be a matter of moving away from what Scratch has, where it's intended for children and it's kept very simple. But at the same time the regularity that it has is a benefit to all human beings, not just children. Would it be moving away from that for the sake of more expressivity? Or would it be something where...

Ivan: Like in Scratch, or in a block language, or Scheme Bricks, one could imagine trying to bring animation into that, and your limitations in doing that are pretty severe, I would think, in that you're not going to be necessarily moving elements around. You might be hiding or showing elements or you might be re-coloring them or you might be lighting them up to indicate some sort of a transient state that they move through as the program executes in slow motion or whatever the debugging experience is like. I sort of wonder whether that would scale all the way up to covering the whole range of what you can do with animation and graphic design or if... Like in Scratch, or in a block language, or Scheme Bricks, one could imagine trying to bring animation into that, and your limitations in doing that are pretty severe, I would think, in that you're not going to be necessarily moving elements around. You might be hiding or showing elements or you might be re-coloring them or you might be lighting them up to indicate some sort of a transient state that they move through as the program executes in slow motion or whatever the debugging experience is like. I sort of wonder whether that would scale all the way up to covering the whole range of what you can do with animation and graphic design or if...

Ivan: My personal inclination is to always go for something that is in the direction of the nodes-and-lines, My personal inclination is to always go for something that is in the direction of the nodes-and-lines, Pure Data , Smalltalk (to a certain extent) school of visual languages. Just because at that point you are in free space. You are in force-directed graph space — spit! You are in the space of having an open canvas in which to move things.

Ivan: As soon as you have an open canvas, you have not just the structured principles of design but you also have the structureless, free, artistic end of our culture that you can bring to bear on this. Of course, going in that direction means you are sacrificing a lot of that uniformity that you said that you prefer, a lot of that consistency. Or maybe not necessarily sacrificing it but, if you're bringing in the artistic cultural side of humanity, things get very subjective. As soon as you have an open canvas, you have not just the structured principles of design but you also have the structureless, free, artistic end of our culture that you can bring to bear on this. Of course, going in that direction means you are sacrificing a lot of that uniformity that you said that you prefer, a lot of that consistency. Or maybe not necessarily sacrificing it but, if you're bringing in the artistic cultural side of humanity, things get very subjective.

Jack: I would say this is one of the cases where I'm very happy that someone else is excited about a particular direction, because it deserves the attention, but I am not the person to give it that attention. Because thus far, I've found — and it has been a fair few of them I've played with and even a couple I've constructed — node-and-box kind of programming to be more frustrating as the complexity of the thing I'm trying to express ramps up than I'm willing to tolerate. I would say this is one of the cases where I'm very happy that someone else is excited about a particular direction, because it deserves the attention, but I am not the person to give it that attention. Because thus far, I've found — and it has been a fair few of them I've played with and even a couple I've constructed — node-and-box kind of programming to be more frustrating as the complexity of the thing I'm trying to express ramps up than I'm willing to tolerate.

Ivan: Yeah, it's terrible! Yeah, it's terrible!

Jack: Yeah! So for simple things it's amazing, and then it crosses a threshold much more quickly. It's like if you drew two graphs of complexity, versus writing something in Scheme, versus doing something in boxes-and-arrows, box-and-arrow starts off easier, but it crosses Scheme's increase somewhere midway along the curve and then goes to Mars. Yeah! So for simple things it's amazing, and then it crosses a threshold much more quickly. It's like if you drew two graphs of complexity, versus writing something in Scheme, versus doing something in boxes-and-arrows, box-and-arrow starts off easier, but it crosses Scheme's increase somewhere midway along the curve and then goes to Mars.

Ivan: I don't even know I'd agree that it's easier to begin with. Everybody likes to say box-and-arrow languages, "Oh, they're easy when you're working in the small, but when you're working in the large, they're a nightmare." I think they suck when you're working in the small! I don't even know I'd agree that it's easier to begin with. Everybody likes to say box-and-arrow languages, "Oh, they're easy when you're working in the small, but when you're working in the large, they're a nightmare." I think they suck when you're working in the small!

Ivan: Everybody's pet example is arithmetic. Would you rather say, `(+ 2 2)` or would you rather type `n` and then `+`, and then type `n`, and then type `2`, and then drag a line from the `+` to the `2`? Everybody's pet example is arithmetic. Would you rather say, `(+ 2 2)` or would you rather type `n` and then `+`, and then type `n`, and then type `2`, and then drag a line from the `+` to the `2`?

Jack: Well, sure. In the arithmetic case, it would be terrible, but many of the situations in which I see people using this kind of programming is at a sufficiently high level of abstraction with the right kind of boxes, that they are actually primitives of sufficient power to make it pretty convenient for some simple things — especially for my friends who are designers or musicians who want to use Well, sure. In the arithmetic case, it would be terrible, but many of the situations in which I see people using this kind of programming is at a sufficiently high level of abstraction with the right kind of boxes, that they are actually primitives of sufficient power to make it pretty convenient for some simple things — especially for my friends who are designers or musicians who want to use Max/MSP , or want to use some visual node environment to do what they're doing.

Jack: They find it less intimidating and more clear than a page of text when they start. But when their patches grow past a certain point, even they don't want to deal with it anymore because it's just too much. I find also in the data visualization side that if you have a big directed graph, it's fun to make a picture of your big directed graph, but it is not particular communicative. They find it less intimidating and more clear than a page of text when they start. But when their patches grow past a certain point, even they don't want to deal with it anymore because it's just too much. I find also in the data visualization side that if you have a big directed graph, it's fun to make a picture of your big directed graph, but it is not particular communicative.

Jack: At some point, it turns into kind of data art and it's cool to look at, but your ability to actually reason about what it's telling you is essentially zero. It approaches zero as the number of nodes increases, right? At some point, it turns into kind ofand it's cool to look at, but your ability to actually reason about what it's telling you is essentially zero. It approaches zero as the number of nodes increases, right?

Ivan: Yeah. Yeah.

Jack: That's my fear about that whole school. But I definitely want other people who are excited about it to work on it and come up with something amazing. That's my fear about that whole school. But I definitely want other people who are excited about it to work on it and come up with something amazing.

Ivan: Yeah. The idea that you are tapping into these very powerful primitives at first, and so that offers a lot of leverage to people who are artists or musicians and not programmers — I think that's the whole reason why Max/MSP and Pure Data and Yeah. The idea that you are tapping into these very powerful primitives at first, and so that offers a lot of leverage to people who are artists or musicians and not programmers — I think that's the whole reason why Max/MSP and Pure Data and vvvv and all of them are as successful as they are.

Jack: Yeah, they're extremely batteries-included and that's very important. Yeah. Yeah, they're extremely batteries-included and that's very important. Yeah.

Ivan: To me, that seems counter to what we would actually want. As to illustrate that thought: we currently live in a world of tools that are made for beginners and pretty much exclusively for beginners. They might permit use by experts. To me, that seems counter to what we would actually want. As to illustrate that thought: we currently live in a world of tools that are made for beginners and pretty much exclusively for beginners. They might permit use by experts.

Ivan: Rich Hickey gave Rich Hickey gave this example . When you pick up a cello, your first couple of weeks or months of playing the cello, you're going to get blisters on your fingers and it's going to be awful, strangling-a-cat kind of a sound, but you move through that initial period of great adversity to get to the point where you are a masterful cellist and you can create this transcendently beautiful music.

Ivan: The computers that we have and the software that we use are for the most part they're the ukulele. That they're very easy to pick up and strum and have a good time with, but you're not going to be playing a solo in front of a symphony orchestra doing some great The computers that we have and the software that we use are for the most part they're the ukulele. That they're very easy to pick up and strum and have a good time with, but you're not going to be playing a solo in front of a symphony orchestra doing some great Shostakovich or something like that.

Ivan: That design prioritization for the novice instead of the expert... I feel like that's heightened in our programming tools especially. Because programming tools are made by programmers, and so it's the one case in computing where people are mostly allowed to scratch their own itch, where they are given the free reign to say, "Okay, For all of the other computing stuff you're building, for the operating system and the window manager and the web browser and all these sorts of things, you have to think about the person who's not a capable user of the computer." That design prioritization for the novice instead of the expert... I feel like that's heightened in our programming tools especially. Because programming tools are made by programmers, and so it's the one case in computing where people are mostly allowed to scratch their own itch, where they are given the free reign to say, "Okay, For all of the other computing stuff you're building, for the operating system and the window manager and the web browser and all these sorts of things, you have to think about the person who's not a capable user of the computer."

Ivan: But for programming tools, this is our one chance to really indulge ourselves in creating something that requires mastery. Yet we keep stumbling over that need to make things immediately adoptable by the beginner, to put in things like two-way data binding — you don't even need to worry about how data flows through your system, just say, "Point A and point B are the same, and if you change one it changes the other," and there's that magic glue between them that works great in the small and does not scale up to the large. But for programming tools, this is our one chance to really indulge ourselves in creating something that requires mastery. Yet we keep stumbling over that need to make things immediately adoptable by the beginner, to put in things like two-way data binding — you do