On Repl-Driven Programming

> The problem is that the reader of your code is not going on that journey with you. They are coming in naively without knowing all of that experimentation you did. The writer now has the opportunity to create code that "just happens" to work by a magic of coincidences and conveniences based on very subtle non-obvious properties of the APIs and systems they are working with. The reader is severely disadvantaged and will have a much harder time to reach parity with the state of knowledge that the writer had. For example, some property of a function or object may not be documented at all, but through the REPL the writer has ascertained it is true. How can the reader know this?

If these sorts of things aren't documented then not having used a REPL won't save you.

Someone ran a function with a println or in a debugger, figured out the answer, then removed the debug stuff... but did it by repeatedly compiling/running instead of in a REPL.

(Or, my personal favorite... someone didn't bother to run that particular code, but just made some assumptions, so has no idea those edge cases are even there...)

One can redefine functions on the fly in Common Lisp. One can retain the source associated with compiled functions (even if the Common Lisp doesn't natively support that, by augmenting DEFUN via the macroexpand hook). I have done just this in an in-core mutation testing framework for Common Lisp, which creates and tests hundreds of mutant versions of a function, automatically.

In general though, there's little good reason to edit Common Lisp code in core. Common Lisp is a language with structure at the character level (reader macros); reading in a form loses all this. This is unlike Interlisp, where everything, even comments, were s-exprs and could be edited in memory with sedit.

> At the end of the day, you quit your environment and shut down. How do you ensure your interactive work is not lost and the environment is still what you expect it to be when you start again the next day. How would you compile such a program?

Modern Smalltalks have solved this problem. Smalltalk has the concept of Packages just like Java, and as you go along building your environment, even though you are modifying the Smalltalk image, you can export these packages to plain-text files, and put them in Git, just like any other language. The environment itself supports Git integration (called Iceberg in Pharo).

> Also, if significant parts of the source code are written inside the REPL, wouldn't the lack of modern IDE features be a hassle? No syntax highlighting, no code completion, no code inspections etc. Or are there tools that offer those?

The command-line REPLs that other languages have are NOT what you get in Smalltalk. I believe the author means the entire interactive environment, and the "style" of development is REPL, not the actual UI. The Smalltalk "IDE" is just as powerful as any other IDE, including code completion, automatic generation of certain getters/setters, renaming methods/classes, finding uses, jumping to declarations and even refactoring within methods. The difference between a normal IDE for Java is that this "IDE" is pervasively available, including in breakloops and the debugger. Since the system is live, there is no separate notion of debugging, the debugger is always there, and you can use all the editor IDE features when stopped in a debugger. You no longer have to deal with a crippled debugging environment way different from your authoring environment. It truly is mind-blowing!

I highly recommend giving Pharo Smalltalk a spin (by following their MOOC or similar). This video is also worth a watch - https://www.youtube.com/watch/baxtyeFVn3w

I did most of this year's Advent Of Code in Smalltalk and saved it in Git just like any other language. Someone else can then import it into their image. https://github.com/nikhilm/AdventOfCode2020.

Note that the source code looks very verbose, but you never actually interact with the source like that. The source is just a serialization. Your actual environment only ever shows you UI elements and entire IDE windows describing your classes and individual methods.

The only thing I miss in Pharo is that it doesn't have Vim keybindings :) Apart from that there is a significant lack of OS integration and polish, but these are due to the small community and priorities than fundamental deficiencies.

Writing unit tests _is_ part of the interactive development style in Smalltalk. In fact TDD arose out of a lot of (ex)-Smalltalk developers. When you have an environment as mikelevins describes, where the debugger allows you to author-as-you-go, you can start by writing a test and fill in the implementation and have your test go green, all in one very tight loop.

You actually can run a bunch of unit tests in Smalltalk with a single-click, get results, and be dropped into a full authoring environment when tests fail, with the bonus that you can just fix the code and resume execution to have the test go green. Modern Java IDEs can probably do this (I've no experience with Java), but you've to understand that this was possible in Smalltalk several decades ago.

This is how any major CMS works to this day, and anyone doing serious development does have the engineering workflows in place to replicate the database content.