On Repl-Driven Programming
mikelevins.github.io
On Repl-Driven Programming
1–10 of 210 posts
Re: On Repl-Driven Programming
#2AFAIK both Lisp and Smalltalk environments are image based. That is, all source code and all objects are stored in memory. You need to save that image in order to continue from where you left off. Snapshots are also used to allow rollback to previous "good" states.
Re: On Repl-Driven Programming
#3AFAIK both Lisp and Smalltalk environments are image based. That is, all source code and all objects are stored in memory. You need to save that image in order to continue from where you left off. Snapshots are also used to allow rollback to previous "good" states.
> That is, all source code and all objects are stored in memory.
Common Lisp usually stores code in form of normal source files that are then possible to load into a clean-slate Lisp image. It's possible to dump images and restore them, but it's not the norm of working with CL.
Unlike in Smalltalk, I currently know of no tools that allow one to easily edit source code of functions/methods that have already been compiled into the system, and therefore the dependency on the filesystem source files is heavy and immediate.
AFAIK dumping images in CL is mostly used for shortening load times by preloading code and data, and for application delivery, but not for live editing support.
Re: On Repl-Driven Programming
#4For what it's worth, IPython's "autoreload" magic and Julia's "Revise" package get you _closer_ to what the author describes. In both cases, one can define functions/classes/structs in a file/module, load it in a repl, create objects etc, modify the file and have the changes propagate through to live objects
Re: On Repl-Driven Programming
#5For what it's worth, IPython's "autoreload" magic and Julia's "Revise" package get you _closer_ to what the author describes. In both cases, one can define functions/classes/structs in a file/module, load it in a repl, create objects etc, modify the file and have the changes propagate through to live objects
You can also add breakpoints which automatically occurs when exceptions are raised. Which is similar to the breakloop functionality mentioned in the article.
Re: On Repl-Driven Programming
#6This article helps us understand what real repls enable that interactive language shells do not.
What would be very helpful next would be a video comparison of writing a program that is just complex enough to not be trivial or too artificial, first using the common approach, and next using repl-driven approach.
Re: On Repl-Driven Programming
#7I think the best modern example is ObservableHQ [1]. I took a screen shot yesterday when I found myself interleaving runtime, TDD, IDE, debugger and partial recompilation in one window. It blew my mind.
I have never experienced such a productive programming environment. https://twitter.com/tomlarkworthy/status/1345321532650905601...
For there I can change variable at runtime. Change the implementation and have the tests auto run. Correct the tests, set a breakpoint in the test or implementation with "debugger;".
I think it might be more productive than smalltalk because of the spreadsheet-like reactive recomputation. Plus it supports real markup as inline documentation.
Re: On Repl-Driven Programming
#8For what it's worth, IPython's "autoreload" magic and Julia's "Revise" package get you _closer_ to what the author describes. In both cases, one can define functions/classes/structs in a file/module, load it in a repl, create objects etc, modify the file and have the changes propagate through to live objects
Closer but still so far. As soon as you have more than one module in Python it completely falls apart, despite any autoreload magic. It just isn't the same at all as REPL based programming. In Lisps you can write your entire program with an instance and a REPL running the entire time. No restarting the instance required. It works because it's just how Lisp works. A REPL is a trivial thing you can write yourself that runs in the same instance.
Whenever I think about it I can't quite put my finger on exactly what Python would need to make it the same. It's something to do with the way imports and namespaces work, though.
Re: On Repl-Driven Programming
#9AFAIK both Lisp and Smalltalk environments are image based. That is, all source code and all objects are stored in memory. You need to save that image in order to continue from where you left off. Snapshots are also used to allow rollback to previous "good" states.
Dart, Java and .NET have a kind of edit-and-continue without images.
It is all a matter of tooling.
Re: On Repl-Driven Programming
#10For what it's worth, IPython's "autoreload" magic and Julia's "Revise" package get you _closer_ to what the author describes. In both cases, one can define functions/classes/structs in a file/module, load it in a repl, create objects etc, modify the file and have the changes propagate through to live objects
You can also add breakpoints which automatically occurs when exceptions are raised. Which is similar to the breakloop functionality mentioned in the article.
Yes, running pytest with the --pdb flag will drop you into the debugger on an unhandled exception which gets a comparable workflow but it's not quite the same as, a) writing tests to file first is not repl-driven development, and b) you generally have to think about doing it first.
In an ideal repl-driven world you could write the test in the repl entirely and commit it to disk once you're ready.