- cross-posted to:
- lisp@programming.dev
- cross-posted to:
- lisp@programming.dev
You must log in or # to comment.
My understanding is that the CADR software was/is free. I never used Allegro and had only slight exposure to the CADR and Symbolics machines but where the article says
there is no reason at all why a development environent that cool could not be built on stock hardware
that papers over a big gap between “could be” and “is”. The Lisp machine debugging environment was way superior to the mainstream stuff I see today. We get by anyway of course.
I do believe there was once an on and off effort to emulate the CADR hardware and run the original CADR software. IDK if that ever got anywhere. I mostly lost interest in Lisp much earlier. And running every program on the machine in a single shared address space these days would be silly, I agree.
I do think a lot of the ideas from Lisp Machines could be adopted in modern environments though. For example, it blows my mind that REPL driven development is still a niche thing today. The sad part is that Js is ubiquitous nowadays, and Js VMs technically support a lot of the features. You can inspect running apps, make changes, see results immediately. All that’s really missing is having a network API that would let you connect an editor to the running app, and reload functions.
All that’s really missing is having a network API that would let you connect an editor to the running app, and reload functions.
Erlang has that :).
Erlang OTP is great in particular since it can run a huge number of green processes, and orchestrate them as needed.
I stil find Lisps have the best tooling for REPL driven development though. I’ve worked with Clojure for many years, and it’s still by far my favorite language because of the interactive workflow, I just couldn’t go back now.
Pretty much everything has a REPL now. The Lisp machine was way ahead in terms of interactive debugging. I still can’t believe that after all these years, stock Python doesn’t have a way to trap to a debugger when your program throws an uncaught exception. I’ve never used Clojure though. I do think the language itself has some cool ideas.
Pretty much everything absolutely does not have a REPL you can connect an editor to and develop your application interactively. This workflow is still pretty much exclusive to Lisps today. There’s a huge difference between having REPL as a standalone toy, and actually having it as an integral part of the workflow.
The way I develop applications in Clojure is by first running the whole app, then connecting my editor to it. I have access to the entire application state, any resources such as database connections, I can change any part of the application at runtime and see the results immediately. I can even connect to remote apps and debug an app in prod. When I write new code, I do it interactively step by step. I write a function, see that it works correctly, then write the next, and so on. At each step I know exactly what’s going on because I’m running my code live. The only context I need to keep is the function I’m currently working on and the last one I wrote. Trying things, and making changes becomes a much tighter loop with this approach.
Python, Ruby, and even Forth have REPLs that I use all the time. Haskell sort of has one. Not C++ etc though.
I’ve just explained the difference between these REPLs and what Lisp REPL workflow is like. It’s not comparable even in the slightest. Actually read what I wrote above and then try doing that in Python or Ruby.
I didn’t realize anyone was even considering it.
There’s practically no barrier to noodling around with proofs of concept using emulators and FPGAs.
I don’t think having hardware level support is even that big of a deal to be honest. The real appeal is in the whole architecture where your application is has a REPL you can hook into, and you can inspect its state, modify the code, change things up, while it’s running. In my opinion, the design of the software stack on Lisp Machines is strictly superior to the garbage we have today. And we’re basically trapped in this ecosystem because it would be a herculean effort to reimplement all the apps people use on top of a different architecture. So, there’s no way to make a clean break.
It would be very interesting to imagine what software would look like today if written fully functionally from the bottom up, but it’s both too hard to implement at this point only to be written off as a proof of concept, and also redoing all cybersecurity would take miracles to happen
Indeed, rebuilding the entire software stack from ground up would take decades of effort. It’s kind of interesting to think about how active experimentation is only possible in the early stages of a new technology. Once you end up with an ecosystem forming, it becomes incredibly difficult for something completely new to break in. It would take a complete paradigm shift where the existing ecosystem becomes obsolete for new ideas to have a chance again.
similar to javascript and its derivatives having become the de facto language of web development, love it or hate it there’s no going back now
Although, you can treat Js as a compile target. For example, I’ve used ClojureScript for most of web dev I’ve done. It has its own semantics different from Js, such as sane equality, immutability, and so on. And it compiles to optimized and minified Js when you ship it for production. It also has Js interop, so you can use stuff like React libraries, and whatever else you need. I’ve found it to be a far more pleasant experience than writing Js directly.
@yogthos “The cold war did not end in 1991. America did not win.”
