Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
My concept of a "REPL" is mostly defined by emacs. You would have a buffer with a code file, with an active jupyter kernel with the correct dependencies loaded in it. Then one would send any active region with `C-c C-c` and get timely feedback.
With this mode https://github.com/nnicandro/emacs-jupyter one can connect to a jupyter kernel running locally or remote (would mostly prefer SSH port forwarding or kubectl port-forward the remote jupyter server). It makes life so much easier to interact with cloud environment (e.g. spark).
For those of us that don't use Lisp (or Emacs+SLIME), and are stuck with Python/Julia/Lua/etc and Vim may I give a practical recommendation? The Vim-Slime plugin [1] is a half-decent way of making interactive development work. With a bit of tuning you can make it start a terminal emulator window inside Vim, and have it send the current paragraph of your source code into it with a press of a button.
While not as great as working with a proper Repl-oriented language (as the article explains), this is still so much more pleasant than having to re-run the whole program every time you change a function.
[1] https://github.com/jpalardy/vim-slime
I’m thinking a SQL console mostly qualifies per the article’s idea of a repl. The break loop concept isn’t perfect there though.
I’ve always liked the python repl, breaking out a django repl and being able to manipulate the db via the api always felt like a super power to me when coupled with the expressiveness of basic python but last year i started dabbling with Clojure. My first “real” repl driven development experience.
2 things stood out for me:
1. You end up with some genuinely useful executable documentation and it just makes sense to me to preserve some of what i did in the repl while developing. I saw this first here: https://github.com/stuartsierra/component/blob/master/dev/ex...
2. Integration with your editor is essential - having a keystroke to send a form to the repl or evaluate in-line is a real productivity boost. It’s like writing code while an intelligent debugger is permanently live. You don’t need to wait for a compiler run then parse the feedback, it’s just instant in-line runtime feedback. “Paredit” is really sweet. I used calva in vs code for this and tbh it’s as attractive as the language in some ways. I have no idea how to meaningfully apply those concepts to something like python or javascript though. They just don’t lend themselves to that kind of structural editing.
And nvim-R for vim/nvim and R.
[1] https://github.com/jalvesaq/Nvim-R
It does not offer the full experience. It has no breakloop and no ability to browse and edit the live running environment. It has no ability to rummage around inside the dynamic environment of a suspended function call, much less to redefine the suspended function or the types of its parameters, nor to restart the suspended call. Indeed, the JVM makes some of that stuff really inconvenient to do.
You cannot do everything from the Clojure repl in the way you can from a Common Lisp repl or from a Smalltalk worksheet.
I don't know that the Clojure language design forbids it; you might, for example, implement Clojure on top of a Lisp or Smalltalk environment and hook up their tools to Clojure through its interop. That might work, and ruricolist has been working on such an implementation called Cloture:
https://github.com/ruricolist/cloture
But existing Clojure implementations don't have the full set of tools.
I agree with you that the immediate start-up and feedback is a great benefit to the coder. This is why I dislike complex, Rube-Goldbergian REPL systems.
There is a use-case for a throw-away interaction with a REPL. For example, how does $builtinFuncX work, or how would $data best be imported into a structure?
A REPL can also be a good initial approach to a more ambitious problem. In this case, a REPL can be good for focus and discipline.
If the second case is going to answer your concern and be constructive, it's necessary to be able to build the code for sharing and cleanly export the code for re-use.
I've had success tackling challenges using REPLs for Python and Perl [1] in both ways. But no tooling is going to solve the problem of a sloppy teammate who claims success just because "it compiles" and "it works on my box". A person who knows how to build good tooling goes further.
[1] https://github.com/viviparous/preplish
> At the end of the day, you quit your environment and shut down. How do you ensure your interactive work is not lost and the environment is still what you expect it to be when you start again the next day. How would you compile such a program?
Modern Smalltalks have solved this problem. Smalltalk has the concept of Packages just like Java, and as you go along building your environment, even though you are modifying the Smalltalk image, you can export these packages to plain-text files, and put them in Git, just like any other language. The environment itself supports Git integration (called Iceberg in Pharo).
> Also, if significant parts of the source code are written inside the REPL, wouldn't the lack of modern IDE features be a hassle? No syntax highlighting, no code completion, no code inspections etc. Or are there tools that offer those?
The command-line REPLs that other languages have are NOT what you get in Smalltalk. I believe the author means the entire interactive environment, and the "style" of development is REPL, not the actual UI. The Smalltalk "IDE" is just as powerful as any other IDE, including code completion, automatic generation of certain getters/setters, renaming methods/classes, finding uses, jumping to declarations and even refactoring within methods. The difference between a normal IDE for Java is that this "IDE" is pervasively available, including in breakloops and the debugger. Since the system is live, there is no separate notion of debugging, the debugger is always there, and you can use all the editor IDE features when stopped in a debugger. You no longer have to deal with a crippled debugging environment way different from your authoring environment. It truly is mind-blowing!
I highly recommend giving Pharo Smalltalk a spin (by following their MOOC or similar). This video is also worth a watch - https://www.youtube.com/watch/baxtyeFVn3w
I did most of this year's Advent Of Code in Smalltalk and saved it in Git just like any other language. Someone else can then import it into their image. https://github.com/nikhilm/AdventOfCode2020.
Note that the source code looks very verbose, but you never actually interact with the source like that. The source is just a serialization. Your actual environment only ever shows you UI elements and entire IDE windows describing your classes and individual methods.
The only thing I miss in Pharo is that it doesn't have Vim keybindings :)
I use a vim plugin called slimux to send code from vim into a REPL running in another tmux pane. It works really well.
Here's the fork that I'm currently using https://github.com/grusky/slimux
I use it with python and node.is and MySQL and psql
It's great because it can work with any REPL.
I used to use jupyter notebooks but almost exclusively use slimux now unless I need to some data visualisation or computer vision.
VS code's ipython REPL is quite good and has support for images and graphs.