44 • Devine Lu Linvega • Making Your Own Tools

2020-02-03

Listen in your podcast player by searching for Future of Coding, or via Apple Podcasts | Overcast | RSS

We live in a world that is gradually becoming more closed off, more controlled, more regional. Our relationship with technology is now primarily one of consumption, buying new hardware on a regular cycle, using software conceptualized to meet a market need and fulfill promises made to venture capitalists. It’s common to hear people talk about both computing hardware and software as though they were appliances, not meant to be user-serviced, not meant to be modified. The tools we use are being designed for the 80% who live in a city, use grid electricity, want to keep up with the industry, and have an unacknowledged learned helplessness about the limitations of their tools.

Devine Lu Linvega and his partner Rekka live on a sailboat. He makes art, music, software, and other cultural artifacts. When Photoshop’s DRM required that he maintain a connection to the internet, he wrote his own creative suite. When his MacBook died in the middle of the ocean, he switched to Linux with hardware he could service. His electricity comes from solar panels, and every joule counts — so that’s out with Chrome and Electron and in with Scheme, C, assembly, and maybe someday Forth.

I wanted to interview Devine with a main focus on just one of the dozens of tools he’s created over the past few years — Orca, a spatial programming environment for generating synchronized realtime events. It’s ostensibly a tool for music, but has been applied to all sorts of other disciplines in wildly creative ways. Devine and I ended up talking for over three hours, and after editing out everything superfluous there was still too much matter for just one episode. So we’re going to take this in two pieces. Today, you’ll hear the bits of our conversation that covered everything other than Orca — Devine’s philosophy, the stories of his other tools, the ways in which boat life have forced certain technology choices on him. On the next episode we’ll have the rest — a deep dive into Orca, covering the thinking and story behind the design of the tool, the community that has picked it up and run with it in all sorts of wild directions, and lots of little nooks and crannies in the space around this fascinating project.

My hope is that the topics discussed today will let you see from Devine’s perspective, so that when we look at Orca in detail you can appreciate exactly why it is the way it is, and take away valuable lessons for your own projects.

Given that his most recent explorations have been making art and programming tools that run on the NES, the best quote of the show has to be: “I never want to have a stronger computer than the one I have today.”

Links

Devine Lu Linvega is our guest. He and his partner Rekka funnel their lives and creativity into Hundred Rabbits. Devine has created countless tools, but Orca, Ronin, Left, Dotgrid, the 1-bit drawing tool Noodle and it’s 3D scene layout tool Poodle are particularly fascinating. His website is like a wiki, a clock and calendar, and an alternate universe.

Devine released a series of beautiful illustrations for Inktober, and while the time tracking / recommendation tool is currently offline, here’s a tweet where you can see the effect Inktober had on it.

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

The motion-to-photon input latency of various computers has not meaningfully improved since the 80s.

Folks interested in energy-efficient spatial programming should watch this Strange Loop talk by Chuck Moore about the Forth programming language.

Potentially similar projects include Inferno and ChrysaLisp.

The resilient, living systems of Dave Ackley are also fascinating.

Finally, the Future of Coding community is running a survey of our audience, and it’d be awesome if you took a few minutes to fill it out.

Full Transcript

Transcript sponsored by Repl.it

Corrections to this transcript are much appreciated!

Ivan:

Welcome to the Future of Coding. I'm Ivan Reese.

Ivan:

We've been on hiatus for the last half year, and I'm pleased to announce that the podcast is back. I've spent the last two months planning, recording, and editing a slate of new interviews, and I'm very excited to share them with you.

Ivan:

That's the good news. But you might be wondering why you're hearing from me and not your regular host, Steve Krouse. Well, that's the bad news. Steve decided to step back from his role as chief podcaster and organizer of our community, and he appointed me as his successor. I'm sad to see him go, humbled that he asked me take over, and hopeful that you'll stick with me as I find my footing.

Ivan:

The backbone of the show is the guests, with interviews that dig deep into their thought processes, how they see the world, and how that manifests in their work. I want to continue the tradition of highly technical discussions about computer science and toolmaking, and broad exploration of things people do with these tools, whether that's science, the arts, or education. I also want to create a new space for some of the people in our Future of Coding community to share what they're working on, and you'll hear more about that a little later this spring.

Ivan:

One area where I will be investing a lot of effort is the production values, like the audio quality, the show notes, transcript, and the sonic identity of the podcast. You'll notice a new sound at the beginning of episodes, which I'm calling the "startup chime". I think it's a fun way to aurally invite you to the episode. It also opens up the possibility space a bit allowing other sounds than just the voice to be a part of the show, and you'll see what I mean by that in the next episode.

Ivan:

My goal is to release at least one new episode every month, or more if time and my life allow it.

Ivan:

Now, on with the show.

Ivan:

IR: My guest today is Devine Lu Linvega, an artist, musician, and programmer from... well, everywhere. Devine has spent much of the past few years living on a sailboat, and as you'll see in the interview, this gives him a very unusual perspective on software that feels both decades behind and decades ahead of our contemporary practice.

Ivan:

My conversation with Devine lasted more than three hours, so I've decided to split the interview into two pieces. Today, you'll hear about the large ecosystem of tools Devine has created — how they're a reflection of his personal values, how he decides when to build a new tool, and how these custom tools let him make very unique art, music, websites, and more.

