Rose Project (April 2017)

About one month ago, I announced The Rose Project, my open source effort to make programming better. If you haven’t read it yet, I suggest you start there. As promised, this is my update one month later.

Pausing Prune

At the time of my last writing, I planned to continue working on a graphical user interface (GUI) for directly manipulating JavaScript abstract syntax trees (ASTs). In short, I planned to continue the work that Kent Beck and Thiago HiraiIn began with Prune.

However, for reasons I will explain below, I decided to put this line of inquiry on hold. Before I move on, I want to note two final insights I had for this project:

1. I strongly believe that the most efficient way to continue with this project is by using “Text as the G in GUI” as I refer to it in my last post. This way, you wouldn’t have to waste any time on building the AST’s display or navigator (because you’d just use the Ace text editor) so you could focus all of your efforts on empowering syntactically correct transformations, a nontrivial problem.
2. JavaScript has many issues (as I refer to below), so I would focus on a key subset of JavaScript so as to not waste time trying to be compatible with all of the weird parts. The downside to this, of course, is that you wouldn't be able to import a project to Rose, only export it out to JavaScript, but I think that’s a fine place to start.

Better programming paradigms

In the course of creating a GUI for JavaScript, I began to ruminate on JavaScript’s warts. The more I thought about it, the more I realized how much of JavaScript I personally “consider harmful,” even the basics like mutable variables and imperative control flow. And so began my search for better foundations for programming languages.

Many people are doing interesting things here. As I stated before, I’m most impressed with Paul Chiusano’s vision for Unison. However, it’s not quite at a developed enough stage for me to play with, but that may change soon.

This month I did a deep dive into CycleJS and Elm, and compiled a more extensive list of others to research more deeply later.

CycleJS

I’ve been following the writing and progress of Andre Staltz for a few years now, so I was not surprised to be impressed by this framework. It allows you to be truly immutable and functional within the JavaScript universe. Paired with TypeScript, CycleJS provides stiff competition for the likes of ReactJS and VueJS.

However, there is a steep learning curve to understanding the “everything is a stream” mentality. It takes time to get competent with stream utilities and combinatorics. Also, it is fairly new software so they don’t have as many libraries as you’d hope for. The more I used it, the more I understood how similar it is to Elm, a comparison that Andre makes himself but never made sense to me before.

Elm

Like it’s parent language Haskell, Elm boasts zero run-time errors. It accomplishes this with a strong type system that forces you to think though all possible cases in your code. It’s impossible to understate how amazing this is. For example, you can’t only handle the success case of a HTTP request — you have to handle all possible responses. Nor can you only handle the non-null cases — you have to handle all possible values.

On the down side, it’s difficult to install Elm (took me hours) and it has a rapidly changing API, so it’s a little too raw for my tastes. Despite this, McMaster University finds it a great tool for teach children to code.

Languages for further research

• Eve — I really admire the people behind Eve but I haven’t been able to wrap my head around it. I probably need to give it more time.
• Luna — I was pointed to this by Andre Staltz. Seems like it could be exactly what I’m looking for but I was unable to get access with it to play around.
• Lambdu — seems similar to Luna and Unison. Need to do more research here ASAP.
• NoFlo, Project Blocks, and Kite are also at the top of my list.
• Irvin Hwang (who contacted me after he read my last post) shared this list of visual programming langauges that I am hoping to look into soon.

Can we do better than HTML and CSS?

Reading Paul Chisuano’s post about CSS made me wonder if we can create better abstractions than HTML and CSS.

For example, HTML attributes have non-obvious names and values, like target="_blank" to get a link to open in a new tab.

In CSS, it’s widely accepted that centering things is a total pain. However, shouldn’t layout be easy with the right mathematical abstraction? It feels like a good functional, mathematical, declarative language could solve this problem.

There are two routes to take here:

1. Build an abstraction on top of HTML and CSS, a language that compiles to HTML and CSS. This has the advantage of not having to re-build the common HTML and CSS widgets by hand. For example, the input box is a tricky thing to get right.
2. Build an abstraction from scratch on top of the HTML5 canvas. This is the route that Jens Monin’s morphic.js library takes. The upside here not having to deal with the finickiness of HTML and CSS, but the downside is rebuilding the entire web frontend UI toolkit from scratch.

I’m surprised that I haven’t seen many other people talking about solving this particular problem. It seems like most of our focus is on improving JavaScript (through languages like Elm) while leaving HTML and CSS as they are.

Rethinking Precision

One of the first lesson that I teach my computer science students is that “computers are stupid.” A computer will only do what you tell it to, no more or no less. To articulate this, we play the “code your teacher” game, whereby they give me instructions that I try my best to hilariously misunderstand. Through this game, students learn that they have to be incredibly precise to get what they want from computers.

Josh Darnit playing the “code your teacher” game with his kids

However, does coding have to be like this? What it would look like to rethink precision as the fundamental concept of computer science.

Could computers be “less stupid?” Could computers allow for more ambiguity?

For example, when a computer is given ambiguous command, here are two different tacts it could take:

1. It could make its best guess about you’re trying to say and run with it. If the computer picks incorrectly, you could notice that and let the computer know it’s not what you meant.
2. It could tell you that it’s confused and give you a chance to clarify what you mean, potentially by giving you a list of options to chose from.

I wonder what work has already been done in this space. If you know of anything, I’d appreciate a note in the comments :)

Not only for beginners

When I tell people about this project, I often get asked “How will your language prepare students for working with ‘real’ programming languages?” I had trouble answering this question until I recently re-read Bret Victor’s Learnable Programming, the landmark article that started me on this path years ago.

In the last section, entitled “These are not training wheels,” he says (ellipses mine):

These design principles were presented in the context of systems for learning, but they apply universally… A frequent question about the sort of techniques presented here is, “How does this scale to real-world programming?” This is a reasonable question, but it’s somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change.

Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow the flow, and see the state. Programmers have to create by reacting and create by abstracting. Assume that these are requirements. Given these requirements, how do we redesign programming?

Taking a break

When I started working on these ideas a year ago, I truly believed that a breakthrough was right around the corner. Only after having worked on this project for over 6 months full time did I begin to realize the scope of this undertaking. To be honest, it wasn’t until recently that I understood how many others have been trying to solve the exact same problem — I thought I was charting new territory when I was in fact retracing steps.

For this reason and others related to my other job as co-founder at The Coding Space, I’ve decided to take some time off from this project to focus on other projects, in particular a program for women to learn to code that we’re trying to get off the ground.

I aim to return to this project in my spare time over the month of May and return to it in a fuller capacity in June or July 2017. In the meanwhile, I’d be happy to hear from anyone that’s working on similar projects or has thoughts on my thoughts.