What's the problem? Someone submitted it for people to read but it didn't catch on, now it's resubmitted and people can read it after all. Everyone happy. Don't be so attached to imaginary internet points.
The leap is not really there yet and it's cheap because you are the product. The robot will be a massive headache, will work poorly for most tasks, frequently break and require maintenance. In exchange for $500/mo and providing those test hours in a novel environment and the data that goes with it, you get to have a robot in your house that occasionally does something right. The bet being made here is that they can turn that data hose into a useful robot before this poor customer experience tanks their brand.
I’d suggest Octave over Matlab, because current Matlab has tons of distracting AI and autocomplete front and center. Probably really helpful for getting a plot just right or implementing an algorithm from a paper, but not so good for learning the basics.
I think his main point is about strict typing in Fortran. You can add type annotations in Julia but it's almost an anti-pattern if you don't need them e.g. for dispatch. In any case the type annotations in these examples would be quite unnecessary, unlike in Fortran (where as I understand you can at best enable implicit typing but then must use variable names with specific patterns).
I would argue that the strict typing in Fortran is actually a significant hindrance. there's nothing about any of these algorithms that requires double precision (or even contiguous storage), so why should the algorithm randomly restrict it? Annotations of rank (e.g. AbstractMatrix in julia) help document what the code does, but the strict annotations of Fortran are restrictions without value.
Step 1) Write the function using high level abstractions
Step 2) Glance over the generated assembly and make sure that it vectorized the way you wanted.
> Glance over the generated assembly and make sure that it vectorized the way you wanted.
Isn't that sth you would also need to do in Fortran? IMO Julia makes this so easy with its `@code_*` macros and is one of the main reasons why I use it.
If you write Julia similar to Fortran, with explicit argument types and for loops and avoiding allocations it shouldn’t be too far off. Fortran IIRC has a few semantics which might make it more optimal in a few cases like aliasing
But indeed there are almost certainly less performance surprises in Fortran
This is the default workflow in every high-level language. Even if I’m writing explicit SIMD intrinsics in C targeting a specific processor, I still have to benchmark and maybe look at the assembly to make sure it did what I intended (or something better).
people like to complain about matlab as a programming language but if you're using it that way you're doing it wrong.
matlab (the core language) is awesome for expressing matrices and vectors and their operations as well as visualizing the results. matrix expressions in matlab look almost identical to how they look in mathematical notation (or how one might write them in an email). you shouldn't be using programming language flow control (or any of the other programming language features), you should be learning how to write for loops as vector and matrix operations and learning from the excellent toolboxes.
Okay and the key difference between crypto and cash/credit/whatever is supposedly that it is decentralized. Or have we abandoned that false premise now?
Cash has centralized distribution, but it's very decentralized in use. That's what makes it useful. However, sometimes people might choose to use a centralized service provider (like a bank, or a credit card company) because it's useful. They still have the option of using cash. What's important isn't that every single transaction happens in a fully-decentralized way: it's that decentralized transactions remain an option. That means that banks and credit card companies have to compete with cash, and that they can never have full control of your financial life.
The same is true of cryptocurrency. It's not a problem that centralized service providers exist. If they stop providing useful services, people can just take their cryptocurrency and go home.
Why is a centralized service provider for crypto useful? It doesn't solve any of the problems that banks and credit card companies solve for cash. Those problems are already solved in the decentralized use case.
That credit cards exist didn't mean cash stopped existing. Likewise, just because CEXes and L2s exist doesn't mean L1 cryptocurrency doesn't exist. You can still grab a non-custodial wallet and still manage your own crypto. Today Coinbase has a debit card that can sell crypto at FMV, apply their spread (1.88% I think?), and immediately use that to pay off USD denominated bills. So if your crypto is in your wallet you can just send your Coinbase wallet the funds for the purchase and then swipe your debit card to pay.
Coinbase's spread isn't the worst thing to pay for the service of having a debit card and auto-selling, but if you also buy crypto using Coinbase, they double-dip on the fee.