Ivan:

On the next episode, we'll do a deep dive into just one tool — Orca, a wildly unique visual programming environment that is ostensibly a tool for music, but has also been used for things like procedural animation and robotics, with an aesthetic that feels like a video game from an alternate history where the Macintosh was never created and DOS terminals ruled the Earth. Devine and I talk about the history of the project, picking apart a number of nuanced design decisions along the way. We also hear how Devine found a user community that embraced Orca and pushed it in all sorts of new directions, how he landed a massive breaking change to the syntax of the language, and of course lots of technical details about how the system works.

Ivan:

To start the discussion, I asked Devine to explain how his work relates to his view of the world, and he responded that it's all about context.

Devine:

Throughout our conversation, you'll realize that while all these little projects that I'm working on seem like different things, they're really not that different. The connecting thread that you'll find in one, and the other — it's what I usually call **context**. I spend quite a lot of time just building tools that would allow me to share context.

Devine:

In most cases, the work that other people do, if they dedicated a tiny bit of time to share the context that would make the things more understandable and exist as part of something bigger. I hate consuming things as separate little planets. What I like is to get a better sense of the whole ecosystem of someone's reflection. Your favourite musician, you listen to their music and you're like, "Wow. What kind of person could be behind this?" Even if the artist didn't decide to be truthful about who they are and what they do, even building some sort of narrative around their work, I find is a way that communicates some context that makes the work more enjoyable, and also long-lasting.

Devine:

We're people who think in stories. Especially today with Twitter and Facebook and all these things that just try to take the context away from people's own personal websites to their own silos. It's harder and harder to appreciate the full picture of the work.

Ivan:

I'm glad that you mentioned people having their own websites, because your website is fascinating. As opposed to a lot of people who are doing work on the internet — where these days, for programmers, the norm seems to be that you have a Github Pages website that has a couple of pages on it, or a blog, or something like that — your website is more like a wiki, but a wiki that only you get to edit, which is a really interesting feeling for being invited to explore somebody's work. It's something that I'd love to see more of, where... like you're saying, context. Each of your projects is presented as: here's what this is, here's why I made it, and links to other projects that are used by this project or vice versa. You try to make the connective tissue between your work really visible.

Ivan:

One of the things that you've made is your own system for... umm... uhh.. like... how do you say this [embarrassed] — your own encoding of time? Like, your own calendar and your own clock and that sort of thing.

Devine:

[laughs] I was like, "I know where this is going." Yeah.

Ivan:

[laughs]

Devine:

I think a lot of people see them and they're like, "Oh, this is too complicated," you know? Like, your mind just kind of erases them. But it's actually pretty clever. It's not a system I made up, first of all. It's a system I found. I was like, "Wow, somebody made this thing that is just brilliant." I think it's maybe 400 years old.

Devine:

So I have two systems — a time system, and a date system. The date system is the alphanumeric thing. It breaks down the year in 26 months of 14 days. So what you end up with is that you have from A to Z, and every letter of the alphabet is a month, and you have 14 days.

Devine:

I just found that it was the best Scrum period. You can start a project, prototype it. In two weeks you have a working copy and at the end of the letter you can decide, well, is it still worth bringing on to the next month? You can expect these months to be just the same amount of days. It's a good way to do work, basically.

Ivan:

That makes a lot of sense. I wouldn't have thought that it had that practical merit to it. Here I am thinking, if I were going to adopt a system like that, it would be purely for the aesthetic reasons. It has a very different feeling from the Gregorian calendar.

Devine:

Yeah, that's usually not a good approach. The aesthetics of it can take you in but you have to find a reason that would make sense in your workflow. For me, counting on my knuckles for the number of days in a month, I didn't find that super practical, and I'm not super tied to the lunar phases. I was like, maybe something more predictable would be neat. Especially in the kind of work that I do. Weekends are not any different that weekdays. I just found that was a really elegant system to work with.

Devine:

For time, I think it's called Swatch Time or something. There's a company, they make watches...

Ivan:

Yeah, Swatch.

Devine:

Swatch made a time system that is decimal. It's very simple. Noon is 500. 999 is midnight. It gives you a tiny bit more granularity during your day. Working with this, I found it was really nice. I usually work with Pomodoro Systems, and I have pomodoros of 30 "beats" (which is the Swatch time). I preferred 30 beats over 25 minutes. It's easier to break down in shorter periods, but that's just a personal preference.

Ivan:

From the way you've described both the date system and the time system, you've emphasized that it helps you organize your rhythm of work. How serious are you about organizing the time that you spend working? Is it something where if you don't have those sorts of structures you feel a bit rudderless? (To make a terrible pun.)

Devine:

Was that a boat pun?

Ivan:

Yes.. Yes. Or is it the sort of thing where you find it adds cohesion? What is it for you that draws you to those sorts of ways of organizing your time?

Devine:

