8 ms·

Switching from Common Lisp to Julia (2017)

118 points by mindB 7y ago

conjectures 7y ago
This is now a little out of date given 1.0+ has been released. Still a decent article though.
adamnemecek 7y ago
Julia is one of my fav languages. For numerical computing, neither python + numpy, nor matlab come even close. The interop is nuts. To call, say numpy fft, you just do using PyCall np = pyimport("numpy") res = np.fft.fft(rand(ComplexF64, 10)) No casting back and forth. This is a toy example, julia ofc has fftw bindings.
- dangom 7y ago
  As of today, how would you compare Julia to the Python ecosystem? Could I use Julia as a "drop-in" replacement for the python scientific stack already?
  - jey 7y ago
    It can depend on which specific Python packages you're using, but generally speaking the Julia ecosystem is pretty mature for scientific computing and data analysis. And as the GP post demonstrated, you can fill in the gaps by using the awesome PyCall interface to directly call Python code.
  - adamnemecek 7y ago
    As I mention above, the interop is really good so you can literally start using it right now without rewriting anything. The ecosystem is smaller, but the average package quality is higher. It's easier to contribute to packages, since in python, you'd sometimes just end up writing C. Julia packages are generally pure julia.
  - ChrisRackauckas 7y ago
    For what I do (scientific computing mixed with differential equations, so lots of things like neural partial differential equations which utilize lots of special numerical linear algebra and sparsity handling), the packages exist in Julia but not in Python, MATLAB, or R.
- marmaduke 7y ago
  It seems little known, but Matlab has had Python interop since 2015, your code would just be res = py.numpy.fft.fft(rand(10,1))
fmakunbound 7y ago
I think Edi uses Julia too, now
- lispm 7y ago
  2018 he published a mathematics book with examples in Python.
ddragon 7y ago
Considering how close Julia is to Lisp, it could be interesting to have an actual Lisp targeting the Julia compiler, for people who don't want to compromise on s-expr but would still want to have a performance oriented Lisp with access to a lot of scientific computation and ML libraries (and probably better interop compared to Clojure and Java for example). The only work I know for this is: https://github.com/swadey/LispSyntax.jl https://github.com/swadey/LispSyntax.jl
- adamnemecek 7y ago
  Julia ships with femtolisp. I've never used it. To start it, run julia --lisp
  - jhbadger 7y ago
    Yes, but this doesn't expose any Julia functionality, so it isn't really useable. I think the parent was looking for something akin to Lisp Flavored Erlang, where the whole language is usable with a Lisp-inspired syntax.
  - 6thaccount2 7y ago
    Is femtolisp useful? Does it expose functions like filesystem interactions?
- doctoboggan 7y ago
  Jeff (creator of Julia) created femtolisp [0] which is used in the Julia parser. [0]: https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp
  - jimbokun 7y ago
    This is a wonderful quote: "This is what I do for fun, because it is the exact opposite of the kind of thing people will pay for: an obscure implementation of a programming language everybody hates." Great attitude!
- pflanze 7y ago
nudpiedo 7y ago
I don't know why no one seems to think about symbolic programming which was the original killer feature of lisp, and one of the main reasons for doing macros. In math oriented programming this should be one of the most powerful features and skills in order to simplify and modify calculations. Sure you can implement that with macros and AST but that is not at the level of S-Expressions. Everything else is not more important as any other competition of DSLs.
- chongli 7y ago
  Generally it seems people prefer to keep symbolic and numerical computation separate. Perhaps it's due to the cultural schism between pure and applied mathematics, or perhaps it's something else. Having said that, I think people tend to prefer to work out their final equations using symbolic software before transcribing the functions into a numerical system. Maybe it's too hard to reason about what's going on if your machine is both deriving the equations and computing the numerical result in one go?
- jahewson 7y ago
  I'm going to speculate wildly and suggest that most math-oriented code nowadays is not analytical, but numerical, where the advantage of having a symbolic system is limited.
- ddragon 7y ago
  That was the strength of Lisp as the original 'AI' language, but the following AI summer were always more numerical oriented (neural networks, bayesian inference, SVM, neural networks part 2), so that particular strength was not very needed. And in the end the most important killer feature of an 'AI' language ended up being approachable and easy to use, and not the "power", which is why Julia goes with the "Looks like Python, feels like Lisp, runs like Fortran". And like you said, even without s-expr you can do it with macros (especially in a homoiconic language like Julia), for example: https://github.com/chakravala/Reduce.jl https://github.com/chakravala/Reduce.jl https://github.com/korsbo/Latexify.jl https://github.com/korsbo/Latexify.jl
  - 7y ago
