> There exist MiniSpec and Common Lisp Quick Reference for a beginner.
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.
E.g. Wilensky's Common LISPcraft [1986] (don't let the all caps LISP put you off) or Stuart Shapiro's Common Lisp: an Interactive Approach [1992]. Norvig's PAIP (the Lisp-based original) can be used for learning Common Lisp by advanced beginners.
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.
I also own 1,5 meters (the sum of the books widths) of printed documentation for Symbolics Genera, which is also available via its integrated documentation reader.
LispWorks and Allegro CL have also a large amount of current documentation.
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.""
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.
To me compilation speed is right up there with runtime speed in terms of importance. I do not like this trend where we sacrifice compilation speed to have "correct" code and give up because computers are so slow when in fact computers are incredibly fast and its this attitude of not caring about compilation speed that makes them seem so slow.
All these typed languages have to balance how much static analysis they do anyways, I just think they should dial it back and settle for the middle ground between analysis and compilation speed as the default. You can have options to increase it just as you have options for optimization levels.
The default should never be having to wait half and hour to fix a typo. That seems crazy to me but that is exactly what we have with some of these languages.
I have a strong preference for fast compilation, but the trade-off with analysis is not so straightforward.
Just finishing compilation is not sufficient to find problems, testing is needed too; if compilation and analysis can be done faster than compilation and testing, then you can still come out ahead.
I think SBCL shows that there's a decent amount of low hanging fruit for analysis; it catches a surprising number of errors with reasonably fast compilation (incremental compilation of dozens of functions feels instant), and notes places where the code could be restructured to allow for better analysis.
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.
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.
(Copy-pasting my comment on this from the other thread)
> 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.
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.
> Dynamic Binding
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.)
> Structural editing
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].
> 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 :).
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. :)
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.
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.
I wonder if this JuliaInterpreter would help with his main concern regarding "a way to turn off runtime optimization to (radically) speed up compile times for purposes of debugging."?
I'd come across it quite some time ago, but it was mentioned in the context of someone saying "I wish it was more actively developed", so I just assumed it was something of a stale project. Looking at the repo now, that doesn't seem to be the case at all. I've added an alias
alias jli="julia --project=@Interpret -e 'using JuliaInterpreter' -i"
and will give it a try over the next few days. (`@Interpret` is the environment I installed the package in.)
the main downside of it is that it is very slow. Julia can always use more compiler people, but if anyone wants to work on a faster, less debug-oriented interpreter for Julia, that would be a really valuable project.
Yeah, that kind of single, long-running project is exactly what Julia is made for, so it works out great for those use cases. I do the same when I have projects like that.
Generally though, I tend to need to switch to different clean environments, to debug others' codebases, or to work on distinct packages, etc. And even in a long running REPL, things suddenly take a lot time to run and then I realize I hadn't run that particular method in this session yet so my workflow is paused suddenly while I wait.
Also, I'd just love to be able to use Julia as a quick calculator, to run little snippets of code I need for non-project reasons, etc., just use it as a general computing environment. But the unpredictable latency makes this less pleasant than it would otherwise be.
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.
E.g. Wilensky's Common LISPcraft [1986] (don't let the all caps LISP put you off) or Stuart Shapiro's Common Lisp: an Interactive Approach [1992]. Norvig's PAIP (the Lisp-based original) can be used for learning Common Lisp by advanced beginners.
Shapiro's book is out of print, but here is the free PDF: https://cse.buffalo.edu/~shapiro/Commonlisp/commonLisp.pdf
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.