Well, it's multiple things. One this is that I'm terrible with time. During these past four years I made, let's say, one or two games. If you asked me, "How much time did you spend working on those games?" I would just make up a number that sounds like it would make sense. But I actually have the data. So usually when I look at the data (after just spitting out a random number) I realized that I have no sense of time. My understanding of how long something takes is terrible. Also, even how enjoyable something is. I have a way of tracking that gives me an idea of how focussed I was doing something. That's kind of correlating a bit with how invested I was with doing that thing at the time. Sometimes I'm like, "Oh, that project, I had a blast, it was great, and I was really into it." Then I realized that, actually, I had other projects that were way more appealing at the time, in which I was way more invested. Keeping track of these little things, understanding that I am terrible at remembering how much time things took, and how much I appreciate doing these things. Now at least I have some data I can rely on. If anything, I can use that to plan. So if I want to start something new, I'm like, "Well, there's no way I can do this in 200 hours, because last time it took 400." I might have a sense that it's doable, but the data that I have clearly says that that's impossible.

Ivan:

Do you feel like the data you're collecting is helping you make more accurate predictions about how you're going to work, and how you're going to feel?

Devine:

No.

Ivan:

Interesting! It sounds like it's enjoyable to have that data, because it helps you reflect. It would be interesting to look back on a project that you'd worked on and think, "Right now, I feel like that project was a blast and it was wonderful," and then you look at the data and go, "Oh, but I actually felt terrible while I was working on it." I could see that being interesting. But it doesn't help you look at a new project and say, "I think I'm gonna feel good about doing this one?"

Devine:

Not really. That's the whole thing about tracking. I think it might help in subtle ways. It definitely has worth that I can't really explain, and its worth is definitely not that it helps me not make mistakes. The whole quantifiable self, and that kind of way of doing things, I do rigorously every day. But I know that it doesn't really work that well. For instance, these kind of systems are really bad at looking ahead.

Devine:

Let's say you discovered 16 new music albums, and you watched 13 movies, and you read 3 books — and a book correlates in like 16 hours of output, and a movie, like 7, and a video game, like 12. Well, the thing is that the systems always look backward. I made tools that would make predictions, but the only thing that it can tell me is that...

Devine:

It can look back really well, but it has a really hard time figuring out where I'm going and what I should be doing. Which is fair. Basically, the way I did it is like: these past few weeks, I have a sort-of trend in my productivity, and I can decide to do the thing that the system thinks would bring me back to my average productivity in a specific sector. So let's say I usually have 16 hours of music per week. Well, if I'm under this more than under the amount of hours I do in the visual sector, then it will say, "Tomorrow if you're doing audio, by your average productivity and the way you do output, it would be your most productive sector / domain of work." I can decide to follow it, and that would reinforce that pattern — and I can choose to not follow it, and create new patterns. The statistics from following or not following are not so far from fifty percent. So it's not that much better than just doing whatever the hell I want.

Ivan:

Just to get clear on this — you're also tracking whether you follow the predictions that your tool is giving you based on the data of what you've done in the past.

Devine:

Yes.

Ivan:

That's amazing. That's very cool. It's neat to hear that it's 50-50.

Devine:

Yeah. I look at others' tracking systems, and I'm always looking at ways I might have overlooked something. But yeah. We're fluid creatures. Like, the Inktober...

Ivan:

Inktober is an annual event that happens in October, where people create a new work of art every day and post it to social media.

Devine:

I decided to do Inktober this year, and that just *breaks* all patterns. Like, I'm going to pay for this for the next few months. I decided that I would invest four hours a day for a whole month... well, like, for two... ahhh... for four weeks, I would do this one sector — even though the system would increasingly shout louder in my ear that I should do something else. I went through this, but what's going to happen is it's going to create a precedent that just raised the number of hours that I can physically invest in visual arts.

Devine:

But that was totally enjoyable. I don't feel bad at all having broken that pattern. That kind of served as an experiment that I might be able to use in the future, anyways. But there was no way that the system would have predicted that I would have done that, and not having done this, I think, might have been more costly in my general output.

Devine:

There's no way of knowing where you're going or why you're doing anything. So you might as well just.. whatever. You can have a look and make a decision and play along, or just follow your own intuition. But for Inktober, I feel like I made the right choice of not listening to my system.

Ivan:

This is interesting to me because it gives me another way to look at your work. You make a lot of tools. Those tools are all very small, and very focussed, and they interact with one another in interesting ways. It sort of feels like these tools are collaborators of yours. Hearing you talk about your relationship with the way you're tracking your use of your time, building tools to make predicitions for it that tell you how you should spend your time. To me that sounds a little bit like you're creating, like, another agent that you're collaborating with. That agent is very rudimentary, and it's based on an echo what you've done in the past. But it's still fulfilling some of the roles that you would get from, say...

Ivan:

You know, if you're in a band, your bandmates are going to impose similar constraints on how you should spend your time. They might say, "We have a gig coming up in a week and our set is terrible. We need to book a lot more time rehearsing over the next week." Or somebody might say, "I'm going away to live in South America now," true story, "So we're not going to play that show in a week." Those sorts of external forces imposing on what you're able to do in your creative process feels similar to this. Is that how you relate to it? Is that what it feels like for you? Or is it something else.

Devine:

Well, the wiki is a complete different tool than every other tool that I've made. But that one tool is kind of like a project manager, like what you're describing. It's like, "Oh yeah? Uh huh. You think you can do this in 200 hours? Well you have no antecedent of being able to do that in this amount of hours, so why would you even..." In this, it has a sort of prescriptive... reminder. The other tools I make, usually I don't see them as collaborators. They're just like tools. They're to get me to some place with the least amount of friction imaginable.

Ivan:

