If you've spent any time using LLMs to write documentation you'll see this for yourself: the compounding will just be rewriting valid information with less terse information.
I find it concerning Karpathy doesn't see this. But I'm not surprised, because AI maximalists seem to find it really difficult to be... "normal"?
Rule of thumb: if you find yourself needing to broadcast the special LLM sauce you came up with instead of what it helped you produce, ask yourself why.
I'm not the PC but I think you miss most of the pain points due to: 'personal' projects.
There's not a compatible format between different compilers, or even different versions of the same compiler, or even the same versions of the same compiler with different flags.
This seems immediately to create too many permutations of builds for them to be distributable artifacts as we'd use them in other languages. More like a glorified object file cache. So what problem does it even solve?
>1. Somebody verifies with the users that speed is actually one of the most burning problems.
Sometimes this is too late.
C++98 introduce `std::set` and `std::map`. The public interface means that they are effectively constrained to being red-black trees, with poor cache locality and suboptimal lookup. It took until C++11 for `std::unordered_map` and `std::unordered_set`, which brought with them the adage that you should probably use them unless you know you want ordering. Now since C++23 we finally have `std::flat_set` and `std::flat_map`, with contiguous memory layouts. 25 years to half-solve an optimisation problem and naive developers will still be using the wrong thing.
As soon as the interface made contact with the public, the opportunity to follow Rob Pike's Rule 5 was lost. If you create something where you're expected to uphold a certain behaviour, you need to consider if the performance of data structures could be a functional constraint.
At this point, the rule becomes cyclical and nonsensical: it's not premature if it's the right time to do it. It's not optimisation if it's functional.
Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.
A state machine is a perfect example of a case where you would benefit from linear types.
Some things just need precise terminology so humans can communicate about them to humans without ambiguity. It doesn't mean they're inherently complex: the article provides simple definitions. It's the same for most engineering, science and language. One of the most valuable skills I've learned in my career is to differentiate between expressions, statements, items, etc. - how often have you heard that the hardest problem in software development is coordinating with other developers? If you learn proper terminology, you can say exactly what you mean. Simple language doesn't mean more clear.
I wasn't born knowing Rust, I had to learn it. So I'm always surprised by complaints about Rust being too complex directed at the many unremarkable people who have undergone this process without issues. What does it say, really? That you're not as good as them at learning things? In what other context do software people on the internet so freely share self-doubt?
I also wonder about their career plans for the future. LLMs are already capable of understanding these concepts. The tide is rising.
>You see, the shapes of roads in real life come from an underlying essential fact: the wheel axles of a vehicle. No matter how you drive a car, the distance between the left and right wheels remains constant. You can notice this in tyre tracks in snow or sand. Two perfectly parallel paths, always the same distance apart maintaining a consistent curved shape.
Emphasis mine - that's not really true
- Cars have differentials, so the wheel speed can differ between wheels
- Steering geometry isn't parallel! The tyres turn a different amount when you turn the wheel
- Unless you're going in a straight line, cars don't go where the tyres point! Tyres 'pull' the car towards their slip angle
What you will actually see in tracks in snow or sand is non-parallel tracks, describing curves of different radii. You can also see this in racetracks, where the path more closely resembles the limits of car physics without care for passenger comfort or tyre wear. The example 'fail' image looks not dissimilar from a hairpin turn.
> Do they have ABS sensors that can detect wheel lockup/speed status? Because I don't.
You should fix that. Go out on a rainy day and slam the brakes hard enough for it to kick in. There's an obvious vibration and knowing what it feels like might save your life.
I have the desktop app open right now. In the top-right corner is a nag saying 'Share your plan'. It's an ad for Proton Duo.
I just clicked 'Don't show again'. I get a toast saying you won't show me that offer again and it's immediately replaced with a nag saying 'Refer friends'. It has its own 'Don't show again'.
In August 2024 I sent Proton support an email with this text:
>I pay 95.88 € a year for Proton and every time I open the webapp or the desktop program, I see this:
The support reply told me I can remove the button by clicking on it, then "Don't show again". If I was frustrated enough to email you about it, I'm guessing I clicked it.
I have expressly opted out of ads for Proton Duo. You're interpreting this as me opting out of a single ad for Proton Duo. Changing the copy doesn't mean I have opted into comms about it. So I disagree you take this seriously.