41 • Jack Rusher • The Aesthetics of Programming Tools
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!
Links
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.
Full Transcript
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.
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.
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:
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 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 HyperCard to annoy my sister, and I've been making silly interactive animations and games ever since.
Ivan:
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 tweet insufferably about 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 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 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 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, 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.
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.
Ivan:
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.
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.
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.
Ivan:
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.
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?
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.
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.
Ivan:
What era about were you working on that?
Jack:
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.
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 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.
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.
Ivan:
What was the name of that technology?
Jack:
The product is the Aleri Streaming Engine—
Ivan:
I was more thinking the generic term, the complex event processing—
Jack:
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?
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.
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.
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?
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.
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.
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?"
Jack:
Yeah, that's exactly it.
Ivan:
Okay. Cool.
Jack:
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.
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.
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.
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.
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.
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.
Jack:
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.
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.
Ivan:
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.
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.
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.
Jack:
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.
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?
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.
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.
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.
Ivan:
Is that faster in a performance sense or faster in just—
Jack:
In a human effort extent. Yeah.
Ivan:
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.
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.
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.
Ivan:
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 into one place."
Ivan:
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.
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?
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.
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.
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.
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.
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.
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.
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.
Ivan:
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.
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.
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.
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.
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.
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.
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.
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).
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?
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.
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.
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.
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.
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.
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 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.
Ivan:
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.
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.
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 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.
Ivan:
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 — 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.
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.
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.
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 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?
Ivan:
Yeah, something like that. Yeah.
Jack:
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.
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.
Jack:
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.
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.
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.
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.
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.
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?
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?
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.
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 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.
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.
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.
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.
Ivan:
Yeah, this is something where I feel like there's a lot of unexplored territory yet.
Jack:
Oh! So much.
Ivan:
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.
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...
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...
Ivan:
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.
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.
Ivan:
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.
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!
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`?
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 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.
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?
Ivan:
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.
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 vvvv and all of them are as successful as they are.
Jack:
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.
Ivan:
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 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."
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.
Ivan:
I wonder a lot if we've ever seen a real visual programming environment that is designed to sustain mastery rather than just cater to people who need to tap-in to batteries included power very quickly. Have you ever seen an environment like that?
Jack:
In the visual space, I think... no, although there are some that scale more gracefully than others. For example, Processing is quite approachable but you can do very sophisticated things with it. It's not a visual programming language in the sense that, say, Pure Data is, but this would be... To make something the gives you that scalability while retaining that ability to understand what you've done and not just have a massive squiggly box of things that you don't really understand how to route it anymore if you go away for two weeks. That would be a fine goal for someone building such a system.
Jack:
Winding back slightly, I would characterize the situation slightly differently with regards to everything optimized for beginners. I would say instead we have this very bimodal distribution where we have the mass of computing tools are built for absolute beginners. Then we have the unapproachable beginner-hostile tools that are almost arbitrarily configurable.
Jack:
As the ultimate example of this, I have been using Emacs for 34 years. My Emacs is an amazing thing that is tuned to my exact preferences. But when I recommend it to young programmers, they frequently fool with it for a week or two and then go back to something like VS Code or whatever. Whatever the VS Code of the week is.
Ivan:
Do you feel like it's... There are a lot of people who, I feel like, have adopted the idea that visual programming languages as a category — not just the boxes-and-line ones, but the whole category visual programming languages — are tools exclusively for beginners, and perhaps that's related to or it's caused by the fact that they have that scalability problem. I get the sense that you don't agree with that.
Jack:
Yeah. I don't think it has to be so. I don't think it must be so. Certainly, there is that perception. I absolutely agree that there is. Part of the problem I think is that expert users who have a background in a different programming paradigm get frustrated when the expressive problem starts to happen and fall back to their other tools.
Jack:
As a consequence, they never ford forward through that sort of veil of difficulty to find what's on the other side. What you need there are some very motivated expert programmers who just want to be able to use those kinds of tools and are willing to put in the effort of figuring out a way to make them pleasant past that point.
Ivan:
Yeah. What would it take for you to leave Emacs behind and to use a visual programming language primarily, as your primary means of solving programming problems?
Jack:
That's a very good question. If I knew the answer, I would probably build that system.
Ivan:
This is actually an exercise that I'm interested in working through with you, if you'll indulge me in that.
Jack:
There are some things already that I've been working on this area that we can talk about.
Ivan:
Sure.
Jack:
One of them is that three of us here in Berlin together tried to make an environment that would be good for beginner Clojure programmers called Maria.cloud. Maria, which is named after Maria Montessori, a teacher whose philosophies we found quite fetching when we were thinking about how we would approach the overall pedagogy — because it's both a programming environment and also a curriculum to get people started.
Jack:
We pirated from the best. We took the visual programming language that comes by way of both Racket and Scheme in the SICP-era and so forth, and some other things like this, so that we could get people started with shapes and colors and more interesting things than just adding things and finding the fixed point of some equation (which is fairly alienating for most students who don't have a mathematical background).
Jack:
In that environment, we have done great many things to try to make shapes and controls first class objects and be able to wire them into the code. There's a dataflow library built in so that even for beginning programmers can use a thing we call cells, which is a library patterned on spreadsheet cells.
Jack:
This allows some very nice things to be done by people with very limited programming background. We've used it to teach in a context called Clojure Bridge, which is an international organization that tries to get people started programming in Clojure, mostly women and people of unusual gender presentation who are underrepresented in our trade.
Jack:
That thing — which we've shipped and is out in the world and that we can go and use now — is actually part of a longer-term project that we are still working on, which is to try to use it ultimately as a springboard to experiment with many different kinds of program editing. Where the underlying mechanism will be some flavor of Clojure, but the overlaid representation could be almost anything.
Jack:
We're going to try to make some more visual things in the upper layer of Maria, and have multiple possibilities, multiple views onto the same code in much the same spirit as Luna.
Ivan:
Very cool. That was actually one of my questions was: why is Maria a literate editor right now? What made you start with that approach?
Jack:
The history of that project is that Matt, who did most of the actual day-to-day programming on the project-
Ivan:
That's Matt Hubert?
Jack:
Matt Hubert, yeah — available at a Twitter near you — he started talking with me about this because he was very interested in trying to do something that had the power and approachability of a spreadsheet, but where the actual programming was done with a language he liked to use.
Jack:
His first project in this series of deliverables was something just called cells, which eventually became the cells library in Maria. This was a very spreadsheet-like idea where you could make little widgets using Cl- It's actually ClojureScript code because it all runs in the browser — and wire them together and write various sorts of programs.
Jack:
Over time of experimenting with it, we found that something more like an IPython Notebook or like Mathematica where one could intersperse text was even more interesting because then you could share your thoughts with someone else but interspersed, drawings that are made by code that's embedded in the thing, including things that might fetch something from an API, and so forth and so on.
Jack:
We noticed when we were trying to help people learn Clojure that we could easily waste four or five hours just getting somebody's old funky laptop to get set up well enough to run a basic editor and have a JVM and run some Clojure. We thought, "Why don't we try to make this into an environment that beginners could actually use?" That's how we arrived at Maria.cloud. But then once we had that, we thought, "Well, it could be a lot of other things as well." It could be a springboard for all sorts of research into programming interfaces.
Ivan:
That's super cool. Yeah. I've played with Maria. The cells that underlie it, it seems like a pretty interesting dataflow model. Could you explain a little bit about how that works and what it is?
Jack:
Sure. Yeah. One of the problems with notebook systems as they are often practiced is that the data flows from top to bottom when you're writing the cells, but then when you go back and change something in a cell that's higher in the document, the change doesn't flow back through.
Jack:
What tends to happen with these kinds of documents is that over time, the state that is represented in the dependent code blocks is no longer in-sync with was has happened above them, and the whole document grows less-and-less aligned with the ground truth of what's happening in that computer program/document.
Jack:
With this dataflow environment, you have a certain data type, a cell that is like a container for another kind of data type, or a box in traditional Scheme parlance, and when one of the values in one of these boxes changes, it propagates it to any other box that refers to it. So, of course, we have a graph in the background that knows what's referring to what, and we propagate the changes down through it.
Jack:
You can see a very similar model in action in ObservableHQ which came out a little while later and used a more popular programming language, and it delighted me to see it. I would love to see every JavaScript programmer become more accustomed to using a sort of dataflow paradigm in these situations because it does simplify many things.
Ivan:
Observable, I think, is a great touchstone for people who haven't seen Maria. Though I would say for anybody who is hearing this and thinking, "Oh, I've seen literate programming before, I've played with Observable, I get the idea," one of the things that I really like about Maria is it's just pleasant to look at. I find Observable is a little bit fiddly. They've put some extra user interface around the text and it doesn't read as cleanly as I think code in Maria reads. It feels like you guys have paid extra attention to making the environment be a nice feeling space to work in, and I really appreciate that.
Jack:
That's back to the same design aesthetic that we try to bring to everything. The three of us have actually made a small consultancy now because we are in such violent agreement about both programming aesthetics and also visual aesthetics, and how approachable things ought to be, and how things should be presented to users.
Jack:
One of those things, which you've just touched on, is that user interfaces — I feel at least — should provide the least possible chrome. There should be no visible control that you don't need, and yet a way to get to everything that you do need.
Ivan:
Yup. One of the topics that keeps coming up in our programming community is that we have a lot to learn from video games. I think this is one such thing. There was a period in video games where chrome was very minimal because people's experiences with video games were... they were a new field, and so we weren't ready for the Xbox controller with 20 different face buttons here. A much, much simpler period where the main interface was maybe your mouse and the screen or before that, arrow keys. Very, very limited input, very limited output.
Ivan:
Then we hit this point where, okay, we have all the keys on the keyboard, every one of them does something. You can hold the modifier keys and hit every key on the keyboard and that's you have your very, very sophisticated spaceship simulator.
Ivan:
There was a famous Xbox game [Steel Battalion] that came with this control surface that you spread out across your lap and you had to flip open a little panel to hit the self-destruct button. In going through that exploration, as a community of game developers, we've learned that there are some experiences, some stories, or some gameplay styles that benefit tremendously from the aesthetic feeling of that complexity.
Ivan:
If you are flying a spaceship, you want there to be a thousand different controls because that's part of our culture of what it is like to fly a spaceship. That's part of what makes it compelling. Then there are other experiences — puzzle games like The Witness), or Dead Space) where you're marooned on a spaceship and it's very spooky and you're all by yourself — where putting anything on the screen breaks your suspension of disbelief. It takes you out of the experience of being in the world.
Ivan:
I feel like that's yet another lesson that programming can learn from video games is that the choice of Chrome that we surround our tools with — its anesthetic choice, it's not just a choice about functionality. I think I skew to the opposite end that you do, where in the visual environment that I'm building I am putting in as many different buttons and control surfaces as I can because the aesthetic that I gravitate towards is that of 3D modeling tools like Maya and 3D Studio Max where they have hundreds and hundreds and hundreds of different commands.
Ivan:
There is an experience you can design around that kind of an impression. It conveys, "This is a tool that you will need to invest time in learning. This is a tool that will meet that investment of time and reward it by giving you lots and lots of capability."
Ivan:
Where on the Maria end of the spectrum where there's very little chrome, it has this almost meditative quality where you're meant to disappear into the experience of reading. It's meant to feel much more relaxing and enveloping rather than something that's meant to stimulate you and charge you up and say, "Okay, there's 1000 different things to do." This is meant to be soothing. I love that about it.
Jack:
You've really hit upon the feeling there as well. When Matt wrote a paper about cells that he presented in, I think, 2016 at a conference in Rome, the opening paragraph was something to the effect of When I Sit Down At My Editor, I Feel Relaxed. For him, this is the emotional space that he wishes to inhabit when he's doing work — one of serenity. That helps to direct the user interface of Maria, definitely.
Ivan:
That was the title of his paper, wasn't it?
Jack:
It might even have been the title.
Ivan:
Yeah. The other person who you are working with is Dave Liepmann
Jack:
It is. Yeah.
Ivan:
Yeah. What's his role in this collective?
Jack:
Dave came to us from a background working on IBM big iron for a long time after he got out of school, where he studied computer science and cognitive science and some philosophy. He fell in love with Clojure some years ago, I think maybe seven years ago now. Yeah, he's a very active part of the Berlin Clojure scene and an old friend of mine, so we all got together and we work on all of these things.
Ivan:
What sort of project are you working on next or what can we can look forward to coming out of your studio? The studio is named Applied Science, is that correct?
Jack:
Yeah. The URL is appliedscience.studio. There's the grotesque plug.
Ivan:
Awesome. Just for the listener: the logo is so good. You should go and look at it. It's a very, very good logo.
Jack:
Thank you very much for that. I did everything I could to make it look like something you would see on a piece of lab equipment in the background in 2001 Space Odyssey.
Ivan:
Exactly. Yup. What are you guys working on? Is it more development for Maria? Is it that visual front end? Or is it also consulting? What are you up to?
Jack:
Well, Dave has written most of the curriculum we have now, and I think he's going to write some more curriculum for Maria. We are currently overhauling the editing experience and the underlying libraries of Maria, partially to enable us to then do the more visual programming thing.
Jack:
Right now, the interface is a little too tied to parse-on-a-keystroke sort of things. We want to move to a directly-editing-the-AST sort of a thing where we serialize it out to different representations. We're pretty close to that. It's Matt doing most of that day-to-day programming on that project and it's starting to shape up and look pretty good.
Jack:
There will be a big release in terms of code changes that makes almost no difference to the day-to-day experience of choosing Maria except having fewer bugs. Then we will start rolling out experiments with it. On the side, we have a bunch of cute little things — that I won't talk about today because they're not out yet, but they are coming in the next few weeks — that are just fun toys for people to play with, with some additional source code that they can look at and learn from. Different things you can do with Clojure, different ways you can host it in the cloud, things like that.
Ivan:
Cool. Are those unspeakable toys — are they in Maria, or is this just for people who are Clojurists?
Jack:
The next few things will be general purpose tools written in Clojure that are not constructed with Maria.
Jack:
One of the things we built when we first rolled out Maria to a class was a service where there was a publish button. You could write a sketch in Maria that was a fully functioning UI of some kind of program, select the cell that created the user interface, and say, "Okay. Publish this." We would spin up a web app somewhere that did a hosted version of whatever that document did, with a link back to the original. This is something like what Glitch does if you've seen Glitch. The idea was that there is so much incidental complexity between a new user and writing a computer program and sharing it with their friends. Many of us are internally and intrinsically motivated to play with computers. We like solving problems, we like the things they can do for us. But many other people would love to be able to do these things if they could share them with their friends, because they're very socially embedded and they want to be able to take the things that they've made and make a friend smile with something. I felt like — and we all felt like — it would be really valuable for new users to have that experience as early as possible so that they could bootstrap them into more excitement about doing this kind of work. That will likely return sometime either late this year or early next year.
Jack:
Then there is an offline experience which is a completely different thing. Not completely different; it's built on the same bones. But it will be an actual kind of environment that one can run locally and build projects with called Lark that we are building on a... lark... that will contain many of the sort of projectional editing and other sorts of features. We're all very excited about that, but it will be a little time yet until it ships.
Ivan:
Yeah. That's interesting. That's for — rather than Maria as it is right now, which seems sort of like an environment for learning and maybe exploring simple ideas — this would be something meant more for doing serious development?
Jack:
Absolutely. Yeah. The idea is that many of the things that we've done in Maria are not specifically for beginners, they're just better ways of doing the things we do. They benefit experts as much as beginners.
Jack:
There was a presentation that we did at a Clojure conference a couple of years ago in which I did a little five minute section of the presentation on Maria for experts — just discussing how much raw power is available to someone in that environment if they already are very aware of how all these things work and do already know how to program. Our idea is to take the things that are just better for everyone and then build more tools for experts — again, that scale across skill levels, so that you don't have a sharp disconnect between things for beginners and things for experts. There's an old saying in the Unix community that you should make the easy things easy and the hard things possible. That's really one of our targets here.
Ivan:
Another permutation of that idea that I'm very fond of is Apple's approach to accessibility where they say, "We will do things that make the phone more usable to people who have different levels of ability, but that all of those things that we do are not specific to that person or that need. They're things that anybody might benefit from."
Ivan:
Adding support for people who might need an assistive device because they don't have a lot of dexterity in their hand, for example. That same feature might benefit somebody who just wants a more comfortable way to use their iPhone. Or things that help people who might need reading glasses or something like that — the ability to adjust the text size, that might help somebody who just wants to be able to hold their phone further away.
Ivan:
I love that thinking of, "It's not just about enriching the beginner experience. It's that things that make something easier for beginners can be created in a way where they benefit everybody." The contrary is kind of true — where if you improve the experience for everybody in just the right way, it also makes the beginner experience better.
Jack:
That's exactly our target on everything that we're doing. We do not, in any sense, want to build a kind of padded chamber in which to lock the noobs. It's not that kind of project. What we're were trying to do is simultaneously make something that's good for new people and that pushes forward the possibilities for experts as well, just for better ways of doing the things that we all do day in and day out.
Ivan:
I met you through the Clojure community and you've talked a bit about some of the different communities that you've been a part of in your life and some of the different tools that you've worked with. Are there any language communities or programming communities or computing communities, that you're aware of, that are interesting to you, that you think people should pay more attention to? Or things from the past that you would say, "Hey, here's this paper I read and I think everybody should read it too."
Jack:
I think that there's wonderful work being done by the Pharo Smalltalk people and that everyone should be paying attention to what they're doing — especially around developer tooling. It's beautiful work. I love the Racket community.
Jack:
This isn't an entire community, but there's a specific person who's doing some wonderful work on structured editing who I want to mention here. I recently (and only recently) became aware of Fructure by Andrew Blinn. He is Disconcision on Twitter. That work is really beautiful. It's very aesthetically motivated — very beautiful editing environment — that attempts to give you the ability to edit that you would have with plain text but in a more beautiful way in a structured editor. I recommend everybody take a look at that as well.
Jack:
Another person whose work I really love is Andrew Sorensen who makes Extempore. I'm not sure how he pronounces it because I haven't heard him say it, but I read his papers and they're lovely, and the environment itself is lovely. What he's done is to create a kind of two-level Scheme language with extensions that uses LLVM to cross-compile to different hardware platforms. He's got a lower level Scheme where you have to manage your own memory and so on, but you can do all sorts of signal processing and other low level stuff in it. Then a higher level Scheme that restricts some of those things but is extremely alive as a programming environment.
Jack:
He does a lot of music with it, and he has a really great paper on something called temporal recursion, which we touch on in the Maria interface as well. If anybody watches the Maria for experts sub-talk, I gave an example of this where you can create a recursive function that recurses over an interval in time so that it develops and evolves over time. Then you can apply all of your normal operations to it.
Jack:
For instance, you can have a random number generator that produces a random number every second, and you can send that through a temporarily recursive function that builds, eventually, a bounded sequence of the last 10 values and then turns it into a bar graph or something like this. This approach is really lovely in an environment that has a good visual layer over it.
Jack:
If I'm plugging things, I always have to plug Sam Aaron who is doing fantastic work with Sonic Pi. He's a good friend of mine and he's doing amazing work and everybody should support him — monetarily — as soon as possible. Go to his Patreon and give him money because Sam is doing God's work.
Ivan:
Yup. Do you know, is he still working on Overtone at all or is that on hold just for the sake of Sonic Pi?
Jack:
He's full time Sonic Pi these days. I think a community of people have arisen who keep Overtone bouncing along.
Ivan:
Cool.
Jack:
There is one thing that I would love to see in the links. There was a French designer and hacker who wrote a really great paper about using the lessons from the grammar of graphics in the context of representing computer source code. I would love more people to see that paper because as far as I can tell — outside of his narrow discipline and computer scientists in his own country — it was not very widely read. It really, in a very short paper, covers the things we're talking about — about spacing, about contrast and so on.
Ivan:
Yeah. You shared two papers with me. One of them is a A visual perception account of programming languages: finding the natural science in the art. Then the other one, Unifying Textual and Visual: A Theoretical Account of the Visual Perception of Programming Languages.
Jack:
Excellent. Those are the very ones that I would love to send more people to those papers.
Ivan:
On the topic of papers that we love, one of my favorite papers is by Paul Fishwick who I believe knew you ...
Jack:
Yeah, who was a professor of mine. Yeah. I wrote my first ray tracer in his graphics class in probably 1991 when I was in grad school. Yeah.
Ivan:
Yeah. It's a paper called Aesthetic Programming. In it, he outlines this wild idea that you can pick any kind of visual representation you want — it doesn't have to be based on those principles of design, or of animation, or anything like that; it doesn't necessarily need to have those first principles underneath it, you can pick anything — and if there's aspects about that visual representation — and I guess this would also apply to a sonic representation or whatever kind of representation you want — if there's an aspect that you can uniquely identify, you can create a mapping between that aspect and some aspect of the lambda calculus or whatever programming model you want to be working with.
Jack:
I would say about that particular idea that it seems obviously true in the sense that — like what we get from Hofstadter for example about analogies as fundamental to human reasoning — if you can generate an understanding of a correlation between two things, then humans can reason about it using analogy very, very well.
Jack:
It seems to be one of the ways that we work, and also one of the ways that, for example, neural networks operate. When we train them, we can teach them correlations and even long range correlations between different kinds of patterns. I think this is something fundamental that probably terminates in information theory.
Jack:
If you think about information theory as a generalization of probability, or as its relationship to first order of Markov chains, and so on, it becomes pretty clear that that's really part of how we deal with perceptual information over time.
Jack:
Whether it's glyphs on a screen or whether it's sounds we're receiving, or learning how to speak a language — maybe with no resources, you know, ending up in my country where people speak different languages picking it up on the go — these are all examples of us doing that, of inferring analogies between things across domains with very little information gone. I think it's very clear that you could start from anything.
Ivan:
Yeah. Whether you should is another matter entirely. Yeah, it's just such a neat idea that it's stuck out in my head all this time.
Jack:
And will you be trying to explore things along those lines in the context of some visual programming? I'd love to see the experiments.
Ivan:
Yeah. Unfortunately — oh hell no!
Jack:
[Laughing] It's a big ask, I admit.
Ivan:
I feel like the approach that it advocates is one of: imagine any kind of depiction that you want, any kind of interface, and work from that back to the model. While I'm not a mathematician — I'm an artist — I am very amenable of the idea that you probably want to have a little bit more certainty about what your underlying model is and establish that part first, and then figure out the depiction that you want. Otherwise, you're going to end up with all sorts of red herrings and baggage from misunderstandings. It would be a lossier way of working, I feel like.
Ivan:
Not to throw it completely out of the window, I feel like it would be wonderful for the creation of art pieces — like, programming as an art practice rather than programming just as a way to raise venture capital money.
Jack:
Which is not a very interesting objective from my perspective.
Ivan:
Yeah, no, but it's the one that seems to get all the attention.
Jack:
This mention of obscure things that you learn to associate with other things in order to make art has reminded me of something that I probably would have wanted to plug before, but I definitely think you should look at, which is an audio environment for a live coding music called... I think he pronounces it Orca, although he does this design thing that I hate which is that the "A" in Orca is actually a lambda, and so I want to say it as "Orcl". The GitHub username is Hundredrabbits.
Ivan:
They're fantastic.
Jack:
Yeah. Everything that they do is great. It has such a beautiful consistent aesthetic through all the tools they make. I love the way they approach everything. Yeah, this tool strikes me as something that really does come from that place of... you just have to learn to analogize the things happening on the screen to their effects over time and you get wonderful things out of it.
Ivan:
Hundredrabbits, which is... I can't remember his last name, but.. Lu... Linvega, something like that.
Jack:
Linvega, I think, but I don't know if this is an actual name or if this is a trade... like a stage name, and I don't care.
Ivan:
Yup, exactly.
Jack:
Yeah.
Ivan:
Yeah. Him, and his partner [Rekka], I believe at one point they were living out of a boat.
Ivan:
Yes, and from the sailboat they are — sustained by funds from Patreon and wherever else — just producing absolutely wonderful tools for creating art and for writing... Not writing code necessarily, but building interesting systems that do interesting things.
Ivan:
They're two figures that I think that our community could learn a lot from. Not just because of their incredibly potent sense of aesthetics, but also their way of approaching programming as an art in itself, and as an art practice, and what that looks like. Just as a way of getting out of Silicon Valley's death grip on our field.
Ivan:
I think there's a lot that we can learn from looking at the past, the 1970s. There's a lot that we can learn from looking at other fields related to programming, like video games. But there's also a lot that we can learn by looking at people who are using programming... like, even the way they use GitHub is interesting and different from the way I use GitHub or the way most people use GitHub.
Ivan:
Their commit messages are: "*" — every commit message is an asterisk. That's an aesthetic choice. He's not going to be using `git bisect` to figure out, "Oh, yeah this is the commit where I made that change." It's something where every choice that they make about how they use the computer is a marked choice that is meant to be interesting for the people who are aware of the work that they're producing. It just leads to this... like, a very cohesive vision that I think is just fascinating.
Jack:
I absolutely agree with you. It's not just their very well developed aesthetic sense, it's also their willingness to just come at everything from a different angle than anyone else would. To be willing to do that. Because so much of what is built is just a clone of something somebody else built with no individual agency injected into the decisions from the earliest stage. To see a team of people just go and make things that really speak to their imagination is wonderful.
Ivan:
Just at a practical level... So, the people listening to this show are probably thinking, "Well, that's all fine and good, but I want to make tools that people can use to solve real problems. Like we've got the climate crisis or what have you. Well, it's all good to be having fun making very, very cool character grid synthesizers that are kind of programmable, but also kind of like an art toy, what can I take away from their work?"
Ivan:
I would say that one thing they excel at is making an immediate impression on people, and having a masterful degree of control around how somebody who's learning about their work for the first time comes to understand what it is.
Ivan:
Something I see a lot of programming tool developers struggle with is that first moment, where an audience arrives at your tool for the very first time, and they have to learn what it is that your tool does. No matter how much Material Design you clothe the webpage in, no matter how nice the rounded edges and the drop shadows behind your code samples are... I think there's a real gap between what programming tool developers think they need to say in order to sell their tools, versus how people who are encountering something for the first time need to be treated in order to really get what the tool is about.
Ivan:
I feel like these guys do it masterfully. Whether they're announcing tools by posting GIFs of them, so you see — since it's a thing for playing with — somebody playing with it. Or if it's for making music, not only are you seeing somebody making the music with it but you're hearing the music. All of their presentation, it's not a narrated video like, "This is a tool for doing X. We included these features." They make the tools really fun and playful, and then they invite you into those tools by showing you people playing with those tools and having fun. There's an immediacy to that that's missing from a lot of the stuff we do. I feel like if somebody is looking for a tangible thing to take away from them, that would be something I would look at first.
Jack:
I will say two things motivated by what you've just said. One would be that I find the culture of using Bootstrap and Material Design and so on a kind of grotesque capitulation to sameness. I don't think it's actually a good thing that people have given up on the idea of improving what they can produce visually, or in terms of interaction, in exchange for not having to think about how they're going to do any of those things.
Ivan:
Yeah.
Jack:
The second thing is — to fugue it back to something we talked about before, when you were talking about video games — I think that no discipline in computing is as good at taking a new user who knows nothing about what they're about to experience, and guiding them progressively to mastery, compared to video game introductions. They don't explain. They just drop you in the world. You begin working and you learn as you go and it gives you the right hint at the right time to become an expert in playing that game.
Ivan:
It's awesome to see when that goes awry. Video games that... you drop into them and they throw up five walls of text explaining, "First, you're going to click on this." Then explaining what that's going to do. It's like, "That builds your power meter and yadah-yadah-yadah." Then you click okay, and then another screen comes up and says, "After you've clicked your power meter thing and built up your mana yadah-yadah, then you have to go to the store." When tutorials in games go wrong, it's such a powerfully negative experience that it's a great way of showing by contrast how great video games normally are at this.
Ivan:
Totally, totally in agreement with you there. One way that I'll play devil's advocate though is that video games are very... Not only are they constrained in the domain that they span, but they also have the ability to selectively widen and narrow the domain of things you need to know about at any time. Because it's a game, they can do whatever they want.
Ivan:
The very beginning of the game, they can say, "Okay, use the left thumb stick to move forward and backward." You don't have to know that later on in the game you're going to be playing the controller like it's a bassoon with fifty different fingerings. At first, it can be very, very, very simple.
Ivan:
I wonder, do you feel like programming tools are in some way different in that they need to be unconstrained in their domain? Or is that something that we might be able to work around as an industry, and if so, how?
Jack:
One thing we have been experimenting with in the context of Maria.cloud is the idea of language levels, where a new arrival to the environment might be in a simpler language level that has more informative error messages and even factors away certain extremely error-prone parts of the language.
Jack:
An example of this would be: Clojure has a great many different arities of `map`, some of which just return a function that you can pass to a reducer later. For someone who has just arrived at the language, it's a bit confusing when, what's really happened is you've forgotten to give a sequence to your map function, but what you get back is a function you don't know what to do with that is now bound to some variable. In the lowest language level, the beginner language level, we remove that arity, and then we add it back in later as the curriculum shows them more and richer things that they might do.
Jack:
I think it is possible to do this kind of thing in the course of teaching a language or introducing someone to an environment. But as is obvious, because there are experts who will be frustrated by that, you have to be able to fast forward through the indoctrination.
Ivan:
Yeah. "Skip tutorial."
Jack:
Yeah.
Ivan:
Just to once again play devil's advocate, this sounds a little bit like it's a feature or an approach that is exclusively useful to beginners. It creates a tension against the thing we talked about earlier, about wanting to make things that are both beneficial for a beginner but also beneficial for an expert.
Ivan:
Do you feel that tension there, and is there a way of resolving that? Or is it just... you make the tutorial, and you skip the tutorial, and that's kind of as deep as it needs to go?
Jack:
Yeah, I think that's as far as we're willing to go in terms of compromising the ability of experts in an attempt to make things better for beginners. To make special paths of learning through which they can go, that offer them a different language level, for example, or other different features. But the overall programming environment should be full-power for everyone who uses it.
Ivan:
Right. Sort of like certain video games that shall remain nameless — of which I am very, very fond, and I know certain listeners of this show will also be very fond — where, from the very beginning area of the game, you can get to the end sequence if you know just what to do in just the right way, and looking in just the right spot.
Ivan:
The entire course of the game is teaching you how to see, so that when you arrive back at the beginning at the end of the game, you go, "Oh, there's this thing that I didn't even know how to see, that I can now see, that lets me get to the end sequence."
Ivan:
That idea of... Because this is an artificial environment, and because people are going to need to be taught how to live and function in this environment — whether it's a video game, or a programming tool, or what have you — you can play those sorts of tricks where you can say, "I know that since I've created something in here that people aren't going to be familiar with, they're not going to know that it exists until I show it to them. I can use that as a way of getting through that skip tutorial kind of thing without actually needing the chrome of a Skip Tutorial button. People who have been here before will know that when they hold [eg] option-shift that brings up the controls for manipulating the outer shell of my environment." That sort of thing.
Ivan:
There's definitely a lot we can do here to not feel these tensions between these different pushes that we have — using design, minimizing chrome, that sort of thing. But there are ways to find harmonies between them that I think have been... Video games have explored those kinds of things. The arts as well, there's lots — lots and lots — of exploration in the arts that I think would lead to similar kind of ideas.
Jack:
Absolutely. I agree with everything you just said.
Ivan:
I listened to some of the stuff that you've posted on SoundCloud. Do you have albums that you've put together?
Jack:
Back in the bygone days — I don't know how old of a person you are, but perhaps when you were just a child — in the 90s, I toured with many bands and recorded with a bunch of bands and have major label releases with those, but I don't own the rights to any of that music because I had this experience that everyone does in the music industry.
Jack:
I had all the experiences of playing with... I mean, pretty much any touring artist you've heard of who is extremely famous in the '90s, I played in the band that opened for... That was what my '90s experience was like when I wasn't programming computers or competing in sports.
Jack:
Yeah, all that stuff has just gone, gone, gone. But I am currently — because I'm in Berlin and it's required actually as part of the terms of my residence, that I create some electronic music — I've bought a Push 2 and a couple copy of Ableton Live. I'm currently learning how to use that which, given that my musical training — actually, I minored in classical composition when I was at school, so it was all string quartets and things and I played in the jazz orchestra and so on — it's very analog, my music history. Now, I'm trying to make friends with these tools, and I'm absolute beginner again and I'm having a wonderful time. Probably, there will be an album of new songs sometime late this year, early next year.
Ivan:
Awesome. Yeah, any other plugs just while we're wrapping up the conversation?
Jack:
That's all of the stuff at the top of my mind, I'm sad to say. Probably the moment we're done, I'll remember three or four things that are desperately deserving, but that's all I've got at the moment.
Ivan:
This is future Ivan. I'm just recording a followup. True to form, Jack sent me a couple of extra links right after we wrapped-up recording and I would be remiss to not include them.
Ivan:
One of them — Karsten Schmidt, @toxi on Twitter — he is a very, very cool programmer who works on this project called thi.ng, and he has a TypeScript project called @thi.ng/umbrella, and the original thi.ng project in Clojure is similar. They're these very, very cool, just monorepos full of resources for building computational geometry and interactive visualizations — just all sorts of wild ideas. Reading his code is like an education in itself. Jack says that Karsten has a series of blog posts discussing his take on Clojure's reducers as implemented in TypeScript that he recommends to our community.
Ivan:
The one other link that he wanted to sneak in under the wire is Nextjournal, which is Nextjournal.com. They are doing work on a multilingual online scientific notebook environment, so do go check that out as well. Now, back to your regularly scheduled programming.
Ivan:
The ultimate last question that everybody asks at the end of podcasts: where can people find you on the Internet?
Jack:
Well, I'm Jack Rusher — that is my actual name, and my username on pretty much every service you might care to find me on is my first name and my last name concatenated with no hyphen or space between. You can find me on Twitter. If you like pictures of beautiful nature and my digital art pieces, you can find me on Instagram. I have a website, jackrusher.com.
Ivan:
Awesome. Well, Jack, thank you so much for taking the time to talk to me and to share your perspective into this field that we're all fighting against and fighting for. I really appreciate it.
Jack:
It's been a real pleasure speaking with you and I hope that we meet someday.
Ivan:
Yeah. That would be great.
Ivan:
That brings us to the end of the show. I hope you enjoyed it. You can find a whole bunch of other episodes of the podcast at futureofcoding.org. There are also links to the Slack group where a bunch of us in the programming tools and programming languages community get together, and talk about our projects, and talk about our big dreams for what the future of computing might look like.
Ivan:
If you really like the podcast and you want to support it: leave a review. Go to iTunes and just say what you think, that really helps people discover the show; tweet about it; you know the deal. Another way you can support the show and the community is to back Steve on Patreon. He does a ton of legwork to organize meet-ups, to promote people in the community to his audience, and to help everyone learn from everyone else. It's a tremendous service and anything you can do to help out Steve helps out all of us.
Ivan:
If you want to get in touch with me, I am on Twitter — @spiralganglion (which is the nerve that connects the ear to the brain). You can of course find the show at futureofcoding.org. Thanks to Jack Rusher for coming on the show, and I'll see you in the future!