This is what makes R (and Julia I think) so special (where everything evaluates to an S-expression). Having REPL for exploratory data analysis is especially useful.
On Repl-Driven Programming
51–60 of 210 posts
Re: On Repl-Driven Programming
#52For 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…
And nvim-R for vim/nvim and R.
Re: On Repl-Driven Programming
#53I admit I have not experienced true REPL driven development as the author defines it, but I have created an easier way for "development with a REPL" in vim. I love it because it's like a looser, faster Jupyter notebook, and it works with any language that has a REPL.
It works by sending highlighted text to vim's terminal buffer. I wrote a short blog post with a demo and the vimscript code here:
https://mcastorina.github.io/posts/vim-repl-driven-developme...
Re: On Repl-Driven Programming
#54I admit I have not experienced true REPL driven development as the author defines it, but I have created an easier way for "development with a REPL" in vim. I love it because it's like a looser, faster Jupyter notebook, and it works with any language that has a REPL. It works by sending highlighted text to vim's terminal buffer. I wrote a short blog post with a demo and the vimscript code here: https://mcastorina.git…
I should have read more comments before posting, but it seems I reinvented an inferior wheel:
Re: On Repl-Driven Programming
#55Definitions 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…
This seems extremely pedantic. Python and Ruby will “read” the string inside the “eval” function.
[deleted]
Re: On Repl-Driven Programming
#56He's right to emphasize the properties of the systems that support interactive development with a long-running image. In Common Lisp, the difference between defvar and defparameter is a simple example. Traditional Smalltalk systems only supported image-based development. But I always preferred the moderate approach exemplified by most Lisp systems where the source code isn't overly entangled with the image state. As…
Why not all of it? Long ago, I was doing Objective-C development with an embedded F-script REPL, hot code swapping, and XCode's built-in debugger. It was very nearly as nice as Smalltalk in many ways, only without the whole IBD situation.
that doesn't sound nearly as nice as smalltalk
Re: On Repl-Driven Programming
#57Is there a modern non-Smalltalk, non-Lisp (or its derivatives) non functional imperative programming language that supports a "real repl" that the author is talking about? I don't know if that kind of environment is for me but I'd love to give it a spin. 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 librar…
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 expe…
have you ever tried something like https://gtoolkit.com/
Re: On Repl-Driven Programming
#58For anyone who would like to see what REPL-driven programming looks like in practice, take a look at this video here:
The author uses the Clojure REPL to walk through the process of developing some non-trivial functionality (calling an API and parsing the results).
It’s a good intro to what it looks like to interactively build a program while it’s running.
Personally, I’ve found that having such a tight feedback loop makes development a lot more enjoyable.
Re: On Repl-Driven Programming
#59> If it now works correctly, then congratulations; you found the problem! This notion if “correct” is “finished the current example as intended”. Running a suite of unit tests would give me more confidence. Even that is only for programming in the small and that is comparatively easy to programming in the large. I don’t see how a REPL would help there. That means a REPL makes easy things easier and hard things are un…
>Even that is only for programming in the small and that is comparatively easy to programming in the large. I don’t see how a REPL would help there.
Because the right way of programming in the large is programming in the small and combining things (e.g. functions, components, classes, whatever, etc.), not building some huge monolithic monstrocity (this is orthogonal to monoliths vs microservices btw).
Plus, this "programming in the large", when it gets to, say, 10.000.000 lines of code will still have bugs and behavior you need to check/search for/and fix in individual parts, and this "restarting/dynamic change" REPL will still be a great tool here.
Re: On Repl-Driven Programming
#60This 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.
Why not just learn a Lisp yourself? You'll get far more out of it than watching a video. The old adage is still true: learning a Lisp makes you a better programmer. Your choices are: * Common Lisp: install emacs, SBCL and set up SLIME, * Clojure: install emacs, Clojure and set up CIDER, * Scheme: install emacs, racket (or guile) and set up Geiser, * Emacs Lisp: install emacs. You'll notice that they all involve emacs…
>Why not just learn a Lisp yourself? You'll get far more out of it than watching a video.
Because one is a 30 minute endeavor and the other is a weeks/years endeavor.