Why Not: From Common Lisp to Julia
gist.github.com
gist.github.com
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.
Lisp, 3rd edition from Winston/Horn
then ANSI Common Lisp from Paul Graham
Common Lisp Recipes from Edi Weitz
On Lisp by Paul Graham
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.
VMs are a powerful concept (...Java....). The execution performance penalty is tolerable for so many real-world applications these days.
As you mention Java, it has been supporting dynamic compilation for 20 years now, and for those willing to pay for it, AOT compilation as well.
It isn't even the first doing it.
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.
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.
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.
> 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.
https://github.com/JuliaDebug/JuliaInterpreter.jl/blob/maste...
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"
I used the latter when I was doing my thesis in Julia, and that cut down on start times a lot.
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.