> What Matlab eventually did was look at what people were writing and making that fast.
Except in practice, to write fast Matlab code you need very deep understanding of Matlab’s internals and years of experience. Seemingly trivial patterns end up slowing your code down by multiple orders of magnitude, and there’s more “guess and check” involved when trying to write code that can be effectively JIT compiled by Matlab than careful reasoning. Even worse, the JIT and the profiler don’t get along, so it’s often impossible to get any insight into the reasons for JIT-related performance differences.
In general, Matlab is an extremely unpleasant and frustrating environment compared to almost any other language I’ve worked with. The only thing Matlab has on Python/Numpy is a nice quantity of publicly available code for various technical functions. Most of this code is hacky academic prototype stuff, but that’s much better than nothing if you’re trying to follow someone’s algorithm written up in a paper.
The Matlab GUI and tooling is a buggy and unpolished Java turd from the 90s which fits in poorly with any modern operating system.
The Matlab GUI and tooling is a buggy and unpolished Java turd from the 90s which fits in poorly with any modern operating system.
And yet every time I try to get Matlab users to use something else (Python or Julia) the one thing they almost immediately complain about is the lack of a GUI IDE as good as the Matlab one.
> And yet every time I try to get Matlab users to use something else (Python or Julia) the one thing they almost immediately complain about is the lack of a GUI IDE as good as the Matlab one.
Pycharm[0] has become my prefered Python IDE about 2 years ago (when they went free commmunity/pay for pro) and it's a way better environment than MATLAB. It now has "Scientific tools" too[1], and I understand some good features, though I haven't used them yet.
The only good thing I still recognize of MATLAB is that most toolboxes work together without (too much?) hacking. Working with Python/NumPy you eventually find stuff that you need to adjust to work with that other library you just found implements that thing you absolutely need.
> And yet every time I try to get Matlab users to use something else (Python or Julia) the one thing they almost immediately complain about is the lack of a GUI IDE as good as the Matlab one.
Spyder offers a similar environment. It has a variable explorer, script editor, console, etc all in one window (which I think is what matlab users are looking for).
It's not just that - it is also the extremely extensive and comprehensive documentation of every function (integrated in the GUI), and the powerful profiler (integrated in the GUI), and the charting (integrated in the GUI)...
Well, they're probably not Linux (Ubuntu only problems perhaps?) users then. Matlab crashes again and again, locking up my entire computer, so I have to hard reset it. It happens so frequently that I simply had to install Windows on my computer, and boot up in that when I need to work on a project where my collaborators voted for Matlab.
It must be then. I had a student doing a term paper with the exact same problem. Often plotting related, but not necessarily. Havn't been able to find a solution myself, or online.
And that's the pitch for julia. Oh, and mostly fast enough to write in julia the stuff that, for python, you'd write as C extensions, crucially enabling lots of optimizations that are terribly hard to do for python. And avoiding the whole pypy / C api plugin problem.
It's still pretty immature, but promising.
That said, matlab's linear algebra syntax is still better than python's.
Your first quip also applies to Mathematica. It's very easy to write quite inefficient code in Mathematica. One classic example of this is a newcomer not using N[] and evaluating every expression symbolically. Seems trivial, but it really isn't for someone new. I still could get speedups on linalg code two years into grad school.
In practice you can't rely on the compiler, because you don't know what the compiler is doing.
You certainly can't assume it's going to make the smartest possible decision for all of your code. There's no standardisation for optimisations, and they're often a context-dependent trade-off anyway.
The only way to write fast code is to learn the quirks of the tool chain and profile production binaries to find the bottlenecks.
Mathematica also has the double disadvantage that it's syntax and semantics are pretty different from what most people are used to. I find it quite pleasant as it's quite consistent, but it's not the most straightforward thing to learn coming from e.g. [naive] MATLAB. When I show people how to use it, the first thing I warn them is "no For[] loops and only use Table[] sparingly."
Except in practice, to write fast Matlab code you need very deep understanding of Matlab’s internals and years of experience. Seemingly trivial patterns end up slowing your code down by multiple orders of magnitude, and there’s more “guess and check” involved when trying to write code that can be effectively JIT compiled by Matlab than careful reasoning. Even worse, the JIT and the profiler don’t get along, so it’s often impossible to get any insight into the reasons for JIT-related performance differences.
In general, Matlab is an extremely unpleasant and frustrating environment compared to almost any other language I’ve worked with. The only thing Matlab has on Python/Numpy is a nice quantity of publicly available code for various technical functions. Most of this code is hacky academic prototype stuff, but that’s much better than nothing if you’re trying to follow someone’s algorithm written up in a paper.
The Matlab GUI and tooling is a buggy and unpolished Java turd from the 90s which fits in poorly with any modern operating system.