[HN Gopher] Why Not: From Common Lisp to Julia
___________________________________________________________________
Why Not: From Common Lisp to Julia
Author : ctrlmeta
Score : 69 points
Date : 2022-09-07 13:08 UTC (9 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| kazinator wrote:
| > _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.
|
| 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.
| lispm wrote:
| notable also:
|
| 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.
| cylinder714 wrote:
| David S. Touretzky's _Common Lisp: A Gentle Introduction to
| Symbolic Computation_ is in print; I picked up a copy at Barnes
| and Noble a few years ago.
|
| http://www.cs.cmu.edu/~dst/LispBook/
| sundarurfriend wrote:
| _(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.
|
| [1] https://emmet.io/
| OkayPhysicist wrote:
| Are you closing the Julia process between each run, or do you
| have a REPL sitting open in another window at all times?
|
| I used the latter when I was doing my thesis in Julia, and that
| cut down on start times a lot.
| sundarurfriend wrote:
| 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.
| borodi wrote:
| --lisp mode just lands you in the REPL of femtolisp, which is
| used for the parser and lowererer. It's kind of an easter egg
| for sure.
| williamstein wrote:
| 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."?
|
| https://github.com/JuliaDebug/JuliaInterpreter.jl/blob/maste...
| sundarurfriend wrote:
| I hope it does, thanks for reminding me of it!
|
| 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.)
| adgjlsfhk1 wrote:
| 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.
| mark_l_watson wrote:
| Nice writeup.
|
| 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.
| pjmlp wrote:
| If only Python embraced native code generation like Lisp
| languages....
| GeorgeTirebiter wrote:
| Part of what makes Python so attractive is I can develop on
| NetBSD/arm64 and deploy on Windows/x86.
|
| VMs are a powerful concept (...Java....). The execution
| performance penalty is tolerable for so many real-world
| applications these days.
| pjmlp wrote:
| No need for slow interpretation as means for portability.
|
| 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.
| Archit3ch wrote:
| The obvious one: CL can be statically compiled.
| aidenn0 wrote:
| 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.
| abrax3141 wrote:
| 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.
| [deleted]
| wudangmonk wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-07 23:02 UTC)