|Algojammer - Python Editor in the Style of Bret Victor|
|Written by Mike James|
|Wednesday, 31 October 2018|
Bret Victor is well known for promoting the idea that programming could be made easier and more natural by providing the right tools and environment. However it isn't easy to create said environment. Algojammer is an ongoing attempt to do just that and it needs your help.
We covered the work of Bret Victor back in 2012 - A Better Way To Program - and have followed some of the attempts to create the sort of thing he was talking about. Why his ideas haven't had more influence is a mystery as just about everyone who encounters them for the first time has a "wow" reaction.
Put simply the idea is that programming would be easier if it was more direct. If the connection between what you write and what happens was made apparent to you at once. One very good reason is that the problem is hard. It is very difficult to build an environment that makes interaction possible in a reliable and simple way. The recent progress in "time travel" debugging - i.e. the ability to move backward and forward in a program's execution state, has made it more possible to see how to construct something that works.
Chris Knott has been working on Algojammer on GitHub:
Algojammer is an experimental, proof-of-concept code editor for writing algorithms in Python. It was mainly written to assist with solving the kind of algorithm problems that feature in competitions like Google Code Jam, Topcoder and HackerRank.
The principle is:
By default your code is re-run immediately on any changes. Algojammer is a "time-travelling" or "omniscient" debugger, where steps of execution can be arbitrarily jumped to. There is not really any concept of "debugging" in the sense of controlling the execution of the code via breakpoints or "stepping through". The Execution of your code should be thought of as just a physical fact about the lines of text you have written. In the same way we might consider the "Number Of 'e' Characters" in the code, or the "Average Line Length" of the code, the "Execution" of the code, is just a static fact that is entirely determined by the code.
Perhaps the best way to understand what all this means is to see it in action:
If you find this approach interesting then you can download it and try it out - it open source under the Apache 2.0 License. However you need to keep in mind that:
- The current implementation of Algojammer is extremely hacky and brittle.
- It *will* crash, do weird things and leak memory like a sieve
This is very much work in progress and more importantly:
- I want to rewrite it from scratch to be more stable, but I'm struggling
- If you are experienced with contributing to CPython and want to help, let me know
This is an opportunity to get involved in an open source project which has the potential to be very important. We still need better ways to teach beginners what code is all about and how it relates to what happens when it is run. You might think that the most difficult part about programming is getting the semicolons in the right place or remembering the syntax of some not-often-used construct - it isn't. If you are worrying about this sort of detail then you have already made it to being a programmer. Non-programmers just don't get the connection between the static text and the dynamic system it creates when you run it. Algojammer and environments like it are trying to make the connection obvious.
But it isn't just education where this approach could be important - how can we continue to ignore the potential advantages that software can bring to coding. It is as if we we can see what software brings to other disciplines but are blind to how it can help our own.
However, some people do have doubts:
A criticism that is sometimes levelled at Bret Victor's (or Chris Grainger's) work is that the demos feel revolutionary but essentially solve "toy problems", and start to creak when you think how they might scale to "real programming".
Algojammer is definitely still within the "toy" sphere. However, I think it moves forward in a couple of important ways. Firstly, it is designed to solve toy problems (questions from algorithm competitions) that are;
I think this is important because it attaches a certain degree of falsifiability to some of the navel-gazing, pretentious nonsense I've written above. Ultimately, when the clock's ticking in Code Jam, and I just really need to solve this problem, do I reach for a tool like Algojammer? This test can't be faked. An actual "bicycle for the mind", is not something that feels revolutionary in a conference talk. An actual bicycle is something that let's me easily beat people who are better than me in a race.
So, this is the current goal for the project: to build a tool that has a provably positive effect on people's performance in Code Jam.
Given the recent interest in time-travel debugging, it no longer seems unreasonable that this approach could be made strong enough to tackle real world problems. This is a good way to go forward.
|Last Updated ( Wednesday, 31 October 2018 )|