We Lost Something: 1970s REPLs Were Better Than Modern Development Environments | Hacker News Reader

We Lost Something: 1970s REPLs Were Better Than Modern Development Environments

programmingsimplicity.substack.com

47 pointssurprisetalk47 comments

I use a modern Lisp everyday...Clojure. My dev environment is VS Code using the most excellent Calva extension which give me REPL-everywhere in my editing experience.

Yes, that 70's experience was better...and it's still here, refined and built on modern tooling and runtimes.

I came here to say this as well. The various Lisp dialects I've used still offer this rich REPL experience today. Other languages haven't caught up.

I love clojure with CIDER but I have heard as a REPL experience it doesn't compare to CL with SLIME. I like emacs as a lisp machine but I know that a big ball of mutable state and functions with side effects on a single thread really doesn't live up to a proper lisp machine.

true. I don't have the energy to learn emacs fu. An actual lisp machine would be dreamy.

Clojure REPL experience is pretty primitive though, you don’t have a step debugger or something like the conditions system, being a hosted language you only get stacktraces from the VM.

Supposedly this is the bees knees and better than a stepper:

https://www.flow-storm.org/

(haven't use it myself yet)

But things like CIDER give you step debugging if you want. For whatever reason it always felt clunkier than ELisp's debugger

What he's getting at is single level storage. Ram isn't used for loading data & working on it. Ram is cache. The size of your disk defines the "size" of your system.

This existed in Lisp and Smalltalk systems. Since there's no disk/running program split you don't have to serialize your data. You just pass around Lisp sexprs or Smalltalk code/ASTs. No more sucking your data from Postgres over a straw, or between microservices, or ...

These systems are magnitudes smaller and simpler than what we've built today. I'd love to see them exist again.

I make a ton of progress with ipython and vim/st3/other text editor with a vertical split. I sometimes screen the terminal in two if I want to run external elements.

We seem to keep iterating back to that modality, but honestly, it's just nice. VS Code starts there but then Java language servers and broken Python language servers and rust language servers and exploding npm dependencies and supply chain attacks just muck everything up.

Simple simple simple is so refreshing.

Try running ipython inside a vim terminal (:below term). Being able to yank and paste between buffers and the terminal (which is itself backed by a vim buffer), and vice versa, is a big multiplier

vim-slime is another variant, easing pasting across a screen multiplexor. It works well with IPython.

https://github.com/jpalardy/vim-slime

Ooh. I'll check it out.

I think there are benefits of interpreters as well as compilers, possibly for the same programming language in some cases (although some programming languages are better for use with interpreter and some are better for use with compilers).

I think JSON is not the best format for the persistence though (despite their claim that it is better than binary formats, it has many problems); it has many problems, such as not a proper integer type and not non-Unicode text types or binary types, etc; and different format would better, such as DER. If you use DER, then you can use better types, better character sets, binary data, and not limits to how big numbers can be, etc. (JSON might work for JavaScript, but even then only for some types; JavaScript has more types than JSON has, including JavaScript does actually have a integer type even though JSON does not.) (With using JSON, it will just mean that you will then have to wrap other data in JSON anyways (e.g. encoding DER as base64) and the meaning will have to be converted.) (Also, you can work around not being a text format, because you can have a program to display them, like a program can be used to display any other kind of data in other ways (e.g. syntax highlighting, pictures, auto formatting, etc).)

> true interactive, exploratory programming environments where developer feedback was instantaneous, context was persistent, and the entire system was designed around the developer’s cognitive workflow.

Reminds me of smalltalk? I’ve played a bit with Pharo and it seems to tick all those boxes

I don't know what author is using, but all these features are present in Visual Studio (2026 now) proper, and pale in comparison with what refactoring tools, code navigation, and autocomplete give you.

VS has most of these significantly improved over too. E.g. live testing. Performance profiler. Like it is really heaven and earth difference in favor of VS.

No love for Forth? The opening paragraph just nails the whole concept of a machine operator instead of machine programmer - the driving principle behind Forth, right?

Also used in the previous FreeBSD bootloader and the "portable" monochrome CRT word processors donated to a middle school I attended around 1992.

In terms of ops usability, it's difficult to beat reliability, availability, and serviceability (RAS) features of mainframes. Erlang/OTP comes close.

Are there any current language REPLs that have save/restore session state commands?

I run jupyter in a docker container and have the ability to just checkpoint it, it would work for any language that runs a REPL. The gotcha's are any GPU state stuff or any database/socket connections.

You could do save-lisp-and-die

My favorite debugging method is still printf()

Macro backed by fprintf(stderr, ..) since stdout is buffered.

Generally avoiding C unless something specific and small absolutely requires performance (rather than premature optimization), because maintainability, safety, and velocity tend to be better in higher-level languages.

This is just my 2 cents.

This is why I programmed in Pharo (a Smalltalk descendant) professionally for a while to get that experience [1].

I feel like that using iPython is good enough of an experience to be honest. Could it be better? Sure.

But the fact that this is my iPython session:

ipython Python 3.12.9 | packaged by conda-forge | (main, Mar 4 2025, 22:44:42) [Clang 18.1.8 ] Type 'copyright', 'credits' or 'license' for more information IPython 8.32.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: def foo(): ...: return 'bar' ...:

In [2]: foo() Out[2]: 'bar'

In [3]: def foo(): ...: return 'baz' ...:

In [4]: foo() Out[4]: 'baz'

says a whole lot I think :)

