Supposedly it was named "caml" because the author was a smoker who enjoyed camel cigarettes, hence the joke that [later implementations](https://en.wikipedia.org/wiki/Caml#History) were named "Caml Light" and "Caml Special Light"
This is more or less my belief too. But I think there are probably domains/companies where the "promo video" is actually good enough to ship (or at least, where that's the quality that devs were shipping before)
People don't write blog posts about how they wake up at 3AM to assign new tasks to their intern, nor do they build "orchestration frameworks" that involve N layers of interns passing tasks down between eachother
Also the process sounds like a nightmare: "it broke and I asked 4 different LLMs to fix it; my `AGENTS.md` file contained hundreds of special cases; etc." I thought this article was intended to be a horror story, not an advertisement
Why? Looks like they're doing realtime network monitoring for security purposes. Sounds like a high performance application to me. Haskell has a reputation for being slow, but the proof is in the pudding - and what's being asserted is that a stronger type system enables better optimization.
Money allows for economic specialization, leading to greater productivity. You don't build an economy that produces cell phones when you're stuck bartering goats for wheat.
I feel like this is not answering the spirit of their question. What is bad about Crypto which isn't some nth-order effect of Money?
- When a layperson is scammed out of their Crypto the problem is that they lost Money because they used Money to buy the Crypto. (Yes, given the current ecosystem it is easier for my grandmother to be convinced to transfer all of her Crypto such that she can't get it back but that's bad because she's losing Money.)
- People are incentivized to run machines which "mine" Crypto -- but otherwise do nothing externally useful while also causing other negative externalities such as carbon emissions -- because the Crypto can be sold for Money.
I thought that Fortran was traditionally faster than C++ for numerical code due to stricter aliasing rules in the language, which I wouldn't expect to carry over to an IR?
That, but also being simpler and higher level, having multidimensional arrays in the language itself and simpler semantics (such as you cannot just take a pointer to an arbitrary variable, it has to be marked with "target"), no exceptions, and so on. What carries over to the IR today are all the language semantic features, such as all the array operations (minloc, maxval, sum, ...) and functions (sin, cos, special functions) as well as all the other features without any lowering, and we then do optimizations at this high level, then only at the end we lower (say to LLVM). Python/NumPy can be optimized in exactly the same way, and that's what LPython does. I think C++ can also be compiled this way, but the frontend would have to understand basic structures like `std::vector`, `std::unordered_map` as well as arrays (say xtensor or Kokkos, whatever library you use for arrays), and lift it to our high level IR. Possibly we would have to restrict some C++ features if they impeded with performance, such as exceptions --- I am not an expert on C++ compilers, I am only a user of C++.
reply