Future of Coding - Research Recap - A Year in Review

Episode Date: July 19, 2017

Let me get you up to speed with my research projects over the past year. You can read more about my projects here and here and about WoofJS here. You can find more notes about this episode at http://futureofcoding.org/episodes/2-research-recap.htmlSupport us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Welcome to the Future of Coding. This is Steve Krause. So I thought that on my first episode talking about the state of my own research, before going on to my current research, I would go back and recap the course of my research over the past year and a half or so in this episode, and also talk about my thoughts about where to go next in my research. I don't have a firm direction on where I want to go next. I have a few ideas, and so I'll talk about those out loud and see if I can come to some sort of consensus here, and if not, I'll write more about

that in my journal, and you'll hear more about where I'm heading next in my next research podcast in about two weeks. So to start everything off, I need to tell you about where I'm coming from. I'm a computer science educator. I teach students how to code, and the platform we use is MIT's Scratch programming language. And very quickly, I fell in love with it. Like, head over heels in love. I'm blown away and I'm still blown away by how much I absolutely love Scratch. I can't talk enough about it. Just to quickly explain some of those reasons. In Scratch, the types of different blocks

are encoded as the shape of that block. So for example, Booleans are hexagonally shaped. And this is cool because if blocks are shaped so that it's like the word if, and then there's a hexagonal shaped hole, so you could put a Boolean. So the student doesn't have to learn the word Boolean, they just know that the hexagonal shaped block goes into this hexagonal shaped hole in an if.

The if block itself is shaped, it has a top connector and a bottom connector. So if blocks are like a sequential block and then it has a space in the middle inside like the body of the if statement. So it's like looks very similar to how an if block would look in code if formatted correctly. But because it's a block, the structure's

so much more obvious. The nesting of it's so much more obvious. And what goes inside what? So, so obvious for students. And it doesn't take long for them to realize the way that the blocks evaluate one after another in order, the way they do in most coding languages. So types of shape, that's a big one. Events, for example, events have a shape on the top that don't connect to anything because events are the beginning,

and then they have a bottom connector. Forevers, for example, have a body like an if block, but they don't have a bottom connector. They have a top connector because you can start a forever, but you can't leave a forever. There's nothing after a forever. And forevers is a wonderful abstraction. Scratch has a lot of wonderful abstractions. One of them is the abstraction of a sprite.

So Scratch is first-person coding. So whenever you're coding, you can imagine yourself as the sprite, the character, that you're currently editing. So you could say, move forward 10 steps, and it's that character. You don't have to say the character's name, dot, move forward 10 steps, which is sometimes difficult for students. You just have to click on the character you want, and then you write the code for that specific character. And then when you want characters to do things in a coordinated way, they have to send messages between each other, which is also a good abstraction. Students understand talking to other students.

So sending messages is a good abstraction. When students come out of Scratch and learn other coding, we have to explain, well, Scratch was first person coding, so that's why messages made sense. But now in third person coding, messages as they conceive of them don't make sense as much. So yeah, forever is another example of a good abstraction in Scratch. So instead of saying on every render loop clear the screen and render the new pixel

to the canvas, the sprites exist where they exist. And then if you want them to move, you could say in a forever loop move move 10 steps and then put that in a forever loop and so the student thinks it's just always moving 10 steps but the way that compiles down to the computer is every render cycle it will render the the object 10 pixels to to the right so it so that's that's a really cool abstraction I'm not doing a good job of explaining it but that's a really cool abstraction. I'm not doing a good job of explaining it, but that's a really good abstraction for students, thinking about the render loop as a forever loop instead of as a render loop. To just keep talking about why I love Scratch, another reason is that it's entirely cloud-based. There's no installation of anything. As long as

your computer has a modern web browser, you can go to scratch.mit.edu, create an account, log in, build your entire game on that one platform. You might want to search for images and import them. But besides that, it's entirely self-contained. You can even see the other games of other students. You can publish. You can share. You can comment. You can remix other students' games, which is kind of like forking other students' games.

It's unbelievably cohesive, and students love that about it. Another side effect of the blocks being encoding type information in the shape is that there are no syntax errors. You know, it's just blocks. You just drag and dropping. And also there are no runtime errors. There are no type errors. There are just no errors.

Obviously you can make logical errors. You can tell, you can want something to happen, but instead, you know, you can code it incorrectly and then that won't happen in your game. And then you have to debug it and whatnot, but that's okay. There are no errors, which is crazy. Cause if you're a regular programmer, there are syntax errors and then there are type a regular programmer, there are syntax errors,

and then there are type errors, and then there are runtime errors. There are all these errors I have to deal with, and Scratch has none of that, which is really magical, especially for beginner students to not have to focus on. So those are some of the reasons why I'm obsessed with Scratch. My students are obsessed with Scratch, and I really recommend it as the place to learn to code for everyone, especially if you're a kid, but even adults. I try and encourage everyone to learn to code in Scratch first because it just makes it so much easier to get started right off the bat and not have to worry about so many things