You don't relate to them in a way that sort of... Earlier in our conversation when I said the reason I would adopt an alternative system for dates and times would first of all be about the aesthetics of it, you sort of scoffed at that. Is it that you don't really like imprinting agency, or imprinting a humanity, on inanimate things?

Devine:

Oh no! I absolutely love anthropomorphizing things. Especially the ecosystem that we created as Hundred Rabbits, we've given little character faces to all the apps that we've made, and that just reinforced the personality that the software might have. When I look at Ronin, I see the character that's kind of a bit dreamy and lost, like a hazy little creature. But Orca is more like a trickster, like a sharper kind of thing. But my website, I don't have this sort of attachment to it. It's more... I guess... I'm part of it, and it of me. It doesn't feel like an external force. It's more like a mirror. Maybe the mirror in Snow White.

Ivan:

I do my own sorts of time tracking, just for tracking my hours for my job. When I look at how I've spent my time it feels a little like looking in a compost bucket. These are all the remnants of the things that I've been eating over the last day or two. What does it feel like to have that relationship with the computer where it's telling you what to do, because you told it to tell you what to do, but at the same time you have to look at that and say, "No."

Ivan:

You said, when doing Inktober, that you were going to pay for this over the next couple months. What does that mean? Where does that come from? Why would you think you're going to *pay for this*. That sounds punitive. Where's that feeling of punishment coming from?

Devine:

Alright, so for audio for instance, let's say... Well, you write music as well I think, so...

Ivan:

Mhmm.

Devine:

For me, the best music I get is from holding off making music. The best music I've written, I've written after not making music for as long as I could. If I gave in every single day to writing music, I would have a poorer general output compared to if I have an idea but I just let it ferment in my head for as long as I could. Then when I just feel like I'm ready to burst, I actually do it. I've found the most focussed, productive periods that I had, especially for music — because this sector for me is kind of unique in that sense — has been after holding off for as long as I could.

Devine:

Visual, like for the Inktober, I usually draw a little a few times a year, and that is it. My impression of visual arts is that you don't really explicitly need to be doing it every single day to get better. I might not draw for two months, but the next time, two months later, I draw, surprisingly, I feel like I have improved. It could be from my eye having gotten worse, and my appreciation of things gotten more accessible, but no. After a while, I feel like there definitely was an improvement, but I feel like it came from other sources than actual direct drawing. If I start to cheat these patterns that I have, like if I just decided, _you know, let's forget that I need to hold off writing music to get good work out, and I'll just spend an hour making music every single day_, which I tried, it took me a while to be able to write music of a good enough quality again. For Inktober, my fear is that this would extinguish the already small flame that I have, that makes me draw in the first place, by just draining it dry.

Ivan:

I feel exactly the same way about the music that I make, and also the programming that I do. When I need to do programming that is not just bugs that need to be fixed or features that need to be implemented, but difficult design work that needs to be done, or abstractions are not what they should be and I need to come up with a unifying concept, that kind of work is very similar to how I feel about making music. Which is exactly what you've described. There's only so much of a flame that I have for it. It's very easy to extinguish that and it takes a while to rekindle.

Ivan:

Do you also feel that about your programming? Or is the way you relate to programming different yet again?

Devine:

Yeah the relate to programming is different. I can do endless maintenance. So I use that. Actually, I found a good way to hack music writing... actually, a good way of hacking anything is... I noticed that I have endless patience for maintenance. So the more I can offload into the maintenance sphere, the more I can sneak in a bit of music, a bit of visual arts into my things. That's a fancy way of saying, somehow, automating boring things is actually more efficient. Like, I don't think I would have been able to get through Inktober by sheer investment of time in drawing. After five days I was already done. I was like, "That's it. There's no way I'm going to be able to keep moving forward with drawing." I had to offload a bit of the visual tasks into the maintenance thing. What I started to do is, I made a tiny tool to do Inktober. It was just a drawing tool — and you don't need much for a drawing tool. It was just, like, a hundred lines of code. But every single day when I went to bed, I thought about my illustration and a technique that I would want to use. What I did is usually I would make a tool designed specifically for that technique, so I could draw that picture. Just shifting the mindset from maintenance to drawing, back and forth, allowed me to survive throughout the month. Because otherwise, just drawing, I would have run out of juice from the beginning.

Devine:

That's something I've been kind of testing with recently. Orca was a good way of hacking back into music. So what happened a few years ago is that I completely extinguished the flame that I had for audio. There was a subsequent show that I was playing, and then I stared to write more music than I could afford, and what happened is that I just ran out of ideas. When that I happened, I thought maybe I'll never be able to write music again. But Orca was a way of gradually rekindling that flame by, like, sneaking audio tasks via programming. I would create little programs that would inspire music, that would inspire the audio mindset, and gradually that came back. Orca basically revived the flame that I have for sound and music — just by hacking, tapping into the maintenance / low-hanging fruit programming things that I had in mind.

Ivan:

I think I get the feeling that you're describing, and the drive that you're describing, but I would use the word "maintenance." I want to drill in slightly to see if we're feeling the same thing.

Devine:

You know the time tracking system I have? It has three numbers. Every single day, for output, I track using three numbers. A little code like 3/4/5, or 1/2/7. The first number is the **sector** — like audio, visual, programming. The second number is the vector of **extroversion / introversion** of the task. So _showing_ something would be an extroverted task, and watching something an introverted task.