pcr910303 7y ago
Common Lisp folks should really start designing a more modern version of CL. I'm pretty sure some old Lispers would come and say, 'Common Lisp's stability is a great feature', 'There are lots of new dialects', and while they are right in some aspects, Common Lisp isn't appealing to anyone these days. (I mean, even C and C++ is improving. Why shouldn't CL?) Even for people who 'get' the ideas of s-exps and macros, there are too many quirks in CL to appeal to people, and most go to Clojure (where the interactive experience is at best moderate, debbuging support/error handling is a mess, e.g.). I believe the hypothetical CL++ should at least: * Straight out incompatibilites between implementations, especially the numerous opinions to make an image or binary, and the FFI parts. * Design a better CLOS system. CLOS feels like an object system thought after (well, after all it is a system thought after) and bolted on CL with duct tape. I would appreciate a CLOS-based type system (based on macros much like CLOS) that integrates well with CL. * Remove unused functions, and fixing some inconsisties in the standard library * Bigger, much much bigger standard library. Crucial, community-standard libraries like asdf & uiop, syntax-sugar like the arrow/diamond macros, and reader macros that allow infix syntax (this currently exists in the standard but nobody uses it partly because most Lisp users don't really care about infix, partly because it's extensiblity is bad) should be in the std. * A compatibility layer. Providing a 'cl' and 'cl-user' package with the usual CL symbols will be sufficient. to appeal to the users. This really isn't sufficient for the hypothetical CL++ itself; there really should be beginner materials that isn't PCL; Lispers shouldn't hate infix reader macros or syntax-sugar like LOOP(IMHO these show the real power of macros, after all, macros are another tool to write readable code with great abstractions) and beginner materials should use, or at least introduce them(infix reader macros and other syntax sugar). Just a rant about the language after reading the post and becoming sad.
- nudpiedo 7y ago
  Don't forget a package installer/dependency manager as in NPM/PIP/CPAN. Nowadays I cannot look to a programming language without one of those... it is just too painful to look for libraries, download them, set in a separate folder, etc...
  - rjsw 7y ago
higherkinded 7y ago
Off the topic but, Why keep reinventing the wheel when there's an ML language family already? Why do people keep giving up these juicy Hindley—Milner-ish type systems and these brief and concise equations for anything? It just doesn't make sense for me.
- antisemiotic 7y ago
  In both SML and OCaml writing a function that's polymorphic over numeric types is a huge pain in the ass, so I'm not sure it's a good choice for numeric programming. (Unless you count Haskell as a member of the ML family?) Though it could be that generics aren't that important here, and I'm just a weirdo who liked to do things like implementing a dual number type to get forward-mode automatic differentiation of standard functions for free...
  - higherkinded 7y ago
    Haskell is its direct descendant, so of course it counts. It has all the traits required to be called that, and I'm implicitly talking towards it in the initial comment while still respecting the family. And for what I know, OCaml has generics, so I'm not exactly sure what do you mean here.
    - antisemiotic 7y ago
      I haven't ever written any OCaml, but I thought it has separate operators for ints and floats. I've written some SML and it has some special hacks to allow overloading on built-in operators. While I do understand that ML style modules are theoretically more powerful than Haskell's typeclasses, they always struck me as much clunkier for everyday use (that's why I personally consider ML family and Haskell family as separate - the approach to ad-hoc polymorphism is an important difference in my opinion)
      - ernst_klim 7y ago
        > they always struck me as much clunkier for everyday use They are simply explicit. What's so clunky about modular implicits, for example? Personally, I prefer explicit modules and hate typeclasses, because I can't look at the code and say if this operation is a primitive operator or some dynamically dispatched class method. Besides, modules are way more powerful, and have a way broader use. They can encapsulate state, types, can be parametric etc.
