I have had this project on the go for a while and have decided to put it out as-is because I can't forsee being able to complete it any time soon. For people who go straight to the comments, here's a video - https://www.youtube.com/watch?v=9XPE4uT0AdE - I have a very mumbly British accent but you should be able to get the gist of it...
The one line summary is - it's a "real" implementation of some of the demo GIFs in Bret Victor's "Learnable Programming" [0]
The original project goal was to create a "bicycle for the mind" that actually has a provably positive effect on people's performance in algorithm competitions like Google Code Jam/Facebook Hacker Cup. I don't think I got there, but I think there's enough stuff here to interest people on a Sunday afternoon...
Constructive criticism greatly appreciated, here or on Github issues page. If you are experienced with CPython (as in, experienced in contributing to the actual interpreter), then I would appreciate input on how to deliver the "recording" aspect of the project properly. The current implementation is very hacky.
This is fantastic, and revolutionary — redefines what a debugger / programming environment should be. Thanks for making it.
(I had a vague idea to do something similar for a specific program that has a reputation for being hard to debug (TeX); will definitely look to your code for inspiration.)
Have you looked at Python Tutor (http://www.pythontutor.com/)? That's another excellent project that has some overlap — e.g. you may look at its insertion sort example (go to http://www.pythontutor.com/visualize.html click on "Show example code and courses" and click on "Insertion sort"). If you have looked at it and can summarize the differences in approach between your project and that one, it would be highly useful.
Thanks for an inspiring project! This is so obviously the right way to do things that in hindsight it's a shame we're not already using it. :-)
Have you considered posting this on www.codeforces.com? They have the biggest active community of competitive programmers, and I'm sure they'd find this fascinating.
You'd also probably get a lot of good feedback from competitive programmers.
Yeah probably GitHub is best. As I've said elsewhere, little bit burnt out atm but will be looking to start afresh at some point probably next year incorporating as many suggestions as possible.
Hi Chris, great project! If you're generally interested in all sorts of ideas on how to make programming better, I can recommend to check out https://futureofcoding.org/ and the slack group that's linked on the website. There are a lot of people thinking about, sharing and discussing great ideas in the slack, and your project perfectly fits into the "future of programming" category.
I think the idea of showing runtime data in various forms to help programmers understand what their programs do is a great idea with a lot of promise — it's my main research area. And this demo shows a plausible way to get some of that in Python, which is great.
But I still wonder if anyone writing actual algorithms would find this useful, and if so what exactly they'd find useful. I'd really like to see the field of UIs for programming get clearer on what data is useful to show to which programmers in what form and when.
You are totally right. My #1 annoyance is research and demos in this space, that don't consider your question. That is why I think it is important that this project aims to tackle problems outside my control, that are genuinely hard to understand (Google Code Jam problems).
My plan was basically to work my way through past problems, for each one thinking specifically about that problem - ok, what's hard here, what would help me solve this, where did I go wrong with this, then adding those features to Algojammer.
Then when Code Jam comes around again, I can really test it in a very falsifiable way.
I need a break and more time so I'm not going to be working on this for a while but I'm 100% on your side. Do you have any links to your research?
Your plan to work through past Google Code Jam problems sounds great. I'm sure that process would help build your intuition for what tools are actually helpful when working on this specific type of problem, which would probably have implications for lots of programs. Personally, I think this type of first-person empiricism is a highly undervalued resource.
Also, I wish there were more research labs that could support folks in UIs for programming like this. Right now there are only a couple and a lot of independent people dabbling.
Nice work! I like this bicycle analogy and believe we have a ways to go for improving programming environments.
In a far less ambitious vane, I've been trying to integrate the pytest-watch plugin to get a tighter feedback loop about regressions when making code changes.
Omniscient debuggers like this are a godsend, and too few and far between. Thank you.
When I was designing a complex, topology-transforming graph / search algorithm in C#, I had to cobble together my own "Algorithm Debugger" to fix some particularly tricky defects. My algorithm emitted a series of messages as it ran, which triggered viewport updates in different tabs, showing coroutine state, intermediate graphs, searches, etc.
It took me a month to write, and it was mired with bugs. Starting with Algojammer I probably could have knocked it out in a couple days.
This is amazing. I've been brushing up on algorithms for some upcoming interviews and could imagine this being super helpful to visualize/understand. Don't give up on the project! It's great!
This is great work and a lovely implementation of a lot of Bret Victor's (and others') ideas. If you're really interested in constructive feedback, I'd love to see the Sheets output directly on the timeline as I step through it but this is probably a very subjective thing.
There are so many ways this could be developed further, I love it!
The one thing I really wanted to do was add a kind of stacking visualisation to the timeline to show depth of callstack. At the moment it is not clear at all how deep you are in recursion. I was thinking thin drop shadows that make it look like the timeline is a stack of paper.
I did half implement "Markers" which are coloured lines on the timeline similar to breakpoints.
I decided to shelve it until I had rewritten the whole thing to be more stable, which I think will require doing it as a fork of CPython.
Recursion visualization would be fantastic, especially in languages like Python where the max depth is quite shallow. You could also develop modules for language-specific visualizations; it would be incredible to see memory management visualized (maybe as an addressed stack?) when writing in C, or how data ownership is being passed around a program in Rust. These would be great for lowering the cognitive load for developers writing more complex programs.
What I really like about your implementation is that it's scratching the itch of abstraction code (i.e. the inherently non-visual), as opposed to something like Light Table's WebGL example (which is very impressive, but not applicable to most developers' day jobs).
Yes, you've hit the nail on the head. The same is true of some of Bret's demos like the Braid one. I was trying to bring some of that tangibility to difficult abstract problems like from code jam.
I think one of the reasons games developers are so ahead of the field in making the abstract visible is they have a "canvas" right there that they are outputting to. It's very common to see really clever and intuitive visualisations covering the screen in game development, not because those guys are visionaries but because they are just trying to understand the code and that's how they naturally express themselves.
Basically what I wanted to do was come up with a solution "one step up the ladder of abstraction" (is my BV fanboy showing?) that let's users define their own, problem specific visualisations. This is where the concept of metacode came from. If you give people access to the data (omniscience), a blank canvas (sheet), and a way to express themselves (metacode) then natural curiosity should take over.
I'm not saying I achieved all that, but that was the idea. I think there's more work to be done on the language of describing the code, the current vocabulary is based around line numbers and execution steps which are brittle when the code is changed. What you want is visualisations that persist and change as you edit the code.
Really cool, I just tried live-py the other day (on emacs, but I think it works in other editors) and I loved how it printed the values of variables at every stage of a loop. This looks like that but more general and much, much prettier.
Excellent work @ChrisKnott, respect for one who ships stuff!
Either Chris or any of the Lispers hanging around here, can they throw deeper insight at the following question/assertion: Isn't what Brett Victor proposing 'visual programming' on top of a live REPL?
> 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?
I have had this project on the go for a while and have decided to put it out as-is because I can't forsee being able to complete it any time soon. For people who go straight to the comments, here's a video - https://www.youtube.com/watch?v=9XPE4uT0AdE - I have a very mumbly British accent but you should be able to get the gist of it...
The one line summary is - it's a "real" implementation of some of the demo GIFs in Bret Victor's "Learnable Programming" [0]
The original project goal was to create a "bicycle for the mind" that actually has a provably positive effect on people's performance in algorithm competitions like Google Code Jam/Facebook Hacker Cup. I don't think I got there, but I think there's enough stuff here to interest people on a Sunday afternoon...
Constructive criticism greatly appreciated, here or on Github issues page. If you are experienced with CPython (as in, experienced in contributing to the actual interpreter), then I would appreciate input on how to deliver the "recording" aspect of the project properly. The current implementation is very hacky.
[0] http://worrydream.com/LearnableProgramming/