Well if we're creating a list then I would also add Factor, which provides a full graphical REPL with code browsing, help/docs system, step-thru & interactive debugger, full data/state inspection and much more.
A REPL doesn't let you write fewer tests. You let yourself write fewer tests because of the mistaken idea that manual testing replaces a coded test that anyone can run again.
Any testing that had been done in the REPL goes out the window as soon as someone needs to change the code, and verify that things haven't broken.
A REPL can get you faster to a testable state. Say you're following TDD and so you need a failing test which passes in oreder to justify a code change. You might not exactly know what that test is, if you're exploring the problem itself and possible solutions. You use the REPL to iterate quickly on things. Then when you settle on the code change you want, you can write the test, and verify that it fails without the change.
I get it now, the screenshot shows it all. I have gotten good with debugging php, but I can see that leaning into repl as a development environment has a lot of benefits. Looks like you can experiment with code, keep the returned data, and reuse what you come up with.
Php has psy shell. When it is loaded for a Drupal/symfony site, you can run api calls against the database. This is where things get tricky.
I can imagine better tooling for psy shell that could protect the underlying data to experiment with code before executing it. It would be great to develop system updates this way if we could work on a copy of the data until we’re happy with the output, then run it for real.
I use psy shell to load services and see what their methods do. The environment is not persistent, but maybe I can export my work to a file. Would love to keep results around for testing or running other functions on.
Ultimately, a good REPL enables you to test assumptions and behaviours before writing a single line of code that rests on them. It can be a life-saver in dynamically-typed languages with complex operator semantics and large libraries. How can that operation fail? How does it work on boundary conditions? You can test these behaviours instantly in isolation without ever "guessing" in your code.
IMO exploration of complex semantics and/or libraries is quite often a bit futile exercise without appropriate boilerplate/scaffolding.
Which means ultimately, a good REPL is an advanced debugger with code sideloading and reloading/monkeypatching. Running in isolation (in context of the REPL, not the attached-to program) would be awesome, but not trivial (if possible at all) in many cases.
To illustrate, suppose you have some network service (an API in todays talk) and want to play with some form of middleware or new endpoints. You need functional boilerplate to encode, sign, send a request and receive, decode, parse a response. You want to load those parts of the program and play around.
The REPL as such is on its base a relatively primitive thing: it reads an expression from a stream, evaluates the expression, while doing that it prints any side effects and then prints the result.
On top of that one can image various user interfaces.
* sophisticated text based repls with integrated repl debuggers and things like structure editors: example Interlisp.
* graphical REPLs which use a graphics capable stream
* presentation-based REPLs like the one from Symbolics Dynamic Windows or CLIM (the Common Lisp interface manager)
* rich structure browser REPLs like the one from Apply Dylan
* REPLs inside a text editor UI
* REPLs inside an IDE
Then there is also the Notebook user interface, which was mostly developed around interactive mathematics software with visualization features. Mathematica made it popular (there were a few earlier systems with similar ideas).
It adds a notebook-based graphical user interface with 2d and 3d graphics. It also usually makes it kind of persistent -> one can store and reopen saved Notebooks.
No wonder that it is popular in areas where data visualization and maths is important. I haven't seen it used outside of that area that much, though.
Something I've been thinking a lot about for Rust is what can and should a REPL experience be for a compiled language (ie what are reasonable compromises).
There seem to be two repls that haven't gotten much traction:
There have been little and big nits that have held me back from wanting to push these further, including
- Bad defaults (having to opt-in to panic handling)
- Command syntax feeling out of place and likely not beginner friendly
- Limits on variable preservation
- Lack of introspection (at least irust as `:type`)
So far I've been punting on wanting to improve this area by instead focusing on polishing up a rust script solution in the hopes of getting it merged: https://github.com/epage/cargo-script-mvs
> (A good REPL) gives you access to your whole project code. You should be able to call any piece of code written in your project of its dependencies. As an execution platform, the REPL should reproduce the conditions of running code in production as much as possible.
Then, some languages (like Clojure) have global functions like `doc` or `apropos` that helps you write code.
=> (doc map)
-------------------------
clojure.core/map
([f coll] [f c1 c2] [f c1 c2 c3] [f c1 c2 c3 & colls])
Returns a lazy sequence consisting of the result of applying f to the
set of first items of each coll, followed by applying f to the set
of second items in each coll, until any one of the colls is
exhausted. Any remaining items in other colls are ignored. Function
f should accept number-of-colls arguments.
=> (apropos #".+?reduce")
-------------------------
(clojure.core/areduce clojure.core/ensure-reduced clojure.core/unreduced ...)
So when you write Clojure code with a REPL, you hardly need anything else but a REPL + text editor that can connect to said REPL.
The docs in the Elixir REPL are such a pleasure to use. Tab completing a function will show a list of possible matches, and then you can type `h function_name` to see the doc for that function.
It's incredibly useful, partially because the standard library is well organized. For example, maybe you need some string manipulation function, but you're not sure what it's called. You'd type `h String.` and then hit tab. Now all the functions of that module are listed. Ah, String.graphemes looks promising - so you finish your line `h String.Graphemes` and skim the doc. Now, to make sure you understand, you might type `String.graphemes("foo")` and then see the result is what you want.
I almost never have to Google for an answer when writing Elixir (at least for simple stuff) because the REPL is so robust as a doc lookup tool.
My only wish is that the vscode extension had some features around sending buffer code to the REPL like SLIME or other Lispy editor plugins. You can reload code, but it's a little more manual than I'd like.
> the truth is that not all REPLs are created equal
Indeed.
Second to Smalltalk (where the entire environment is your REPL), the best REPL is a Common Lisp REPL. Even the most primitive of Common Lisp REPLs is more useful than a Clojure REPL. This is because the Common Lisp is designed with interactive development in mind.
In Common Lisp, an error doesn't print out a stack trace and leave you puzzling to parse its meaning – it drops you into the debugger where you can inspect the entire system (including local variables on the stack where you are), invoke whatever restarts apply, modify code and continue on.
True, the CL REPL is more useful than the Clojure REPL, but CL has a 20-30 year head start in development. Plus, Clojure was developed as a hosted language, and runs on .NET, Javascript, JVM, and even Dart (in-progress).
Since exceptions are quite deeply integrated into those platforms (as opposed to conditions), it has "bled through" to the Clojure APIs, and, in turn, REPL.
Speed. Whether it's hot reloading, auto-completion, history searching etc. as has been discussed in the thread, it's really all about doing things faster with less input and better feedback.
I like IPython but: I always lose my IPython session and have to start over again. I find copying and pasting to and from an editor to be clumsy. I sometimes have to keep "%load"-ing the same file over and over again to test my changes.
I do want to be able to write my Python code with the help of a REPL.
it's my favorite REPL ever. super easy to use, full of features (like, always storing the last variable on a number with %), you can easily browse both documentation with ? (as in list?) or the source code (when available) with ?? (as in requests.get??).
the only thing i wanted was better integration with my editor of choice (nvim).
With node you can definitely reload a module without restarting the REPL, you just have to make sure to reassign your references to the new module. The ecosystem generally haven't considered things like that in the past though, so requires quite a bit of setup to get working well in your own apps.
I've been using the Hy REPL[0] whenever I've wanted to drop into a python REPL. The lack of whitespace formatting with Hy is great, and it still has access to all of python's libraries.
With TDD you can work without a REPL :) If you really want a REPL, use something like TypeScript.
Lisp and Smalltalk look neat in screencasts and have been hyped to the stars for decades, but for getting things done in the modern world, nothing beats a good, statically typed, object-oriented language in an IDE like Jetbrains or Visual Studio (Code). In addition to the benefits of static type checking, in an IDE you can type a variable name and a dot, and get a list of valid methods, exploring what's possible with a given object much faster than even a Lisp machine or Smalltalk environment would avail you. And in a modern IDE, running any test you've written is just a click away.
Lisp and Smalltalk were groundbreaking in their day, but modern languages and environments build on what they provided.
I think the elisp repl is a good example, can reload on the fly and see result on the fly, also can define load path directly in repl, not like jshell etc have to set class path before entering repl, which is not so user friendly
7. live object exploring (in Ruby pry, ls something returns a human-oriented list of methods, grouped by their owner module, contants, ivars. also cd something changes context, dramatically reducing typing)
Highlighting in the REPL is not needed, because your editor does code highlighting already and as Val argues in this blogpost, a good REPL is one you don't interact directly with but via your code editor.
https://mikelevins.github.io/posts/2020-12-18-repl-driven/
https://hyperthings.garden/posts/2021-06-20/hell-is-other-re...
They say Common Lisp (and Smalltalk) provide the "best" REPL experience.