sischoel 7y ago
As far as I know, parts of the Julia parser is still written in a Lisp variant called Femtolisp. Also one can run Femtolisp by executing: julia --lisp
markhalonen 7y ago
I'm using Julia instead of Python/Pandas for a machine learning project and I'm happy with how things are going. Multiple dispatch is very cool. The project was previously written in R, but the performance and lack of programming clarity inspired a re-write in Julia. There is something satisfying about writing code in a high-performance language, you just know you won't be kicking yourself because it would run 10x faster in another language.
leanthonyrn 7y ago
I was thinking about this the other day. How can I expose my Common Lisp code to Julia. 1. You could take the Clasp path by exposing CL to C++. https://youtu.be/8X69_42Mj-g https://youtu.be/8X69_42Mj-g This means taking / writing a CL in Julia. 2. Julia has an AST representation written in femtolisp. So it would be in interesting target for CL or some glue middle language like Shen. http://www.shenlanguage.org/ http://www.shenlanguage.org/ https://youtu.be/lMcRBdSdO_U https://youtu.be/lMcRBdSdO_U
vindarel 7y ago
For numeric work in CL, one might like Numcl, a clone of Numpy: https://github.com/numcl/numcl https://github.com/numcl/numcl
cat199 7y ago
Seems like this: You can of course branch on the array element types and maybe even paper over the whole mess with sufficient macrology (which is what LLA ended up doing), but this approach is not very extensible, as eventually you end up hardcoding a few special types for which your functions will be "fast", otherwise they have to fall back to a generic, boxed type. is exactly what numpy/scipy is doing (s/macrology/c-functions/), but they are successful.. granted julia has more ground-up support for these things, but it doesn't seem like an impediment to scientific computing per-se, provided sufficient userbase
dang 7y ago
Discussed at the time: https://news.ycombinator.com/item?id=15478131 https://news.ycombinator.com/item?id=15478131
StefanKarpinski 7y ago
Tamas is a very active participant in the Julia ecosystem, so it seems that the switch went pretty well! Julia 1.0 was released a little over a year ago at JuliaCon 2018. At this year's JuliaCon, there was, imo, an even more positive "vibe" than past years, which were already full of excitement. My guess is that it may be because everyone has been really happy to have a year of not breaking things and building cool new stuff on top of the solid foundation of Julia the Julia 1.x series.
coldtea 7y ago
>The standard does not guarantee that this gives you an array of double-float: it may (if the implementation provides them), otherwise you get an array of element type T. This turned out to be a major difficulty for implementing portable scientific code in Common Lisp. Well, so? Just use a single CL implementation that does give you the guarantee. After all you are now switching to use a single Julia implementation (there's no other anyway). If portability is a concern, at least with CL you can always port 95% of your code to several implementations, and then write special code those kind of incompatibilities. With Julia one platform is all you get. So how's that better, from the point of this complaint?

118 points by mindB 7y ago

This is now a little out of date given 1.0+ has been released. Still a decent article though.

Julia is one of my fav languages. For numerical computing, neither python + numpy, nor matlab come even close. The interop is nuts. To call, say numpy fft, you just do using PyCall np = pyimport("numpy") res = np.fft.fft(rand(ComplexF64, 10)) No casting back and forth. This is a toy example, julia ofc has fftw bindings.

dangom 7y ago
As of today, how would you compare Julia to the Python ecosystem? Could I use Julia as a "drop-in" replacement for the python scientific stack already?
- jey 7y ago
  It can depend on which specific Python packages you're using, but generally speaking the Julia ecosystem is pretty mature for scientific computing and data analysis. And as the GP post demonstrated, you can fill in the gaps by using the awesome PyCall interface to directly call Python code.
- adamnemecek 7y ago
  As I mention above, the interop is really good so you can literally start using it right now without rewriting anything. The ecosystem is smaller, but the average package quality is higher. It's easier to contribute to packages, since in python, you'd sometimes just end up writing C. Julia packages are generally pure julia.
- ChrisRackauckas 7y ago
  For what I do (scientific computing mixed with differential equations, so lots of things like neural partial differential equations which utilize lots of special numerical linear algebra and sparsity handling), the packages exist in Julia but not in Python, MATLAB, or R.
marmaduke 7y ago
It seems little known, but Matlab has had Python interop since 2015, your code would just be res = py.numpy.fft.fft(rand(10,1))

fmakunbound 7y ago

I think Edi uses Julia too, now

lispm 7y ago
2018 he published a mathematics book with examples in Python.

ddragon 7y ago

Considering how close Julia is to Lisp, it could be interesting to have an actual Lisp targeting the Julia compiler, for people who don't want to compromise on s-expr but would still want to have a performance oriented Lisp with access to a lot of scientific computation and ML libraries (and probably better interop compared to Clojure and Java for example). The only work I know for this is: https://github.com/swadey/LispSyntax.jl https://github.com/swadey/LispSyntax.jl

adamnemecek 7y ago
Julia ships with femtolisp. I've never used it. To start it, run julia --lisp
- jhbadger 7y ago
  Yes, but this doesn't expose any Julia functionality, so it isn't really useable. I think the parent was looking for something akin to Lisp Flavored Erlang, where the whole language is usable with a Lisp-inspired syntax.
- 6thaccount2 7y ago
  Is femtolisp useful? Does it expose functions like filesystem interactions?
doctoboggan 7y ago
Jeff (creator of Julia) created femtolisp [0] which is used in the Julia parser. [0]: https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp
- jimbokun 7y ago
  This is a wonderful quote: "This is what I do for fun, because it is the exact opposite of the kind of thing people will pay for: an obscure implementation of a programming language everybody hates." Great attitude!
pflanze 7y ago

nudpiedo 7y ago

I don't know why no one seems to think about symbolic programming which was the original killer feature of lisp, and one of the main reasons for doing macros. In math oriented programming this should be one of the most powerful features and skills in order to simplify and modify calculations. Sure you can implement that with macros and AST but that is not at the level of S-Expressions. Everything else is not more important as any other competition of DSLs.

chongli 7y ago
Generally it seems people prefer to keep symbolic and numerical computation separate. Perhaps it's due to the cultural schism between pure and applied mathematics, or perhaps it's something else. Having said that, I think people tend to prefer to work out their final equations using symbolic software before transcribing the functions into a numerical system. Maybe it's too hard to reason about what's going on if your machine is both deriving the equations and computing the numerical result in one go?
jahewson 7y ago
I'm going to speculate wildly and suggest that most math-oriented code nowadays is not analytical, but numerical, where the advantage of having a symbolic system is limited.
ddragon 7y ago
That was the strength of Lisp as the original 'AI' language, but the following AI summer were always more numerical oriented (neural networks, bayesian inference, SVM, neural networks part 2), so that particular strength was not very needed. And in the end the most important killer feature of an 'AI' language ended up being approachable and easy to use, and not the "power", which is why Julia goes with the "Looks like Python, feels like Lisp, runs like Fortran". And like you said, even without s-expr you can do it with macros (especially in a homoiconic language like Julia), for example: https://github.com/chakravala/Reduce.jl https://github.com/chakravala/Reduce.jl https://github.com/korsbo/Latexify.jl https://github.com/korsbo/Latexify.jl
- 7y ago

pcr910303 7y ago

Common Lisp folks should really start designing a more modern version of CL. I'm pretty sure some old Lispers would come and say, 'Common Lisp's stability is a great feature', 'There are lots of new dialects', and while they are right in some aspects, Common Lisp isn't appealing to anyone these days. (I mean, even C and C++ is improving. Why shouldn't CL?) Even for people who 'get' the ideas of s-exps and macros, there are too many quirks in CL to appeal to people, and most go to Clojure (where the interactive experience is at best moderate, debbuging support/error handling is a mess, e.g.). I believe the hypothetical CL++ should at least: * Straight out incompatibilites between implementations, especially the numerous opinions to make an image or binary, and the FFI parts. * Design a better CLOS system. CLOS feels like an object system thought after (well, after all it is a system thought after) and bolted on CL with duct tape. I would appreciate a CLOS-based type system (based on macros much like CLOS) that integrates well with CL. * Remove unused functions, and fixing some inconsisties in the standard library * Bigger, much much bigger standard library. Crucial, community-standard libraries like asdf & uiop, syntax-sugar like the arrow/diamond macros, and reader macros that allow infix syntax (this currently exists in the standard but nobody uses it partly because most Lisp users don't really care about infix, partly because it's extensiblity is bad) should be in the std. * A compatibility layer. Providing a 'cl' and 'cl-user' package with the usual CL symbols will be sufficient. to appeal to the users. This really isn't sufficient for the hypothetical CL++ itself; there really should be beginner materials that isn't PCL; Lispers shouldn't hate infix reader macros or syntax-sugar like LOOP(IMHO these show the real power of macros, after all, macros are another tool to write readable code with great abstractions) and beginner materials should use, or at least introduce them(infix reader macros and other syntax sugar). Just a rant about the language after reading the post and becoming sad.

