Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of Matlab Code

runmat.org

Post reply on HN
Print view View original

21–30 of 174 posts

Re: In Defense of Matlab Code

#21

Post by nallana »

drnick1 wrote: post #15
fph wrote: post #7

Earlier quoted context omitted.

Precisely; today Julia already solves many of those problems. It also removes many of Matlab's footguns like `[1,2,3] + [4;5;6]`, or also `diag(rand(m,n))` doing two different things depending on whether m or n are 1.

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…

In Julia, you explicitly need to still reason about and select GPU drivers + manage residency of tensors; in RunMat we abstract that away, and just do it for you. You just write math, and we do an equivalent of a JIT to just figure out when to run it on GPU for you.

Our goal is to make a runtime that lets people stay at the math layer as much as possible, and run the math as fast as possible.

Re: In Defense of Matlab Code

#22

Post by nallana »

boscillator wrote: post #4

Interesting... I wrote a similar post about MATLAB's syntax a while ago, and I still think MATLAB is one of the best calculators on the market. RunMat is an interesting idea, but a lot of MATLAB's utility comes from the toolboxes, and unless RunMat supports every single toolbox I need, I'm going to be reaching for that expensive MATLAB license over and over again.

Yep! Makes sense. Though I think the cost of writing these toolboxes is lim --> 0.

Will have a really solid rust inspired package manager soon, and a single #macro to expose a rust function in the RunMat script's namespace (= easy to bring any aspects of the rust ecosystem to RunMat).

Re: In Defense of Matlab Code

#23

Post by sundarurfriend »

drnick1 wrote: post #15
fph wrote: post #7

Earlier quoted context omitted.

Precisely; today Julia already solves many of those problems. It also removes many of Matlab's footguns like `[1,2,3] + [4;5;6]`, or also `diag(rand(m,n))` doing two different things depending on whether m or n are 1.

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 much rather be working on their research than on the code), and the Python way of doing things actively encourages that. Julia's type hierarchies, integrated easy package management, and many elements of its design make writing better code easier and even the smoother path.

> I don't think Julia really solves any problems that aren't already solved by Python.

I don't really need proper furniture, the cardboard boxes and books setup I had previously "solved" the same problems, but I feel less worried about random parts of it suddenly buckling, and it is much more ergonomic in practice too.

Re: In Defense of Matlab Code

#24

Post by constantcrying »

What a terrible article. The author does not understand matlab at all and he is also either lying or totally clueless.

Matlab is successful because of precisely one thing, which nobody has replicated. It offers a complete software environment from one source.

Nowhere else can you get scientific computing, a GUI toolkit, a high level embedded software environment, a HiL/SiL toolkit, a model based simulation environment, a plotting and visualization toolkit and so much more in a single cohesive package. Nobody else has any offering that comes even close.

>The engine is closed source. You cannot see how fft or ode45 are implemented under the hood. For high-stakes engineering, not being able to audit your tools is a risk.

This is just a lie. Open matlab and you can inspect all the implementation details behind ode45. It is not a black box.

>The Cloud Gap: Modern engineering happens in CI/CD pipelines, Docker containers, and cloud clusters. Integrating a heavy, licensed desktop application into these lightweight, automated workflows is painful.

Another lie. See: https://de.mathworks.com/help/compiler/package-matlab-standa... Mathworks has done everything hard for you already. I do not understand why the author feels the need to authoritatively speak on a subject he absolutely does not understand.

Re: In Defense of Matlab Code

#25

Post by NeroVanbierv »

For me, the main appeal to MATLAB was the REPL experience, allowing me to experiment with ideas and inspect results in the UI. Python notebook have bridged the gap a bit, but always require a combination of libraries (with different docs & design choices) to write a single script.

Re: In Defense of Matlab Code

#27

Post by constantcrying »

lemonwaterlime wrote: post #2

There'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.

Re: In Defense of Matlab Code

#28

Post by nallana »

fithisux wrote: post #5

Matlab code is fantastic for prototypes and for getting a "feeling" before doing the expensive optimal implementation.

If the rewrite is for performance, ideally the logic capture = the thing executing in production.

Cases where a JIT running would conflict with requirements notwithstanding (e.g. HIL with strict requirements and whatnot)...

Re: In Defense of Matlab Code

#29

Post by cogman10 »

NeroVanbierv wrote: post #25

For me, the main appeal to MATLAB was the REPL experience, allowing me to experiment with ideas and inspect results in the UI. Python notebook have bridged the gap a bit, but always require a combination of libraries (with different docs & design choices) to write a single script.

Yup, for both Matlab and Maple the big feature was the Jupyter notebook experience right out the box. On top of that, at the time it had a pretty high number of math functions implemented.

Re: In Defense of Matlab Code

#30

Post by Vaslo »

Every data scientist and statistician who joins our team is always happier moving to Python or R away from Matlab after using it for a bit. I guess it’s ok for academia but at the two large companies I have worked at, no one is using Matlab or complaining about it being gone.
Post reply on HN