My position is that despite all of Julia's problems (many of the worst being internal) I think it's the best choice of the three. And at least as far as the move from MatLab to Julia that's just a win for all of science.
> This is partly because Matlab’s version of “object orientation” is a horrendously broken pile of trash.
Sure, but also multi-methods are objectively better than single dispatch object systems. And per Graham's web of power this is easily demonstrated by the fact that what a multimethod can do in one line, a single dispatch system requires n^m (n being objects in the hierarchy, m being the number of objects in the call) lines of pattern code (sans any meta programming features of course) to match in expressiveness.
The fact that Julia can use multi-methods with type inference to improve the compilation of typeless methods to the level of native compiled program speeds is just gravy.
> I’ve poked around in several large Matlab projects, and there are huge performance problems everywhere.
A problem python can share, with the worst offenses requiring rewriting the given chunk of code in a different language and then writing bindings for it, and managing the compilation of it.
And that Julia works very hard to avoid, through it's gradual type system (often allowing a programmer to add a type to a single line of code and have the entire project get 10x performance gains) and multimethods (allowing programmers to optimize specific edge cases without intruding on the formula code).
> Overall my impression is that Julia (and Matlab’s) language choices are driven by people who want to directly type their math paper into a program with as little thought and as few changes as possible.
Yes, but at least Julia does so in a way that allows for professional programmers to easily work with and maintain it. Between multi-methods, optional typing, choose-your-own-starting-array-index, a programmer can modify an existing Julia code base without the language itself being the problem.
Julia could certainly do better here - they are often hostile to attempts to improve the software engineering story around Julia - they at least have a path forward for a programmer attempting to maintain or optimize their scientific computing code in a sane way. Something that neither python nor Matlab can really claim.
I think the most egregious problem from a holistic perspective is their lack of prioritization for software engineering. Things like packing large amounts of specialized mathematics constructs (and whole libraries like git and markdown) into the main distribution (causing memory size and startup time problems), lack of interfaces or similar abstraction tools (which are strictly speaking not necessary from a functionality perspective, but are useful as organizational and code safety tools), and an inability to tune their garbage collector. Their debugger was also pretty shoddy when I last used it (e.g. it wasn't a priority for many years), but I'm pretty sure they have fixed it significantly by now. And hey they have macros, which just invokes the problems with lisps, but at least you can do whatever you want programming construct wise if you really want to.
"Internally" they have some poor interactions with external developers (meaning people not from MIT). [deleted a rant] In the end I suspect Linus is probably worse to work with, it probably comes with the territory, so it's not like it's a deal breaker.
All of this is to say I agree with this article: http://worrydream.com/ClimateChange/ one of the best things a programmer can do is contribute to tools, specifically including Julia, which advance our ability to understand climate change. It really is in my opinion the best programming language to further scientific advancement. I just wish I had the capability to work with them.
> This is partly because Matlab’s version of “object orientation” is a horrendously broken pile of trash.
Sure, but also multi-methods are objectively better than single dispatch object systems. And per Graham's web of power this is easily demonstrated by the fact that what a multimethod can do in one line, a single dispatch system requires n^m (n being objects in the hierarchy, m being the number of objects in the call) lines of pattern code (sans any meta programming features of course) to match in expressiveness.
The fact that Julia can use multi-methods with type inference to improve the compilation of typeless methods to the level of native compiled program speeds is just gravy.
> I’ve poked around in several large Matlab projects, and there are huge performance problems everywhere.
A problem python can share, with the worst offenses requiring rewriting the given chunk of code in a different language and then writing bindings for it, and managing the compilation of it.
And that Julia works very hard to avoid, through it's gradual type system (often allowing a programmer to add a type to a single line of code and have the entire project get 10x performance gains) and multimethods (allowing programmers to optimize specific edge cases without intruding on the formula code).
> Overall my impression is that Julia (and Matlab’s) language choices are driven by people who want to directly type their math paper into a program with as little thought and as few changes as possible.
Yes, but at least Julia does so in a way that allows for professional programmers to easily work with and maintain it. Between multi-methods, optional typing, choose-your-own-starting-array-index, a programmer can modify an existing Julia code base without the language itself being the problem.
Julia could certainly do better here - they are often hostile to attempts to improve the software engineering story around Julia - they at least have a path forward for a programmer attempting to maintain or optimize their scientific computing code in a sane way. Something that neither python nor Matlab can really claim.