Hacker News Reader

Comment by jonahbenton | Hacker News Reader

There is a non-virtuous (vicious not the right term) cycle at play.

Many problems are only solvable with compiled languages, for performance, correctness, or other non-functional considerations. Many people are first taught on compiled languages, and bring those approaches to dynamic languages. The popular dynamic languages, in their standard/common toolchains, do not have robust repl support (looking at you Python and Javascript). The absence of a robust repl workflow means people who are exposed to it in those languages aren't really impressed by it. Really too bad.

View on HN

Compiled doesn't have to mean batch compiled. Most modern Common Lisp systems are compiled, but you can compile smaller units (down to individual functions).

The problem with the way we're taught (or I was taught, circa 2000), was that it was still in the batch-oriented mode: "Gather all your source files, and run them all through the compiler together." "But I only changed one thing." "That's fine, `make` will do the right thing for you." "But I also have to close the program." "Well, yeah, there are ways around that but we won't teach you, maybe your future coworkers or employers will."

Clojure is a compiled language btw. It's just compiled on the fly. When you're evaluating new functions at the repl, Clojure is generating Java bytecode and dynamically loading it.

Thank you Alex, I know, "compiled" in my post was lazy shorthand for something like "low abstraction, batch compiled" which in the context of the non-virtuous cycle limiting the reach of the repl/conversational workflow also touches on the historical and pedogogical legacy of people being smarter than the machines and needing brains to work at low levels of abstraction. Now that's rapidly, though unevenly, becoming a myth.

Your work over the years on Clojure is so deeply appreciated and my post was also to some degree coming from a place of lament that more people don't know about it and benefit from it. Thank you for it.

Compiled languages can have REPLs as well.

In fact Mesa had one on XDE, which was improved in Mesa/Cedar, because the team wanted to cater their environment to the Lisp and Smalltalk developers at Xerox.

Wirth built on top of this when he designed Oberon, where the OS only supports dynamic linking, and every public exports from a module can be used on Oberon's REPL as a command.

Although many people aren't aware of this, Eclipse always had a crude REPL via Java Worksheets, which allowed to execute Java expressions and saving those sessions on the workspace. This trances back to Smalltalk transcripts and Visual Age for Smalltalk heritage.

Eiffel also offers a REPL like experience in Eiffel Studio via the MELT VM.

.NET had Linqpad for quite some years, until Visual Studio got interactive C# and F# shells, and immediate debug mode goes back to the VB days of yore.

So there are plenty of options with compiled languages, but like with graphical debuggers, teaching is lacking on the availability of such tooling.

I do repl driven development just fine with ipython and autoreload setup. What features do you feel are lacking?

Yes, when I work in python, I do that too. It certainly works ok.

The place I would start from a critique perspective is around lifecycle. Python has encouraged carelessness and overwork at module load and init time, and there aren't common protocols (that I have seen) that involve standing up a graph of objects across an application after a single module reload. So when you reload a single module and the names in the module now point to different data and code elements, all the downstream dependencies on those names have to change as well, and Python doesn't have patterns for organizing and managing at that level.

This also impacts runtime introspection, which is a key benefit of a repl oriented language. One implication is that there is not at all a pattern of "repling into" a running python application to poke around and see what is going on. To most python programmers this is a foreign concept.

Related others involve code style, and implicit vs explicit ways of referring to and moving data around, which also impacts runtime whole system introspection.

Python has all the pieces to have a very nice repl-first programming model, but lacks patterns for key parts of that- explicitly standing up the graph of live objects, and using a repl to interact with a live system with live objects.

Hope that makes sense.

Here's an overview: https://lisp-journey.gitlab.io/pythonvslisp/

In short, the Python process has to restart to take changes in, and you loose your objects in the REPL. The Lisp process doesn't and is built to (lazily) update your objects to reflect structure changes (such as if you deleted a class slot). I particularly like the Lisp way for unit tests or the web.

Not a JVM expert but the fact that it's all JVM bytecode for both comiled and dynamic langs should help.

Reply on news.ycombinator.com