nudpiedo 7y ago
Don't forget a package installer/dependency manager as in NPM/PIP/CPAN. Nowadays I cannot look to a programming language without one of those... it is just too painful to look for libraries, download them, set in a separate folder, etc...
- rjsw 7y ago

higherkinded 7y ago

Off the topic but, Why keep reinventing the wheel when there's an ML language family already? Why do people keep giving up these juicy Hindley—Milner-ish type systems and these brief and concise equations for anything? It just doesn't make sense for me.

antisemiotic 7y ago
In both SML and OCaml writing a function that's polymorphic over numeric types is a huge pain in the ass, so I'm not sure it's a good choice for numeric programming. (Unless you count Haskell as a member of the ML family?) Though it could be that generics aren't that important here, and I'm just a weirdo who liked to do things like implementing a dual number type to get forward-mode automatic differentiation of standard functions for free...
- higherkinded 7y ago
  Haskell is its direct descendant, so of course it counts. It has all the traits required to be called that, and I'm implicitly talking towards it in the initial comment while still respecting the family. And for what I know, OCaml has generics, so I'm not exactly sure what do you mean here.
  - antisemiotic 7y ago
    I haven't ever written any OCaml, but I thought it has separate operators for ints and floats. I've written some SML and it has some special hacks to allow overloading on built-in operators. While I do understand that ML style modules are theoretically more powerful than Haskell's typeclasses, they always struck me as much clunkier for everyday use (that's why I personally consider ML family and Haskell family as separate - the approach to ad-hoc polymorphism is an important difference in my opinion)
    - ernst_klim 7y ago
      > they always struck me as much clunkier for everyday use They are simply explicit. What's so clunky about modular implicits, for example? Personally, I prefer explicit modules and hate typeclasses, because I can't look at the code and say if this operation is a primitive operator or some dynamically dispatched class method. Besides, modules are way more powerful, and have a way broader use. They can encapsulate state, types, can be parametric etc.