Devine:

When I say "maintenance" it's basically a shorthand that I use for saying something is introverted. Something that doesn't really change. If we looked at that vector from +10 to -10, when it's near 0 you get these tasks that don't really move the project forward. I'm very comfortable in this space. I can spend a countless amount of time doing tasks that are basically just maintenance. Just improving, reflecting on how the thing was built, or even generally building tools instead of building an actual game. It's like the easiest way of procrastination. You could directly attack a problem, or you could spend an endless amount of time making an engine for getting the thing. So in the sense of getting an end product that is a game, making an engine is a super introverted task, because this is not going to be front-facing. I could do that forever. I could act in that space forever. So when I'm out of juice — out of direct-action juice — I just try to exist in that space and be productive in this sort of maintenance stuff. Usually it's good for kickstarting a new project, or getting myself back into a state where I can finish projects.

Ivan:

Are there kinds of programming that you have to do that don't feel like maintenance, and if so what kinds of programming are that?

Devine:

I find game design, level design, animation — like asset animation in a game. This sort of programming I find is very direct. You tell the computer what you want, and how to do it. I find it's very extroverted. I have a hard time tackling these sorts of tasks repeatedly. The kind of programming I hate the most is animating assets. I have a really hard time putting days of that sort of programming one after the other. But I can do an endless amount of tasks of... re-linting my code, and adding comments, you know?

Ivan:

Yeah — fixing up names, reorganizing things.

Devine:

Exactly, yeah.

Ivan:

You say animating, and other asset creation — is that something you're doing by writing code? Like writing new systems? Or is it where you're using the tools you've built to create the data for those animations?

Devine:

Well, in an ideal world I would already have libraries that I made to do this, but I haven't really... I'm fairly new to... well, I guess I'll be fairly new to programming forever. Even though I've been doing that for years, I feel like I'm only starting to grasp the basics of how I can be efficient with programming. Recently I've been compartmentalizing a lot of the things that I do repeatedly. It hasn't really reached that kind of stuff yet. I still do all the animation by hand, for moving assets around. That kills me. Right now I'm refactoring two games that I want to release, and this really... this is the last time I'm doing this. This is the last time I'm doing this by hand.

Ivan:

That means, then, you now have the impulse to make better tools, so that you don't have to do as much of it by hand the next time you're doing this?

Devine:

Yeah. I didn't really understand the problem at first, so I could not have done it sooner. I am usually ten years behind common practices. So.. I guess I would be, like, 2009. I don't know where JavaScript was at the time, but that's pretty much where I'm at now.

Ivan:

Yeah. You have good company there in me, because I've looked at what JavaScript has done over the past decade and said, "No thanks."

Devine:

Classes? Really?

Ivan:

Yeah.

Devine:

My code still looks like... It hasn't really changed much, I guess.

Ivan:

Can you name all of the software tools that you've made, and give a 10-second description of what they do.

Devine:

So, the _ecosystem_ (which is how I call it) that we create at Hundred Rabbits, is basically...

Devine:

One called Left, which is the tool that we use to write. It's a very simple writing tool. Imagine Word, but with autocompletion. Maybe Word does it now, but.. we wanted something that was cross-platform, that worked on Chrome OS. We live on a boat, and we don't have that much power, and one of the devices that we use for writing is a Chromebook which... [sigh]... only has Chrome. So we have to work in the browser. But it has some interesting autocompletion things. It's the thing that we use for long-form writing, usually.

Ivan:

How does it derive the autocompletions? Where do they come from?

Devine:

It builds a dictionary from everything that you write. So over time it has a good idea of what you're trying to write.

Ivan:

So it's that classic: using a database to do a perfectly good job of things that everybody's trying to do with machine learning nowadays.

Devine:

Oh my god, don't get me started on that.

Ivan:

Yeah. [laughing]

Devine:

But yes. All the programs that we make are very, very simple, so this one is the simplest.

Devine:

Dotgrid is the thing that we use to make vectors. We do a lot of typography, or iconography. I'm not a super fan of GIMP and Inkscape.

Ivan:

No, me neither.

Devine:

You know, sometimes you just want to have a frigging... circle with a cross in the middle, and then you're fighting with, like, 0.005 decimals on Inkscape. I just want something simple I can use to make SVG files, or something I can laser cut, or whatever. So I just made a program. It's, you know, almost a single file. It's a very simple thing. It works in the browser.

Ivan:

Yeah. Anybody out there, if you need to make a logo for your project, go use Dotgrid. It's very cool for that.

Devine:

Super simple. All keyboard-operated. Well, actually — with Dotgrid, I created all the iconography for Orca.

Devine:

The other one is Ronin, which is what I use for doing batch resizing. It does a whole bunch of stuff now, but the idea was that, you know, you take a whole bunch of pictures and you want to resize all the pictures to half their size and export them to JPG with a new name. There's all sorts of ways of doing this with the terminal, which I find super complicated. I just wanted a simple way of scripting this sort of actions in Lisp, and just getting the result. I made a sort of like... a little engine to do that... a little interpreter, a little library. You can do all sorts of photo manipulation and export files. But people added a whole bunch of functions to do Processing type things. So now it's basically like canvas using Lisp in the browser that can do all the processing things that are visual — also, even, like audio related now. It's becoming a bit of a monster, so I'm going to have to take the axe out.

