A Lisper's first impression of Julia
p-cos.blogspot.com
A Lisper's first impression of Julia
1–10 of 41 posts
Re: A Lisper's first impression of Julia
#2This is a refreshingly specific post. Many articles of this kind ham-fistedly define various philosophical criteria throughout the post and make sketchy judgements within these. Here however there is just "here's the main comparative languages, here's the difference, here's where there may be issues".
NB. I'm very much in favour of a principled (qua philosophical) approach to language comparison (etc.) but its rarely done well.
Re: A Lisper's first impression of Julia
#3Comprehensive! Covers the Lisp-y influences of Julia in great depth.
My perspective on Julia is that it has 3 ingredients:
1. A principled design that derives from the experiences of past programming language and particularly the creator's experiences with Lisps. This is where a lot of the "magic" comes from: multiple dispatch, the type system, metaprogramming, etc. The article covers this aspect.
2. A need to be accessible to those transitioning from other languages, like MATLAB and Python. MATLAB, for example, has guided function naming (although Numpy also has similar names for similar reasons). The author mentions the lack of distinction between creating a variable and changing its binding: I'd suggest this is an example of something affected by this design point.
3. A need to be fast. The author brings up the Int vs BigInt distinction. Python, for example, allows Ints to get as big as you want but at a cost. Adding to Ints is not simply an add instruction, you must do a lot more work. Julia, falling on the side of performance, elects to distinguish between arbitrary BigInts and machine Int.
Re: A Lisper's first impression of Julia
#4Comprehensive! Covers the Lisp-y influences of Julia in great depth. My perspective on Julia is that it has 3 ingredients: 1. A principled design that derives from the experiences of past programming language and particularly the creator's experiences with Lisps. This is where a lot of the "magic" comes from: multiple dispatch, the type system, metaprogramming, etc. The article covers this aspect. 2. A need to be acc…
Great points. To add to the second point, much of the surface syntax also is also similar to Matlab/Octave/Scilab, in addition to function names being similar. Of course, this similarity is only superficial and by design.
Re: A Lisper's first impression of Julia
#5Comprehensive! Covers the Lisp-y influences of Julia in great depth. My perspective on Julia is that it has 3 ingredients: 1. A principled design that derives from the experiences of past programming language and particularly the creator's experiences with Lisps. This is where a lot of the "magic" comes from: multiple dispatch, the type system, metaprogramming, etc. The article covers this aspect. 2. A need to be acc…
Regarding the Int / BigInt distinction, other issues besides performance, which haven't historically been prominent considerations in new language designs, are interoperability and transparency. In the current design, a Vector{Int} always has the same in-memory representation as it would in C or Fortran – you can take a pointer to the first array element and pass it to a library function using the C ABI and it will just work. You also know exactly how your data is represented and can reason about it. You know, for example, that a Vector{Int} definitely does not require any additional heap allocation besides the inline Int values and that arithmetic operations on Ints will just be machine arithmetic ops. I think that the transparency of the C data and performance models has been one of the major reasons for C's long-lived success. One of the design goals of Julia is to have similarly transparent data and performance models.
Re: A Lisper's first impression of Julia
#6Comprehensive! Covers the Lisp-y influences of Julia in great depth. My perspective on Julia is that it has 3 ingredients: 1. A principled design that derives from the experiences of past programming language and particularly the creator's experiences with Lisps. This is where a lot of the "magic" comes from: multiple dispatch, the type system, metaprogramming, etc. The article covers this aspect. 2. A need to be acc…
Great points. To add to the second point, much of the surface syntax also is also similar to Matlab/Octave/Scilab, in addition to function names being similar. Of course, this similarity is only superficial and by design.
That (and not having daft slow loops is) what got me into Julia from octave. I tried it a while back and the biggest issue was the in equivalency of array{n} and array{n,1} now that that's been fixed, it's awesome.
Parallelization in Julia is still a little scary though, I'm waiting a bit before delving into that.
Re: A Lisper's first impression of Julia
#7I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison.
Re: A Lisper's first impression of Julia
#8It seems weird to try to characterize Julia in terms of object-oriented programming. Is that just me? Julia's approach to subtyping and multiple dispatch is sufficiently different from the C++ and Python approaches to OOP that I don't even put them in the same bucket, and it seems about as far away from CL's objects as well. Julia doesn't really advertise itself as OO; you can't even find the word "object" on the front page of their site. So I wouldn't try to think of it that way.
A lot of the comparisons in this article seem like that to me. Julia and Common Lisp are apparently just close enough to make a point-by-point comparison like this plausible, but things are not quite aligned close enough to make it work. It's still a good article with a lot of solid meat in it, but I think the topic would have been better served by going up the abstraction ladder a bit and talking about how the different paradigms of each language motivated the differences between them.
Disclaimer: I'm only somewhat familiar with Julia and not at all with Common Lisp.
Re: A Lisper's first impression of Julia
#9I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison.
> I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison.
I suspect the authors main problem with Clojure is, that it is a mostly functional language which heavily emphasizes doing things in the functional way and discouraging imperative programming whereas CL is more like a true multiparadigm language.
I used to think that multiparadigm is best, but after migrating from Scheme which is mostly functional but has a lot of mutation and a sad lack of interesting datastructures apart from Lisp to Clojure which has good support for dicts and persistent data structures I think I prefer a community that is more focused on one approach.
Re: A Lisper's first impression of Julia
#10I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison.
> I would very much like to read a comparison of CL and Clojure from the author at some point. As it seems he is offering a fair comparison. I suspect the authors main problem with Clojure is, that it is a mostly functional language which heavily emphasizes doing things in the functional way and discouraging imperative programming whereas CL is more like a true multiparadigm language. I used to think that multiparadi…
I feel the need to chime in: working in a language where the assumption is that everyone has agreed on a functional approach makes it much easier to stick to that approach myself. And, of course, reading other people's source code makes that much more sense.