Open science depends on open tools! Octave is such a good resource for otherwise walled off code (that doesn't use newer matlab features). But I'm curious where octave is popular. Does anyone pick it over julia or python when starting a new project/research?
I also wish the state of science/engineering software shook out differently. There's plenty of money to pay Mathworks. Is there some kind of license like pay us if you're doing commercial work or publishing research on grants worth over $XXX, otherwise consider it open source?
Another take: There's value in using a compiled language here. I'm an amateur dabbling in computational chemistry, and my weapon of choice is Rust. (After starting using Python). Why:
- Fast, in an area where speed is important
- Can be made faster for repetitive tasks by communicating with a GPU using Vulkan, CUDA etc
- Can incorporate a GUI, and 3D graphics, which helps for exploring things visually, tweaking parameters, doing time simulations etc.
- Can share. Ie, I showed my brother yesterday by sharing a 10Mb executable. Matlab has license complications and you need it installed. Sharing Python programs is a disaster. (Docker? Pip? Pyenv? Poetry? Virtualenv? System Python? System dependencies for the C and Fortran dependencies?)
Interesting. You might be the first computational chemist I know who actually uses Rust. I know a lot of computational chemists!
Python is the big one, all of the aforementioned chemists are either intermediate or advanced in that. The runner-up seems to be Julia, which I personally have no experience with. The big guys are Fortran and C++. I prefer C for tasks of this nature, but I also shill Scheme so don't listen to my opinions on programming languages.
Best of luck on your computational chemistry endeavours!
i think there are only a couple exceptions to the Fortran/C++ rule. DFTK.jl is the only one I know written in Julia, and there’s GPAW and pySCF in python
I don't know, but whenever I plead with people in computational science to read Structure and Interpretation of Classical Mechanics I'm usually met with an eye-roll.
Don't listen to my opinions, sure. But pay heed to the large number of computational chemists who do use these languages. There is a reason that professionals employ the tools that they do.
One reason we have lots of people in numerate disciplines using Python is that we taught them Python. Python is very teachable. Given a class of average 19 year old students from a numerate discipline, my colleagues will teach most of them Python to a reasonable standard in a single module (so e.g 2 hours of teaching per week over 16 weeks).
The same would not be true if we were supposed to teach them C++ for example. It's a huge, sprawling language, full of difficult concepts that are unfriendly to teach, and equally filled with foot guns that if you don't teach them will definitely maim your students, but if you do teach them take up yet more precious time on minutiae.
Safe Rust wouldn't be as hard to teach as C++ but it's no picnic. So even if the Chemists decided that ideally they'd like their undergraduates to learn Rust instead of Python, I think the argument would be that it can't be done on the existing timeline.
Now we teach them Python, because the ecosystem and mindshare is there. But why didn't Perl or Ruby (or Tcl) win? It seems like Ruby didn't get the right ecosystem around it, but Perl has PDL (which does seem to predate much of the Python scientific ecosystem), and had SWIG support before Python. Maybe there's a lesson there for the Rust scientific ecosystem?
IIRC at the time Perl had a bad reputation because of the weird syntax "$%@" (not weird to shell programmers, so much, but they were weird...)
Python was "object orientated" and from a computer scientist.
Perl is very imperative and informal. Python felt to people like a real language, Perl did not.
I am reaching for reasons as I was very disappointed that Python was the winner. I have never liked Python (personal taste - meaningful white space? Really?) and knew Perl very well.
(Perl Vs. PHP is a different, much more interesting, and tragic story)
> Python is very teachable. Given a class of average 19 year old students from a numerate discipline, my colleagues will teach most of them Python to a reasonable standard in a single module
Compared to Perl, sure, Python is teachable. But I'm willing to speculate that Safe Rust as a semi-pure functional language (basically: when in doubt, .clone() all the things and don't even think about the minor hit to performance) can also be taught as a first-time programming language. Rust may be at a disadvantage to Python wrt. bindings to the existing ecosystem of C/C++/F0RTRAN scientific codes, but that's a temporary state of things.
To science majors? No. It lacks so many of the things you'd need to get them started (e.g. a REPL/notebook server, interactive plotting, a "here's everything you need" install (a.k.a conda)), and most (but not all) students have no real interest in learning to program. You could get the interested-in-programming ones to learn Rust, but then they're going to hit the large legacy of existing code and wonder why you taught them something that not related to what they're going to use.
There's an interesting experimental project for a Rust REPL and notebook interface at https://github.com/google/evcxr . Other things, e.g. semi-officially endorsed collections of community crates with no strong backward compatibility guarantees, have seen some development already.
> but then they're going to hit the large legacy of existing code and wonder why you taught them something that not related to what they're going to use.
OTOH other languages should be easier to learn by reference to a comparatively elegant language like Rust. Python, Fortran, C++ etc. have almost nothing in common but Rust could arguably be a good introductory baseline that shares features with all of these.
* Host-side use of CUDA is at least as nice, and probably nicer, than what you'll get with Rust. That is, provided you use my own Modern C++ wrappers for the CUDA APIs: https://github.com/eyalroz/cuda-api-wrappers/ :-) ... sorry for the shameless self-plug.
* ... which brings me to another point: Richer offering of libraries for various needs than Rust, for you to possibly utilize.
* Easier to share than Rust. A target system is less likely to have an appropriate version of Rust and the surrounding ecosystem.
There are downsides, of course, but I was just applying your criteria.
> Fast - in many cases faster than Rust, although the difference is inconsequential relative to Python-to-Rust improvement I guess.
Do you have any examples? AFAIK properly tuned rust and c++ will perform largely the same. Actually, Rust should have a bit of an edge due to the prohibition of aliasing. In practice it can vary if a standard library implementation is suboptimal or the compiler has suboptimal codegen into Bitcode but that’s generally going to be rare these days I think.
> Richer offering of libraries for various needs than Rust, for you to possibly utilize.
Are you talking for computational chemistry specifically or general libraries?. Don’t know about the former. For the latter I’ve found not only are more interesting libraries available, there seem to be generally high quality versions. Additionally, “cargo add xxx” is infinitely faster than integrating some random third party c++ dependency. Not to mention that C++ falls on the floor if one dependency requires transitive dependency X and another (or you) requires X at an incompatible version? Rust handles that elegantly where two different modules can depend on the same package at different versions without conflict without you needing to worry about it beyond the size of the executable.
> Easier to share than Rust. A target system is less likely to have an appropriate version of Rust and the surrounding ecosystem.
Again, haven’t that found to be my experience. Rustup lets you obtain any version of the rust tool chain, no muss no fuss. Additionally, it does a phenomenal job of not worrying about which compiler vendor you’re using (there’s only one) and more importantly there’s no versioning issues with libraries written against an older version of the language - 2021 and 2018. Oh, if you’re on windows, you also don’t have to worry about whether the target person has the right c++ runtime library version installed. With rust they just run the exe.
> Do you have any examples? AFAIK properly tuned rust and c++ will perform largely the same.
In principle, Rust has some overhead for being "safe", which C++ does not. Also, C++ benefits for longer period of time and more people working on optimizing its libraries and compilers.
> Are you talking for computational chemistry specifically or general libraries?
Ah, indeed, no. I have no idea which chemistry libraries are available for Rust and for C++. I was referring to scientific computing, algebra and other heavy-lifting work.
> Additionally, “cargo add xxx” is infinitely faster than integrating some random third party c++ dependency.
That's not one of OP's criteria. But - seeing how you like package managers, try `conan install /path/to/srcdir` from the build directory. For more details, read:
> Not to mention that C++ falls on the floor if one dependency requires transitive dependency X and another (or you) requires X at an incompatible version?
C++ is a language, it doesn't have dependency management. As for libraries, that situation is so rare - in my experience - that a chemistry person should not even be bothered to consider it.
> haven’t that found to be my experience.
Well, I learned something new today... I didn't know about rustup. Was it introduced recently?
> In principle, Rust has some overhead for being "safe", which C++ does not. Also, C++ benefits for longer period of time and more people working on optimizing its libraries and compilers.
Do you know of any specific safety features that makes rust slower? About the only one I can think of at runtime is that everything is bounds checked but that’s usually fixable in many ways (and technically c++ has that too except it’s applied randomly based on subtitle API differences like [] isn’t but .at is). As for quality of the standard library it’s hard to say. I haven’t found it to be bad. The HashMap implementation is better out of the box, a Vec/vector doesn’t really have anything special. File system APIs, error handling, modules, and async all feel more mature and polished (not performance per se but just overall completeness of the language). What is on your mind when you say that the c++ standard library is higher quality? Oh, and which of the three major implementations are you referring to?
The compilers story is actually even better because very little optimization happens in the frontend and thus a lot of the optimizations done for c++ apply to rust too. One specific way the language itself is better is that it disallowed aliasing so it’s closer to Fortran for numerical stuff and there’s various optimizations that c++ just can’t do. If I recall correctly that hasn’t been fully hooked up to the compiler due to bugs in LLVM but that will get resolved eventually. Overall, I’m not familiar with the claim that Rust code compiles worse than c++. About the only thing I’ve run into so far is bound checking showing up in hotspot code that I wrote non idiomatically because I’m still new to the language.
> Well, I learned something new today... I didn't know about rustup. Was it introduced recently?
> if you’re on windows, you also don’t have to worry about whether the target person has the right c++ runtime library version installed
It's usually easy to build such binaries for Windows. That's a single combobox in project settings. Here's an example, just running the .exe works: https://github.com/Const-me/Whisper
I want to get into that for CUDA. I've been using Vulkan via WGPU. But there, everything has to pass between CPU and GPU as byte arrays, when I've heard CUDA lets you maintain the same data structures. On the to-do list.
Would also def benefit from the larger selection of C++ libs, especially for GUI and graphics.
Given the main computation issue is doing the same operation on many values in a 3D array, using the GPU more would be great. And my current setup for that is clumsy.
I disagree on easier to share. Binaries work the same either way. Compiling from source on rust is generally install Rustc, and do `cargo b --release`. Compiling someone else's code in C++ is... complicated.
> when I've heard CUDA lets you maintain the same data structure
Yes, that's possible with a combination of:
* Unified address space for pointers (and C++ references are basically pointers)
* Paged virtual memory on GPUs
... however, remember that many/most data structures which make sense on the CPU may not make sense to use on a GPU. And - NVIDIA very often implements and promotes certain features because they sound good in marketing, not because they're actually that useful. Or because they let you make a super-slow program into a meh-speed program, not because you would use them in a really-fast program.
> Compiling from source on rust is generally install Rustc, and do `cargo b --release`.
Well, I guess you may have a point, but let me still make a couple more arguments.
First, installing Rust (and related libraries/tools/whatever) is not trivial for people who don't know rust, and some OS distributions only offer you an older version of rust using their distro-package-managers. It's more likely that a C++ environment is already set up on someone's machine... TBH, though, if the distro is older, that might not be a perfect fit for what you're building.
Second C++ package managers becoming more popular, e.g. Conan: https://conan.io/ ; and that helps for when your OS distro doesn't cover you.
> Compiling someone else's code in C++ is... complicated.
This has actually improved a whole lot over the past... say, decade or so!
* Unzip/untar
* Configure the build with CMake (cross-platform build system generator - almost ubiquitous these days in C++ projects): `cmake -B build_dir/`
* Assuming you have the dependencies set up - it should "just build": `cmake --build build_dir`
* Run the thing from the build directory or install it with `cmake --install build_dir`.
... and if you want to tweak package options more easily than via the command-line, you can use a TUI (ccmake) or GUI (cmake-gui).
The problems start when you're missing dependencies, or if the author didn't make their code platform-independent / multi-platform.
Maybe it is not part of computational chemistry, but how do you do explorative analysis? More than half my time working with data is spend grouping and summarising data, typically in Pandas and drawing interactive graphs in plotly.
Plots and visualizations in 3D. (Vulkan / WGPU) For example, to compare wave function solutions, I use surface plots of a 2D slice. I have a UI that can change the slice of the non-mapped axis. Plots of psi'', the potential etc too.
Or for simulating molecular motion, draw it out in 3D, with 6DOF FPS-style camera controls etc.
I imagine Pandas would be OOM too slow for this. Compared to Numpy, Pandas is, in my experience far too slow. Another speed limitation is Matplotlib's 3D plots make my computer crawl when rotating them etc; and they're not very interactive, at least on their own.
When dealing with these systems, a particular computational challenge is that they're 3D, so computation scales with precision^3. (This also adds complications to visualization, as I alluded to above)
If sharing is a problem I’m unsure why you didn’t think docker was the solution. I can’t think of an easier way for both the provider and the consumer than docker.
Python sometimes feel like being stuck in a local-maximum: the network effect is real, but there are so many downsides to the platform itself, and the "two-languages" paradigm renders the computational code obscure and undebuggable.
I've tried it, and it seems interesting. But I distrust anything that appears to have a lot of propaganda behind it, and rust definitely fits that bill. The hype will need to die down and the dust settle before I trust anything important to it.
I think you are being unfair here. Literally every community has the 1% of toxic, loud and insufferable people in it. Point me at your hobbies and I'll find these kinds of people there, I can bet my neck on it.
Many people conflate their own irritation from hearing about the thing X often and against their will, with the quality of the thing X.
IMHO critical thinking and maturity demands that we make that distinction.
I have worked several times in Rust companies and their devs are extremely hardcore and very quiet. You couldn't tell these people are responsible for the technical operations and code of worldwide financial services.
So again, be a bit more charitable. Every community has its rotten apples. That says nothing about the quality of the thing that the community stands for.
After being a curmudgeon from 30 to 40 years old, I've figured it's not good for me so I started changing things around and I like my life and career more now.
Don't get me wrong, insufferable people still exist! But I no longer judge an entire community by them.
I used to use it a lot, but the python libraries are much further ahead at this point. For my uses (essentially image processing and statistics) Octave is always playing catchup with Matlab but python is mostly at par or ahead of Matlab. With the exception of the parallel stuff... but that wasn't anything Octave had either. Eventually when I need performance again I'll see about figuring out how to migrate parts to Julia. One thing I like about the python things is there are some hints of IDL in there (I'm a masochist and liked IDL... Matlab frustrates me at times). Matlab was great for slapping quick UIs together and making little tools, but Jupyter works well enough for that.
The 0 indexing in python does really and truly suck sometimes though.
> The 0 indexing in python does really and truly suck sometimes though.
Now that's something you usually don't hear. At my university I heard a bit of "urban legend" about how back in the day (think early 1990's) a couple of professors got a peer-reviewed article published because they found out that Matlabs 1-indexed implementation of some algorithm resulted in numerical errors, which they measured and corrected. Don't really remember the details, and most of those involved have already retired.
The problem isn't whether 0 or 1 are "right" or not, it's the inconsistency. It makes transcribing something from a textbook harder, because the indexing logic in a textbook algorithm can get quite intricate. It's even worse if they use slices like M[i:j,m:n].
Indexing from 1 is the standard in many areas, going back many decades. SWEs have adopted a different convention.
but this depends a lot on the particular formula. For example, if you use discrete Furier transforms, all formulas are natural with 0-indexing, but weird with 1-indexing. In general, when the indices of an array are to be interpreted as modulo N, you want them to be 0, 1, ..., N-1
It is inevitable to have to use both conventions if you do varied math stuff. Thus, you will never be happy.
The pragmatic solution for transcribing is probably to make some functions `array_index` and `array_slice` that automatically convert between the two conventions. I think Julia offers another way: It lets you choose between them.
I just never find myself working out formulae/series/proofs on paper using zero-indexing. When you look up derivations/solutions in books and references they're one indexed. A recent example was a formula that had a (n-1)!*n! term that made sense from understanding the derivation. But I forgot to code it as (n-2)!*(n-1)! at first.
So you end up having to translate from one-indexed derivations to zero-indexed code and it leads to different bugs. Ultimately zero-indexing just trades one layer of bugs for another.
IMHO zero-indexing makes sense to people thinking about the machine, not necessarily the work people are trying to use the machine to do.
To be fair sometimes the opposite is true and zero-indexing gives less complex expressions.
It's a bit like all those people claiming that the new millennium shouldn't have been celebrated until 2001. They didn't stop to think how many years pass between the epoch and the time of interest. You celebrate a baby's first birthday after one year of time has passed. Until that point they are zero (and a bit) years old.
We're discussing programming language design. Referencing a prominent computer scientist to explain something on that subject better than I can seems like a reasonable thing to do. If you want to point me to somewhere where it can be argued that indexing from one is useful (not just a matter of aesthetics), please do.
"The purpose of computing is insight, not numbers." (Hamming)
Machines and notation are both tools. Aesthetics do matter particularly for tools used for thought.
There is no correct answer and imposing one tool's limitations on everything is not useful. Particularly not "just because Dijkstra said so".
Sometimes 0-indexing works well. Sometimes it sucks. Sometimes 1-indexing works well, sometimes it sucks.
I did in fact give you a reference. The fact that it's irrelevant to you and dismissed as merely "aesthetics" and that you think a computer scientist is the domain expert of all science tells me everything that needs to be said--you never deal with questions of correctness beyond mere transcription.
What I said is that moving from Octave/Matlab to python's zero indexing sometimes does truly suck. And I mean it. That doesn't mean 1-indexing never sucks or that I am inaware of Dijkstra's opinions. Having to arange(1, N+1) or 1:N+1 or whatever everywhere isn't eliminating off-by-one errors.
Matlab and Octave and FORTRAN etc are domain languages designed for linear algebra. They are of course going to be more convenient for their domains.
In language design, a choice is necessary. You can support all possible indexing strategies, but that's problematic for a whole different set of reasons. So you need to choose, index from 1 or from 0. I've never once thought my algorithmic implementation is mucky because of the index from zero, inclusive lower bound, exclusive upper bound policy languages. I used to regularly lament how ugly the MATLAB code was for that reason. Unless MATLAB had bolted on another language feature to solve that problem, I'll let my extensive (albeit 15 years old) use of MATLAB in signal processing algorithm implementation be my aesthetic guide.
I'm not here to defend Matlab as some aesthetic language (in fact why on earth they haven't poached more of Octave's syntax improvements remains an eternal mystery) so if you just want to bitch about Matlab go right ahead ;)
For anyone that spends significant time using these languages, those mental mappings are as natural as the one you seem to think is obvious - then the additional advantages of the approach become apparent.
Exclusive upper bounds mean slices work neatly: a[0:10], a[10:20], a[20:30] etc. That's very neatly represented in a loop from zero in steps of ten. That pattern turns up all over the place when accessing arrays.
I've spent enough time in MATLAB to have been scarred by that kind of array slicing and off-by-one errors.
In my past engineering university Matlab is popular. Students and staff get access to a network license and courses (non CS) are built around it. It is what older professors are used to and I don't see them shifting to a new language given how busy university professors are, and that Matlab just works.
So outside the university, Octave is the path of least resistance for those not planning to purchase Matlab or get it by "other means".
> But I'm curious where octave is popular. Does anyone pick it over julia or python when starting a new project/research?
In many non-CS engineering disciplines Octave (and Matlab) is quite common. For doing everyday numerical calculations. Python and Julia do not compete with the simplicity of using GNU Octave.
>> Python and Julia do not compete with the simplicity of using GNU Octave.
Python I understand. The numpy notation sucks big time for translating straighforward notation of engineering disciplines and is a huge step backwards in readability; but Julia? That's a surprise. In fact the opening code in the Octave page can be copied almost exactly into Julia and it works.
The big simplicity is that you install octave and you have a gui development environment ready to go. Julia and vscode are great, but setting up a project with all dependencies is a little more work for university students with no programing experience .
I actively despise how MATLAB code looks, despite spending years using it. I spent 6 months translating a library to python and it was so difficult to understand what it was trying to do because of how it was represented. I find numpy notation much easier to grok. For sure, you can do interesting indexing that makes it hard to understand, but that isn't even possible in MATLAB.
I guess Mathworks is pushing very very hard to get Matlab into Universities at the teacuing level, with campus licenses, which honestly for students are great (until they stop being students and realize they have been sucked into an abyss of cost).
It is really costly for a dept. to switch to Julia, say, as you would need all your colleagues (I teach applied maths and use matlab/octave) to make the switch lest you annoy the students (because ones learn one thing, others other).
It's also difficult to learn the new paradigm of a language, especially since MATLAB is so tightly coupled with the IDE and every other programming languages is usually run on the command line. You can use an IDE for those languages, but it usually requires some setup and sometimes that breaks.
I recently found Spyder IDE for Python which feels a lot like MATLAB. Despite my hate for MATLAB, I did at times appreciate the layout of the IDE and the way variables are still available after running a script. Spyder fortunately has a similar interface, except even better since you can restart the interpreter without restarting the IDE. I highly recommend it as a MATLAB replacement!
Autodesk did the same with AutoCAD with student licenses, and they unofficially allowed the pirating and use of AutoCAD knowing it would then win market share when people went to work for a company that needed to secure licenses.
I agree with you, but times are changing. In my experience quite a few departments are moving to python now. This is largely driven by new students who choose or push for python based subjects, because of the much broader applicability. Typically that's a slowish process, starting at the first year level and transitioning to later levels. It's not like it hasn't been done before, when I was a student we would be taught in c or java.
Indeed, despite the tale in university that Matalab is what “the industry uses”, never found an established business willing to pay the license fee. The single only shop using Matlab I encountered was venture capital funded.
But truth be said, nothing so far quite managed to replicate Matlab syntax succinctness and ease - even if it’s a (unstated?) design goal of Julia.
I use it when I’m given a model by a scientist they wrote in matlab and I need to port it somewhere else to integrate with an actual system. Octave is great for testing to make sure port matches etc. I also use Octave to learn how matlab algos work because octave is open source and reimplements most if matlab a standard library
I'm an engineer who does a lot of "applied research" projects. I've used (still do some) octave quite a bit.
There's nothing like octave (or MATLAB) for scripting to "get shit done." There is a plethora of packages and tools to do whatever you need.
Need to import excel data and graph it? Octave is great. Need to connect to an sql database, pull data and export it? Octave. Linear algebra. Nuff said.
It's a great tool for engineers / scientists who don't want to "program" (although you can!) and want readable syntax to just git r dun. Also, there's a shit ton of m code floating out there on the internet and in engineering schools / university research groups. Octave isn't 100% m compatible but if you don't have a special tool boxes & functions you can get them to run in octave with a little debugging.
I love octave. It's gotten me out of a lot of binds.
Its use is mostly limited to STEM undergrads that for some reason have trouble installing/running MATLAB.
Especially in Engineering (Mechanical/Electrical/Civil) Octave is not a substitute to MATLAB for the simple fact the former does not feature the various toolboxes useful to practicing engineers.
> for some reason have trouble installing/running MATLAB
The reason is perhaps the biggest argument against its use in an academic setting, so I'm quite happy that they are the biggest customer
I found it really useful when I got started in numerical computing and machine learning. Now I use the Jax/Numpy stack and Pytorch, but octave still has a special place in my heart due to Andrew Ng's canonical intro to ML Coursera course.
I used it in grad school a lot, especially when I was running/editing someone else's Matlab code. But if I were to build something on my own, Python would be the way to go.
I use Octave when I teach linear algebra, but it is missing some things even for that, e.g., lasso was missing the last time I tried it. So back to Matlab it was. When I have time (not in the middle of an academic year) I might try to contribute some code.
The GNU universe is wide and deep, and although each program is developed independently by different people with different backgrounds, the name still stands for something special.
For me, it's a quality attribute, among others; I'm less hesitant to install and try GNU applications than other, more free-floating ones.
And I have never been really disappointed.
Furthermore, the software philosophical aspect should not be underestimated. The more you realize what software can do and what powerful influence it has on our society in many ways, the value of a GNU Public License has increased for me.
Branding has never been the Free Software Foundation's strong suit.
(Even the FSF's name is unfortunate, IMHO. It's not an opportunity to tell the person you actually mean "free as in freedom", like some imagine. It's just starting people off with the wrong idea of what your mission is. And the result sure looks like most people went with the wrong idea, for whatever reason.)
Octave is a great project though since it is Free (in both senses of the word) it would be nice if people who end up saving €120/year on ML could consider passing a portion of those savings on in the form of a donation.
Yeah the home MATLAB license is the most expensive software I've actually bought. Octave is... okish. But Matlab is like 80% plotting and Octave's plotting support is pretty terrible.
In my opinion there isn't really anything that competes with MATLAB for the things it is really good at. Numpy is shit.
If you really can't afford £120 for MATLAB then I would say the next best option is Scilab.
Now we just need SOLIDWORKS to introduce a decent hobby license. They added one recently but it's subscription only so screw that.
There is a vast amount of talent that has created all the powerful open source numerical platforms we have today but if it could somehow coordinate we'd significantly accelerate these projects to maturity.
Octave is playing in a crowded orchestra, with the python scipy stack, the R and julia ecosystems, not to mention libraries in c++ like armadillo and eigen or even new projects in rust.
The funny thing is that in individual projects we like to apply DRY but we thinking more broadly, when solving numerical / computational problems there seem to be (too) many open source alternatives with significant overlap and duplication
No doubt all them have their pros and cons and optimal niches or historically strong points.
Ultimately though it might be an idea to somehow consolidate and coalesce around fewer and more mature stacks that have large use and development communities and which dont compete against each other for attention
This simply means that there is a need for an open source api that emulates the matlab api. But other components, e.g. IDE, compute engines etc could (theoretically) be shared between various stacks. To some degree this happens already, eg when they link underlying linear algebra libraries written in c++ or even fortran.
> Initially I hated the language but grew to like it.
Ye in the end I started to like it too. I mean, as long as you don't try to do string manipulations and mainly do numerical stuff it is a very nice language all the quirks be damned.
I also started doing that MOOC, when it was hyped. I got to the first Octave exercises. Immediately I felt uncomfortable with the code base presented. It seemed really badly structured. It felt like I was just hacking something into a mess.
I knew I was side-tracking, but still I tried to refactor it a bit, to make it more acceptable. Modularization felt somehow shoehorned into the language though. Then the grader did not work any longer. Not sure it was because of my "refactoring" or because of the course platform. More likely my modifications, or that the grader checks the integrity of files one is not supposed to change.
After that experience I threw the course and did 2 other MOOCs, which taught with the up-to-date (back then) Python stack, which I found much more useful for real applications. However, in those 2 MOOCs I could already use the knowledge learned from the Andrew Ng MOOC, so at least in that aspect of teaching the actual theory, he did a very good job.
Octave seems great since it’s open and let’s you run Matlab scripts.
A bit offf topic, but is Matlab relevant still? I’ve heard it’s still in use a lot, but what’s the benefit of going with a walled off proprietary $$$ tool when you can use something like this? Python and R also seem like they’re growing so much and are very open.
I just remember taking a class on Matlab and being pretty disappointed in it with how closed it felt. Will totally check out octave tho!
Yes, in traditional industries. Robotics, automotive, industrial automation, and aerospace are using it.
From my experience in automotive, Matlab alone is not the sole selling point, but the proprietary tooling around Matlab for modelling, hardware-in-the-loop simulation and online calibration for various ECUs is unbeatable and saves the OEMs and manufacturers weeks or months of labor and debugging various platforms. And since it's the industry standard all automotive companies use it to collaborate on projects.
There's also the important fact that many users of these tools are not programmers. They could be mathematicians, physicists, chemists, designers, process engineers, test engineers, test drivers, test pilots, etc. and the GUI block-diagram based visual programing paradigm of Matlab tooling allows them to quickly understand, collaborate and iterate on various control schemes that learning how to code. If you're a test pilot or a process engineer, it's much easier to look at a Simulink block diagram and quickly understand the process going on, than to start reading python code.
There are no open source tools that can do all these things and nor is there a market for them as these companies don't mind sticking with Mathworks & Co. and paying them juicy license fees in exchange for getting the user-friendly tools they want that enables them to get the job done.
The network effect is also too strong to disrupt. Every company in the Michigan area serving the auto industry is running Matlab and so is every company in Stuttgart and Bavaria as most big OEMs have international offices in all these regions which must collaborate together. I assume it's similar in aerospace with the likes of Lockheed, Airbus, Rolls-Royce and many other of their suppliers are also deeply entrenched in the Mathworks ecosystem.
Basically entire industries, that don't get much air-time on the start-up focuesd HN, have standardized on Matlab. In a way, it's similar to the semiconductor industry that standardized exclusively on the tools from Synopys, Mentor Graphics and Cadence. Or how how the CAD industry is run by Autodesk, Siemens and Dassault. None of these players will be disrupted by open source alternatives any time soon. Or ever.
MATLAB is ubiquitous in the aerospace industry. There probably isn’t an aircraft or spcecraft built in the west in the last twenty years where matlab wasn’t used.
The two big reasons are simulink and the availability of extremely domain-specific modules.
Simulink is a graphical modeling lanaguage for developing/simulating closed-loop control systems among other things. Flight controls people build aircraft controls in simulink and then the software engineers take it and use it to generate code that can be integrated into the rest of the flight software.
Then Mathworks builds and maintains a specific tool box for every niche engineering domain under the Sun. Need a set of simulink blocks and/or matlab functions for simulating phased-array radar systems? Mathworks has you covered, for an expensive license fee.
Both these things, IMO are ripe for replacement by open-sourced Python-based modules that do the same things, but it would take the right people with the right domain knowledge to have the incentive to do the work.
Replacing Matlab with Python in engineering seems like a very bad idea, given Python's poor performance. Matlab (and most Python) packages get around this by coding everything in C++, then just having users call that C++ code. But then you have to code in C++, which is expensive.
Julia would probably be a better solution for this use case.
The performance of matlab/Python the traditional engineering world isn’t relevant though, its just for modeling/simulation, it never runs in live systems.
It’s way cheaper to just buy a faster machine then to try and retrain a mechanical engineer who learned matlab in college on Julia, at least for now.
Matlab isn't exactly fast, and the same technique is used for python modules.
The problem isn't performance, it's that matlab is a single click install of everything and an ide that takes care of everything for you. By comparison, managing a python environment is a nightmare.
Your last paragraph is why that's never going to happen. You can make a lot more money using Matlab or making Matlab than replacing it just to give it away for free.
You can already find free and open source alternatives for just about everything in Matlab. And yet, even many companies that complain about the cost of Matlab don't use the Python and Octave alternatives. Seems like money is achieving something that other motivators aren't.
"Know your users". Something is preventing them from considering those alternatives as replacements.
There is high resistance to learning new tools in many environments, especially workplaces. Someone who learned a lot of Matlab will not easily be motivated to learn a better tool. And I would claim, that well supported non-proprietary tools like NumPy and other Python Libraries in the ecosystem, or Julia, are inherently better in the long run.
Some people in teaching roles will even further Matlab's spread irresponsibly out of not wanting to learn a new tool. I have seen this myself. A professor showed the students Matlab, instead of using non-proprietary alternatives. He also did not seem interested in learning about anything else, when I used Python + Numpy instead and showed him.
The alternative to Matlab is not necessarily another programming language. Often, it's a purpose-built tool with maybe some scripting built in.
That's what confuses software engineers about Matlab. They see code and think that the work is software engineering, but that's not always the case.
Imagine the reverse scenario. The professor sees you crunching numbers in Python and tries to convince you to switch to Matlab because it's "better". But you're a software engineer, and you still have to do all your software things that Matlab isn't great for. Why would you be interested in it?
Your previous comment suggested nobody will develop that software because it has poor financial outcomes, that was what I was responding to.
Of course you're right in this comment. Just because something exists doesn't mean people will know about it or trust it. Relationships, support, marketing etc that businesses provide go a long way to helping adoption.
Universities are still using Matlab. It's effectively "free" thanks to generous site licenses, and there's a lot of mature curriculum built up around it. The academics in my family (mostly physical sciences) would say "just use Matlab" and consider everything else to be unnecessary fuss.
Python installation is a headache in a classroom setting. Matlab provides an official installer that guarantees that every kid in the class has a working installation and the same user environment by the time the lesson starts.
It seems like Python and R have taken up residence in fields that had no prior loyalty to Matlab, such as biology.
What I've noticed is that where new graduates used to list Matlab on their resumes, now they list Python. In both cases, whether they can actually do anything useful with it or not. Many of those people didn't actually learn to program. Depending on what courses they took, exposure to Matlab or Python may have consisted of pasting some code written by the TA and running it. Students are not unaware that Python is associated with the job market for programmers -- a career "Plan B" that many are considering. At the same time, if someone can program in Matlab, they can learn Python in a jiffy, or vice versa, so it's not a life-or-death choice.
Whether they actually want to use Matlab or Python in their jobs probably depends on what industry they're in, and their interests. None of the traditional engineers in my workplace (mechanical, electrical) do any programming to speak of. Their CAD software does the engineering calculations that they need. For basic data manipulation, including graphing, they're happy with Excel.
I think you should try out Julia, in that case. Julia installation and package management is extremely easy (MUCH easier than Python). The syntax is very similar to a cross between Matlab and Python, so it's easy to pick up if you're used to either of those--it's also a lot more readable than R. And it's way, way faster than either Python or Matlab.
I've been keeping an eye on Julia. Right now my entire work group is using Python, thanks to me introducing it at my site roughly 10 years ago. But I'd rather let "what comes after Python" happen on my own terms, rather than being blindsided by it.
> but what’s the benefit of going with a walled off proprietary $$$ tool when you can use something like this
My day-to-day stack nowadays is mostly Python with a smattering of others, but I’ve been using MATLAB for almost 15 years.
Like any other enterprise software, you’re paying for support and generally very good documentation. If you have a technical issue or even just a development question you get a response from a human within a day or two, often just a few hours.
There are also many domain-specific tools (e.g. Simulink) that do not have similarly functional open alternatives. Octave is great, but can lag behind new language features and generally isn’t 100% cross compatible. Whether or not this affects you is really dependent on your use case.
There are also many domain-specific tools (e.g. Simulink) that do not have similarly functional open alternatives.
It's interesting how close GNU Radio Companion is getting to Simulink's domain. I don't know if that's their plan or if things are just evolving that way, but I like it.
MATLAB is very much still in use by large corporations and national laboratories. I'm currently a full time researcher at MIT Lincoln Laboratory and did a summer internship at MITRE a couple years ago, and MATLAB is/was the de facto standard language for the majority of staff.
If your company can afford it, and if it has good toolboxes for your field, MATLAB is a solid tool. Its plotting capabilities are the gold standard for a large portion of science--python's matplotlib and similar plotting libraries in other languages are in large part based on MATLAB's plotting experience. Others in this thread have mentioned Simulink, which is also top of the line for control theory analysis.
I think an underappreciated capability of MATLAB is its C/C++ code generation, which is quite good. It'll transpile MATLAB source code (with some minimal type annotations) into C/C++ source code that you can take wherever you want.
Having said all that, it still has plenty of flaws including its price tag. One field where I get the sense that it lags is AI/ML--I have never seen a paper introducing a groundbreaking result that uses MATLAB's ML toolboxes.
I prefer Julia / Python / C++ for my own work, but will still reach for MATLAB every once in a while.
very relevant. Mathworks has an iron grip on the defense industry and academia. Like others have said, because of simulink and a paradigm called "model based engineering". Simulink is nice, especially HDL coding tools because writing HDL by hand can be a real pain. I wish Octave made an open source - maybe one day.
As someone who works at a DoD FFRDC, I can confirm this is true. Matlab is the language of choice for 95% of my colleagues who have no CS or programming background, the other 5% is Labview. They write spaghetti code to get the job done. I’ve been scolded for using Python or Julia in programs because no one else can use it/understand it. I’ve wasted hours setting Python environments up for people which is especially hard due to strict firewall rules. Even once it is setup, it is usually to run some script the found on the internet, if it doesn’t do exactly what they need, they give up and move on. Matlab on the other-hand is a one click install with all the packages pre-installed.
I think the reason is that Matlab is more oriented to people that are not programmers, such as mathematicians and engineers, since it's more "user friendly" than python. It has everything is needed (an IDE, interactive REPL, tools to make graphs, graphical tools to build systems without writing code, etc) integrated, no need to install external library or tools, no need to use the CLI, just run the installer and done. The language then is more natural for non programmers (for example array starts as 1 and not 0), and it's use is more similar of the one of a graphical calculator than a programming language.
I think Python is superior, but perceived as difficult for non programmers.
There's a subtle difference between most programming work and non-programmers (usually engineering).
A lot of programmer work is general purpose, create something new in a novel way.
A lot of non-programmer work is highly specialized, tailoring a solution for a specific use case out of existent but adapted parts.
For the latter, it can make a lot of sense to work within a mature ecosystem, where most of the components are already available, even if you sacrifice flexibility when you need to go out of bounds.
And also you adapt your workflow and designs to the tool, not vice versus.
Matlab's Simulink is the best graphical tool for laying out causal systems modeling that I've ever come across. OpenModelica has a similar tool but it is nowhere near the same experience.
There isn't anything else on the market I know of that comes close.
I recently talked to a math postdoc about Python. He said
> "Yea some of the new PhDs try it out until they find out how awful it is!"
I clutched my pearls, aghast, and asked him why he thought Python was awful? He said that the community supported tools have problems, but the toolboxes provided by MATLAB are high quality and just work. I told him that I thought he was misguided, that Python tools work quite well and that the Python community is a strength not a weakness, that when a tool doesn't work well it's an opportunity to contribute.
I use Mathematica, and it's great strength is the curated data available for doing exploratory work. You can link to data with Python, but you need to set it up, but in Mathematica it's there from the installation. There are more things you can pay for and add, but the base installation is cohesive and powerful. Mathematica's notebook preceded Jupyter and is still better. I use the Home edition that I pay for. If I get work that uses Mathematica, I will buy the full version. I tried to use Octave as a substitute for Matlab but wound up moving to Julia. The code is very similar and easy to jump between the two sans the Matlab add-ons, however, Julia is developing a Symlink alternative.
My aversion to Python is a personal bias. It is an easy language to pick up and has won its place. I just don't like it. I was using Lush back in the day (Yann LeCun was one of the creators), and I wish it had won over Python due to my Lisp predilection [1]. It is a Lisp-like syntax that compiles to C.
What's the Julia Simulink alternative called? In Googling it I found sims.jl which isn't quite a simulink alternative so I wonder if you're talking about something else?
He uses whatever software helps him gets his job done and that's it. Software developers and enthusiats in general usually care about free software, other people not so much.
And also we can't pretend that free sotware projects like octave are not playing catch up with its commercial counterparts, it's not like hundreds of paid developers and billions of dollars getting thrown at the development of new features don't make any difference.
The statement about matlab toolboxes is so wrong it's almost funny. The quality of different toolboxes varies dramatically. Some are quite high quality but others are a buggy mess and all of them are expensive. That said, the statement is very field dependent. Fir example I know that many (most) communication theorists are using matlab, because the communications and signals toolbox does so much that would be otherwise tedious to implement. On the other hand many experimentalists in the same field have moved on to python because the instrument toolbox is so buggy and coding GUIs in matlab is an exercise in self mutilation.
To further reinforce the above argument, many environments dominated by Matlab have their instrument control software written in Python. Mathworks have made it pretty easy to call out to Python (although no Conda/Venv support...), they definitely feel the pressure in that area.
(Double checked your username, seems we've discussed the Matlab/Python space before!)
> when a tool doesn't work well it's an opportunity to contribute
That's like trying to convince someone to buy a fairphone and telling them that if the phone is lacking in some area, they can contribute to the design. Maybe you believe in the message and you're willing to make sacrifice, But if you're a math postdoc whose immediate concern is getting a tenured job before time is up, you just use what's easy and works, because you've got other stuff on your plate that is much closer to your expertise (developing new mathematical knowledge).
You're right, and honestly I was just trying to think of something to try to shift the narrative. There are other advantages to Python, personally I really value its expressiveness, the plethora of good tools (Jupyter, PyCharm, Spyder), and the massive amount of libraries in different domains (beyond all the scientific stuff there's Panda3D, pygame, Django), but I don't think these things are selling points to those in the MATLAB world. Having used MATLAB to a medium degree, I know that if you're just trying to get something done you can do it, so a more expressive language is not really a selling point. The extra tools and libraries might be a better talking point, but yea I was just trying to find some angle that I could leverage to make the guy curious about Python.
I think you're both right, but you might be thinking of different tasks and libraries. If we're talking about solving a specific type of PDE, then in that scenario he's probably right that MATLAB will work better out of the box, but if we're talking about logistic regression on data from a messy CSV table, then python will work great and have better usability than MATLAB (IMO). He might also be thinking of versioning and packaging headaches in python, which are quite a pain the first time exposed to them coming from a walled garden environment.
Actually, yes, he did mention packaging headaches as well. MATLAB manages to sidestep the issue by not having a package manager, and basically forcing you to include the literal source code of any non-mathworks dependencies in your repo.
We do need a better story with dependencies in Python, and I'm happy to see there have been several posts over the last week talking about this issue.
That said I think that for academic projects it can be fairly straightforward to handle after an initial learning curve. A lot of projects can be accomplished with just numpy/scipy/matplotlib and maybe a couple other specialty libraries.
MATLAB does not sidestep that issue. It kicks it back to the user to worry about. Dependencies in MATLAB are essentially non existent. It's up to you as the user the manage everything about them.
Well he's right. Python can't scratch the surface of most MATLAB toolboxes (Octave is a lot closer). And Matlab's general user experience and plotting support is just a million miles better. Both languages are fairly bad so I don't think that would be a factor.
Have you tried the Spyder IDE for Python? For me its user experience and plotting support are very MATLAB like. It was the missing IDE that made it possible to get that MATLAB style workflow but do it with Python (or alternatively, to use Python for scientific tasks without having to always be going through CLI or notebooks, each of which have their issues).
You are right Python, R and Julia are good enough for Data Science and Ml. But the Matlab ecosystem is deeply intertwined for a variety of fields, including ones that don't require coders.
My wife has been using primarily Python in her latest postdoc in those fields so there is hope! Admittedly that might just be on the ML side of the field though
My impression is that 10 years ago, Matlab had a few things going for it in terms of plotting, general usability,... that made it a valid competitor for eg R, even if you didn't depend on some of its more unique features like Simulink. Nowadays, I consider it essentially legacy. R has pulled so far ahead in terms of plotting/data manipulation/apps that it would be a no-brainer even if there was no price difference. What used to be a Matlab-R choice is now an R-Python choice, maybe Julia. I happen to have to maintain a fairly large Matlab codebase, if we were to start over it'd definitely be one of those, probably R. I still like the Matlab IDE best, but that's not going to keep me. The most annoying thing is that you have to buy another license on top of the regular one for most interesting things (even the optimization toolbox costs extra, so does statistics, ML, DL - and they're still no match for R or Python).
As many others have pointed out, Matlab is not only relevant, but thriving in many fields. It's a great package and is deeply embedded into the engineering world.
I won't repeat points others have made, but here are a few of my observations:
* Matlab is a great language for domain specialists -- non-programmers who want to solve technical problems. There is almost no barrier to entry to Matlab for such users -- you just start using it at the command line. Python and Julia assume the user is a programmer -- you need to worry about variable types, quirky syntax, finding and importing the right libraries, etc.
* Julia started out as a next step beyond Matlab for numeric computation. It was relatively easy to use at the beginning. However, the language has now grown and generalized to the point where I find that it has become as difficult to use as C++. For example, error messages thrown by Julia can be multiple screens long and are as hard to read as C++ errors. And getting types right is a pain. Here's the Julia manpage discussing all the types you need to worry about when writing Julia programs:
Maybe hard-core programmers love the available abstractions, but this level of complexity is a real turn-off for domain specialists who just need to crunch some numbers.
* Matlab is highly performant. The Mathworks implemented a JIT some years ago which largely mitigated the need to write (tortured) vectorized code. On the other hand, "for" loops in Octave are still dog-slow since it's interpreted on a line-by-line basis.
* Matlab has tons of toolboxes implementing advanced functionality. The toolboxes are widely used in industry. Octave mostly lacks this toolbox ecosystem.
* As others have mentioned, Simulink provides a graphical tool used almost everywere to design control systems. The control systems guys at my workplace use it. There is also an open-source alternative to Matlab/Simulink, Scilab/Xcos, which was originally written at a French university but is now owned by Dessault:
Unfortunately, I have never seen anybody on this side of the Atlantic Ocean use Xcos for anything, but I see Simulink all over the place.
* Finally, I'll point out that the Mathworks remains very innovative and continues to invest in their products. Their stuff is improving in quality and extending into new domains. I agree Matlab's price tag is steep for individual users, but for companies the price is a drop in the bucket, and the Mathworks puts its revenues to good use. I can think of many other software companies who charge far more for their stuff, but simply collect their revenues and leave their products to stagnate. The Mathworks is a good model of what a commercial software company should be.
For those who can't pay for Matlab, Octave and Scilab are both good enough for home use.
> For example, error messages thrown by Julia can be multiple screens long and are as hard to read as C++ errors.
The good news is this can be fixed by using AbreviatedStackTraces.jl, which will probably be added to the base language in the next update (1.10).
> And getting types right is a pain.
Julia's types are almost identical to Python's. Julia is dynamically-typed, with optional type annotations. You don't have to touch types, ever, if you don't want to. I never worry about types when I write Julia programs.
Wow, I didn’t know you don’t need to vectorize Matlab code anymore! Though that’s a useful skill to have, has saved my skin a few times in scientific Python land too!
It has some add-ons (tool-boxes) that aren't as complete or don't exist in the open source world and would be a big lift to reimplements. If you are just writing all your own code there isn't any advantage over python, Julia, etc.
Octave is wonderful. It's one of those free software projects whose success and necessity inspire the entire movement.
In one of my first jobs I saved a bunch of money for the company just by porting stuff out of Matlab. It wasn't just that the licenses were pricey, it's that they were a pain in the butt, plus the program was slow and very difficult to orchestrate. At least at the time.
It wasn't always easy or possible to replace a client's Matlab analyses with an Octave script, but we at least confined it to just one license on one server, stashed inside a utility closet. While meanwhile all other data analysis work flows had been automated and moved into EC2, where they ran for free on Octave.
hehe, I used in my college classes, at Technical University of Moldova, my teacher was a bit on the fence about it (he was demanding Matlab, but the uni wasn't providing any licenses), but he reluctantly agreed to it. Worked pretty fine, I could use my linux laptop, and didn't need to crack matlab.
A couple of years ago I came across a paper on Gaussian Mixture Models. Googled the author, downloaded their MATLAB code from their University homepage (with a timestamp more than 25 years ago), and installed the most recent version of GNU Octave. Everything ran absolutely flawlessly the first time.
By comparison, whenever I encounter Python code just a few years old, half the time it's (almost irreparably) broken.
(Are you sure Octave didn't have simular ones when it was as young ? Not to mention that they are kind of forced to follow behind Matlab : for instance IIRC they only recently started to think about adding Unicode support ?)
Octave is nice, but I never found it very compelling as an open source but lesser version of MATLAB. In part, this is because I have been privileged to have someone else cover the costs for me.
Numpy and Julia are alternative open source projects that cover some of the same use cases, but also add some additonal value. Numpy works with the Python ecosystem and its API has been emulated for distinct applications. Julia shares some of MATLAB and Octave's syntax, adds an advanced algebraic type system, and has expanding native code generating capabilities.
I’ve only used Octave extensively, so maybe this is a dumb question, but how well does Matlab run on the terminal? With Octave you just need to chmod and set the shebang.
I wish people would stop just posting links to projects with no explanation. It's not linked to a new release or any news, just here's the name of the project, go find out for yourself what it is.
At the very least add some blurb to explain what you're linking to
This is from 2008-2011, so adjust accordingly for evolution:
For people who did Google stats, R was the unchallenged leader. Almost no one used Octave. I think they did have a site license for Matlab, if memory serves.
I disliked R until I took a bio statistics course. It then made a lot of sense. For graphing and analysis it's great, as a general computing language it's wanting.
In that case I'd suggest Julia; it's got syntax pretty much identical to R, and is just as easy to pick up, but it's much, much faster, and it works as a general-ish computing language. (It's still definitely math/science/research-oriented, but it's not like R, which is only really usable for statistics scripts.)
The problem with Octave seems to be that, even if you put in the time to dig, you eventually hit some insurmountable roadblock because there’s no library that does what you need, IMHO.
A great way to counter this would be a series of online tutorials showing how to do common and popular tasks, projects & applications with Octave’s existing libraries.
Surely people versed with it (or the developers) would be able to show how to work around its limitations vs. Matlab toolboxes’ über-completeness.
Call Python libraries if you must from within Octave. But show how to accomplish a popular application from beginning to the very end.
This is a very good point, and is likely one of Matlab's pillars of strength. As an open-source guy I find it painful to say it, but the fact that the Mathworks is a commercial organization means they have lots of revenues which they use to hire people to implement new features. They have loads of very smart engineers building new toolboxes and other new features all the time since they have a money fountain (revenues) to fund it. The toolboxes are important to paying customers with advanced requirements, and they are willing to pay for them. It's a virtuous circle.
Octave has some volunteer hackers who poke at the code base for fun. I recall that about ten years ago development of Octave had a crisis -- the primary developer John Eaton lost his funding from the University of Wisconson. Many people who followed Octave feared the project would die. Fortunately, that did not happen, and I am not sure how the whole kerfluffle worked itself out. However, it illuminates the shaky foundations of the volunteer-project software development model (Octave) compared to having a cash fountain from real revenues (Matlab). The cash fountain means you can fund development of features desired by your users.
Octave has been an excellent alternative to MatLab. I don't see, for a grad student, what you cannot do in Octave but can in MatLab. Not like MatLab is any cheap either.
Nicer syntax for mathematical operations, but it's very slow (even slower than Python, similar to R) and it doesn't always work with Matlab code like it's supposed to.
Julia is just a straightforward improvement (substantially faster, but it has the nicest mathematical syntax of anything I've seen).
Compared to numpy, octave has a nicer syntax for matrix math, but a bit idiosyncratic as a general language. It doesn't have anywhere near the ecosystem of Python/NumPy/SciPy. It is also nice in that there is a standard development shell with REPL plotting, debugging and text editor. Like numpy it is pretty slow if you have to actually use for loops over large data sets.
I wonder if Russia’s invasion of Ukraine related sanctions - and - the simultaneous restrictions to China using western technology (namely Matlab) will have an effect on Octave progress and development?
I also wish the state of science/engineering software shook out differently. There's plenty of money to pay Mathworks. Is there some kind of license like pay us if you're doing commercial work or publishing research on grants worth over $XXX, otherwise consider it open source?