that are terrible about programming. So I was really inspired by how amazing Scratch was to think about building programming languages for adults that are as good. There's no inherent reason that's obvious to me why the rest of our programming languages can't be that good. So my first thought was, well my first attitude towards this entire problem was nobody's really tried to make programming better in a long time. Scratch is amazing, but it's only for kids.

Why don't I apply what I've learned from Scratch and make a system where people can code anything they want and make it as easy as Scratch? My attitude was that if I just spent enough time one-on-one with my computer, I'd have this problem licked in just a matter of time, maybe a year, maybe two years, I could do this. As you'll see over time, I began to learn that it's a much bigger project. It's a research project that involves many people and collaboration. And that's part of why I started this podcast and I'm having these thoughts out loud instead of just me coding in isolation. But anyways, at the time I decided let's just build something.

The first thing I built was using Google's open source project Blockly. So Blockly is a framework for creating block-based programming languages like Scratch. So the blocks in Blockly are slightly different than the blocks in Scratch, but it's a wonderful, wonderful framework to right from the get-go, just get running right away with a block-based language with minimal overhead.

You don't have to do, you don't have to build the actual blocks. You just, you don't have to build the layout for the blocks. The whole interface, block-based interface, is built for you with Blockly. You just add the specific blocks you want and describe how they should compile to code. That's how Blockly works. You just say let's have a block move 10 steps and then when that user adds that block to the workspace and they hit compile it'll compile to sprite1.move10,

left-parenthesis 10, right-parenthesis semicolon, that kind of thing. That's how Blockly works. It's a really wonderful platform. And now, actually, the new version of Scratch, Scratch 3.0, is actually using a fork of Blockly under the hood. It's kind of irrelevant, but it's an interesting tidbit. So my first version of my first prototype, I called it Cycle at the time, was basically blocks, Scratch-like blocks via Blockly for jQuery.

So if you're not familiar, jQuery is a front-end library for manipulating the HTML document object model, commonly known as DOM. And jQuery, yeah, it's a very commonplace library. I'm going to mostly assume that you've heard of it. So the way Cycle 1 worked, and I'll have links in the documentation so you can check it out for yourself. It was only jQuery. There was no HTML and no CSS. It was just jQuery. So if you wanted to add HTML or CSS to your code, you could do it via jQuery.

Because that's what jQuery is. It's for editing HTML and CSS. So you could build, in theory, anything you wanted to with the tool, but it was very imperative. So imperative is kind of the opposite of declarative. So if you wanted a page with 10 elements, you'd have to add 10 elements to the page. And then if you wanted to change their color, you'd have to refer to them by their ID and then change the color. So you couldn't just say, there are 10 elements on the page, here are their colors.

You'd have to go add the first one, add the second one, make the first one's color blue, make the second one's color red. It was very imperative. The reason I did this is it's so much simpler to have one interface, like one for HTML, one for CSS, one for JavaScript. The problem was, it was just way too imperative. And I should have learned the lesson

from that we are all learning now from React that declarative makes much more sense. However, for all of its faults, it was really fun and kids got excited about building things in it. It was so much more accessible for them to use than programming in HTML, CSS, and JavaScript, which are three separate languages with three separate

syntaxes whole new slew of abstractions it's a mess so this tool with one block based language was a godsend for students but it wasn't extensible enough one of the things we thought about a lot with cycle version one, is it a tool that helps kids learn how to code in JavaScript? Or is it a tool that will replace JavaScript? So is it a learning tool or is it a better tool? This became relevant because there were certain times when I wanted to build a feature into Cycle Version 1 that was very different than JavaScript.

And so the worry was, well, if we build this feature in, it'll make it easier now, but then when the students transition to regular JavaScript, they're going to be confused. So we were going back and forth on which direction to go, but then we found a product very similar to what we were building that Code.org had been building called the Code.org App Lab. And they have a product that's very similar to what we were building that code.org had been building called the code.org app lab and they have a product that's very similar they uh but much much they were much farther along and it was much fuller featured and they took a hard line that it was a learning tool so everything at least from my perspective that was the hard line they took everything they every block compiled directly to javascript there was no funny business and i think their platform even allowed you to go back and forth between coding blocks and coding in in the

text you can go back and forth they might have used pencil code which is a learning tool that lets you do that they might have used their droplet technology. I'm not sure how they went about doing that. We'll talk more about that approach, block to text and back, in the future because there are a few other platforms that I find interesting that do that. So when we found the Code.org App Lab, we decided, you know what, someone's already doing something similar to what we're doing. And at the same time, the business, the educational business that I was running with my partner,

Eli, was going through some tough times. So I went back to the business. I put this research on hold for later. I also, during this break, I began working on my programming language, WoofJS, which is highly related to this whole discussion and particularly related to Scratch. But I'm going to leave that to the end of this recap to discuss Woof. So a few months later I decided to come back to

