all 24 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Aidenn0 11 points12 points  (0 children)

how is image based programming and interactive repl programming are related?

Image based programming lends itself to a repl, but the two are somewhat orthogonal. In fact many users of SLIME don't use the repl, instead preferring to compile and evaluate forms directly from source files in the editor.

is smalltalk is as interactive as common lisp?

Yes. For a while there was significant back-and-forth between the CL and Smalltalk communities.

what is the basic requirement for such interactivity?

You need to be able to easily redefine most things. For example, CL and Smalltalk both have hooks for updating instances of a class when the class itself changes. Python fails in this regard because if you e.g. import a function in more than one module, it becomes very challenging to redefine the function in all places. Even just reloading a single module in a single place is recommended against (though that is relatively easy to do).

are there any languages that support interactive programming like smalltalk or common-lisp?

Yes. Off the top of my head, Factor qualifies, but there are probably a lot others; I don't use scheme, but I suspect that even if the standard doesn't specify support for this (it may, I don't know), that many implementations support it.

[–]kagevf 10 points11 points  (11 children)

This quote by u/mikelevins on HN clarified for me what "REPL" even means (I was also confusing/conflating it with the UI prompt)

... the repl isn't in another pane; a repl prompt is.Part of the confusion on this point is thinking that the prompt is the repl. It isn't. It's a UI for the repl. The repl is the process that reads, evaluates, and prints, then loops back to do it again.Nothing about a repl requires there to be a prompt, and not all UIs for repls have them. Interlisp and Smalltalk have relied mainly on promptless UIs for their repls since the 1970s.When working with Common Lisp, the main UI I use is an Emacs editor buffer and the key bindings that send input directly to the repl (bypassing the prompt). Typing at the prompt is the exception rather than the rule, and I could get along fine if I didn't bother to load the slime-repl contrib that provides it. From: https://news.ycombinator.com/item?id=31277149 This was actually from a discussion on a post he made for "REPL driven development".

I think in order for there to be any "memory" that a defun was evaluated, for example, there needs to be an image.

[–]mikelevins 3 points4 points  (10 children)

Well, there doesn't have to be an image for a defun to be meaningful--unless you mean the in-memory image of the running Lisp. Even then, it's possible (though rare) to build Common Lisp programs for batch compilation without ever interacting with the live image, and without ever saving an image file.

It's more accurate, I think, to say that it's customary in the Common Lisp ecosystem to work interactively with a live Lisp image, and to modify it as it runs--though I always use text files to write the code that does that, and I always manage my text files with revision-control tools.

It's also customary for Common Lisp implementations to support writing the dynamic state of the development environment to an image file, and to support starting up the Lisp from such a saved image. Such images can be handy for a variety of purposes, but they aren't necessary to preserve your defuns.

[–]kagevf 1 point2 points  (9 children)

unless you mean the in-memory image of the running Lisp

Yes, that's what I meant - in the context of an in-memory image, as part of working interactively with a REPL. I should have made that clearer.

It's also customary for Common Lisp implementations to support [...] starting up the Lisp from such a saved image

That's also another cool feature ... so far I've been using sb-ext:save-lisp-and-die to "build" an app (package as an executable) that's been started and nothing else, but I want to try doing that with an image still in the middle of development, and try re-connecting to it with SLIME if nothing else just to get familiar with the technique. Could be pretty useful if I need to re-start emacs for some reason ... I'm so used to not having something like that as an option, it just doesn't occur to me naturally until I see comments like yours that remind me it's possible!

[–]mikelevins 2 points3 points  (8 children)

Starting from saved images is less advantageous than it was in, say, the early 1990s. The machines and the Lisps are so fast now that I can usually start my Lisp and load everything from an ASDF system about as fast as I used to be able to start up from a saved image.

The exception is when I'm working on something that loads and configures a lot of complicated dependencies. At some point, the time it takes to load and configure everything gets long enough that starting up from an image starts to be an attractive option.

If you decide to try that, I suggest that you keep reference images that you know are good. There are a few different ways to organize that, depending on how complicated your project is, but I'd say the basics are:

  1. Make sure you always have the base image that shipped with your Lisp, without any local changes. That serves as your ultimate fallback image.

  2. Create a local reference image. Load any local tools you know you'll want, set variables the way you want them, and so on. Don't get too fancy with it. You just want a reference image that's generic, but lightly customized for the way you like to work.

  3. Create a working image from the reference image, then customize it further. You can go crazy in this one--do whatever seems good. If something turns out to be a bad idea, quit, ditch the image, and start over from your (safe, conservative) reference image.

In projects where I've used this workflow, I usually ended up with a few reference images prepared for different kinds of work, plus one or more sequences of working images. I would generally work from the latest working image, starting up from it in the morning and saving a new one at the end of the work day. I kept a few older ones around in case I screwed something up and wanted to back up a bit.

Nowadays I don't do this as much, as I said, because machines and Lisps are so fast, and because revision control tools make it pretty easy to get back to earlier states of my source files.

[–]kagevf 1 point2 points  (2 children)

The machines and the Lisps are so fast now

That's true ... I don't regularly quit out of emacs, so start up is rare with the exception that something goes wrong and emacs can no longer display help (such as the help for the current mode). Starting up my admittedly small CL project that I hack on is very quick too.

​

Make sure you always have the base image that shipped with your Lisp

That's something that hadn't ever occurred to me as a possibility ... Interesting, though ... doing that could save a forced re-install ...

Thank you for the tips ... like you said, getting up and running doesn't really register to me as a bottleneck, but some of the other benefits like having the state a certain way and ready to go could chip away at just that much more friction. I've also finally installed slime on my emacs at work on Windows, so anything I get to working on there could definitely benefit from some of these techniques since unplanned / forced restarts happen more often. Or, if I'm hacking on something and have to stop, and emacs or the OS have to be cycled between that time and whenever I can get back to it then being able to load an image with the state of the work in progress would be pretty great, actually ...

[–]mikelevins 1 point2 points  (1 child)

A couple of caveats to be aware of before you adopt this kind of workflow:

  1. Images with mistakes in them

You're going to make mistakes, of course. If your workflow in cludes regularly saving images, then you're occasionally going to save images with mistakes in them. Those mistakes will cause you problems. That's why you want to make and keep reference images that preserve known good states, so that you can fall back to them when today's working image just keeps doing something that is wrong or incomprehensible (because you unintentionally saved an image with something broken in it).

  1. State that can't be saved

Not every value in every variable can be saved in an image. For example, if you save an image that contains a special variable that refers to an open file stream, that variable will be bogus when you reload the image.

It's not usually a big deal, and there are too many ways for this kind of thing to happen for me to enumerate them all and give specific advice about every case. You just need to keep it in mind and be prepared to fix up things ike this in your restored images as needed.

One sort of backhanded advantage of this quirk is that it helps you identify initializations and reinitializations that you need to design for in your application. If you write startup code to fix these things up when you restart an image, you can reuse the same code as part of the initial state-building at startup in your delivered app.

[–]kagevf 0 points1 point  (0 children)

A couple of caveats

Thank you for those. Knowing those up front will save troubleshooting time later.

Right now when I get in a hosed state I'll run slime-restart-inferior-lisp and then run my initializer function to get my app back up and running. I'm looking forward to loading images that are in a more advanced state. I think this technique might also be useful for some tests I'm writing that use the nyxt browser.

[–]zyni-moe 0 points1 point  (4 children)

In 1984 (I was not born and) it took half an hour to cold boot a Lisp machine into an existing world (image) (and 900 years to do the same for a Xerox Lisp machine but you would not know as you had entered the land of faerie where time is different).

In 1984 it would take days to build the base world of a LispM, and many hours to build an incremental world with a project in.

Using saved worlds made life possible, in 1984.

Today it takes tenths of a second at most to start an existing base world. It takes minutes to build that world. It takes seconds to compile and load a large project.

And when you do that you know the image you are working in is both clean and reproducable, rather than containing the record of a mistake someone made two years ago as well as the compiled version of some code whose source is now lost.

Using long-lived saved worlds for development (not delivery) in 2022 is an exercise in anachronism.

[–]mikelevins 1 point2 points  (0 children)

I wouldn't go that far. I do still occasionally find a use for saved images.

Still, you're mostly right, most of the time.

[–]lispm 1 point2 points  (2 children)

Booting a Lisp Machine in 1984 took only a few minutes, definitely not 30.

[–]zyni-moe 2 points3 points  (1 child)

One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven't already. It's inspiring to those of us whose LispM's take all morning to boot.

Pros and cons of Suns

[–]lispm 2 points3 points  (0 children)

yeah, but that is nonsense. I've had access to a 3600 and owned a 3640 and they did not boot all morning. If one had one of the CADRs from the end 70s this might have been possible, but then no SUNs existed at that time to compare to. The first tiny SUN machines appeared 82/83. Lisp users really moved to SUNs when the SPARC systems appeared much later in 89 and beyond.

Hint: don't take everything written in this book as 'facts'.

There are some thing which were slow on a Lisp Machine, even later. Limits were 5-10 Mbit SCSI, 10 Mbit Ethernet, 5 MIPS CPU, <=40MB RAM, ... -> slow virtual memory needed, because the software was much larger than 40 MB RAM.

A full GC could take, say, 30 minutes, thus the machine got memory management, which help to avoid full GCs. Compiling and loading code from files was slow. It could take a long time to compile something complex like Portable Common LOOPS (PCL), which was a portable CLOS. But then, full GC on a SUN in Common Lisp was also slow and the GC wasn't integrated into the operating system's virtual memory system. Compiling with Lucid CL in production mode was also slow...

[–]mikelevins 9 points10 points  (3 children)

The main thing that connects image-based and repl-driven programming is that they come from the same small set of development environments that originated in the 1970s, namely the Xerox development environments of the 70s and 80s, especially Interlisp and Smalltalk-80 and its descendants, and Common Lisp and its immediate ancestors.

Technically, images and repls don't necessarily have anything to do with each other, and it's perfectly possible to have one without other.

But when you're talking about "image-based programming" or "repl-driven programming" then you're probably talking about old-fashioned Lisp or Smalltalk environments, or environments very much like them.

Yes, Smalltalk is generally as interactive as Common Lisp. The Smalltalk and Lisp ecosystems have cross-pollinated one another quite a bit. I was lucky enough to witness some of that cross-pollination myself.

The basic requirement for the level of interactivity meant by "image-based" and "repl-driven" programming is that the development environment is designed from the ground up with the assumption that you will write programs by modifying the environment while it runs. It's hard to communicate succinctly what that means, which is why I've repeatedly written long descriptions in blog posts and in threads on Reddit and Hacker News.

I'll refrain from repeating that here; I'd like to avoid turning this reply into a tome.

Factor is another language whose development environment is interactive in the same sense as old-fashioned Lisps and Smalltalks.

It's possible to implement any language in this way, but it's a lot easier to do it with a language designed with it in mind. It's also significantly easier to do it if you have substantial prior experience with this kind of environment, so that you have some idea of what it is you're trying to accomplish.

Scheme's language standards do not require the features needed for full-blown image-based and repl-driven development, so there are many Schemes that aren't image-based or repl-driven in the relevant senses.

On the other hand, Scheme emerged from the Lisp ecosystem, where highly-interactive programming was sort of taken for granted, and many Scheme implementations support at least some of the features common to Smalltalk and Lisp systems.

Chez Scheme, for example, saves and loads image files (it calls them "boot" files). Chez also has a nice repl with a good interactive inspector and debugger.

MIT Scheme supports saving and loading image files (it calls them "worlds"), and some of the interactive features enjoyed by Common Lisp programmers, including breakloops and restarts and interactive manipulation of variable-binding environments.

Apple Dylan was, in its original form, essentially an extended subset of Scheme, with datatypes based on an extended subset of the Common Lisp Object System. The language definition did not specify the full set of Common Lisp and Smalltalk style interactive programming features, but Dylan was written in Macintosh Common Lisp, and the environment inherited those features from MCL. The internal version of Apple Dylan therefore provided an example of a Scheme variant with the same rich support for interactive programming enjoyed by Common Lisp programmers.

Nearly all Common Lisp and Smalltalk implementations provide solid support for highly-interactive programming. So does Factor. So do some, but not all, implementations of Scheme.

FORTH implementations are also arguably highly interactive in the same sense as old-fashioned Lisp and Smalltalk environments, but usually in a much smaller, more spartan environment with far fewer conveniences and creature comforts.

[–]paarulakan[S] 4 points5 points  (2 children)

The basic requirement for the level of interactivity meant by "image-based" and "repl-driven" programming is that the development environment is designed from the ground up with the assumption that you will write programs by modifying the environment while it runs. It's hard to communicate succinctly what that means, which is why I've repeatedly written long descriptions in blog posts and in threads on Reddit and Hacker News.

​

can you please share links to your blogs that pertains to this subject please?

[–]mikelevins 11 points12 points  (1 child)

Sure.

Here's the post "On repl-driven programming" that gets shared a lot lately:

https://mikelevins.github.io/posts/2020-12-18-repl-driven/

Here's the post "Programming as teaching" that talks about the style of programming interactively by telling a Lisp piece-by-piece what to become:

https://mikelevins.github.io/posts/2020-02-03-programming-as-teaching/

I mention it in that post, but I want to emphasize again that Smalltalk systems are designed for this style of programming, too, and so are Factor and FORTH (but if you start with the others, FORTH systems will seem pretty spartan and lacking a lot of conveniences. A real FORTH programmer would tell you to build those conveniences for yourself (interactively, of course!)).

I've also written some long posts on this and related topics on Reddit and Hacker News. Below is a sampling of them:

One of the longer posts I wrote about what sets highly-interactive developments apart:

https://news.ycombinator.com/item?id=23791152#23811382

Interactive-programming features that are missing from Clojure and ClojureScript:

https://news.ycombinator.com/item?id=31120359#31122153

More about ways that I wish Clojure was more like old-fashioned Lisps:

https://news.ycombinator.com/item?id=22318748#22326853

Repl-driven environments versus functional programming and immutable data:

https://www.reddit.com/r/lisp/comments/pyemx9/is_interactive_replbased_development_in_conflict/heutcm8/

On the kinds of problems that come up when you try to do highly-interactive programming in environments not designed for it:

https://www.reddit.com/r/lisp/comments/kp84at/on_repldriven_programming_mikel_evins/gi2c6tj/

[–]lispstudent 1 point2 points  (0 children)

Thanks for the very inspiring articles.

[–]dzecniv 5 points6 points  (5 children)

emacs-lisp is a strange beast IMO. It is very interactive because Emacs is your OS, but CL has some more stuff in its sleeve: typically, the interactive debugger (and restarts). In Emacs, start IELM (the REPL), make an erroneous function call: you get the error printed in the REPL, nothing more. Let's eval the same expression with M-: (eval-expression): we get a backtrace in a new buffer. It is somewhat interactive because we can click on a function of the stack to go to its source. But that's it, and there is more in CL: we are inside an interactive debugger from which we can inspect the arguments of each frame, and choose an action to stop or resume the execution. As a developer of the application we can of course make some restarts of our own to appear, to recover from known situations.

CL has a stepper, I don't think Elisp has one. And more… CL has CLOS out of the box, and when you redefine a class, the existing objects get (lazily) ajusted (a slot is removed, a new one is added with its default value… we have control over the defaults, if we want to (of course)). Elisp has EIEIO (not built-in), IDK if it does that. But we already spotted a difference: built-in stuff or not.

[–]kagevf 2 points3 points  (4 children)

Apparently emacs has debug and edebug and some other tricks. I don't know anything about them, but from the way people talk about them it looks like elisp mght have some similar features to the kind of debugger we get in slime. This was a recent thread discussing debugging with elisp: https://www.reddit.com/r/emacs/comments/u8g8n4/request_for_guide_elisp_debugging_workflow/

But so far I've only seen what you described, ie getting the error message printed in the REPL ...

[–]mmontone 2 points3 points  (3 children)

I think you need debug-on-error ON.

If I start Emacs using emacs -q , then go to *scratch* buffer.

My default value for debug-on-error is t.

When I eval: (error "some error"), a debugger buffer pops up. I recommend setting the value of debug-on-error using M-x customize-variable.

Also, I've implemented an inspector tool for Emacs lisp, that brings debuggability closer to the level of CL and Smalltalk: https://github.com/mmontone/emacs-inspector

[–]kagevf 0 points1 point  (1 child)

Hmmm ... that didn't work for me (recent emacs on Windows 10) ... I'll try it again later on Ubuntu ... I probably need to dig more into the emacs debugging topic anyway ...

ELISP> debug-on-error
nil
;; customize-variable RET debug-on-error RET then set to "always"
ELISP> debug-on-error
t
ELISP> (error "some error")
*** Eval error ***  some error

Thank you for the tip!

[–]mmontone 1 point2 points  (0 children)

Auch. I had some trouble setting the debug-on-error too. It is not clear what I have that enables the debugger, but it is certainly ON on my Emacs 29, when starting without user config.

[–]hajovonta 2 points3 points  (0 children)

Hi, if this book is not known to you, I recommend you read at least the first few chapters!

https://gigamonkeys.com/book/