Ivan:

So for Ronin — just to go a little bit further on that one, because that one's another really interesting one — it's a two-pane window, and on the left side there's a text editor. It works just like a Lisp REPL that, you know, you've all see a thousand times. You type in your Lisp code and then invoke it, and it does something on the right pane, which is your graphical preview.

Devine:

Imagine Photoshop with Emacs on the left side.

Ivan:

There are all sorts of nice things you can put in. There's a little special syntax you can enter that says: replace this spot with whatever position the mouse is in. So you can use that to — in a DIY sort of way — build a drawing tool right there in the program.

Devine:

Yep.

Ivan:

There are people using it to do animations, and there's people who have written strange attractors that rotate around.

Devine:

Yes, it's just so simple, but I wanted that in my life and I couldn't find it.

Ivan:

You also have tons, and tons, and tons, and tons of little things that you've built. I think my recent favourite was, for Inktober you made a 1-bit drawing tool.

Devine:

Yeah. I had just transitioned to Linux from OS X. I hadn't been using Photoshop in a while, because when you're sailing and you don't have access to the internet, when your drawing tool and resizing tool breaks because you don't have internet access... [long sigh]... that becomes kind of a problem. So we decided to ditch all DRM bullshit.

Devine:

But then I was like... I have to draw. I just want to draw something really simple. So I was looking up online, you know, something that is web-based that just lets me draw. Something kind of like Paint basically, because I didn't really need much more. But I really wanted halftone. So that's where I started. I was like, well... I don't want colours, but I do want different weights of halftone. There wasn't really much out there. I'm not super comfortable with OpenGL or SDL, and I was like... I know canvas so I'm just going to build it in canvas. I was afraid that it would take a lot of memory. You know? Like sometimes, web tools, like, "Ugh it's going to kill my battery," whatever. But the way I implemented it, it turns out, it takes less power than using GIMP. So that was a win. So I did my whole month using this little tool that I made that is a single file. I think it's like 180 lines of code.

Ivan:

Just to help people picture it: the aesthetic of the images it creates is very similar to what you'd get using something like MacPaint on an old black and white Macintosh from the 80s.

Devine:

Yes!

Ivan:

It's a white canvas, and your only operations are: to turn individual pixels black, there's no antialiasing, there are tools for drawing straight lines, there's an eraser, and then there's a tool for putting in just individual black pixels.

Devine:

What else do you need!

Ivan:

Well! But then, the thing that I love is, you built that tool and you started doing some drawings with it, and then you thought, "You know what I need? I need to build a little 3D engine for laying out the scene of the thing I'm going to draw."

Devine:

[laughs]

Ivan:

So, on the one hand it's this throwback to the black and white 80s drawing applications of yore, but on the other hand it's like, "I'm going to make a 3D engine." When I saw that I almost fell out of my chair. It's such a beautiful synthesis of simplicity, that takes you back to some of the roots of computing, but at the same time you have everything that's happened since the 80s to draw on. So you know when something like a 3D engine is the right tool for the job. By this point, it's not hard to make something like that.

Devine:

Yeah, how lucky are we can we can do this. While I was working on this, everyday I was surprised. How is this possible that I can... like, in the morning, I really want to do _X_, and you can actually do it. Like, if you live on OS X and Windows your whole life, you miss this whole way of doing computing where actually building the specific thing that will get the job done with absolutely no friction is not that far out of reach. I lived outside of this sphere for the longest time, but now if anything gives me any kind of friction I know I can turn and just rebuild it. There's a massive amount of really clever people who address these problems before. You can draw on this and pick-and-choose the parts that you want, and actually begin to experience modular computing.

Ivan:

Not to derail it, but I think that's where the people who are the staunchest critics of JavaScript are missing the bigger picture. A lot of these tools you build, you build them in JavaScript to run in the browser. What you get in exchange for doing that is... sure you have to use JavaScript which is, you know.. it has some storied history, and it's not the most elegant language by a long stretch, but... you get the whole web platform. You get canvas, you get CSS (if you need that), you have WebGL, you have WebAudio, WebMIDI, WebVR. Those standard are created to be portable. The browser vendors are pulling just _insane_ levels of optimization just to make sure that you can write all sorts of malformed, badly organized code and have it not destroy the battery on the computer of everybody who's running it. So with a little bit of know-how you can build yourself exactly the tool you want using this web platform. It's such a tremendously powerful point of leverage. If you turn your nose up at JavaScript, you are also missing out on that leverage.

Devine:

Yes. I think JavaScript is the perfect way to invite you in that sort of place where you can feel empowered by the tools. On the other hand... I mean, I absolutely love JavaScript, and I am on the side of the people who... I mean, I find the language is beautiful. What you can do with it is great. Sure, people will always raise the Wat video and be like, "Oh, how can you work with things like this?" This doesn't apply to my everyday life. Like these edge cases, you have to actively look for them, especially in my case since I build really simple things.

Ivan:

Or you can use a transpiler. If you need types, use PureScript, use TypeScript, something like that.

Devine:

Yeah, but all of this is something I'm trying to phase out of my... I have no problem with JavaScript as a language, and I wish it was easier to spin outside of the browser ecosystems.

Ivan:

Yeah.

