Interactive Common Lisp Development

For many Common Lisp scenarios, it's actually similar -- start with the raw based image, load in your code and data, snapshot it, and ship the resulting artifact. At least for me, interactive development aside, it's not untoward to restart a CL system from scratch as a routine part of development. We're not running on Lisp Machines anymore where restarting was actually quite expensive (though there were anecdotes about how at some point it was faster to restart a LispM than let it grind through its GC process, I don't know about that).

However, I don't know how common that is with Smalltalk. How often they restart from scratch. Saving the image is routine in Smalltalk. Where in Lisp you CAN save the image, it's not necessarily part and parcel operationally, historically, or culturally to constantly save the image, especially post LispM. In Smalltalk it is.

I think with CL folk moreso build a new base image, load in some routine utilities, etc. to form a baseline. But application code and image are separate.

Smalltalk, they're not. Code is part of the image (it's stored separately, but it's presented as if they're one and the same). So the image is a much more first class citizen in the Smalltalk world, rather than, perhaps, an artifact.

Especially today, I imagine they have build processes that build up the entire thing again from scratch, but it would not surprise me if they bumped into problems where the image and the source code "don't quite match" that they have to suss out in testing before deployment, because something slipped through and tweaked the long saved image that wasn't properly captured.

In any case, while I'm sure it doesn't quite happen like that today, its not unreasonable to have someone ship a "ball of mud" Smalltalk image in contrast to one in CL.

The tooling is nice, but it’s not what defines CL. The language has ample benefits just on its own.

A paren matching editor is the minimum tooling necessary for CL. Auto indent is a nice to have. vi has had both for pushing 50 years now.

The REPL is a standout feature of the system. Being able to load your code and poke at it is wonderful. Very powerful feature.

Python has a REPL. I never felt it was very good, but that’s me. I never used it much. Perhaps I was missing something. I wrote a bunch of Python without ever using it. And I’d wager many coders have treated Python like they’d have treated Perl, or most any scripting language. Write code, save code, run script, rinse, repeat.

With no interim step, turn around was fast and work got done.

There is nothing stopping folks from doing the same with CL. I’ve developed 1000s of lines of CL with little more than 2 little defuns. (e) and (l). (e) fired off ‘vi code.lisp’ and (l) wrapped ‘(load “code.lisp”)’. My knowledge of the debugger was knowing how to abort it back to the top level. I mostly did “print” debugging. If I was clever, I’d write a ‘dprint’ function that would take variable arguments. If I was lazy, I’d just “(print ‘(“x=“ x “y=“ y))”. No big deal.

Even when working with LispWorks (which has much to recommend it), I operated much like this. Reload all the code, dabble with the REPL, add print calls, reload, test individual functions. I never took the time to learn the higher level tooling and such. I didn’t feel it was necessary, and I’d rather code than fight tooling.

So, as the Lisp cognoscenti stares on in mouth agape horror as I left much of the Lisp experience on the shelf, I got stuff done anyway.

Which goes back to the fundamental point. CL is a language like any other. It’s a very cool language, very powerful, and worth using just for itself. Its environment does not define it as a language. It augments it, it’s cultural and useful to be sure, but you don’t necessarily need it to be capable and productive and to solve problems.

If all the talk of tooling and what not deters you from trying the language, don’t let it. It’s worth trying all on its own. Try it your way, however you’re comfortable.

But do get a parenthesis matching editor.

Edit: just to highlight the point, if you read PGs “On Lisp” and “Common Lisp” books, you’ll notice they’re pretty much all about the language and its power. He does not talk much as I recall about the environment.

Im curious why you think this is the no.1 issue? I think a bigger issue is that so many CL programmers prefer to talk about lisp instead of just getting their hands dirty and making cool original open source things with it that other people would get excited to use. Thats actually a much harder problem. Plenty of people actually use Emacs even if they dont care for elisp and end up learning and writing elisp because they like Emacs. I think CL should market itself to uni or even high school students. Kudos to you though! You are doing great work to promote CL

Lisp can be at least as high level and expressive as any other language.

I just learned today that another new GC for SBCL is in the works, with GC pauses under 100 microseconds.

Python doesn't have a standard, but it has a canonical implementation, so maybe a "defacto standard". Not having an official standard didn't matter, though.

Common Lisp has defacto "standard libraries" for things like threading. Other things, such as async, are less clear (to me), but libraries do exist. Just because something isn't in the standard, though, doesn't mean it can't exist. Also, implementation such as SBCL pick up a lot of the slack, filling in some of the missing gaps.

Yes there are a lot of content. Just the topic is …