8 ms·

From Common Lisp to Julia

108 points by mark_l_watson 4y ago

huijzer 4y ago
Earlier discussions at https://news.ycombinator.com/item?id=32745318 https://news.ycombinator.com/item?id=32745318 with 183 points
medo-bear 4y ago
detailed answer from previous discussion Why not: from Common Lisp to Julia https://gist.github.com/digikar99/24decb414ddfa15a220b27f6748165d7 https://gist.github.com/digikar99/24decb414ddfa15a220b27f674...
mark_l_watson 4y ago
I have been mostly a Common Lisp developer since 1982 (probably 30% professional work, the rest of my paid for time split between Java, C++, Python, Prolog, and Ruby). About three years ago I was very enthusiastic about Julia becoming my primary language because so much of my work was in deep learning. I created a small repo of examples using Julia for non-numeric stuff like string processing, SPARQL query client, etc. Julia was pretty good all around. What kept me from adopting Julia was realizing that Python had so many more libraries and frameworks. Right now, I split my time between Common Lisp and Python.
- nanna 4y ago
  What kinds of areas are you finding CL work in?
  - mark_l_watson 4y ago
    Right now, at Mind AI. In the 1980s most of my IR&D at SAIC (neural networks, symbolic AI, UI demos on my Lisp Machine), and lots of consulting work. A lot of paid Clojure work also.
- uoaei 4y ago
  This is where I am stuck (albeit with drastically fewers years of experience). I want to make every piece of code in our pipelines differentiable. But ramping people up to Julia, not to mention creating and maintaining specialty libraries for in-house use, is too much just for me. But we are a small shop and no one around feels like learning a new technology.
- moelf 4y ago
  yeah general chicken and egg problem but I guess if we don't collectively take a bit of initiative, we can never have better things!
- ralphc 4y ago
  I can see needing Python instead of Julia for the libraries, but what about using Julia for new work that you'd normally do in Common Lisp, for the reasons sited in the source article?
jimbokun 4y ago
> There was no latency, or waiting for the language at all. I could live in a running Lisp image and iteratively define my programs from the inside out, or in whatever way I wanted to, with immediate feedback after each change. I am becoming more and more convinced that developer latency is the most important metric for being able to deliver value to your customer (broadly defined). How fast does you code compile? How long for test to run? How long to deploy to an integration environment? To test environment with real users? To production? Lisp in some ways is still unmatched in this metric, for the kinds of reasons cited by the author.
- Jtsummers 4y ago
  > I am becoming more and more convinced that developer latency is the most important metric for being able to deliver value to your customer (broadly defined). This is generally true. Tighter feedback loops lead to greater responsiveness. You just have to make sure you don't get overwhelmed by them, too (feedback faster than you can respond to it).
  - guenthert 4y ago
    A shorter change->effect delay eases learning (near instant gratification), but then again, Turbo Pascal on CP/M did already a good job at that.
- aidenn0 4y ago
  I have experienced this at work. We were working on a somewhat complex embedded system and seeing some unusual performance corner-cases. Everyone had a different theory for what was causing the problem. So I fired up SLIME and wrote a high-level simulator for the system, starting simple and adding in the complexities. Once we were seeing the same performance profile as the embedded system, I stopped, and we now had a malleable system. Then I spend the next 15 minutes implementing each of the recommended performance fixed individually, and we found one that worked in the simulation and then implemented that one in the real environment (it took almost 15 minutes just to update the program on the embedded target, and much longer to run a full test-case). Making it so you can check your guesses faster means you need not be as good at guessing. I should put in one additional warning though: don't fall into the trap of "make random changes until it looks like it works" and call it done. At this point we had only demonstrated that we knew where the issue was; the final fix was significantly different than the "quick and dirty" fix suggested by the simulation. The simulation I wrote definitely saved weeks (if not months) of time because 90% of the team was convinced that the issue was in a different part of the system than it ended up being in. We found the issue only because "It will take less than a minute, so what's the harm in trying?"
Joel_Mckay 4y ago
Lisp has a readability issue, where the syntax makes the authors intent not immediately clear with all the brackets. I think it shared too many of the issues RPL and Forth had to be sustainable outside academia. When it comes to implicit parallel code, Julia hid a lot of the gruesome details in a friendly interface similar to Octave, Matlab, and Python. However, what surprised me most of all was its math ops are often still faster on a CPU than Numpy and many native C libs. Julia still has a long way to go with its package version compatibility, but it is slowly improving as the core implementation stabilizes.
- deleted 4y ago
  [deleted]