this research and build a new prototype, Cycle version 2, and this version can be summed up very quickly as blocks for Vue.js. And so Vue.js is a front-end framework similar to jQuery, but it's kind of like the next generation. So it's actually very similar to React. So jQuery was how we, jQuery or like the jQuery style of coding was how we built front-end websites for a number of years. But then React.js came on the scene and kind of taught us this new, more declarative way

of building front-end interfaces. And Vue.js is very similar to React. It's almost not worth going into differences. It's maybe syntactically a little bit nicer, in my opinion. Different things like that. But it's basically the same. So if you're familiar with React, just when I say blocks for Vuejs just think blocks for react so my second version built upon the

drawbacks of the first version it also just had one language so there was blocks i used blockly again and there was one interface i didn't have one for h HTML, one for CSS, and one for JavaScript. It was one interface, but it was much more declarative. So you didn't have to add the elements. You could just say, here's what the page should look like, declaratively. The page should have three buttons, and they're blue.

And they were. And then what makes React work, or the React style, everything's reactive. So you could say there are three buttons, and they're blue. Or you could say there are three buttons, and're blue, or you could say there are three buttons and their color is value color, and color is a variable.

And so you could set the initial value to the color variable to be white, but then later in your code, you could, later in the program, you could change the value of the color variable to blue, and all of a sudden the color of any elements that you say should be the color of that variable, which is automatically updated. So that's why we say that React is declarative, because you declare what the color is, and

it always is that that's the color assigned to that variable. But then when the variable changes, the color reacts to the new state of the world. So you don't have to manually change the color reacts to the new state of the world. So you don't have to manually change the color. You just, in all of the elements, you just set it to what it is, and then as that variable changes, everything updates. So this prototype was head and shoulders better than the last one. I was able to build some real things with it. So my goal was to build the ToDo app.

ToDo MVC is this project. You can go to todomvc.com. It's this project that allows developers to compare different front-end frameworks. And so most people, when they're developing a front-end framework, they see the ToDo MVC as the first milestone. It's like the proof of concept

that your framework can do complicated things. And it's a great comparison point. So if a developer is shopping around between different frameworks, they could see how the same exact pixel-perfect app is implemented in a range in hundreds of different frameworks. So my goal was to build, to do MVC.

I thought it would take me a few months. I was able to get it done in like a month or two, mostly because Blockly is just such a great tool to use. And it was fun. It was really fun to work on this and it was fun to build the TodoMVC app. It was like, from my perspective, I didn't thoroughly test it, but from my perspective, it was definitely more enjoyable and faster to build TodoMVC in Cycle version two than in Vue or React or any other framework I know of. I definitely think, you know, obviously I built a tool in order to build to do MVC. So, you know, it was built especially for this.

But it's more general than that, but I really believe that it's the most intuitive, easy, fast way to build user interfaces that I know of. Obviously, you know, I don't use it now. There are drawbacks, but for what it was, it was, you know, there were a lot of cool ideas in that prototype. And I'll have links to all of these, including this one, in the notes for you to play with. And on the website, futureofcoding.org. So some of the problems. Vue.js, as far as I could tell, has had some really terrible error messages. Sometimes, most of the times, it would just say error in template. And you just have to kind of figure out what was wrong, which oftentimes would mean like undoing until there was no error or like commenting out large swaths of code until you isolate the error by hand.

So that was terrible for users. It was just awful, untenable. And then worse, it was very brittle. It was kind of like strung together with duct tape. So if something broke, which it was common to do, students were kind of stuck. So you really couldn't work in this prototype without me physically next to you. So it was brittle. It was a prototype. But there were definitely ways in which I built it, in particular relying on Blockly that made it hard to fix some of these bugs.

Blockly and Vue.js that made made it hard to fix on these bugs. So if I were to ever go back to this prototype-y idea, I would get off of Vue.js and I would get off of Blockly. I'd build my own block-based framework, so I could own that. And instead of using Vue.js, I'd probably do something more lightweight and less opinionated, like virtual DOM, which is the specific library within Vue.js and React.js

that allows them to sync the updates when the model or different variables change. So basically I would do it right. I would take a step back, lose other people's tools that didn't work well together and build it from scratch in a way that made more sense. So that's what I learned there. One of the things I did after we built this, Eli and I held a number of user interviews and I went to different hackathons and taught them how to use this and went to see if they would use it if it were to solve any of their problems what the problems would be when they used so we did we did a lot of user user testing with the second prototype

and it was mixed like i knew kids were able to build things that they never would have been able to build without this there are no there's no other tool out there that would allow them to build the things they built with this tool like chat apps or different interfacy like things but um it did stink for a lot of reasons and it was hard for them to build things if we weren't there. But for what it was, it was powerful. I think the real killers were the terrible error messages, the brittleness, and then, of course, the fact that you couldn't import anything into it or export anything out of it.

