hatmatrix

A lot of the early, absolute advantages of Fortran (numerical precision, non-aliasing) has been adopted by C.

However what still makes it a great choice is that it still a relatively simple language compared to C, and maps mathematical formulas to code very well. Inelegant code will still run reasonably fast (which is not the true with C) - so all of these points make it actually a good language when the program is being written by domain experts (i.e., scientists) rather than professional programmers or software engineers.

But doesn't this reduce the required amount of farmland?

Don't most researchers fall into this category?

Julia's Tidier.jl ecosystem is getting there too. It uses macros to mimic this 'special' evaluation framework of R, so the code is also readable in a similar way.

There was XLISP-STAT before R, but the scientists have spoken. They don't like the parentheses.

cries in org-mode

That study must have compared beginners in LaTeX and MS Word. There is a learning curve, but LaTeX will often save more time in the end.

It is an old language though. LaTeX is the macro system on top of TeX, but now you can write markdown or org-mode (or orgdown) and generate LaTeX -> PDF via pandoc/org-mode. Maybe this is the level of abstraction we should be targeting. Though currently, you still need to drop into LaTeX for very specific fine-tuning.

Yeah I started using GitLab for the same reason and also that FSF "approved" of its CE version. But doesn't hosting private repos on GitLab and using public repos on GitHub just give GitHub that much more monetizable value?

But then you lose the readability that is the core defense of MATLAB/Octave. Ok so NumPy is readable, but less pleasantly so.

It's one of those languages that outgrew its original purpose, as did Python IMHO. So non-matrix operations like string processing and manipulation of data structures like tables (surprisingly, graphs are not bad) become unwieldy in MATLAB - much like Python's syntax becomes unwieldy in array calculations, as illustrated in the original post.

An understated advantage of Julia over MATLAB is the use of brackets over parentheses for array slicing, which improves readability even further.

The most cogent argument for the use of parentheses for array slicing (which derives from Fortran, another language that I love) is that it can be thought of as a lookup table, but in practice it's useful to immediately identify if you are calling a function or slicing an array.

Indeed, there are many high-quality alternatives (sometimes described as "MATLAB clones" back in the day) that never gained bigger traction.

Among modern alternatives that don't strictly follow MATLAB syntax, Julia has the biggest mindshare now?

GNU Octave, as a superset of the MATLAB language, was (is) most capable of running existing MATLAB code. While Octave implemented some solvers better than MATLAB, the former just could not replicate a large enough portion of the latter's functionality that many scientists/engineers were unable to fully commit to it. I wonder whether runmat.org would run up against this same problem.

The other killer app of MATLAB is Simulink, which to my knowledge is not replicated in any other open source ecosystem.

What's the business model?

fft.m is the more obvious example of the closed source algorithm here. You open it and it just says

% Built-in function.

The algorithms written in C and compiled by mex are the "built-in" ones that are not viewable.