3 ms·
Very nice description of the power of the Common Lisp REPL. Did you have the pleasure (?) of working on any of the lisp machines? I got into Common Lisp in th
by minerjoe 6y ago
Very nice description of the power of the Common Lisp REPL.
Did you have the pleasure (?) of working on any of the lisp machines?
I got into Common Lisp in the early 90's and even then, with GCL and CMUCL, it blew my mind at how much more productive I was compared to my years of C,C++ just due to the one fact that I was now freed from the edit, compile, run cycle, let alone all the other benefits.
It's truly a joy. I don't have a full grasp of why others don't make the deep dive. I suspect it just had too much a learning curve nowadays, with Emacs being almost a requirement, and developers, like most humans, don't like to slow down for a while while they learn before they speed up.
- vindarel 6y agoFYI the Atom SLIMA package is very good: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Emacs is still the best, but not THE required editor anymore.
- minerjoe 6y agoAtom is OK, but many people bound to eventually be caught in it's local maxima, such as needing to run in a terminal.
- mikelevins 6y agoI feel like I ran out of room before I really covered all that I wanted to cover, but maybe it's better that way. I wrote a tome, as it is. The market for multi-page screeds about how great ancient programming systems were may be limited. I had a Symbolics Lisp Machine in my office at Apple for several years, and I noodled around with it a lot, but didn't build anything very serious with it. It's certainly relevant to any discussion of the power of full-bore repl-driven programming, though. Now that was a repl! To be fair, I don't think everyone will find the advantages compelling. As far as I can see, some folks honestly prefer the programming-as-carpentry approach, and a skillful software carpenter can be extremely productive, too. On the other hand, for someone who is, like me, more effective using the teaching approach, the difference is night and day. I have actually been one of those mythical 10X programmers before, as measured by version-control-system statistics, but only when I was working with a programming-as-teaching toolchain. You touched upon a point that I think does work against Common Lisp nowadays: it's not super easy for someone to get started with it. I was lucky in the 1980s in that there was a very good Common Lisp on the Mac that was also really really easy to get started with. Installing Coral Common Lisp was as simple as dragging a folder icon in the Finder. Starting up a usable IDE? Just double-click the app icon. Create a fully-working application window that handled standard events properly? (make-instance 'window) Build a GUI? You could either make-instance a bunch of objects and stick them into the window, or you could open a UI-builder window and drag stuff together. Tell the objects what events to handle and what functions to call, and you had a working app. Deliver the app to production? Choose "save application" from the File menu. The core of that same Lisp still exists in the form of Clozure Common Lisp, and it's very good, but it's not the same. For one thing, the IP agreement that open-sourced the compiler and runtime did not include the Mac integration. For another, there are a lot more hoops to jump through in UNIX-based macOS than in the old Mac system to achieve the kind of integration that Coral Lisp had. I'm not saying you couldn't do it; I'm just saying it would be a lot of work. Actually, I think you could make a pretty good try at a Coral-like Lisp, and I think it would make things a lot easier and more attractive for new Lispers. It might even grow the pool of working Lispers, and improve awareness of programming-as-teaching. It would just be a lot of work, and it's not blindingly obvious that the result would pay for itself.