On Repl-Driven Programming

So go ahead and set up that working situation and try this:

Define a function foo() in one module that calls a function bar() in another one, but don't define bar().

Now call foo().

Now, in the debugger that you break into, give a definition for bar(), and resume the execution of foo(). Don't quit the program and restart it; that's cheating!

If that works fine, please tell me what tools you're using, because they'll materially improve my tools for some work I need to do.

Also, try this:

Define some classes and make a bunch of instances of them. Write a few methods on the classes. Start your program running with code that uses those classes and methods.

Now change one or more of the class definitions. Don't stop and reload the program! Again, that's cheating.

When you land in the debugger (you do land in an interactive debugger, right?) use it to inspect the stack and find out which classes and methods are on the stack and what's responsible for the breakage. Ask the Python runtime to show you all the functions, types, and values that are on the stack, and when you find the likely culprit, ask it to take you to the source for the version that's currently on the stack.

Now, while you're still suspended in the call stack, redefine the offending classes and methods and tell Python to use the new ones. Now resume the broken computation. If you hit another problem, use the same tools to find and fix that one, too.

After you've done all that, please let me know what your Python toolchain is so that I can use it, too.

Also, if that's all perfectly doable in Matlab and R, that's good to know. Let me know about those tools, too. I haven't had much occasion to use them, but that might have to change if they work that way, too.

As I said elsewhere, when I say "repl-driven programming", I do not mean "programming in a repl window", or "programming at a command shell". I'm talking about the runtime's read-eval-print loop, not the UI's repl window.

When I'm working, there is little or no migrating of code from the repl buffer to a file because it's already all in a file. I almost always work in a file. I write snippets in a file, send them to the repl with a keystroke, and build up the world incrementally as I discover what it needs to be. As the contents of the file get larger and more complicated, I move things around and organize them. It's a conversation with the repl, not an editing session in the repl window.

I don't consider any Clojure tools I know of to constitute a proper repl-driven environment, precisely because the language and runtime lack support for the kinds of programming and debugging that I've taken for granted for decades. If I can't inspect and edit and redefine everything in the runtime, it's not the full, proper set of tools.

I've written a good bit of Clojure code, and I'll happily do it again if I need to do something that isn't convenient in, say, Common Lisp, but I consider it an acceptable alternative to things like Haskell and Scala and F# and Swift, not an attractive alternative to Lisp and Smalltalk.

I do occasionally need to restart a Lisp environment because of some gnarly breakage I've committed, but it's pretty rare. Moreover, killing and restarting my favorite lisps takes about--wait, let me check--okay, a second and a half to kill a live app in staging and have it back up, fully-functioning.

I've used it a good bit. When I'm using it, I miss the tools I have in Smalltalk and Lisp environments.

When I use Smalltalk or Lisp, I don't miss pry or the other tools I have when working with Ruby.

I do like Ruby, though. I probably like it better than any other language that isn't made of s-expressions. (Well, I like ML a lot, too.) But the whole time I'm working with it it just makes me want to write another Ruby implementation, but this time on top of a proper interactive runtime.

There is one, actually: MagLev, which is built on a Smalltalk runtime. As far as I can tell, though, it's dormant.

I think it's a valid observation. Circumstances that make you think things through ahead of time compel you to learn things and gain skills that you would not otherwise learn and gain.

The other way around is true, too, of course.

But the intensely-interactive style of programming-by-teaching is the less common approach. In pretty much every thread I've been part of about the topic there have been commentators who've said they just weren't even aware of it as an option, who had no idea that full-featured repl-driven environments had ever existed or were a possibility.

What are the odds that such an obscure approach to programming has already attracted all the programmers who would benefit from it? Long odds, I'm guessing.

So my guess is that it's worthwhile to point out the option for the sake of people who would benefit from it but don't know they have the option.

For my benefit too, of course. I want more people to know about it, because that increases the chances that demand will rise. Rising demand increases the chances of greater investment in those kinds of tools, and reduces the chances of their extinction.

> Whenever I think about it I can't quite put my finger on exactly what Python would need to make it the same. It's something to do with the way imports and namespaces work, though.

Python has a fundamentally broken module system, and Python 3 did nothing to fix it:

https://nedbatchelder.com/blog/201908/why_your_mock_doesnt_w...

https://docs.python.org/dev/library/importlib.html#importlib...