That was bad because unless this tool is so great that you're like, you know what, I'll rebuild whatever I've already built in this new system because it's that good. Or, you know what, I'm never going to want to leave this system because it's that good. Like, it has to be so good to convince people that they want to move here and that they're never going to leave here. Or it has to allow some import or export. So the self-contained nature of it was bad considering how beginner it was. You know, you think maybe if it was better or over time,

it wouldn't be as bad that it's self-contained, but any system really, when you're designing it from scratch and you want to convince people to use it, the value prop has to be there even though it's bad, and I don't think the value prop was quite there yet. But regardless, I definitely learned that lesson that self-contained, not being able to import or export is bad, with my next prototype. So at this point, I rebranded the name of these prototypes. I used to call them Cycle. Now I call them Rose, after my dad and my dad's grandma. Her name was

Rose. My dad was named after his grandma, who was named Rose. The next version that I worked on was based off of this essay. It was published by Kent Beck and Thiago Harari. And they published this post on Facebook about how to build a projectional editor for JavaScript. And a projectional editor is a more structured way to edit your code. So normally when you're editing code, not in blocks, regular text code, you're editing a 2D grid of text, and then you hit some sort of Compiler Run button, and the computer parses that into a tree structure, and then uses that tree structure to run your code. And so a projectional editor basically says, well, that's kind of silly. Why are you editing this 2D structure of

characters when you could be editing the actual tree structure? And that way you couldn't make any errors in syntax because there is no syntax. You're just editing the tree directly. So this is something that I believe that coding should be liberated from editing text. Back in the day, text was all we had. Computers didn't have graphical user interfaces, so you had to code in text. But today, we have graphical user interfaces. If coding is really a tree at the end of the day, why don't we just edit the tree directly?

So that's what Prune was all about. And so I decided to pick up where they left off, or really reinvent the wheel, but based on their specification, and then hopefully catch up to them and then pick up where they left off. I didn't quite get to where they got to, but I did play around a little bit and get somewhere. I built a place where you could import any JavaScript and it would render it for you as a tree strip. It would render for you looking like the regular JavaScript but you could click on any part of it. You could click on the parameters, you can click on the function, you can click on different parts of it and then it would

give you semantic actions that you could do at each point in the code. So delete this, add another parameter, delete this parameter, add another line, add a function. Anything you would want to do in JavaScript, it would let you do that thing. You could change the names of variables. It would let you do anything you wanted, but in a way that wouldn't cause any syntax errors. It forced you to be syntactically correct constantly. And it could import any JavaScript program and it could export. And so I have a few demos on the website that I'll link to where you could type in the JavaScript over to the right

and it'll update this grid. It would update the code on the left that you could then click on and then add semantic actions, do the semantic actions that would edit the code, and then you'll see that updated in the code on the right. So it showed how it was a one-to-one correspondence between the code and this user interface where you could do semantic actions. So in theory, it would allow you to do what App Lab and Pencil Code does, where you can go back and forth between the code and this semantic editing tool, the projection editor. So in theory you could do either one and you could infinitely go back and forth between

them. It's importable and exportable for forever. So check out the prototypes, you'll see what I'm talking about. It's very buggy, it can only do a few things, but you'll get the sense of what I was going for. There were a few things I learned'll get the sense of what i was going for there were a few things i learned about working on this um one is it's very hard to list all the possible transformations at any point in the javascript code because there really are like an infinity of different transformations or

things you might want to do to a piece of code so it's kind of hard to list them all it's hard but not impossible i think it just might take a number of weeks or months. It's not insurmountable, but it's a hard problem. And then surfacing all of those possible transformations is tricky, like what the interface is. Is it a list? Is it something you search for? Is it a list of categories? Those are open questions.

So what I learned through this process is just the code itself would be the interface. You would just click on the code. You couldn't edit it, but you could click on the code wherever you wanted, and it would list up all the semantic actions you could do. So that way I wouldn't have to waste time building out the view layer of this app. The view layer is just the text. And then when you go to edit it, and then when you go to edit the code, it'll list the actions for you there.

During this project i was realizing how many warts javascript has how many problems it has inherently as a language so even if i fix the syntax error problem which this projectional editor would i'd still have the run time error problem we still have type errors we still have people learning all the wacky abstractions in j and HTML and CSS. It doesn't solve everything. It pushes, it solves one class of errors, but it pushes the puck down. And we still have to solve another class of errors.

And I don't think this works on solving those in a meaningful way. So it definitely is like a short-term solution. So that's, that's Rose version one. After Rose, I've been doing research into other people's life and it's been off and on it it's harder to stay on task and stay excited about doing research it's just not as fun as building things building things you have a vision you have you you code it you iterate you show it to people it's very exciting when you're doing research into other people's products you're you're clicking on links you're reading stuff you're trying to understand it you're building you're following their tutorials building little toy things it's unclear like what what

