Comprehensive! Covers the Lisp-y influences of Julia in great depth.<p>My perspective on Julia is that it has 3 ingredients:<p>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.<p>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.<p>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.
This 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".<p>NB. I'm very much in favour of a principled (qua philosophical) approach to language comparison (etc.) but its rarely done well.
As an aside (and please do not take it as a flame), this is a very neat article that shows a class of languages in a paradigm I have never considered: Lispy languages (semantically) without Lisp morpho-syntax. I had heard of Julia of course, and see a few mentions here and there of Dylan. It is interesting Dylan had such little interest, or even similar projects, because everyone complains about Lisp syntax (as I see here, I am an amateur Lisper and I understand its history and appreciate it), but bemoans not having other languages with the power of homo-iconicity and other core parts from which the macro system and others gem are based upon (I forget the guy with that quote: keeping adding features to a lang, and you get a much shittier Lisp).<p>Why did these languages not take off (at least pre-Julia)? I have heard other people "debate" (and I use it hear to say disagreement on principle not on details of said debate that Ruby and other langs are Lisp-like, but fall short. Dylan seems to have been Lisp (proper) without Lisp syntax on purpose (after intentionally moving from the design phase). So why do languages with such powerful expressiveness (for your value of the word, I do not want to start that discussion either) never take off, Dylan or otherwise? It seems that is what all programmers, at least the ones more advanced than me, clamor for.
It 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.<p>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.<p>Disclaimer: I'm only somewhat familiar with Julia and not at all with Common Lisp.
> I would like to see something like Oberon’s support for renaming identifiers on import in some Lisp dialect someday<p>I couldn't find any specifics on how it's done in the linked PDF (modules are described at the end, 11 section), but I think both Clojure and Racket do this already. The `require` mini langauge in Racket is very rich and allows for prefixing, renaming, selective import of identifiers and so on: <a href="http://docs.racket-lang.org/reference/require.html#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._require%29%29" rel="nofollow">http://docs.racket-lang.org/reference/require.html#%28form._...</a>