Devine:

I have friends that work at Google on the canvas implementation. When you go there you realize that my ease of being able to tap into all these sort of technologies to make these tools really quickly relies on incredibly powerful machines that I don't have access to. I'm basically at the mercy of Google for anything WebMIDI — and Firefox, and these handful of browsers — to create the things that I do now, which is something I don't really like. Building Chrome is a massive thing. I don't have the hardware here to do this, and in the future I'm hoping to...

Devine:

Actually, one of the things that I'm really thinking about these days is: I never want to have a stronger computer than the one I have today. There's no reason I shouldn't be able to do what I want with the things that I have today. Walking that treadmill of thinking that I need a stronger computer to do more things... I think computing capped in the 80s. Nothing really improved. For me right now, for the few basic things that I need computers for, I don't see why I should want to keep getting more processing power. So what I want to do now is gradually learn how to go a little bit deeper and build the things on a smaller stack of technologies. One of my big hobbies right now is — how can I make everything run on Scheme, or run on vanilla C. Yeah, just kind of get away from this thing that invited me in, and that taught me about programming a little bit, and that taught me about how I can feel empowered by computers. But now I also want to be independent from a lot of the things that I find are destroying the environment right now. The treadmill of disposable electronics. I would love to be able to just keep on using disused or secondhand computers, and just keep on doing the things I like to do with them, without having to constantly keep up with the updates of Chrome, and so on.

Ivan:

I feel that in a big way, especially — you said that you feel like computing sort of capped in the 80s, and my go-to example of that is a measure of latency called motion-to-photon. If you push a key on your keyboard, how long does it take for photons to be emitted from your display? That's something that in some cases has improved since the 80s, but in a lot of cases has regressed. It's the sort of thing where the industry has made choices that prioritize things other than latency. The motion-to-photon latency in most computing systems is at the point where it is slower than the threshold that you need in order to deal with things in a musical way. So for instance, the granularity of music is at, like, 10ms... 15ms... 20ms, somewhere in there. If you are more than that amount of time out of sync, you will hear the difference. The motion-to-photon on most computers is like 30ms... 40ms... 50, 60. One area that we could have spent the benefits of Moore's Law would have been to improve latency, but that's not where we went. We went with improving how many pixels of video can you decode per unit of time. I really feel you when you say you're not feeling the benefit of the treadmill of new disposable computer hardware. I'm very familiar with that feeling.

Devine:

I feel like I'm ten years behind. This is a whole culture that I'm discovering but that hasn't been active for a long time. It was completely in my blind spot. Just a few years ago, I was building apps for iOS. People were warning me about...

Devine:

The only part I remember of these comments is the cynicism, but I didn't really quite understand. Now I'm like, "Oh, that's what people were warning me against." The platform locking. The grip that Apple is gradually closing. The January thing — in a few weeks, all the apps that are not code signed are not going to work on OS X. That's like half our market, because _we_ inspired all our friends to migrate to the Apple ecosystem, and I feel so bad for this. I totally regret that. I didn't know better. I was not surrounded by people who could have showed me, but now how can I make up for that sort of ignorance?

Ivan:

The web standards people have always held the mantra, "Don't break the web." If you're introducing a new standard, do it in a way that's backwards compatible; don't rename existing functions; don't remove features — and yet, it happens. There was a change in early 2019 where Chrome changed the autoplay behaviour so that things that use audio won't be allowed to emit any audio until the user interacts with the page. That was a breaking change. Previously if you wanted audio on the page you could make that autoplay as soon as the page started running. A bunch of independent artists and game developers had made video games that run in the browser that relied on that behaviour, and the change in Chrome broke that. I think that was a really big wakeup call to a lot of independent creators. The web is not a platform where you can make something and expect it to continue to run indefinitely, even though there's all the counterexamples of, like, the Space Jam website from 1996 still runs today the way it did back then. That's survivorship bias. There are a lot of cases where you can make something, it will run for a while, and then it will stop.

Ivan:

You're responding to this by moving more towards C and Scheme. What other sort of changes are you making to try and avoid being herded in the direction of perpetually upgrading?

Devine:

I feel like this occupies my mind constantly right now. A lot of the time I spend doing research, I'm absolutely enamoured by the romantic idea that someday I could just spend a whole year in FreeBSD. I could build every single tool that I need, and not rely on more. It's like a road. I'm not really sure what the ultimate point is, or where exactly I'm going. I'm trying to explore the idea of modular computing as far as I can, and on as little resources as possible. Our studio runs 100% on solar. It makes us very conscious and aware of where the cycles of our computers are being spent. If I had the choice between two apps, usually my first question is which one takes the least amount of CPU? Nobody thinks like this anymore. I was giving a talk in Portland. Every single day I would have startups coming up to me, introducing me to their product. The first thing I would say is, "Does it work offline?" — and then, "Oh no, sorry, it's some sort of web service." I don't feel like I'm a demographic anymore for anything that is computer related. So I figured I might as well just experiment in that space where some people in their 50s are exploring how to keep Plan 9 running on their Raspberry Pi, or keep their favourite bits and pieces of what's around, and live off that, and experiment with computing in a way that is not super common. Recently for fun I just started using Gopher. It's the best way of getting access to long-form content, or a database of things that doesn't need to blink and play music and play videos at the same time and ads and all that kind of stuff. If you're looking for one thing... I feel like one-third of the web could be just Gopher databases. If you're looking for some thing, you don't need bells and whistles. Most of the time I browse, I'm in the reader mode — and Gopher gives you that with, like, one-hundredth of the processing power required. That's a form of computing that is not the norm. I'm all for efficiency. When there's an efficient way of doing something, I'll try to gun for it. If I was for convenience I wouldn't be living on a sailboat, and solar. But I've found that this way of life advised the way I interact with the computer. Even though there's less and less people that are interested in that kind of stuff, I can still try to live in that space and build things for that space. I'm pretty sure it's complete a forgotten demographic. From our perspective, I look at all the people like, "The new Xbox is coming," and they're all jumping on that sort of garbage. They're not really seeing how that Xbox came into being, and how long it's going to be on Earth, and how they're going to get rid of it. I find it's completely tone-deaf to look to these technologies and seeing them as better. They're really not better.