- Oreb 4y ago
  Like any language, Lisp has readability issues when you’re not familiar with it. You find it hard to read because it’s alien to you. To my eyes – because Lisp is what I’m used to – every non-Lisp language has readability issues. These days I do a significant amount of work in Python, Rust and Julia, and although there are things I love in all of these languages, I always miss s-expression syntax when using them.
  - kazinator 4y ago
    Infix notation can be useful for arithmetic; as a "Lisp person" I acknowledge that. S-exps can be good for arithmetic too though. S-expressions allow n-ary operators: (+ (* 3 x y) (* a b z w) (* r s t u v)) There is a systematic way to break up large expressions across multiple lines, which helps readability. Infix doesn't have a satisfactory way to do this: (+ (* 3 x y) (* a b z w) (* r s t u v)) We see just from from the + * * * pattern that we have a sum of three products. S-exps are unambiguous. You never misread an arithmetic (or any other) S-exp due to precedence, unless it's a macro that has created precedence rules among its arguments (vanishingly rare). N-ary math functions associate left to right in Common LIsp: (+ a b c d) means we add (a b) first, then c, and d. This makes a difference when you have mixed types, which have to undergo conversions, and when you have non-associative types like floating-point. If I'm cribbing some numeric calculation to use in my code (whether that code is Lisp or not), and have examples in half a dozen languages, none of which I use, I will crib it from that one that is a Lisp dialect, just because of the vanishingly small opportunity for getting it wrong due to some ambiguity issue.
twobitshifter 4y ago
What are some Julia projects outside of data science and academia?
- europeanguy 4y ago
  Many examples finance, just companies in finance for the most part don't talk about their tech stack much (although that's changing).
- thetwentyone 4y ago
  https://juliacomputing.com/case-studies/ https://juliacomputing.com/case-studies/
guenthert 4y ago
So far I have little experience with Julia, but it looks to me very promising. Personally, I like a more settled environment and prefer languages defined by a standard, not by a single implementation. "Infact, the first version of my most recent project saw an order of magnitude difference when ported from Common Lisp to Julia, without any effort or attention to optimization techniques." That might have been the case, but one mustn't expect that generally to be so, see e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-sbcl.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... which shows much closer results (and multiple attempts for either language for any given benchmark to get better results). Seems that Julia struggles with the binary-tree benchmark. Then again, run-time performance is for many (and over time, more and more) applications not the most relevant criteria (otherwise Python wouldn't be so successful).
- jakobnissen 4y ago
  That benchmark in particular has different rules for GC languages vs non-GC languages. Absurd, but true. Non-GC languages are allowed to pre-allocated a memory arena, GC languages are not. For the naive implementation, Julia beats Rust in this benchmark.
  - guenthert 4y ago
    > That benchmark in particular has different rules for GC languages vs non-GC languages. Absurd, but true. Fair to point out, but since that benchmark is "A simplistic adaptation of Hans Boehm's GCBench", those rules are perhaps not quite so absurd. It also doesn't explain why Julia should be so much slower than Java or SBCL. I rather expect Julia to do better here in the future.
    - adgjlsfhk1 4y ago
      Yeah. The problem here is that Julia gives you a bunch of tools to avoid GC by aggressively stack allocating or preallocating so our GC algorithm is pretty meh. We're about to merge a parallel algorithm, and are looking into switching to MMTK, but if anyone from the Java/lisp/Go world wants to help us out, we would love people who can help improve our GC. There are a few things Julia does that makes it a bit harder (the stack allocation+LLVM makes getting roots a little more complicated, and we make it easy for C to take Julia memory so we can't do a compacting collector).
