See https://stackoverflow.com/questions/12084246/differences-bet...
Anyone who runs up against a limitation of Octave has probably hit the point where they should consider switching, but not to Matlab or some other scripting language, but to Fortran or maybe Julia or something.
Therefore, I disagree with the accepted answer in that StackOverflow thread. The language is only good in the first place for short codes anyway, so fixing any little octave/matlab regionalisms is not a big deal. And, since it is a mathematical experiments, you should understand what every line of code does, so running the code without reading it is not really an option.
The language itself is awful.
YouTube playlist: https://www.youtube.com/playlist?list=PLiPvV5TNogxIS4bHQVW4p...
Using Octave for a beginning ML class felt like the worst of both worlds - you got the awkward, ugly language of MATLAB without any of the upsides of MATLAB-the-product because it didn't have the GUI environment or the huge pile of toolbox functions. None of that is meant as criticism at Octave as a project, it's fine for what it is, it just ended up being more of a stumbling block for beginners than a booster in that specific context.
It comes with vendor support and "official-ness" for lack of a better word.
Things are changing rapidly in this area but it wasn't very long ago that most people reacted to open-source software as something weird that shouldn't be trusted.
* c++ * python * R * lua * javascript
Try them here:
* https://jupyter.org/try-jupyter/lab/ * https://jupyterlite-xeus.readthedocs.io/en/stable/lite/lab/i...
Or create your own deployments by using this template repo: * https://github.com/jupyterlite/xeus-lite-demo
It is a great example of GNU's contribution to the advancement of human kind.
It is highly recommended for numerical mathematics and can be extended with GNU-Fortran or GNU-C. It comes bundled with many extensions.
It is mostly a DSL for numerics.
Scilab is another recommended similar package but comes with less extensions.
Octave could be embedded as a C library for some time:
https://stackoverflow.com/questions/9246444/how-to-embed-the...
https://docs.octave.org/latest/Standalone-Programs.html
There is an OpenCL package to provide GPU acceleration:
https://gnu-octave.github.io/packages/ocl/
Unfortunately it looks like they did it wrong, by providing explicit GPU types and functions, instead of converting unmodified Octave code to run directly with GPU acceleration implicitly:
https://octave.sourceforge.io/ocl/function/oclArray.html
It would be awesome if Octave got implicit GPU acceleration in the browser with something like OpenCL. Unfortunately it looks like OpenCL was never ported to WebGL, so WebCL isn't implemented yet:
https://en.wikipedia.org/wiki/WebCL
https://www.khronos.org/webcl/
WebCL is apparently being replaced by WebGPU:
https://stackoverflow.com/questions/11532281/how-to-use-webc...
https://gpuweb.github.io/gpuweb/
https://developer.chrome.com/docs/capabilities/web-apis/gpu-...
- unsolicited opinion -
It's always astonishing to me how the obvious path is rarely taken by industry, because writing open solutions is self-evidently less profitable than writing proprietary ones. Look up the history of the blue LED and countless other innovations to see how that works and why.
I'm hopeful that AI will relieve programmer burden enough that we can explore these obvious roads not traveled. Because we're off on a very long tangent from what mainline computer science evolution might have looked like without tech's wealth inequality.
Unfortunately I see two major (rarely discussed) pitfalls looming with AI:
1) Every tech innovation brings a higher workload for the same pay. The amount of knowledge required to be a full stack developer in 2025 in higher than in 2015, which was higher than in 2005, which was higher than in 1995, and so on. Yet starting pay has not increased with inflation.
2) With AI bringing pair programming everywhere, we may see a decline in overall code quality if humans don't have to deal with it directly. Extended pair programming can lead to over-engineered codebases that can only be read by teams of humans instead of individuals. So whereas one untrained hobbyist could build a website in 1995 using principles like data-driven design, declarative programming and idempotence, today it requires a team to untangle the eventualities of imperative nondetermistic async code that from a user perspective is equivalent to simply hiding the progress bar in the browser.
That's why I'm such a proponent of alternative methods. Abstractions that are quite verbose to represent in, say, Python, can be expressed as one-liners in Octave. The only way to get more concise would be to move towards more of a functional assembly language like Lisp, at the cost of the syntactic sugar provided by array-based languages.
TL;DR: I believe that the most direct path from J.A.R.V.I.S./Star Trek style AI prompts to readable but efficient code is through DSLs like Octave/MATLAB, and some of the lost ways of doing business logic in the 1980s like Spreadsheets, HyperCard and Microsoft Access or FileMaker. Open tools like a GPU accelerated Octave would help us gain more leverage in writing software and possibly speed the evolution of AI itself by helping us more closely express abstractions in code.
This strongly agrees with you: https://alexalejandre.com/languages/end-of-programming-langs...
