I certainly wouldn't call it "least resistance", simply because I never use it enough to be completely comfortable with even some of the basics (i.e. loop). Always hitting the hyperspec about something.
But, even then, I find it's much easier to write in simply because of its syntax.
I use dashes-in-all-my-identifiers. Those are very easy to type. Most of my routines break up easily in to "bunch of assignments and destructuring in let" and then "code to work on those". All of the argument lists and structures and what not are broken in to their component bits early on, then its "just code". It's very stream of consciousness then.
That said, however, I have not done a lot of interfacing to external libraries. It's mostly just me and the listener. But, even with me constantly bouncing back and forth doing prefix math (my little brain doesn't think far enough ahead to naturally use prefix math), it still flows really easily.
My experience with CL (as someone who loves it very much) that while the syntax is relatively easy to use (with the CLHS caveats that you mentioned - does the list or symbol come first for GETF? is it TYPE-OF or TYPEOF?), there's friction around getting set up for the first time. I've tried to teach it to many people before and getting a sane development environment is orders of magnitude harder than with Python.
I find your "stream of consciousness" description to be very accurate, and it's one of the most addicting parts of it for me.
Now, if only it scaled better to larger systems, it would be perfect - I would like to have better types and type-checking, and macros that have access to type information, for starters...
I appreciate that I'm off the beaten path here, and folks look for a much higher fidelity dev experience than before.
That said, outside of using a bit of LispWorks 20+ years ago, my "dev environment" for Common Lisp is CLISP and Emacs, but not like you think. I use Emacs simply because of TAB to autoindent. (I'm sure vim has something similar, I just haven't bothered to look it up.) I don't use SLIME or anything like that. While I used to be an Emacs user, not so much any more. It's all arrow keys, pg up/pg down, some ^S to search, ^G to stop, mouse to select, Cmd-XVC cut/paste/copy, ^XS to save. And, that's about it. Forget window and buffer management, one and done!
I reload in CLISP, and run everything from there. Relying on the GNU readline interface, the listeners , *, *, etc. Particularly today, it has to be the lowest bandwidth dev experience. I don't even use any of the S-expr manipulation commands in Emacs. Just doesn't get much more advanced than ^D, backspace, ^A, ^E, ^K and ^Y, and relying on paren matching and TAB indention to catch things.
But it works. 99% of the time, I simply abort out of the stacktrace. Very rarely I'll crawl up the stack. I use the time proven "print" debugging "tool". And the listener. LOTS of rinse and repeat.
I don't do huge projects, but they're "thousands" of lines of code. I don't use many libraries (I have quicklisp installed, I just don't use any of them). But I'm not interfacing with anything. It's mostly a bunch of crude simulations and such I dabble with.
Even back with LispWorks I operated this way. My mind doesn't "see" S-exprs like that, it's just lines of characters. But, I don't think it slows me down. Learning SLIME, scaling the wall of the "sane development environment", yea, it's steep. It's why I haven't scaled it.
Simply, I want to get stuff done, not fight the tools. So, I get stuff done with my stone knives and bear skins "IDE".
The language has value, and power, and is very useful outside of its dev environment.
You might want to setup Slime using Quicklisp and give it a really good try. Simple interface to learn, especially if you use Emacs menus and don’t try to memorize all the command key combinations.
Yes, there is friction around getting set up if you want to do graphics. Or gui development.
I have managed to piece enough together to let me get started on the graphics development. I plan on bootstrapping by using Blender as my renderer (via USD transfer).
I have used LispWork’s CAPI on occasion. Just now, I am slowly starting to experiment with McCLIM more often, and I have Franz’s Open Graphics in my radar.
I still need to use Python for deep learning, but even for that Common Lisp is also a good glue language.
What's the process look like for Python these days, after you install Python itself (or are made aware of the system Python if there is one)? IDLE was pretty bad back in the day and even though it was 'easy' I wouldn't have recommended it to newcomers.
Assuming you can convince people to give emacs a try (shouldn't be hard if they're convinced to give Lisp a try and otherwise don't have preexisting biases against emacs for other reasons), getting setup for Lisp is as easy as installing Portacle (https://portacle.github.io/). It and any decent Lisp setup includes things like a hotkey to autocomplete, so you just type 'typ' and tab or whatever, and out pops suggestions like 'type', 'typep', 'type-of', ... and so you don't have to remember spelling; similarly they all should have some sort of intellisense to minimize trips to the CLHS or jumps to source code. I'm a vim head (which is why I don't know what newbie setups are like anymore apart from doing it in vim) but even when I type "(getf " I'm shown at the bottom "(getf PLACE INDICATOR &OPTIONAL (DEFAULT NIL))". If that's not enough, I can jump to source with "ctrl+]" (really nice being able to jump to the Lisp implementation's source for built-ins too without having to do anything special -- can even modify it live by adding print statements or whatever I want), or typing ",s" to get the symbol's describe output (I mainly like it for getting the docstring -- if memory serves though Portacle gives you the docstring with the lambda list in an intellisense popup automatically, like a Java IDE), and if I really need to ",h" opens a browser tab to the hyperspec page on that symbol.
If Portacle isn't one's cup of tea, it becomes a bit harder, but I don't think it's "orders of magnitude" harder... Compared to setting up a local (L|W)AMP environment back in the mid-late 2000s, which tons of teens learning PHP did, it's a piece of cake. You install a Lisp implementation (like SBCL -- http://www.sbcl.org/platform-table.html if your distro doesn't package it/have a recent version), configure it to use Quicklisp (a couple commands -- https://www.quicklisp.org/beta/), and consult the CL Cookbook for further basic steps on setting up the best environment you can for a variety of editors (https://lispcookbook.github.io/cl-cookbook/editor-support.ht... -- emacs, vim, VS Code, Atom, Sublime...).
For scaling, CL has scaled to multi-million lines of code projects, it scales fine. If you want more sophisticated type checking, there have been solutions over time, but in case you missed the latest and greatest take on it: https://github.com/coalton-lang/coalton
You asked about Python, which obviously has fantastic support: Emacs has super good support, and I also like VSCode and PyCharm. An embarrassment of riches…
And, their free versions are very capable. I subscribe to LispWorks Pro yearly updates, and if I had extra money I would like the commercial version of Allegro Common Lisp also - but since I also use SBCL a lot simply because some software like McCLIM is just easier to run with SBCL, it is really hard to justify also paying for Allegro. Initially, I paid for LW Pro to get no charge redistribution of apps, which is a good selling point. Allegro is more of an enterprise software product, and I had a long term customer who used them because of great support, AllegroStore, AllegroGraph, etc.
Compared to the 1980s, the Common Lisp ecosystem seems so much healthier and more vibrant now!
I see a lot of people using loop in the wild, but personally I took to heart Paul Graham's advice from ANSI Common Lisp to generally avoid it because of the exact reason you've suggested, it's complicated and honestly not very "Lispy". I just use do instead, and I'll admit it's not the most streamlined compared to other languages but it does the job in a simple and predictable way.
I only use loop if I'm iterating over multiple sequences or doing something tricky. Otherwise I use dolist, dotimes, map, mapcar. But it's nice to know loop is there...
Same here. Loop is handy for iterating over hash-tables and collecting. Beyond that I prefer tail recursion, map, reduce, some/every, and the do forms.
> my little brain doesn't think far enough ahead to naturally use prefix math
Nor mine, it's the only Lisp-ism I choose not to try and integrate apart from trivial expressions. (I do rather like not having to type extra +s when I'm adding multiple things together.) Similarly I disliked my dad's postfix HP calculator apart from trivial things.
But this is Lisp, and my worries were solved when I was still just a toddler: https://github.com/quil-lang/cmu-infix Being in my .sbclrc file I can always use infix math whenever I need, and it's trivial to add it as a dependency to an asdf system.
I'm surprised how little of my code, even in a 3D graphics system, is basic math on numerical types. It's mostly on points and matrices and the like, where I prefer point-add (or p+) to overloaded infix operators.
I also prefer dashes to camel case names. Plus the Symbolics keyboards let you type parens without having to use the shift key.
But, even then, I find it's much easier to write in simply because of its syntax.
I use dashes-in-all-my-identifiers. Those are very easy to type. Most of my routines break up easily in to "bunch of assignments and destructuring in let" and then "code to work on those". All of the argument lists and structures and what not are broken in to their component bits early on, then its "just code". It's very stream of consciousness then.
That said, however, I have not done a lot of interfacing to external libraries. It's mostly just me and the listener. But, even with me constantly bouncing back and forth doing prefix math (my little brain doesn't think far enough ahead to naturally use prefix math), it still flows really easily.