silasdavis 4y ago
I was looking for a new data notebook toy to ease the tedium of reporting some metrics. I found the clojure-based https://github.com/nextjournal/clerk https://github.com/nextjournal/clerk which I like the look of and remember clojure being rather pleasing interactively. That lisp and Julia might have some commonality made me look for something similar (that isn't jupyter) for Julia. Seems like https://github.com/fonsp/Pluto.jl https://github.com/fonsp/Pluto.jl is such a thing. Does anyone have any experience of either they could share?
- casparvitch 4y ago
  Pluto is the best notebook system I've used, and development is very rapid so it's getting better all the time.
  - nerdponx 4y ago
    My problem with notebooks is that I don't get to use any of my highly-customized Neovim extensions. I'm sure Emacs users feel the same way. That aside, I still have not found my ideal notebook client. I don't particularly like the "notebook" format anyway. I prefer having my code and output side-by-side. I want to be able to toggle among the "code | output" vertical split layout, code-only, and output-only, on a per-cell basis. I also want the split to be adjustable in each cell, so I can make the code take up 90% of the width or 10% of the width if I want it to. I of course want cells to be vertically collapsible. And I want an automatic table of contents in a sidebar "drawer". I want reactivity between cells. I want an extension ecosystem with things like a nice file picker and a built-in Git GUI. I want to connect to remote kernels (this is supposed to be possible with the Jupyter ecosystem but practically it's not well supported). And most of all, I don't want to run it in a damn Web browser! And if the text editor box was also an embedded Neovim frontend, I wouldn't complain about that.
martinsmit 4y ago
On the flipside, I was thinking of learning CL as a Julia developer and this post has somewhat discouraged me to do so. What can learning CL do for me apart from realising that S-expression syntax is superior? For context, I very often find myself building small libraries from scratch to solve very specific scientific problems which is somewhat performance critical. Julia has worked very well for me for this, but I recognise that moving outside of your comfort zone is the best way to become a better programmer.
- reikonomusha 4y ago
  It's not that S-expression syntax is superficial better or worse, it's that S-expression syntax acts as a vehicle for linguistic abstraction. What I mean by that is that Lisp lets you seamlessly integrate new constructs into your programming environment that didn't previously exist. Lisp doesn't have a "parallel for-loop"? Well, it's easy to add one in a few lines of code. That, combined with the unrelenting support for interactive and incremental development, make Lisp at least a novel experience, and hopefully a transformative one.
  - int_19h 4y ago
    Thing is, by now, we have plenty of languages with macros that let you do things like implement a parallel for-loop as a library - and it doesn't require keeping all your syntax that primitive. It does mean that macros are a bit harder to write, but I would argue that more readable syntax saves more time overall (since you aren't writing macros most of the time).

108 points by mark_l_watson 4y ago

Earlier discussions at https://news.ycombinator.com/item?id=32745318 https://news.ycombinator.com/item?id=32745318 with 183 points

medo-bear 4y ago

detailed answer from previous discussion Why not: from Common Lisp to Julia https://gist.github.com/digikar99/24decb414ddfa15a220b27f6748165d7 https://gist.github.com/digikar99/24decb414ddfa15a220b27f674...

mark_l_watson 4y ago

I have been mostly a Common Lisp developer since 1982 (probably 30% professional work, the rest of my paid for time split between Java, C++, Python, Prolog, and Ruby). About three years ago I was very enthusiastic about Julia becoming my primary language because so much of my work was in deep learning. I created a small repo of examples using Julia for non-numeric stuff like string processing, SPARQL query client, etc. Julia was pretty good all around. What kept me from adopting Julia was realizing that Python had so many more libraries and frameworks. Right now, I split my time between Common Lisp and Python.

nanna 4y ago
What kinds of areas are you finding CL work in?
- mark_l_watson 4y ago
  Right now, at Mind AI. In the 1980s most of my IR&D at SAIC (neural networks, symbolic AI, UI demos on my Lisp Machine), and lots of consulting work. A lot of paid Clojure work also.
uoaei 4y ago
This is where I am stuck (albeit with drastically fewers years of experience). I want to make every piece of code in our pipelines differentiable. But ramping people up to Julia, not to mention creating and maintaining specialty libraries for in-house use, is too much just for me. But we are a small shop and no one around feels like learning a new technology.
moelf 4y ago
yeah general chicken and egg problem but I guess if we don't collectively take a bit of initiative, we can never have better things!
ralphc 4y ago
I can see needing Python instead of Julia for the libraries, but what about using Julia for new work that you'd normally do in Common Lisp, for the reasons sited in the source article?

jimbokun 4y ago

