[nuntius]

Matlab has always been a quirky language. It has good libraries for common math operations, good visualization tools, good documentation, and toolboxes available for many special tasks. There are a number of common pitfalls, with well-known workarounds, that cannot be fixed without breaking backwards compatibility. The performance of a "for loop" is usually dog slow (some special cases were optimized recently). You often spend hours figuring out how to vectorize your code so it runs decently fast. OOP and other techniques have been bolted on in a workable but unusual way, and they are not widely used. Licensing costs add up.

People looking for a free Matlab replacement often gravitate to a full replacement, rather than a clone. In the past, this meant learning something like C++, a significant hurdle to migration.

Python is generally seen as a much better general-purpose language than Matlab. It is building a much larger developer community. It is no harder to learn than Matlab, and it supports similar interactive development. Tools like numpy start adding easy support for Matlab's core strengths. Python is free, even in commercial deployments.

Matlab's primary competitor used to be Excel. Python is emerging as a very real threat. Outside of the core Matlab user base, preference for Python (or Go or ...) is building fast.

[SandB0x]

> The performance of a "for loop" is usually dog slow (some special cases were optimized recently). You often spend hours figuring out how to vectorize your code so it runs decently fast.

A similar story for Python and NumPy on this point, mitigated by NumPy's elegant broadcasting rules. Agree with everything else!

[BeetleB]

>A similar story for Python and NumPy on this point

Not as similar. When I was in grad school and encountered NumPy, I ported over my Matlab code to NumPy. It was hard to vectorize and so I had an explicit for loop (in both code bases).

NumPy ran 7x faster.

Did not really drill down to whether it was the loop itself or the operation in it, but I suspect it was the loop itself.

Matlab really has a slow for loop.

[sedachv]

Matlab/Octave is an array programming language. You are supposed to use array and matrix operations. If you are using a for loop you are writing Matlab code wrong.

[BeetleB]

I think you're missing the point of the thread.

Obviously, you should vectorize your code and avoid explicit loops. In both Octave and NumPy

However, what the thread is pointing out is that if you do have explicit for loops, Octave is much slower than NumPy.

For the code I was writing, I had trouble vectorizing a particular piece of code. I'm sure if I spent many extra hours, I'd figure out some way. But why should I when it's 7x faster in NumPy without vectorizing?

And whatever way I would discover for vectorizing it in Octave would likely work for NumPy as well. It'll be a rare exception that NumPy is slower than Octave.

For me, the only reason to use Octave is if someone hands me Matlab legacy code. For my scientific computation, NumPy/SciPy has always been superior.

Ironically, Octave usage is inherently tied to Matlab's existence. Were Matlab to disappear, Octave would have little use when it comes to developing new code. I cannot think of a good reason for someone new to the field to develop in Octave, other than the need to interface with others who use Matlab.

I know this comment sounds critical, but I'm not anti-Octave. When I first started using it, I was very impressed, and I learned far more about Matlab by using Octave and reading Octave's docs than any docs from Mathworks. As a Matlab clone, it is superb.

It's just that now the alternatives to Octave are superior. Personally, I would like to see development continue for Octave, just because I appreciate it so much as an open source project. But the reality is when I give new young scientists advice, it is almost always "Use NumPy/SciPy".