3 ms·

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 def

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 a long-time but now lapsed Lisper, I never understood some people's elevation of the REPL. A command-line REPL is a poor man's development environment. If you're doing interactive development in Lisp, you'll be far more productive if you use a normal buffer with eval-defun, eval-buffer and friends. When debugging, you'll primarily want auto-updating watch expressions and object inspectors. And when you do have good use for a REPL, you'll still want it to exist within a proper buffer with persistent history, inline object inspection, etc, instead of the low-effort rlwrap terminal experience which usually passes for a REPL. All of this holds doubly true for Smalltalk environments.

lispm 6y ago
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.
mumblemumble 6y ago
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.
- moocowtruck 6y ago
  that doesn't sound nearly as nice as smalltalk
mikelevins 6y ago
You misunderstand me. By "repl-drive programming" I do not mean programming that is fixated on the "command-line repl". On the contrary, what I'm talking about has much more in common with what you describe as "far more productive". It's not about a particular shell or window or buffer; it's about a runtime environment that is designed to support writing software by building and changing it as it runs. By "repl", I do not mean the window or the buffer or the shell program. I mean the loop of: read an expression, evaluate it, and present the results, in the context of a runtime that is designed to comprehensively support it. Moreover, you can have all of the tools that you listed and still not be working with a properly-designed repl-driven environment. For example, I built a 3D interactive environment on the JVM that worked quite well--it launched into the 3D environment ns no more than a second or two, and could build whole procedurally-generated scenes in a few seconds. It supported networked multiuser interactions. I could start it from a repl and dynamically alter scenes and objects and their behavior in the environment by talking to them. It still wasn't a proper repl-driven environment because the underlying runtime could not correctly handle dynamic redefinition of classes and methods. That meant that if I decided that I needed to change a representation or something, I had to kill the environment and rebuild it. It meant that there was always a gratuitous barrier that I might run into at any moment. It meant that some abitrary set of things I was working on was always on the other side of that barrier. Contrast that to working with, for example, SK8, where I could redefine absolutely everything in the environment (including, for example, the system-level procedures used to draw window frames) without ever restarting the code that was under development.

lispm 6y ago

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.

mumblemumble 6y ago

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.

moocowtruck 6y ago
that doesn't sound nearly as nice as smalltalk

mikelevins 6y ago

You misunderstand me. By "repl-drive programming" I do not mean programming that is fixated on the "command-line repl". On the contrary, what I'm talking about has much more in common with what you describe as "far more productive". It's not about a particular shell or window or buffer; it's about a runtime environment that is designed to support writing software by building and changing it as it runs. By "repl", I do not mean the window or the buffer or the shell program. I mean the loop of: read an expression, evaluate it, and present the results, in the context of a runtime that is designed to comprehensively support it. Moreover, you can have all of the tools that you listed and still not be working with a properly-designed repl-driven environment. For example, I built a 3D interactive environment on the JVM that worked quite well--it launched into the 3D environment ns no more than a second or two, and could build whole procedurally-generated scenes in a few seconds. It supported networked multiuser interactions. I could start it from a repl and dynamically alter scenes and objects and their behavior in the environment by talking to them. It still wasn't a proper repl-driven environment because the underlying runtime could not correctly handle dynamic redefinition of classes and methods. That meant that if I decided that I needed to change a representation or something, I had to kill the environment and rebuild it. It meant that there was always a gratuitous barrier that I might run into at any moment. It meant that some abitrary set of things I was working on was always on the other side of that barrier. Contrast that to working with, for example, SK8, where I could redefine absolutely everything in the environment (including, for example, the system-level procedures used to draw window frames) without ever restarting the code that was under development.