> There was no latency, or waiting for the language at all. I could live in a running Lisp image and iteratively define my programs from the inside out, or in whatever way I wanted to, with immediate feedback after each change. I am becoming more and more convinced that developer latency is the most important metric for being able to deliver value to your customer (broadly defined). How fast does you code compile? How long for test to run? How long to deploy to an integration environment? To test environment with real users? To production? Lisp in some ways is still unmatched in this metric, for the kinds of reasons cited by the author.

Jtsummers 4y ago
> I am becoming more and more convinced that developer latency is the most important metric for being able to deliver value to your customer (broadly defined). This is generally true. Tighter feedback loops lead to greater responsiveness. You just have to make sure you don't get overwhelmed by them, too (feedback faster than you can respond to it).
- guenthert 4y ago
  A shorter change->effect delay eases learning (near instant gratification), but then again, Turbo Pascal on CP/M did already a good job at that.
aidenn0 4y ago
I have experienced this at work. We were working on a somewhat complex embedded system and seeing some unusual performance corner-cases. Everyone had a different theory for what was causing the problem. So I fired up SLIME and wrote a high-level simulator for the system, starting simple and adding in the complexities. Once we were seeing the same performance profile as the embedded system, I stopped, and we now had a malleable system. Then I spend the next 15 minutes implementing each of the recommended performance fixed individually, and we found one that worked in the simulation and then implemented that one in the real environment (it took almost 15 minutes just to update the program on the embedded target, and much longer to run a full test-case). Making it so you can check your guesses faster means you need not be as good at guessing. I should put in one additional warning though: don't fall into the trap of "make random changes until it looks like it works" and call it done. At this point we had only demonstrated that we knew where the issue was; the final fix was significantly different than the "quick and dirty" fix suggested by the simulation. The simulation I wrote definitely saved weeks (if not months) of time because 90% of the team was convinced that the issue was in a different part of the system than it ended up being in. We found the issue only because "It will take less than a minute, so what's the harm in trying?"

Joel_Mckay 4y ago

Lisp has a readability issue, where the syntax makes the authors intent not immediately clear with all the brackets. I think it shared too many of the issues RPL and Forth had to be sustainable outside academia. When it comes to implicit parallel code, Julia hid a lot of the gruesome details in a friendly interface similar to Octave, Matlab, and Python. However, what surprised me most of all was its math ops are often still faster on a CPU than Numpy and many native C libs. Julia still has a long way to go with its package version compatibility, but it is slowly improving as the core implementation stabilizes.

deleted 4y ago
[deleted]
Oreb 4y ago
Like any language, Lisp has readability issues when you’re not familiar with it. You find it hard to read because it’s alien to you. To my eyes – because Lisp is what I’m used to – every non-Lisp language has readability issues. These days I do a significant amount of work in Python, Rust and Julia, and although there are things I love in all of these languages, I always miss s-expression syntax when using them.
- kazinator 4y ago
  Infix notation can be useful for arithmetic; as a "Lisp person" I acknowledge that. S-exps can be good for arithmetic too though. S-expressions allow n-ary operators: (+ (* 3 x y) (* a b z w) (* r s t u v)) There is a systematic way to break up large expressions across multiple lines, which helps readability. Infix doesn't have a satisfactory way to do this: (+ (* 3 x y) (* a b z w) (* r s t u v)) We see just from from the + * * * pattern that we have a sum of three products. S-exps are unambiguous. You never misread an arithmetic (or any other) S-exp due to precedence, unless it's a macro that has created precedence rules among its arguments (vanishingly rare). N-ary math functions associate left to right in Common LIsp: (+ a b c d) means we add (a b) first, then c, and d. This makes a difference when you have mixed types, which have to undergo conversions, and when you have non-associative types like floating-point. If I'm cribbing some numeric calculation to use in my code (whether that code is Lisp or not), and have examples in half a dozen languages, none of which I use, I will crib it from that one that is a Lisp dialect, just because of the vanishingly small opportunity for getting it wrong due to some ambiguity issue.

twobitshifter 4y ago

What are some Julia projects outside of data science and academia?

europeanguy 4y ago
Many examples finance, just companies in finance for the most part don't talk about their tech stack much (although that's changing).
thetwentyone 4y ago
https://juliacomputing.com/case-studies/ https://juliacomputing.com/case-studies/

guenthert 4y ago

