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.
A similar story for Python and NumPy on this point, mitigated by NumPy's elegant broadcasting rules. Agree with everything else!
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.
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".
Anyway, my thought on why numpy seems more widespread is simple: efficiency.
Even Matlab code gets rewritten if it needs to be used for something intense, and Matlab has many more optimizations than Octave to get away with sloppy coding. Python+numpy is pretty easy even for a non-programmer to write (at least compared to C++ or whatever a DSP wants you to use) and even sloppily done is generally fast, plus it has a great and large community. But both Matlab and Octave are great (at least if you use octave-forge) for prototyping and doing a lot of domain specific things python/numpy/scipy don't support out of the box. Matlab especially has a lot of neat GUI helper tools. Meanwhile R is over in its own world where if you're doing anything in that domain it's a questionable choice not to take advantage.
Octave also never had the span of toolboxes that MATLAB had. With MATLAB, you could always find fairly usable toolboxes that covered most engineering computation needs.
Octave was on par with MATLAB on some fronts, but it rarely exceeded MATLAB capabilities. And it was worse than MATLAB on tooling maturity. People hate The Mathworks for charging an arm and leg for its software, and for breaking backward compatibility, but most people will admit the MATLAB environment is pretty polished and seamless compared to open-source offerings in the same space.
So far no one has mentioned Scilab (http://www.scilab.org/). Scilab is a much a better MATLAB alternative than Octave, though Scilab code is less compatible with MATLAB that Octave code.
And for some reason, it was virtually unknown - Octave is superfamous compated to FreeMat.
I remember when I was in university students were acutely aware that tools like PhotoShop, Microsoft* and MATLAB were used in businesses. I doubt this has changed.
Even if superior Free options had been available, many of them would still have opted for the "safe" proprietary options because they wanted to be sure they could get work and felt (rightly or wrongly) that it was important they could put the right product names on their resumés.
Most people are goal-oriented when it comes to using software, not ideological, and they'll go with what gets the job done with the least amount of effort.
The GIMP-over-Photoshop argument should be because it does something Photoshop doesn't (very possible with its ecosystem of plugins/filters -- for example a "smart remove" plugin was around for quite some time before Adobe made their own and spent who knows how much in marketing/demos for it) or because the artist wants to save money.
Agree that people are goal oriented. OSS that's free-as-in-beer can help drive adoption on account of being free, but ultimately the best OSS succeeds because it's better than its competition in important ways. Pure clones are risky, I'm glad Gimp doesn't try too much to be a clone.
Sadly most artists who want to save money just pirate, which is what led to the terrible Creative Cloud situation. But that led to Affinity which seems to be a solid, buy-once (for cheap!) replacement. I agree the monolithic nature of Adobe is bad for everybody but that's not a reason to choose a subpar tool. Also people can write and sell their own plugins for Adobe products as well.
Anyway I think we're mostly on the same page.
That said, the world has become more accommodating in other ways. Python and R are now more well-accepted signals for data skillset than say, SAS. (exceptions: finance, pharma)
or R.