We Lost Something: 1970s Repls Were Better Than Modern Development Environments
Posted27 days agoActive24 days ago
programmingsimplicity.substack.comTech Discussionstory
skepticalnegative
Debate
60/100
ReplsDevelopment_toolsProgramming History
Key topics
Repls
Development_tools
Programming History
Discussion Activity
Very active discussionFirst comment
59m
Peak period
39
0-6h
Avg / period
8
Key moments
- 01Story posted
Dec 13, 2025 at 2:54 PM EST
27 days ago
Step 01 - 02First comment
Dec 13, 2025 at 3:53 PM EST
59m after posting
Step 02 - 03Peak activity
39 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 16, 2025 at 2:04 PM EST
24 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 46257410Type: storyLast synced: 12/13/2025, 9:05:17 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
For interpreted languages, most fancy IDEs provide a language interpreter shell, which is a REPL.
Yes, that 70's experience was better...and it's still here, refined and built on modern tooling and runtimes.
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
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.
https://github.com/jpalardy/vim-slime
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.
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.
For example?
Which Smalltalk features do compile-time type declarations replace?
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.
BASIC, Common Lisp, xBase/Clipper, Perl
So yet again we got a cycle of people rediscovering the tools that predated them.
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
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.
https://www.jrebel.com/products/jrebel
In terms of ops usability, it's difficult to beat reliability, availability, and serviceability (RAS) features of mainframes. Erlang/OTP comes close.
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 most 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 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.)
Reminds me of smalltalk? I’ve played a bit with Pharo and it seems to tick all those boxes