sischoel 7y ago

As far as I know, parts of the Julia parser is still written in a Lisp variant called Femtolisp. Also one can run Femtolisp by executing: julia --lisp

markhalonen 7y ago

I'm using Julia instead of Python/Pandas for a machine learning project and I'm happy with how things are going. Multiple dispatch is very cool. The project was previously written in R, but the performance and lack of programming clarity inspired a re-write in Julia. There is something satisfying about writing code in a high-performance language, you just know you won't be kicking yourself because it would run 10x faster in another language.

leanthonyrn 7y ago

I was thinking about this the other day. How can I expose my Common Lisp code to Julia. 1. You could take the Clasp path by exposing CL to C++. https://youtu.be/8X69_42Mj-g https://youtu.be/8X69_42Mj-g This means taking / writing a CL in Julia. 2. Julia has an AST representation written in femtolisp. So it would be in interesting target for CL or some glue middle language like Shen. http://www.shenlanguage.org/ http://www.shenlanguage.org/ https://youtu.be/lMcRBdSdO_U https://youtu.be/lMcRBdSdO_U

vindarel 7y ago

For numeric work in CL, one might like Numcl, a clone of Numpy: https://github.com/numcl/numcl https://github.com/numcl/numcl

cat199 7y ago

Seems like this: You can of course branch on the array element types and maybe even paper over the whole mess with sufficient macrology (which is what LLA ended up doing), but this approach is not very extensible, as eventually you end up hardcoding a few special types for which your functions will be "fast", otherwise they have to fall back to a generic, boxed type. is exactly what numpy/scipy is doing (s/macrology/c-functions/), but they are successful.. granted julia has more ground-up support for these things, but it doesn't seem like an impediment to scientific computing per-se, provided sufficient userbase

dang 7y ago

Discussed at the time: https://news.ycombinator.com/item?id=15478131 https://news.ycombinator.com/item?id=15478131

StefanKarpinski 7y ago

Tamas is a very active participant in the Julia ecosystem, so it seems that the switch went pretty well! Julia 1.0 was released a little over a year ago at JuliaCon 2018. At this year's JuliaCon, there was, imo, an even more positive "vibe" than past years, which were already full of excitement. My guess is that it may be because everyone has been really happy to have a year of not breaking things and building cool new stuff on top of the solid foundation of Julia the Julia 1.x series.

coldtea 7y ago

>The standard does not guarantee that this gives you an array of double-float: it may (if the implementation provides them), otherwise you get an array of element type T. This turned out to be a major difficulty for implementing portable scientific code in Common Lisp. Well, so? Just use a single CL implementation that does give you the guarantee. After all you are now switching to use a single Julia implementation (there's no other anyway). If portability is a concern, at least with CL you can always port 95% of your code to several implementations, and then write special code those kind of incompatibilities. With Julia one platform is all you get. So how's that better, from the point of this complaint?