The cool thing with Pharo and Lisp of course is the whole "treating code as data", where Lisp is arguably even more intense at it than Pharo - since the syntax is basically an abstract syntax tree. It really allows for automated reasoning (e.g. "give me all functions of xyz type with abc parameters, constrained to only pqr classes and only showcase the lines where they were being called, skip the definitions). So that's awesome. I haven't tested Python on this a whole lot yet and I don't know enough about Lisp to say anything useful about it, but with Pharo I vaguely remember doing some insane things since you can also access the AST and have reflection on that as well.

Pharo of course has the whole debugger inside a debugger inside a debugger experience. But that has had quite some limited use because a new process is spawned for that new debugger, so you won't have access to the exact same context that you need. I vaguely remember that some class based variables didn't have the state I needed when I went debugger inside a debugger mode. I think it was WADynamicVariable of the Seaside framework and it was because it was a singleton like thing (IIRC) and in order to have a certain behavior it could only do that by triggering exceptions (I really don't remember it well). The point is, it needed such obscure behavior to behave in the way it needed to that the debugger inside a debugger wasn't expected to copy that exception flow context, as it wasn't really intended to be used like that.

[1] I would've worked there for longer but the company got Americanized. Our company - that was profitable - got subsumed by a venture capitalist firm that had 2 companies like it that were unprofitable. We became a subsidiary/sub-company basically. Suddenly tech layoffs came, 2 rounds at least, because the company as a whole was unprofitable (as in: the other 2 subsidiaries were unprofitable and we had to pay the price). I'd have stayed there for much longer if that didn't happen. I will go on record and say that: it is my personal opinion that they destroyed a good company with good people. I won't name the company, but given that I'm posting under my real name, it's not too hard to figure out.

I could never make myself like Pharo (or Smalltalk). Yes, it's interesting and exotic, but it never seemed really practical. Maybe what I was missing the most was static/explicit typing, which replaces the need for many of Smalltalk's features. I also never liked working with Python or JS for that reason.

It's amusing that in the mid-2010 with the raise of Node, web (turned "full stack") devs advocated for JS and how static typing was really not that relevant. Then TS came and suddenly the same folks considered it an absolut game changer.

> it never seemed really practical.

IMO this is partially true but that's mostly because not enough people are working on it. If Pharo would have as much people working on it as Python, it'd be practical really quickly.

> Maybe what I was missing the most was static/explicit typing

I actually have a talk where you can hack typing in. To be fair, it will be checked during execution, so it's not a compile time thing. It's somewhere around here (I did like 3 mini talks in one mini talks, it was pure chaos, haha [1]). It's about 5 min., the whole talk.

Personally, I'm a fan of type hints, but ultimately engineering culture and standardization is more important. Or at least, in a professional context, in a personal code context I like dynamic typing and when it gets too big, I refactor it to explicit typing.

[1] https://www.youtube.com/watch?v=FeFrt-kdvms&t=2270s

The irony is that many dynamic languages have had optional typing for decades.

BASIC, Common Lisp, xBase/Clipper, Perl

So yet again we got a cycle of people rediscovering the tools that predated them.

> static/explicit typing, which replaces the need for many of Smalltalk's features

For example?

Which Smalltalk features do compile-time type declarations replace?

Dynamic inspection of an object's API? I think it's a very common thing for programmers to explore a type's API on-the-go (as we can't memorize every function name). With static typing, that information is known before run time and can be immediately displayed by the IDE in the form of auto-complete. In dynamically typed languages, the most reliable way to achieve the same is by running and inspecting it, which is basically how people work in Smalltalk from what I've seen.

Things are a little confusing when we can both use the Smalltalk IDE with or without running our stuff.

Code exploration tools are available before "running and inspecting" our stuff. We read the protocols and code without "running and inspecting" our stuff.

It is true that static types provide more-precise more-automated identification of implementations and call sites.

But we have the same 1970s REPLs in 2025; additionally, the web browser, how end-users consume most programs, is a giant REPL.

For interpreted languages, most fancy IDEs provide a language interpreter shell, which is a REPL.

Yea JS code inside the browser has a lot of REPL like functionalities, including a complete debugger to boot!

Speaking of better in the old days, MSVC in the 90s had edit and continue, where you could stop in a debugger, change the source code and move the current breakpoint back and run it again. Even VBA had this 30 years ago, why cant I do in Python?

The visual IDEs of the 90s (MSVC, Borland Delphi, heck even MS Visual Basic) were way more tightly integrated, performant and usable than anything we have today, despite running on hardware with a fraction of the power. It seems so bizarre how much we've regressed.

MSVC is still here in 2025.

You can still do it in Java.

The best I can do is rebuild the class, then when the function runs next time you get the new code. Is that what you mean? Quarkus is good like this too.

There is better than that.

https://www.jrebel.com/products/jrebel

Microsoft QuickBasic does too, which I sometimes still use when programming on DOS (one of the reasons for this being what efaref mentioned about performance and usability and being regressed); and also has a "immediate mode" that you can enter BASIC commands and execute them; I think this is helpful.

I call bullsh*t. None of those IDE's had any such feature.

What? Excel has this today. Open your VBA/Developer window

I found a video! 14 years ago and its C#, but VC++ had this in the 90s too. https://www.youtube.com/watch?v=M6J34B37wUc

.NET can hot reload during debugging session. Even that I never get used on this feature and just restarting debugging from scartch.

Which makes me wonder: at the end of the day 1970 or 2025 doesn't matter, it's the same plain text editing no matter what. As if we are still in the silent film era of programming. Visual programming seems to be the "obvious" generation leap but we are still not there yet (something like the UE Blueprints) https://dev.epicgames.com/documentation/en-us/unreal-engine/...

Every time I've tried visual programming for anything other than data flow I find it way more painful than just typing code. It's particularly hard to follow control flow, and organization is a pain. So I'm not convinced that visual programming (as conventionally envisioned) is the future. That said, I'm a big fan of making use of visual intuition, at least how dynamic land and folk computer envision it (they also have the datalog-like reactive database that is the glue that connects different programs together in a nicer way than data flow).

Text and language didn't begin in 1970. We've been using words to communicate for a long time, and text is pretty good for that. We don't communicate complexity to humans via hieroglyphs; why would we think visual programming is somehow superior to code?

Reply on news.ycombinator.com