In Defense of Matlab Code
121–130 of 174 posts
Re: In Defense of Matlab Code
#122I had a bad time with MATLAB. https://www.nayuki.io/page/matlab-language-pet-peeves
Re: In Defense of Matlab Code
#123I dislike Matlab's licensing and spaghetti style coding practices like anyone else, but there's another reason python or other modern replacements are scorned at. There are some algorithm/theorem implementations that will produce different results based on the platform and version you are using. With Matlab the chance of that happening is much much lower, if not zero.
Re: In Defense of Matlab Code
#124One small piece of feedback for the dev, since I see you've been replying to comments here. I had to jump like 3 links and 4 pages down to figure out what runmat actually "is" / "does". As someone who's done their whole thesis using Octave this looks interesting. I love Octave, it's one of my favourite languages. And, for reasons I don't understand even myself, I don't like matlab that much (though I admit their docu…
Thanks for digging in ;) We just released RunMat in August as an open-source, fast MATLAB runtime. The goal is to make it the fastest way to run math, period. Coming from Octave, you'll notice significant speedup advantages, you can see some of our benchmarks with it here https://runmat.org/blog/introducing-runmat Last month, we put out 250+ built-in functions and Accelerate, which fuses operations and routes between…
I feel like you should be saying Matlab / Octave wherever possible; especially since your target audience is far more likely to be the one that wants a "faster Octave" rather than a "cheaper Matlab".
PS: Don't trust github language stats; half of that code is octave specific, but still gets labelled as Matlab.
Re: In Defense of Matlab Code
#125I want to come out and say that a long time ago at a startup we needed to generate a very particular type of analysis graph for a human operator to review in our SaaS. and I just straight up installed GNU Octave on the server and called out to it from python, using the exact code the mathematician had devised.
These days however with all the AI coding tools that are available, it probably makes more sense to just ask Claude to port the Matlab/Octave script to Python and directly integrate it into your program. Numpy/Scipy often provide drop-in replacements for Matlab functions, even the names are the same in some cases. I have gone further and asked AI to port working but somewhat slow numerical scripts to C++ and it's com…
Re: In Defense of Matlab Code
#126Earlier quoted context omitted.
I don't think Julia really solves any problems that aren't already solved by Python. Python is sometimes slower (hot loops), but for that you have Numba. And if something is truly performance critical, it should be written or rewritten in C++ anyway. But Julia also introduces new problems, such as JIT warmup (so it's not really suitable for scripting) and is still not considered trustworthy: https://yuri.is/not-julia…
As your comment already hints at, using Python often ends up a hodgepodge of libraries and tools glued together, that work for their limited scope but show their shaky foundations any time your work is outside of those parts. Having worked with researchers and engineers for years on their codebases, there is already too much "throw shit at the wall and see what sticks" temptation in this type of code (because they'd…
At least it has those tools and libraries, what cannot be said about Julia.
Re: In Defense of Matlab Code
#127Earlier quoted context omitted.
I don't think Julia really solves any problems that aren't already solved by Python. Python is sometimes slower (hot loops), but for that you have Numba. And if something is truly performance critical, it should be written or rewritten in C++ anyway. But Julia also introduces new problems, such as JIT warmup (so it's not really suitable for scripting) and is still not considered trustworthy: https://yuri.is/not-julia…
Yes, Python code is indeed fast if you write it in C++... what a bizarre argument. The whole selling point of Julia is that I can BOTH have a dynamic language with a REPL, where I can redefine methods etc, AND that it runs so fast there is no need to go to another language. It's wild what people get used to. Rustaceans adapt to excruciating compile times and borrowchecker nonsense, and apparently Pythonistas think it…
It is, because usually someone already did it for them.
Re: In Defense of Matlab Code
#128Earlier quoted context omitted.
I remember the pitch for Julia early on being matlab-like syntax, C-like performance. When I've heard Julia mentioned more recently, the main feature that gets highlighted is multiple-dispatch. https://www.youtube.com/watch?v=kc9HwsxE1OY I think it seems pretty interesting.
Julia is actually faster than C for some things.
Re: In Defense of Matlab Code
#129Re: In Defense of Matlab Code
#130There's also Julia. Earlier in my career, I found that my employers would often not buy Matlab licenses, or would make everyone share even when it was a resource needed daily by everyone. Not having access to the closed-source, proprietary tool hurt my ability to be effective. So I started doing my "whiteboard coding" in Julia and still do.
Julia competes with the scientific computing aspect of matlab, which is easily the worst part of matlab and the one which the easiest to replace. Companies do not buy matlab to do scientific computing. They buy matlab, because it is the only software package in the world where you can get basically everything you ever want to do with software from a single vendor.