progress you're actually making what you're learning from it what you're gaining from it but i think it's very important because there are some really amazing projects going on that i have already learned a lot from and that I know that there's more to learn from. And I think some of these projects have the potential to really be what I'm looking for entirely, in which case I would stop working on any of my own prototypes and just throw my weight behind these other people. I've been talking with Paul Trisano at Unison about helping him there for a while. We pair programmed a few times. It's hard because I don't know very much about what he's working on. I don't know very much about, you know, designing compilers.

He's at another level than I am, so it's hard for me to contribute at where he's at. But that's why I'm excited about doing research. I learn a lot and maybe I'll find something out there that's what I'm excited about doing research. I learn a lot and maybe I'll find something out there that's what I'm trying to build, someone's already working on it, and I can get inspiration for my own ideas. So let me tell you about the research I've been doing into other people's programming languages and products. So Elm is one that's been on my radar for a while. It's a lot like Haskell, which I've had experience with and I really love. However, even though it's familiar to me and I'm a functional programmer, it was very tricky for me to get started using it. Not least of which, it was just so hard to get to a place where I could install it and have it working.

There are a few online IDEs to program in Elm, but they weren't great and they weren't full featured and it was hard to install things and whatnot. So even just getting it to run was difficult. But then once I got it to run, it's hard. I think I really like so much about it. In particular, I love that there are no runtime errors and the type errors are so helpful and wonderful.

That's what they pride themselves on, just really user-friendly type errors. But it's just hard to know how to use the functions and how to look them up and the syntax. It's a lot of typing. It's a big learning curve, the syntax. So there's a project that I'm going to talk about later down that deals with that. So another project that's very similar to Elm is Cycle.

So Andre Staltz is this wonderful programmer. I hope to have him on here on the podcast at some point. I've been following his thoughts and research on programming languages interfaces for years now. He's had some really wonderful things to say about reactive interfaces over the years. And so he created this framework, Cycle.js. And as part of the reason I had to change the name of my framework from Cycle to Rose is because he already has the name Cycle.

I named my project Cycle before I saw that he had his out. But I respect him and his project is bigger so i need to change my name uh so cycle is very very similar to elm it wasn't obvious to me how similar they were when i started using cycle and elm but um it's something that andre says a lot and over time when i began to use them both i saw how similar they are and uh yeah it's fun streams are the the core data structure in elm i'm sorry in cycle and they're really nifty and like they bend your brain in a fun way and i think potentially if you built the right visual metaphors or interface streams could be a good foundation for a programming language that's more intuitive for end users.

I don't entirely see how that would be, but streams are an elegant data structure, an elegant abstraction. And so if you could make them more understandable, they're very powerful. So that's what working with Cycle left me with. It was also very exciting to be so declarative in JavaScript. Like, there are no vars anywhere.

Everything's a constant. Everything's a constant. So that was exciting. Another product that I've spent, you know, maybe half a dozen hours researching is Eve, Chris Granger's startup product. They're, like, brilliant people. They've done a lot of amazing work. It's really fun to follow their development journals, which I've read each post a number of times probably

at this point. And because of all that, clearly they're smart people and they're doing amazing work. Clearly there's a lot of value to learn from what they've been up to. Unfortunately, I haven't been able to suss it out. I keep trying to play with Elm, to Eve, and get excited about it, but it hasn't happened yet. I'm still confused about what they're exactly doing, what problems they're solving, what the abstractions are. It doesn't quite sit well with me yet. But that's definitely my fault. I need to spend more time with it.

These are smart guys, so I've been looking forward to doing that. The product I'm probably most excited about is Unison, which I mentioned before, because I've been reaching out to the creator, Paul, and we've been talking about working together. Unison is like Haskell or Elm. It's a strongly typed functional programming language. What got me most excited about it initially was he had a projectional structured editor for Unison. So it combines the prune idea or the rows version 1 idea where you can't make any syntax errors and the Haskell idea and the Elm idea of no runtime errors.

So it eliminates the two biggest classes of errors right off the bat. You can't make any syntax errors and you can't make any runtime errors, which is crazy. And really, you can't make any type errors either because the projectional editor won't let you put anything anywhere

where the types don't match. And his initial demos, I'll link to them, are really amazing because you just go ahead and type like you normally would when you're programming. And instead of actually typing what you're typing, it's actually searching for things that have the appropriate type for where your cursor is. So if you do 1 plus and then you search for variable 1, if variable 1 isn't a number, it's not going to let you put it there. But if you put 57 divided by 2, it will because it knows that that expression is also a number. So that was very exciting to me.

