11–20 of 210 posts
I'm thankful for this article shedding light on what it really is. It's sad that most programmers haven't experienced.
That means the code you enter at the prompt is converted from a String into literal data that can be evaluated (read). The data is then evaluated to produce a result (eval), and the result is then printed (print).
If that's not what your REPL is doing then it's not a repl.
That is not what's going on in e.g. python or ruby "repls". There is no "read" step here converting the text of the program to data. The program text is simply passed to an "eval" function that produces the result directly.
As someone who has used CL and Clojure to write non-trivial code using REPL driven programming it makes me mad that the word REPL has been hijacked to mean "interactive shell". I'm thankful for this article shedding light on what it really is. It's sad that most programmers haven't experienced.
Definitions matter. A repl is a read, eval, print, loop. That means the code you enter at the prompt is converted from a String into literal data that can be evaluated (read). The data is then evaluated to produce a result (eval), and the result is then printed (print). If that's not what your REPL is doing then it's not a repl. That is not what's going on in e.g. python or ruby "repls". There is no "read" step here…
As a long-time but now lapsed Lisper, I never understood some people's elevation of the REPL. A command-line REPL is a poor man's development environment. If you're doing interactive development in Lisp, you'll be far more productive if you use a normal buffer with eval-defun, eval-buffer and friends. When debugging, you'll primarily want auto-updating watch expressions and object inspectors. And when you do have good use for a REPL, you'll still want it to exist within a proper buffer with persistent history, inline object inspection, etc, instead of the low-effort rlwrap terminal experience which usually passes for a REPL.
All of this holds doubly true for Smalltalk environments.
As someone who has used CL and Clojure to write non-trivial code using REPL driven programming it makes me mad that the word REPL has been hijacked to mean "interactive shell". I'm thankful for this article shedding light on what it really is. It's sad that most programmers haven't experienced.
I have never found the REPL (the Python/Ruby REPL which is not a "real repl" according to this article) to be that useful beyond quickly playing with API of a library with sample data and getting a feel of it and its return types. So this version of repl described in the article does sound interesting.
AFAIK 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 compi…
As someone who has used CL and Clojure to write non-trivial code using REPL driven programming it makes me mad that the word REPL has been hijacked to mean "interactive shell". I'm thankful for this article shedding light on what it really is. It's sad that most programmers haven't experienced.
The examples from Mikel are just not possible in a default Clojure setup. It does not have break loops and it does not have a dynamic object system (by design).