by zackmorris | 2025-10-19 18:36:15+00:00
This is great! I always wanted a GNU Octave transpiled to other languages.

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.