I think since then he's moved away from the front end of Unison and more towards the back end. Because Unison has a very broad and exciting vision for the world. He's moved more towards the distributed system side of things. I think his – my experience – I've been more of a front-end programmer over the past few years, so I'm excited about enabling people to build interfaces without learning HTML, CSS, and JavaScript. Paul's, I think, spent more of his time building backend interfaces, so he doesn't understand why it's, while it's so easy

to run code on one computer, it's like so much harder, exponentially harder, to run that same code on a network of computers. Basically, why are distributed systems so hard? Like, why do we, why can't you just write your code once and then like hit deploy, hit scale, and it just work? For example, on Paul's website, he shows how you can make a search engine in like 20 lines of code with with his unison system you basically describe how your crawler works how your indexer works how your pay tranks works and you just say go and then like depending on how much money you throw at the at the system it'll just crawl the web for you and you know assimilate things as as it does and so i think that's unbelievably wonderful.

It's a little over my head, but the way I perceive that, or I conceptualize that, is I think about how Twitter was started on Ruby on Rails and had all these outages, and they just had all this troublemaking available everywhere, and so they hired... Now Twitter has hundreds of engineers.

Much of them are doing other things, but they had to hire hundreds of engineers just to make the Twitter service, which is a very simple service, available everywhere. And so wouldn't it be neat if in the future, if you wanted to build a service like Twitter, you would just describe it the way you, you would describe it in a similar way

to the way they described it on Ruby on Rails. You described the basic way things should work. And then it just scales infinitely. As long as you keep putting money into the system, as long as you add the coins, it just continues to scale with usage. Obviously, the cost might be prohibitive. But putting that aside, you don't have to build more tool to manage clusters of computers and load balancers and all that stuff.

You just define the way your service should work and the scale just happens. Like, you know, a common – building a Twitter clone is a common first programming task that a programmer can do in like a week or a weekend or, you know, a number of weeks. And so the fact that – like, why can't that just be it like why can't someone build twitter in a week or a weekend and then just have it scale infinitely why can't one person why can't twitter have an engineering team of one person obviously i'm exaggerating twitter does a lot of a lot more things than just run the core service but why can't the core twitter engineering product just be one person who defines the basic why it should work. So Unifitsin is very exciting.

And I hope to have Paul in here soon to talk about it. There are two other languages that are in a very similar vein to Unifitsin. They are like Elm, but they also have projectional editors. So one is Lamdu, which is open source that really should be on the top of my list to look into next. And the other one is Luna. I think it's like lunalang.com.

And they're both pretty similar. What struck me about Luna is that they have a structured editor, but they also have text editing, so you can go back and forth, which is interesting. Like Unison, it's its own language, so they didn't use an existing language. They designed their own language, which to me seems like a little bit too much all at once, but I could see the argument for why you need to do that because no language was designed for visual metaphors from the ground up.

So if you want to do it right, you probably have to design your own language. But LunaLang is on like a private beta thing. They say that they're going to launch soon, so maybe I'll just wait till then, but I hope to reach out to them soon and maybe even have them here on this podcast because it seems like they are in the same

like headspace as Unison and Luna and Lamb do, which is really exciting because all really interesting projects. So I actually have a list of maybe like 50 or 100 other products that I've been meaning to look into. I have it in a Google Doc somewhere. I'll probably add it to my website at some point. I need to organize those and prioritize them. As I've said here, I think Lambda is the one I want to look into next, but also Luna and Eve. So that's kind of where my head's at in terms of researching other people's

projects. I'm sure there are other ones that are really interesting that I don't know about. So let me know if you know of other ones that you think I'd find interesting that I don't know about, or even ones that you find interesting that maybe I wouldn't find interesting. I'd love to add them to my list and let people know about them. Because yeah, the more we collaborate, the less we have to each reinvent the wheel. Okay, so before I go and talk about my thoughts about where I'm going to go next with my research, I want to take a break and explain what my programming language WoofJS is, because it's slightly related to my thoughts about where to go next. So let me tell you the whole story with Woof.

Take a step back. Before I even get into Woof, I want to tell you about how I got into this whole business of teaching kids to code and designing programming languages. Because to me, they're unbelievably interrelated, and the place that they start with is Brett Victor's Learnable Programming essay. So in that essay he explains how programming currently is built in a way that doesn't enable the right kind of computational thinking in children. It hinders it. And how it doesn't need to, and he shows examples of how we could build systems that enable the kind of

children, the kind of thinking we want to see in children the kind of computational thinking that we want to see so the way he illustrates this point is by going point by point through khan academy's processing js environment and showing how that environment does not serve kids well so i read this article and i was like oh my, it's so interesting. I really want to work on building more intuitive software systems for children or just more learnable software systems for everybody. Because like Brett Victor says at the end of that article, these systems aren't just for kids. Everyone should have a learnable system that's intuitive, that helps them, enables the good kinds of thinking instead of making it harder for them.

