> <i>There exist MiniSpec and Common Lisp Quick Reference for a beginner.</i><p>Not only that, but books. Common Lisp books going all the way back to the 1980s are perfectly, or almost perfectly usable, modulo some small issues due to CL not having been ratified until 1994.<p>E.g. Wilensky's <i>Common LISPcraft</i> [1986] (don't let the all caps LISP put you off) or Stuart Shapiro's <i>Common Lisp: an Interactive Approach</i> [1992]. Norvig's PAIP (the Lisp-based original) can be used for learning Common Lisp by advanced beginners.<p>Shapiro's book is out of print, but here is the free PDF: <a href="https://cse.buffalo.edu/~shapiro/Commonlisp/commonLisp.pdf" rel="nofollow">https://cse.buffalo.edu/~shapiro/Commonlisp/commonLisp.pdf</a><p>It is disingenuous to state that the only resource for learning Common Lisp is the HyperSpec, which is hard to use, ignoring decades of books, and tutorials.
Nice writeup.<p>re: ""All these paragraphs might seem like I use Common Lisp as my daily driver. But because the people around me rely on Python, and because Python has vastly more libraries that Common Lisp, I am stuck with Python. However, sometimes, I also rely on py4cl/2 to use python libraries in Common Lisp in cases where performance is not a concern.""<p>I am in the same position. I am right now working for a 95% Common Lisp shop, but very often in the last 7 or 8 years using Python is close to mandatory when working with deep neural networks, graph neural networks, etc.
Nicely argued. I do agree that the compile times in Julia are annoying, and the debugger sucks, but I’ve come to think of them as features rather than bugs; reminders to, as you say in your note, stop and take a breath, a reminder that computers are actually very very slow and you should strive to emulate them by slowing down and stopping to skim HN while the operator puts your punch cards in the card reader and your output will show up on the line printer in a half hour or so, then you can go back to the keypunch and fix the typo and recurse.
I've been thinking about the "50% solution" problem and it's a tough nut to crack because it's self perpetuating. When combined with the lack of documentation, it means it's often faster to write your own 50% solution than it is to determine if any of the 6 existing 50% solutions already meet your needs.<p>Something I hadn't originally predicted is that Github has helped with this a bit; I have gotten PRs on my own 50% solutions that fill in some missing features. I never got a patch e-mailed to me, so the familiarity and low-friction of GH PRs is doing some good here.
<i>(Copy-pasting my comment on this from the other thread)</i><p>> If I had to wish something from Julia, it would be to provide a way to turn off runtime optimization to (radically) speed up compile times for purposes of debugging.<p>100% agreed on that. I've tried a Julia alias with `--compile=min --optimize=0` options passed in to try to say "please give me responsiveness over runtime performance", but it's still not quite the smooth flow I'd like it to be.<p>> Dynamic Binding<p>Beyond performance, it sounds like dynamic binding would have the same hard-to-debug action-at-a-distance problems that global variables often land you in, so I'm not sure it's worth it. (The specific case the author mentions would also lead to type stability problems, but that's maybe beside the point.)<p>> Structural editing<p>It's hard to process things from gifs, especially since I can't tell what the starting point of the gif is. It vaguely gives me the impression of the Emmet plugin for HTML development [1].<p>> I am aware julia has a --lisp mode, but I have never found any documentation for it. So, I don’t agree that all the things in julia are well-documented either :).<p>Afaik, the `--lisp` mode is intended to be sort of an easter egg, rather than a real mode for practical coding. I doubt many people use it other than Jeff himself. :)<p>The author doesn't say everything in Julia is well-documented by the way, or even mention Julia documentation. There's just complaints about the Lisp ecosystem's lack of documentation, and perhaps from that an implication that Julia has better docs, but I doubt the author would say all the things are well-documented - there's still quite a way to go for that to be the case.<p>Overall, the article left me more curious to explore Lisp, not less. It didn't feel particularly gloomy, and exposed me to many features of the language that make me really want to try it out. I hope there's more articles like this - in the sense of being intended for a general (non-lisp) audience, and talking about specific features rather than just "it expands your mind, it's programming like you've never done before" type statements.<p>[1] <a href="https://emmet.io/" rel="nofollow">https://emmet.io/</a>