
Switching from Common Lisp to Julia (2017) - mindB
https://tamaspapp.eu/post/common-lisp-to-julia/
======
ddragon
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
Julia ships with femtolisp. I've never used it. To start it, run julia --lisp

~~~
jhbadger
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.

------
StefanKarpinski
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.

------
markhalonen
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.

------
adamnemecek
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
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?

~~~
adamnemecek
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.

------
pcr910303
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.

~~~
stassats
I don't want to ruin the language just so that it appeals to some people, it's
already fine for me.

~~~
oblio
> I don't want to ruin the language just so that it appeals to some people,
> it's already fine for me.

To an outsider his comments seem pretty reasonable. Why would they ruin Common
Lisp?

~~~
varjag
* There are larger incompatibilities between implementations in other popular languages, like C, C++ and Java.

* It's easy to suggest designing an OO system better than CLOS. It's harder to point out any examples tho.

* Remove unused functions, what?

* "Make FOO standard" but a bunch of popular languages don't even have a spec, why is this an issue even?

~~~
zeveb
That other languages are worse than Lisp is no reason not to improve.

I didn't read him as suggesting that CLOS be replaced, but that it be
embraced.

I have no idea what he meant about unused functions. My experience has been
that when I think something in Common Lisp is pointless … I'm wrong.

One of the great advantages of Lisp in the 90s was that it standardised things
that other languages left undefined (indeed, this is still an advantage Common
Lisp has over Scheme). It seems like a good idea to keep on expanding the
standardised area, as we gain experience & understanding.

~~~
varjag
All good points but well.. this discussion appears to be about possible
reasons people migrate to other languages. And I just can't see how addressing
these (rather arbitrary) points would reverse it.

Some people just don't like CL much, despite solid foundation and steady
progress with community projects. That's okay, we all have one or another
language we are not very fond of.

------
cat199
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

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

------
leanthonyrn

      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)

------
coldtea
> _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?

------
vindarel
For numeric work in CL, one might like Numcl, a clone of Numpy:
[https://github.com/numcl/numcl](https://github.com/numcl/numcl)

------
nudpiedo
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.

~~~
ddragon
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)

~~~
nudpiedo
Somehow you moved the discussion to AI comparisons and macros back again,
instead of the point of solving/simplifying math problems by using abstract
symbols and grammars.

Although Julia can be represented in a homoiconic representation, no one sane
can believe that Julia is homoiconic. Unless such person is so optimistic that
could believe things such as Europe-Asia-Africa is a big giant island.

------
sischoel
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

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=15478131](https://news.ycombinator.com/item?id=15478131)

------
higherkinded
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
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
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
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
> 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.

------
fmakunbound
I think Edi uses Julia too, now

~~~
lispm
2018 he published a mathematics book with examples in Python.

