http://www.math.udel.edu/~driscoll/SC/ or on github https://github.com/tobydriscoll/sc-toolbox
But I can’t say I agree with much of this.
> One function per disk file in a flat namespace was refreshingly simple for a small project, but a headache for a large one.
This is an absolutely horrible bonkers limitation for a “small project”. It’s “refreshing” like someone constantly dumping buckets of ice water over your head. Being able to define functions in the repl, export multiple functions from a single file, etc. are things I pretty much can’t live without in an interactive programming language. Needing to make every tiny utility function into its own file adds SO MUCH FRICTION to basic prototyping workflows.
The result is that when working with Matlab I try to make as many functions as possible into lambdas, e.g. square = @(x) x∗x. But these are very limited in practice, and the workarounds to make a function work as a lambda often compromise readability, performance, correctness, and functionality.
+ + +
Is an occasional V.conj().T @ D∗∗3 @ V really that much worse than V' ∗ D^3 ∗ V?
I find that in even small programs, syntax complexity and clarity is dominated by logic flow rather than matrix multiplication. My Python programs end up dramatically easier to read than my Matlab programs, including the almost-pure-numerics parts of them.
If concise built-in syntax for numerical operations were our highest ideal, we’d all be using APL.
> exists a matrix class, and yet its use is discouraged and will be deprecated
I think Driscoll doesn’t understand what’s going on here. There is plenty of discussion for someone who searches about the problems with the matrix class. The matrix class dated from a time when there was no @ operator, so ∗ was used for matrix multiplication instead of elementwise multiplication. This made it inconsistent with everything else and artificially limiting in obnoxious ways. Now that Python has an @ operator it is no longer useful or necessary. This has nothing to do with matrices being important or not.
> Matplotlib package is an amazing piece of work, and for a while it looked better than MATLAB, but I find it quite lacking in 3D still
YMMV, and maybe I’m spoiled by D3, Vega, Altair, ggplot2, etc., but I really don’t like Matlab’s plotting tools or Matplotlib. They are inflexible and full of arcane details, and produce mediocre output. We should aspire to better plotting than those in all of our environments.
+ + +
> The big feature of multiple dispatch makes some things a lot easier and clearer than object orientation does.
This is partly because Matlab’s version of “object orientation” is a horrendously broken pile of trash.
> Partly that’s my relative inexperience and the kinds of tasks I do, but it’s also partly because MathWorks has done an incredible job automatically optimizing code.
I’ve poked around in several large Matlab projects, and there are huge performance problems everywhere. In particular any project using Matlab’s version of object orientation ends up incurring huge amounts of overhead.
+ + +
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.
For folks with decades of experience reading and writing math papers, this is fair enough I guess.
For many people from a software background it seems like a poor choice of priorities.
Programs written by researchers are often unintelligible without the accompanying paper (and sometimes with, depending on the paper). Full of 1-letter variable names defined off-screen somewhere with no comment explaining what it stands for, weird API inconsistencies, lack of structure, hacks that worked on one set of inputs for a demo but don’t handle edge cases, ....