So I was inspired through this to read the work of Seymour Papert. He really encourages you to read Seymour Papert. And through Seymour Papert, I learned about Logo, which is a language I used as a kid and I loved. And then I also learned about Scratch, which is really the successor to Logo. And I fell in love with Scratch, as I already talked about. I had all these kids who fell in love with Scratch and became really, really good at Scratch and really good at programming. And then they kind of got bored with Scratch. Scratch was childish.

They were doing the same sorts of things. They wanted to move on to the next thing. I didn't know what that was. I had a lot of ideas. I had some kids doing HTML, CSS, and JavaScript, but that was a nightmare. That was really hard on kids, learning three different syntaxes at the same time, a whole new set of abstractions. They went from being the best at Scratch to the worst at web programming. It was just a nightmare.

Eventually, I kind of backed my way into this idea that I should just have kids coding in one language, and that language should probably be JavaScript. Because JavaScript and Scratch are pretty similar, and HTML and CSS aren't even really programming languages. They're more markup languages, and I could have them do Python or Ruby, but to me JavaScript made the most sense because it worked in the browser, and I have Chromebooks, and I want things to just work seamlessly, and I'm a JavaScript guy, and to me JavaScript is the language of the future because it's the language of the web.

But whatever. I love Python and Ruby. I'm not really against those languages, but JavaScript seemed the obvious one to me. And so when you think about teaching kids JavaScript, Processing.js and Khan Academy is the platform of choice for many people. But of course, I couldn't let my kids use Processing.js because the whole reason I was even a programming educator was because of this wonderful essay, Learnable Programming, which talks about all the flaws in Processing.js. So something needed to be done about that, for sure.

I couldn't just put them on this platform I knew was bad. But I didn't know what, so I kind of balked and had kids code directly on the HTML5 canvas. So the HTML5 canvas has an API where you could draw rectangles and clear the screen and draw another rectangle. And so I worked with a few students in a tutoring context building games directly on the HTML5 canvas. And it was fun. And they liked it. And, you know, it was similar to processing.

I probably could have just gone with processing. But I'm really glad I didn't because by using the canvas with these students, I began to see like, wait a second, I could build a framework that's better than processing on top of the Canvas. And when I say better than processing, I would just copy scratch directly. Like there were all the, it became obvious to me. And I was like so confused why there wasn't something like this that already existed.

So I started building it. And within a few months, I had a framework that my kids were using. They were like importing this framework into their code. And then after a few months, a few months after that, I realized that it was annoying to have them import this framework into their code. So I created a website where they could code in WolfJS directly, a website specifically tailored, like an IDE, specifically tailored for Wolf.js. And one thing led to another, and I have accounts and documentation and all sorts of bells and whistles. Now I have Google Docs style collaborative editing. It's this whole rigmarole. And I think we have about 800 kids using it now. I don't know what my daily usage numbers are. I need to refactor the database in order to get those. But in total, we have almost 800 users

from around the world. We have people, I have friends in Sweden and Australia and Japan. It's really fun to have a product that people use. It's really one of my first successful software projects, well, that I've started myself. So it's very meaningful to me. And I'm really glad that I've been able to contribute to this conversation of making more learnable programming languages. In particular, I've been able to respond to the essay that Brett wrote. I wrote an essay called WoofJS Making JavaScript Learnable, where I kind of respond to Brett's article point by point showing how where processing failed, WoofJS is succeeding. And I'll link to that article in the notes.

And yeah, I'm really excited about that. So the reason I bring up Woof is because I have users, I have students using it, and I'm wondering if building on top of Woof, like continuing to make it better, could somehow morph its way into what I'm seeing as a future of coding or like a new programming language? Or if I could, you know, kids start in Scratch and then they go to Woof and then, you know, right now I have them going to making websites, but that's still not quite right

because making websites is terrible. HTML and CSS and JavaScript are terrible languages when compared with Scratch and Woof. Could I build another language thing after Woof that students go to use that becomes this next language? I'm such a big fan of having products that are being used by real people because then you understand if it's useful at all and you know in which directions to build things. When you're coding in a vacuum, it's unclear if anyone's ever going to use what you're building and which directions to go next. So I've just been thinking about whether or not building on top of the success of Woof and using the audience I have, students, as beta testers,

is a good way to go for me. So that's why I brought that up. So now I'm going to talk about some other ideas for next steps. It's going to be be stream of consciousness. I'll do this maybe 10 or 15 minutes. Feel free to zone out or stop listening at this point if you don't want to hear it. So okay so here are some of the ideas. So the way WolfJS works right now it works just like Scratch. You could create a character and then create a forever loop and then say, in this loop, character.move10steps. And then the character will always be moving in the direction they're pointing by 10 steps. So character is by default start by pointing off to the right.

And so if you don't change the direction, the character will of zip off the screen to the right and never come back that's that's kind of the level of abstraction however there's there are a few places in wolf where things don't work that way where wolf is reactive so text is one of those places so you can give text a string, like a piece of text, a text sprite. You could say make this piece of text on the screen and have it say hello. And that's fine. You change its color, that sort of thing. But you could also, instead of giving the text sprite function a piece of text,

