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

31–40 of 210 posts

Re: On Repl-Driven Programming

#31

Post by lispm »

psykotic wrote: post #16

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

The mindset is slightly different. From a buffer one can interact with the system and it may show things inline.

The REPL, often called a 'Listener' in Lisp is an explicit dialog with the system, where the dialog is visible and parts of the dialog can be reused and inspected. Also the dialog can be suspended temporarily and we interact with the running code itself in break loops until we resume the original dialog in some way.

This usually is the horror for people wanting predictable code - where in an interactive Lisp, one can change code interactively at runtime.

Re: On Repl-Driven Programming

#32

Post by lispm »

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

Earlier quoted context omitted.

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

> therefore making source locations useless

Just make source available on the file system. Mount it. Copy it.

That's why Common Lisp has logical pathnames. Typically one uses logical pathnames in source locations. When I set up my application on a machine, I define a translation table to point to the source code.

One can also just use standard pathnames and mount the source code to a standard path. That's how one also has set up Lisp systems in clusters. Every machine mounts the source in a standard path (or a logical path) and a client system will then have access to that source code. The image still has the recorded locations.

Btw., even Smalltalk stores its source code not in the image. The Smalltalk source code is stored OUTSIDE of the image in the file system and it has to have the files available and needs to know the location of these source files.

See: https://squeak.org/downloads/

    The Squeak/Smalltalk programming system consists of three parts:

    * a virtual machine for your platform,
    * both image and changes files of a particular version, and
    * a sources file for the particular image file.
The source and changes files contain the source code of the running Smalltalk. An edit of source code will then lead to an entry in the changes file.

Smalltalk usually can decompile byte code, so one can edit code which has no corresponding source code, with some loss of original source information.

Re: On Repl-Driven Programming

#33

Post by kitd »

lispm wrote: post #21
TazeTSchnitzel wrote: post #15

Earlier quoted context omitted.

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 > '(wh…

All very nice, but in Python/Ruby/etc, the source code isn't data. So your point is only relevant to Lisp, not REPLs generally.

Re: On Repl-Driven Programming

#34

Post by lispm »

kitd wrote: post #33
lispm wrote: post #21

Earlier quoted context omitted.

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 > '(wh…

All very nice, but in Python/Ruby/etc, the source code isn't data. So your point is only relevant to Lisp, not REPLs generally.

That's why it is not a REPL (Read Eval Print Loop), but a ReadString, Parse, Compile, Execute, Loop.

Re: On Repl-Driven Programming

#35

Post by andybak »

pjmlp wrote: post #9
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.

Dart, Java and .NET have a kind of edit-and-continue without images. It is all a matter of tooling.

> It is all a matter of tooling.

I think the point of the article is that tooling can only get you so far. The abstraction they attempt to provide is leaky if the support for this style of development isn't firmly designed into the entire system.

Re: On Repl-Driven Programming

#36

Post by rightbyte »

tluyben2 wrote: post #12

I think it would help as well to list languages that have various levels of 'real repl' implementations. Wonder what modern (systems you can 'make money with') there are that support this. I know common lisp + smalltalk and worked with both and really liked them for these reasons. I miss this functionality all the time as it was far more efficient (to me!) than modern debuggers.

Isn't Python and Matlab a 'real' REPL? They are money makers.

Re: On Repl-Driven Programming

#37

Post by alpaca128 »

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…

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

Defining keybindings for splitting the window, opening a terminal buffer and copying a paragraph does not really require a plugin. That's one of the features I like most in Vim, its ability to just map any input to another sequence of keypresses can replace whole scripts and plugins provided you're fine with readability comparable to regular expressions.

Re: On Repl-Driven Programming

#38

Post by alpaca128 »

nikhizzle wrote: post #29
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.

If you're using Jupyter within the browser you can have both via the FireNVim plugin in Firefox. It connects to NeoVim in the background and lets you edit any multi-line text field with 100% of your personal Vim configuration, the only limitation is that the color scheme cannot be changed.

Re: On Repl-Driven Programming

#39

Post by milansuk »

REPL is very useful, but few months ago I realize[0] that setting a break-point is not easy as people think, because the program can visit the line through multiple paths(function can be a call from different places), so you can spend a lot of time debugging/finding the right path to the line, which means that you probably have to set more break-points to get the program to the right place faster.

[0] https://skyalt.com/blog/repl.html

Re: On Repl-Driven Programming

#40

Post by mettamage »

rightbyte wrote: post #36
tluyben2 wrote: post #12

I think it would help as well to list languages that have various levels of 'real repl' implementations. Wonder what modern (systems you can 'make money with') there are that support this. I know common lisp + smalltalk and worked with both and really liked them for these reasons. I miss this functionality all the time as it was far more efficient (to me!) than modern debuggers.

Isn't Python and Matlab a 'real' REPL? They are money makers.

The article specifically stated that Python does not have a real Read-Eval-Print-Loop mechanism like Lisp or Smalltalk. For example, the Python REPL doesn’t go into a breakloop mechanism for undefined functions.
Post reply on HN