Blocks and Beyond 2015
A couple of weeks ago I went to Atlanta for the Blocks and Beyond workshop. This conference brought together a bunch of folks working on blocks languages to discuss our current work and future directions. Since I have been implementing a blocks interface for my Madeup language and had some things to say about it, I was invited to present. I share a few stories from my journey.
Getting to Atlanta went very smoothly. The plane didn’t crash and I didn’t get mugged between the train station and my hotel. At the hotel, however, the clerk gave me keys to room 918. When I entered room 918, I found some lights on and some clothes lying about. I exited and reentered only to find the same conditions. Thankfully, there was not a person with a gun in the room. I went back to the desk and got a different room.
The hotel was tall and the exposed atrium made my stomach lurch:
When I get to big cities like this, I immediately set to work on two goals: find some postcards for the family and make the city mine by walking around it. I decided to head to the Atlanta Botanical Gardens. Unfortunately, my timing was off, because I ended up walking behind a strutting man who made me ashamed to be his fellow man. After passing a woman on the sidewalk, he would turn around, pull down his shades, and leer at her. When passing a woman in a car stopped at a red light, he would spin toward her and drop his own mouth open as he took in her beauty.
Eventually I arrived at the gardens. Traipsing through the green did wonders for my burnt out soul. I saw and smelled. Though not currently growing anything, this sculpture haunted me:
I thought I had visited everything when I found a new path that took me to twice as much space as I had already visited, with exhibits for orchids, jungles, deserts, a fragrance garden which nearly destroyed me, and a cooking demonstration. The sun was starting to set:
Since starting to work on Madeup, I’ve had a very difficult time not noticing algorithmic shapes. The paths in the gardens were no exception. What a pleasure to walk on such algorithmic simplicity:
You can be sure that I modeled these in Madeup:
The code behind a single tile is just some nested loops:
/usr/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'coderay' (>= 0) among 56 total gem(s) (Gem::MissingSpecError) Checked in 'GEM_PATH=/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0:/home/johnch/.gems', execute `gem env` for more information from /usr/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec' from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem' from ./coderay:24:in `'
Regarding the actual conference, I was very glad to meet Neil Fraser, the primary developer of Blockly at Google. Blockly is what I’ve been using in Madeup, but I had been running into some design constraints that were preventing my further progress. For example, Blockly considers functions to exist at the top level, independent of all other code. This makes supporting closures challenging, as closures capture the current environment when a function is defined. If a function exists outside all environments, there’s nothing to capture. Without closures, all outside information would need to be passed in as parameters and all computed values would need to be explicitly returned. I asked Neil if I could just add previous and next connections to the function blocks to situate them inside the regular program flow and he said, “Probably.” He was right.
With Neil’s humble nudge, I was able to make steady progress on my blocks-to-text translation:
A central theme of the conference was what I regarded as a battle between text and blocks. Many people think there is no such battle, but after talking with some of the major players in the blocks world, I’m certain the battle is real. After seeing a demo of a blocks language that’s striving to be a general purpose language, I asked its developer about the psychological importance of being able to make mistakes while crafting code. I said that many people don’t feel in full control when they believe they are using “training wheels.” He said that this phrase makes him mad, and that parsing text is artificial and that we should be editing abstract syntax trees directly. He was certain text languages will die. As a lover of text and its liquidity compared to blocks, this scares me.
This conversation and others lead me my current outlook on the blocks vs. text battle: the war is only about the interface. We incorrectly associate block languages with the slow mouse and text languages with the fast keyboard. I look forward to a day where I don’t have to worry about indentation, semi-colons, braces, and linebreaks. We can have a language where we do not have to worry about these superficial details that only make the parser’s or human reader’s lives easier. But this language must still allow a recall-based user interface, one where we can use the keyboard to generate programs quickly and share code between programs. If that language is a blocks language, so be it.