you could give it a function that returns a piece of text. And then every render cycle, it will evaluate that function and put that new value there so you could this is very useful when students say you know score colon plus and then the score valuable the score variable so that way when the score value increases the piece of text that shows the score automatically updates so that's really cool so one idea i've had is building a version of woof that's entirely reactive. So instead of saying, creating a sprite and then in a side of forever loop moving it, you declaratively define its exposition as a function of time.

And it automatically will update. So if you wanted the character to zip off the screen you define the character and in the exposition you would say is a function that is 10 more than the exposition was before so it's this this dot x plus 10 and whoop and it zips off the screen and so you know is this it's just an interesting idea an interesting thought experiment i don't know if this is gonna be the next version of wolf or if this is gonna somehow inform my research into the future of coding but it feels like a worthwhile experiment into changing abstractions like for example where I find this is interesting is with gravity. So Scratch is unbelievably, it's easy, so easy in Woof and Scratch to make gravity.

You create a speed variable, and then every render loop, you change the character's velocity, you change the character's position by speed, but also in every render cycle, you change the speed by a constant amount. So it's very straightforward. In like three or four lines of code you have realistic gravity. But instead of that you could define it all declaratively. You could say acceleration equals minus one, speed equals this dot speed plus acceleration and then position equals

this.position plus speed. And then everything just works. It just updates automatically. I think the way I do it right now, everything is a function that evaluates in a random order at the render cycle. So if I'm really going to make a reactive version of this figuring out the dependencies of how things resolve is probably going to be really tricky and

might make this harder but the general principle i think is like a really interesting experiment so that's one idea of where i can go next i'm not super excited about it but it's it's an idea another direction is is I built a few different things in Elm. I built a Mario game. I built a... And so I'll stop there. So with this Mario game I built in Elm, it was interesting, but it was hard and tricky. And there's actually a group of people up in Canada, McMaster University they're using Elm to teach game development but it but it's hard and I the way they're doing it it's it's tricky like they don't have a framework

the way wolf yes is a framework they just have like some code at the bottom where they tell the students like don't touch this code and it's very limited they don't students can't build games from scratch that way kids can only like edit the colors or the the amount that gravity affects things it's very limited. Students can't build games from scratch that way. Kids can only edit the colors or the amount that gravity affects things. It's very limited. So in a similar vein to building a reactive WooFDS is could I build a reactive Elm game engine? So Elm is projects is, if I could build a reactive version of these languages, could I then build a projectional editor for these languages that's also reactive? So basically, the question I'm trying to answer here is, could I build a reactive Scratch? Scratch is reactive in some ways,

in that you don't have to manually change things. Everything's kept in sync for you but basically I want to get rid of all forever loops and have things instead be reactive declarative another idea is I was building a spelling bee app game for my parents in Elm and I could continue working in that to learn more about Elm and be inspired that's something that I could spend some time on I need to reach out to Luna Lang to get access I need to spend more time with Lamdu that's something I've already mentioned that I think is probably the top of my list I need to organize the list of resources and other links in the space that I've

been accumulating and add more to them I think I need to look through I have a lot of resources of resources. So Brett Victor and Alan Kay will have lists of links that I need to take all the links from their links and add those to my links. Yeah, so that's a whole separate project. So I think right now where I'm leaning is I should spend a lot of time organizing my links, prioritize them, and start with some of the interesting ones. So LambDew is a good one to start with.

Luna is another one. And I have a few other ones. And then let's think. Yeah, so where I'm at right now is I should organize my resources, prioritize them, probably with Luna and Lambda at the top. I'll probably spend a few weeks plowing through my prioritized list of resources and then I'll probably get bored or feel like I've exhausted a lot of what's out there and want to begin on a prototype which may be prune or a prune thing or like I said it might be more of cycle version 2 or rose version 1 or might be something else or it might be building an elm game engine or something like that. So that's where I'm at now. Organize my links.

In the course of doing research, build little toy things over the next few weeks. And then after I feel like I've done a thorough bit of research on what else is in the space, go back to building a prototype of my own in one of the domains that I've listed. Or, you know, hopefully I'll come up with new, better ideas of building prototypes in the next few weeks. That's the whole point of the research I'm doing in the next few weeks is coming up with more ideas for prototypes and building more informed prototypes and not making the mistakes

that I've made in the past or other people have made in the past. Because I think what I've been realizing through a lot of these prototypes is that people have made similar mistakes in the past. So that's about it. That's the story of my research and you have a sense of where my head's at about where I'm going to head in the future.

So thanks so much for listening and I will see you next week with an interview. I don't know who's interview I'm going to be airing next week, but I guess it'll be a surprise for both of us. Talk to you later.