So far I have little experience with Julia, but it looks to me very promising. Personally, I like a more settled environment and prefer languages defined by a standard, not by a single implementation. "Infact, the first version of my most recent project saw an order of magnitude difference when ported from Common Lisp to Julia, without any effort or attention to optimization techniques." That might have been the case, but one mustn't expect that generally to be so, see e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-sbcl.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... which shows much closer results (and multiple attempts for either language for any given benchmark to get better results). Seems that Julia struggles with the binary-tree benchmark. Then again, run-time performance is for many (and over time, more and more) applications not the most relevant criteria (otherwise Python wouldn't be so successful).

jakobnissen 4y ago
That benchmark in particular has different rules for GC languages vs non-GC languages. Absurd, but true. Non-GC languages are allowed to pre-allocated a memory arena, GC languages are not. For the naive implementation, Julia beats Rust in this benchmark.
- guenthert 4y ago
  > That benchmark in particular has different rules for GC languages vs non-GC languages. Absurd, but true. Fair to point out, but since that benchmark is "A simplistic adaptation of Hans Boehm's GCBench", those rules are perhaps not quite so absurd. It also doesn't explain why Julia should be so much slower than Java or SBCL. I rather expect Julia to do better here in the future.
  - adgjlsfhk1 4y ago
    Yeah. The problem here is that Julia gives you a bunch of tools to avoid GC by aggressively stack allocating or preallocating so our GC algorithm is pretty meh. We're about to merge a parallel algorithm, and are looking into switching to MMTK, but if anyone from the Java/lisp/Go world wants to help us out, we would love people who can help improve our GC. There are a few things Julia does that makes it a bit harder (the stack allocation+LLVM makes getting roots a little more complicated, and we make it easy for C to take Julia memory so we can't do a compacting collector).

silasdavis 4y ago

I was looking for a new data notebook toy to ease the tedium of reporting some metrics. I found the clojure-based https://github.com/nextjournal/clerk https://github.com/nextjournal/clerk which I like the look of and remember clojure being rather pleasing interactively. That lisp and Julia might have some commonality made me look for something similar (that isn't jupyter) for Julia. Seems like https://github.com/fonsp/Pluto.jl https://github.com/fonsp/Pluto.jl is such a thing. Does anyone have any experience of either they could share?

casparvitch 4y ago
Pluto is the best notebook system I've used, and development is very rapid so it's getting better all the time.
- nerdponx 4y ago
  My problem with notebooks is that I don't get to use any of my highly-customized Neovim extensions. I'm sure Emacs users feel the same way. That aside, I still have not found my ideal notebook client. I don't particularly like the "notebook" format anyway. I prefer having my code and output side-by-side. I want to be able to toggle among the "code | output" vertical split layout, code-only, and output-only, on a per-cell basis. I also want the split to be adjustable in each cell, so I can make the code take up 90% of the width or 10% of the width if I want it to. I of course want cells to be vertically collapsible. And I want an automatic table of contents in a sidebar "drawer". I want reactivity between cells. I want an extension ecosystem with things like a nice file picker and a built-in Git GUI. I want to connect to remote kernels (this is supposed to be possible with the Jupyter ecosystem but practically it's not well supported). And most of all, I don't want to run it in a damn Web browser! And if the text editor box was also an embedded Neovim frontend, I wouldn't complain about that.

martinsmit 4y ago

On the flipside, I was thinking of learning CL as a Julia developer and this post has somewhat discouraged me to do so. What can learning CL do for me apart from realising that S-expression syntax is superior? For context, I very often find myself building small libraries from scratch to solve very specific scientific problems which is somewhat performance critical. Julia has worked very well for me for this, but I recognise that moving outside of your comfort zone is the best way to become a better programmer.

reikonomusha 4y ago
It's not that S-expression syntax is superficial better or worse, it's that S-expression syntax acts as a vehicle for linguistic abstraction. What I mean by that is that Lisp lets you seamlessly integrate new constructs into your programming environment that didn't previously exist. Lisp doesn't have a "parallel for-loop"? Well, it's easy to add one in a few lines of code. That, combined with the unrelenting support for interactive and incremental development, make Lisp at least a novel experience, and hopefully a transformative one.
- int_19h 4y ago
  Thing is, by now, we have plenty of languages with macros that let you do things like implement a parallel for-loop as a library - and it doesn't require keeping all your syntax that primitive. It does mean that macros are a bit harder to write, but I would argue that more readable syntax saves more time overall (since you aren't writing macros most of the time).