I'm not sure how I feel about multi-dispatch...I've had a few headaches chasing down problems with multimethods in Clojure...I'd have to try using Julia full-time to see how it feels.

I was unaware that Julia was homoiconic...I'm somewhat of a Lisp fanboy so I might need to give the language another chance.

There's pretty big differences in usage between multimethods in Clojure and Julia. I've used both a decent amount. All functions in Julia are multimethods by default. If you don't use type annotations, a new method will be generated whenever you call the function with new argument types. This explicit type specialization is a very important part of why Julia can have such a consistently fast JIT despite its dynamicity.

Errors from missing or conflicting methods tend to not happen much in practice.

https://docs.julialang.org/en/v0.7.0/manual/methods/

> If you don't use type annotations, a new method will be generated whenever you call the function with new argument types.

Damn. That's a pretty clever trade off between dynamic and static types.

I vaguely recall a talk by Stefan Karpinsky where he mentions meeting one of the big names in compiler land (working on V8 or something) and they said Julia's JIT is just a lazily evaluated AOT compiler, and as a result much simpler than the JITs typically seen in other languages.

Forgive a bit of ignorance here, but that doesn't sound terribly different than overloading functions in C++. Am I way off on that?

The difference is run-time (semantically) vs compile time. If you had overloading at runtime in C++, you wouldn't need virtual functions or any of the thousands of OO "patterns" (visitor, factory, etc.), that are working around the lack of this capability.

> Julia is homoiconic

It depends on what you understand by homoiconic:

https://stackoverflow.com/questions/31733766/in-what-sense-a...

This is why the language creators usually avoid using the word 'homoiconic' because every time one uses that word there's a finite probability of being bogged down in an incredibly uninteresting semantic argument.

Instead, people prefer to say that julia code is just another (tree-like) data-structure in the language and it can be manipulated at runtime with functions or compile time with macros or at parse time with string macros and now with Cassette.jl[1] we can even manipulate the form of code that has already been written and shipped by other packages all with first class metaprogamming tools. It seems to me that even if Julia is not 'truly homoiconic', that we seem to get the touted benefits of homoiconicity to the point that it seems like an unimportant distinction.

[1] https://github.com/jrevels/Cassette.jl

Then why not just say 'Julia has macros'? Lightly perusing the description of Julia's features, that seems like a clear way of expressing what it is.

(I also vaguely recall Julia describing its type system as "dependent" in way that goes against convention. Maybe they just liked controversy in the early days!)

What I just said is why Julia people don’t tend to call it homoiconic or dependantly typed. It lead to so many semantic arguments that most just talk about actual features such as macros and various multiple dispatch features instead of using words like homoiconicity and dependant typing.

"macros" are unfortunately used by C and lisp to describe two different things, and both usages are as widely popular as their parent languages (i.e. very).

That's a good point that it doesn't have the direct homoiconicity of Lisp, but it is not buried deep, since we have full access to the underlying AST as just an Expression type. In practice, this makes macros much less painful than in other non-lisp languages. This means that macros are used all the time, and idiomatically. The most proiminent non-lispy language with a macro system that I can think of is Scala. Macros there are a nightmare, and so tend to be only used in library code that really, really needs them.

I agree that macros are better than in other non-lisp languages, but I find them ugly in Julia. Maybe not painful, but they don’t integrate seamlessly into the language.

They are ugly, I agree. Personally, I prefer lisp (especially Clojure) syntax, but not many people agree with me there.

What's actually sad (I learned this quite recently) is that the inventor of Lisp wanted to include a mechanism to evaluate formulas along the lines of FORTRAN. Something like:

(math "x = sin(a) * b ^ 2")

Lack of something like that turned me away from Lisp (LISP at the time) a (cough) long time ago, since I didn't like the impedance mismatch between Lisp code and math for numerics.

At any rate, Julia looks like a fine general purpose language, I'm going to see if I can contribute somehow. I'm hopeful that GC pauses can be avoided for large classes of Julia programs, but we'll see...

Throughout Lisp history, this has been done.

(Let's not count things like computer algebra systems written in Lisp that have some sort of actual math notation for input and output, just alternative syntax for programming in Lisp itself.)

As early as 1973, there was https://en.wikipedia.org/wiki/CGOL

That can actually be made to work today: http://abcl-dev.blogspot.com/2010/04/cgol-on-abcl.html

Please don't vilify Python or R thinking that will help with Julia's adoption or popularity. If Julia is as awesome as its evangelists say, it will gracefully displace its competitors without the need of a smear campaign

Criticisms of languages should not be taken as criticisms of their creators or users. I don't see anything wrong with saying "Language X does Y better than language Z in my use cases."

Languages are toolsets and programmers are always looking for appropriate tools for a given task. It seems crazy to demand that people not be able to talk honestly about their experiences using a given tool. Python doesn't have feelings, it won't be sad if you don't like it.

Even if it does, what's wrong with stating an opinion? Why does an honest opinion have to be branded "smear"?

You seem to be suggesting it’s not fair to make superior comparisons to python until Julia has mainstream popularity. That’s rubbish. Python is much less expressive.

Python does have excellent libraries and it fits many people's mental model of programming, but not mine. I still use it often. However, for a dynamic language, it is simply not very expressive. It has no multi-line lambdas, OO syntax that I find a bit awkward, and some other limitations. These can be seen as advantages, since they enforce the "there's only one way to do it" philosophy, but that doesn't work for me.

Hmm ... I remember when Perl was king and Python was the shiny new thing. I watched Python supporters belittle Perl as "line noise" and other quite silly descriptions. They were all proud of "there is only one way do to it" versus the linguistic Perl way of "there is more than one way to do it."

I am experiencing something of a sense of schadenfreude over defense of Python against a newcomer. 20 years on, Perl is still in widespread use, still unbeatable for its growing use cases. I don't wish to speculate where Python will be 20 years from now. I do know that Fortran will still be around. That's about the only sure thing.

Wish advocates of all new languages stuck with this principle.

I wasn't being disrespectful of Python. We are allowed to criticize languages. The fact is, by any reasonable measure, Julia is more expressive than Python, which was all I stated. This is an advantage of Julia. Both languages have advantages and disadvantages, and comparing them honestly is necessary for people to make a good choice when selecting a language for a project. C is less expressive than Python or Julia, but no one would say C is a bad language based on that. And no C programmer would disagree with that statement.

It's not about putting any language or community down.

By your argument, it sounds like we cannot talk about any advantages a new language may have over existing ones. If we stuck to that, how could we possibly make any argument over why one may want to select a newer language?

Can you give concrete examples of where Julia is more expressive than Python? I can think of defining custom units https://medium.com/@Jernfrost/defining-custom-units-in-julia...

I give examples of expressivity in my comment above. The multiple dispatch is completely ubiquitous in Julia, being the default. This allows for the definition of flexible and extensible interfaces similar to Haskell's typeclasses. Macros are used to make things like PyCall or generate fast and flexible CUDA code.

This is not easily possible in Python, especially not with high performance.