Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Repl-Driven Programming

mikelevins.github.io

Post reply on HN
Print view View original

21–30 of 210 posts

Re: On Repl-Driven Programming

#21

Post by lispm »

TazeTSchnitzel wrote: post #15
mvc wrote: post #13

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…

This seems extremely pedantic. Python and Ruby will “read” the string inside the “eval” function.

In Lisp it makes a difference, because source code is data (other than text) and one can also compute source code in the REPL.

For example we can write a macro in Lisp and play around with it giving it code as data and see the result as code as data.

    CL-USER 1 > (defmacro while (condition &body body)
                  `(tagbody start
                            (if (not ,condition) (go end))
                            ,@body
                            (go start)
                            end))
    WHILE

    CL-USER 2 > (setf a 1)
    1

    CL-USER 3 > '(while ( (macroexpand-1 *)
    (TAGBODY START (IF (NOT ( (pprint *)

    (TAGBODY
     START   (IF (NOT ( (eval ***)

    1 
    2 
    3 
    NIL

Re: On Repl-Driven Programming

#22

Post by tlarkworthy »

avl999 wrote: post #18

Is 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…

https://news.ycombinator.com/item?id=25620899 (JavaScript)

Re: On Repl-Driven Programming

#23

Post by globular-toast »

blunte wrote: post #6

This 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. There are probably other ways but you want something that is quite tightly coupled, which all of those emacs packages provide. REPL driven programming is better served by an editor like emacs rather than vim. You want something where you can quickly write/edit code in one buffer and send it to the REPL with a couple of keystrokes. The lower the "cost" of this operation the better; it should be as easy as typing (as it becomes that frequent of an operation).

To help you choose: Common Lisp and Clojure are the most practical. They are both general-purpose languages with a wealth of libraries available. Common Lisp, as the older language, has far more literature available including some of the best programming books ever written. Scheme is the most beautiful language and has one of the best textbooks ever made: Structure and Interpretation of Computer Programs (SICP). Emacs Lisp is the most fun, practical but also the most quirky. Luckily, learning any Lisp will put you in a better position to learn any other Lisp.

Emacs Lisp is fun because it presents the most exciting part of REPL based programming: hacking a live, running system. Most of the time you run a lisp instance just for the purpose of development, but if your program is working and doing something, then why not hack on it while it's running? There's no difference between running a REPL in a "development" instance and a live, production instance. When you hack on emacs you are doing just that: hacking a live, running instance. It's not often you get to use a tool to hack on the tool itself while it's running.

Whatever you choose, good luck on your journey. I truly envy those who have yet to experience the beauty of Lisp programming. It changes you forever.

Re: On Repl-Driven Programming

#24

Post by magv »

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

Re: On Repl-Driven Programming

#25

Post by globular-toast »

lispm wrote: post #17
globular-toast wrote: post #11

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).

Yeah, true. I would still consider Clojure a "proper" REPL driven language, though.

Re: On Repl-Driven Programming

#27

Post by lispm »

phoe-krk wrote: post #3
GianFabien wrote: post #2

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…

> 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

Lots of Common Lisp systems support that in some way. Those record the location of the source code together with the machine code. These locations are stored in the image.

For example the standard CL function ED takes a function name and in many Lisp systems this will edit the function in some implementation specific way. In Emacs one uses M-. to get the definition of a function. In those implementation it will ask the Lisp for the location of that function source code.

The one system that worked similar to Smalltalk is Interlisp. See https://interlisp.org . It recently has been open sourced and is in the process of making it more accessible. It's a glimpse into an alternative world of computing from the past.

Re: On Repl-Driven Programming

#28

Post by CraigJPerry »

avl999 wrote: post #18

Is 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 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.

Re: On Repl-Driven Programming

#29

Post by nikhizzle »

magv wrote: post #24

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…

I also recommend jupyterlab for a similar experience. I was a hardcore vim terminal guy for 17 years, but now I won’t be going back.

The ability to interactively develop functions in almost any language inside the same environment had been revolutionary for my productivity given my short attention span.

Re: On Repl-Driven Programming

#30

Post by phoe-krk »

lispm wrote: post #27
phoe-krk wrote: post #3

Earlier quoted context omitted.

> 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…

> 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 Lots of Common Lisp systems support that in some way. Those record the location of the source code together with the machine code. These locations are stored in the image. For example the standard CL function ED takes a function name and in many Lisp system…

I know that many implementations record source location, but the source itself is still on the filesystem, not in memory, therefore making source locations useless if we move the filesystem out of the equation.

I also know that many implementations store the forms in FUNCTION-LAMBDA-EXPRESSION, but as I said, I know of no easy way to edit these in-memory forms either. Interlisp has had a structure editor to work with those, but that utility was not ported back into the CL workflow. I hope it eventually will be, with Interlisp being open sourced now.

Post reply on HN