Comment by socialdemocrat | Hacker News Reader

Comment by socialdemocrat | Hacker News Reader

Parent Full thread

Lots of truths there but also colored by someone who evidently has not been a fan of technologies before and seen how it works.

I am not as pessimistic as a Julia fan. Why? Because I have been where this guy is now ever since I was an Amiga user. I was like that with Python, Ruby, Go and a whole other languages.

And what I learned from that is that it takes time. Neither Python, Ruby or Go had success over night. Yet almost all these languages I homed in on in the past have seen what I would call success later.

I was certain Perl would go downhill when it was at its top. I kept argue with Perl fans that Python was a cleaner language that would see more success. Ditto with Ruby. That turned out to be quite accurate.

I said while D looked like a nice replacement for C++, it simply wasn't big enough improvement to go anywhere. That also seems to have been an accurate prediction.

Go on the other hand had a very obvious appeal from the get go. It did something important different and sufficiently better than before while keeping things simple.

I am confident about Julia, because I have not in 20 years since a language with so much potential and so many advantages. You just got to give it time. This reminds me of myself following solar and wind energy in the early 90s and deciding it was not going anywhere.

Ironically I see people like Michael Shellenberger having become a cynic about wind and solar now that it has actually achieved some measure of success. Why? Because it didn't happen fast enough. He poured all his enthusiasm and hope into this industry long before there was reasons to do so.

People have to be aware of the same about Julia. It is not taking over the world any time soon. There is a long road ahead. And I would not define success as getting to Python scale. But if Julia can get to a similar position as Go is today, then I would call that success.

I rewrote some stochastic simulation R code in Julia recently, and it sure feels like the future.

Julia's already making (fairly substantial) in roads. It's just not as visible as Python, since the niche it's occupying is much smaller and out of the way.

When Julia finally comes of age, there will be a new, emerging language claiming it will eat Julia for lunch.

Absolutely and there is nothing wrong with that. But over the decades I have followed computing I have seen languages with much smaller advantage relative to the competition than Julia rise to prominence.

But I am also pretty sure that whatever replaces Julia in the future, it will have borrowed heavily from Julia in terms of semantics, syntax, libraries etc. Multiple-dispatch that Julia pioneered is almost certainly going to dominate future languages.

This is in similar ways to have functional programming has entered almost every mainstream language and OOP entered almost every language before that.

AFAIK, it was Lisp that pioneered multiple dispatch. It hasn't “dominated” a substantial number of languages since then. Maybe the problems it solves haven't been seen as important enough? I really don't know, it seems such a logical extension of the single dispatch known from many OOP languages.

Arguably it may also be because without JAOT compilation as in Julia, multiple dispatch normally comes with a significant runtime performance cost, as far as I understand.

Languages have addressed that in a variety of ways before Julia.

I'm not aware of any that had the sort of complementary designs between the compilation model and multiple dispatch. E.g. in Common Lisp, two of the most important functions for multiple dispatch, addition and multiplication aren't generic functions and need to be shadowed and replaced by generic functions if you want multiple dispatch. My understanding is that they did this for performance reasons, but julia doesn't have any performance degradation from making literally everything other than like 5 builtins generic functions because of the way it's compilation model dovetails with multiple dispatch.

I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods. If you look at https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_pract... they present some evidence that multiple dispatch sees far more use in julia than other languages.

Dylan was/is generic functions everywhere.

> need to be shadowed and replaced by generic functions if you want multiple dispatch.

yeah, but there are extensions for some Common Lisp implementations which would allow that with reasonable speed. I've seen a bunch of CLOS extensions in recent years in that direction.

> ulia doesn't have any performance degradation

Common Lisp generally has a different generic function model from Julia. It's extremely dynamic with an optional meta-object system. Thus its use case is different. But: for example a CLOS-based CAD system might use generic functions everywhere and needs the respective performance for that.

> I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods.

In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface.

CLOS has before, after, around and primary methods for a default method combination. One can write arbitrary new combinations and have different ways to dispatch, different inheritance strategies, etc. Thus its optimization problems to provide faster dispatch is different from what Julia wants to address.

Dylan then for example had to address the 'generic function everywhere' problem. There binary+ is a generic function.

> In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface.

Totally agreed here. However, addition, multiplication and so on have a very uniform and well defined set of semantics that apply to many types from all the various representations of real and complex numbers to the many many different types of matrices in Julia's LinearAlgebra library (lots of wrappers for things like Symmetric, or Tridiagonal matrices, lazy matrix factorization objects, adjoint matrices, etc.)

That's why there's so many methods on addition and multiplication in julia, and why I found it so surprising that CL doesn't do this on purpose. But I get that scientific computing isn't as big a part of the demographics in the CL community so I guess it makes sense.

AFAIK, it was Lisp that pioneered multiple dispatch

Cf. CommonLoops, https://en.wikipedia.org/wiki/CommonLoops

a bunch of languages (incl. Julia) has been influenced by CLOS' multiple dispatch (Fortress, Perl 6 (aka Raku), R, C#, ...). Many languages have extensions for multiple dispatch incl. C, Factor, Java, Python, Scheme, Ruby, ...)...

Reply on news.ycombinator.com