I think the idea is that nobody will need to understand the code or plan an implementation. The AI will do that. Now, whether that is a good idea is debatable, personally I think we should not make all software engineering depend on just a few AI companies. Oh, and nobody will notice that nobody has an understanding of what is built, as all those management positions will sooner or later also be filled by AI.
That is the point: our minds are also next-„token“-predictors, at least we can‘t prove they‘re not. That‘s why I don‘t agree with the article: LLMs _are_ next-token predictors. However, that says little about their capabilities. Also, while I have no idea what „consciousness“ is, I have difficulties believing that it could arise in a program that, in theory, you could execute with pen and paper.
It doesn’t mean that these “thoughts” influenced their final decision the way they would in humans. An LLM will tell you a lot of things it “considered” and its final output might still be completely independent of that.
We once rented bikes in Copenhagen, they all looked like they were fresh from the junk yard. We had to try several to find ones where at least one of the brakes was still working. It was a horrible experience, and we tried several different places. That was after we found out that the public bikes that were supposed to be available all over the city had all been stolen.
True. I often think of Rust as a best-of compilation of Haskell and C++ (although I read somewhere that OCaml had a greater influence on it, but I don’t know that language well enough)
In real life, I find that Haskell suffers from trying too hard to use the most general concept that‘s applicable (no pun intended). Haskell programs happily use “Either Err Val” and “Left x” where other languages would use the more expressive but less general “Result Err Val” and “Error x”. Also, I don’t want to mentally parse nested liftM2s or learn the 5th effect system ;-)
If only I had known this earlier in my career! They should really add a feature to make a hard copy of the big bucket list to minimize memory overhead, though.
Most standard containers have no way to communicate allocation failure to the caller in the absence of exceptions (think of constructors that take a size). Worse, the implementations I’ve seen would eventually call operator new, assuming it would throw if it fails. That is, subsequent code would happily start copying data to the newly created buffer, without any further tests if that buffer is valid. In the absence of exceptions, that won’t work.
On the other hand, once your embedded system is sufficiently large, people will want to use (and inevitably will use at some point) standard containers such as std::string or std::vector. And without exceptions, all of those might invoke UB at any time (I have yet to see a standard library that understands and honors -fno-exceptions; usually they just drop all try-catch blocks and all throws)
And the C library‘s hacks around not being able to overload functions (which is the only reason for strstr et al‘s weird signature) wouldn‘t stop me from using const. It can be really useful both for documentation and for correctness. Think memcpy, not strstr.
The idea is to make the accesses safer, not necessarily more readable. The monadic operations make it impossible to access the value in a std::optional without first testing that it actually contains a value.
Afaik, underscore-underscore anywhere in a name is reserved in C++ only. C only reserves names starting with underscore-underscore. And yes, you can get away with using these identifiers, but you could almost never be certain that you did.
You’re comparing apples to oranges. The correct analogy is: you pick any other sequence of numbers between 1 and 20 and then tell me you’re more likely to win because your sequence is more random.