Ivan:

Or they're better if you only look at certain kinds of measurements that are very selective. They're not holistically better.

Devine:

Yeah, not better in ways that I value things.

Ivan:

You say that this puts you in scarce company. I would say that there's actually some places where I've seen a lot of sympathy for this move toward being very conscious of energy efficiency, and being very conscious of the upgrade treadmill. For instance, the programming language Forth. I think it was from the 70s originally. It's sort of a spatial language, where you're creating little units of code that exist on a kind of two dimensional space. Each unit can communicate with the units side to side, or above and below, and they sort of pass data around. I remember seeing a Strange Loop talk by the creator of the language, Chuck Moore. It's a language that he created with energy efficiency very much in mind. Not only is it an interesting language because of the spatial character of it, and the influential role it played in the development of later languages. He created it thinking that this spatial character would be useful because, perhaps, one thing that might have happened in the development of computers would be little tiny independent micro-computers that would communicate. Instead of having like one big single-core processor that would do a whole bunch of work in-order, you'd have something more like a GPU — where you have lots of little independent units of computation — but that they would be arranged spatially, and they'd be able to communicate with their neighbours, which in a GPU you can't do. In a GPU, each core is independent.

Devine:

I think Inferno works like that, right?

Ivan:

What is Inferno?

Devine:

It's an operating system. Inferno has some ties with Plan 9. But also, I've seen this sort of physical computing model. Like, there's a Lisp OS called ChrysaLisp, and I think it's designed to work on multiple cores that are spatially organized. On its documentation there's, like, a matrix of computers talking to each other, and the OS kind of takes that for granted, takes that into consideration.

Ivan:

Or there's Dave Ackley. He has a programming model that is designed for resiliency, and it was also spatial. It was like each unit in the program would try and build up the units around it. If some of the units were destroyed — because, you know, this is executing in an environment where that might happen, there might be some physical damage or something like that — this is a programming model that would sort of work around that. Part of the model is that you're not just sending data over to your neighbour expecting it to be there, you're handling the case where your neighbour doesn't exist and you need to build them from nothing. It makes the code into the self-replicating, self-perpetuating model.

Devine:

That's so cool. I'm really excited to look up Forth and how they plan for efficiency of energy, and I'm also interested in how these other languages plan for resilience. That's things I'm not really seeing a lot, or exposed to.

Ivan:

I'll put that Strange Loop talk in the show notes. He goes into a good explanation of... I think he was aiming for something like... he wanted the execution to be, like, so many picojoules per clock cycle, something like that. The idea was to make computing happen at many thousandths of the amount of energy that it would take to run an x86 CPU. Unfortunately I don't think it works if you execute it on top of our current hardware. It would require the hardware that it was being designed for. But it's definitely one of those shining examples of people looking at energy efficiency as part of the design of their programming model.

Devine:

When I said I felt alone, I mean... There's so many people in that space doing amazing things that I'm just not aware of. I'm just kind of new, stumbling on that stuff. I don't want to say that I've covered the whole area. There's definitely all that kind of stuff I still have to find. It's just that me, myself, my own experience in that sphere, I've found there's a few people here and there and when I look on their website it really feels like... it's really hard to reach them, outside of the mainstream.

Ivan:

Yeah. It's definitely not something that Microsoft or Google or are saying, like, "This is our vision for the future."

Devine:

Yeah, that's what I mean. They're being left out of where things are going.

Ivan:

That brings us to the end of the interview for today. Be sure to stay tuned for part two of my discussion with Devine Lu Linvega where we go very, very deep into his Orca spatial programming environment. It's super weird, and very interesting.

Ivan:

I've got a couple of quick things to point you to before I conclude the episode today.

Ivan:

First of all, the Future of Coding Community is running a survey to collect information about the interests of our audience, and to set the roadmap for what sorts of new projects we're going to be working on this year. The survey is pretty quick and fun. If you'd like to take a couple minutes to fill it out, I would greatly appreciate that. You can find the survey at the convenient radio-friendly link bit.ly/foc2020.

Ivan:

Yes, the implication is that we will probably do another one of these surveys in about a year just to see how things change over time.

Ivan:

Thanks again to our sponsor Repl.it. The transcript is available at futureofcoding.org/episodes/044, and you'll find links to everything that Devine and I mentioned in the show today on that page.

Ivan:

That's it for this time. Thanks for listening, and I'll see you in the future.