Nobody's saying you have to build an airplane to know how it works, the point is you have to know how it works to either build it, or fly it effectively. You won't know why it stalls if you don't know what makes it stay up.
The point of the time travel story is that Feynman understands it to the level that would let him recreate the technology from scratch in a society without powered heavier-than-air flight, not that he can compete, John Henry-like, with a Boeing assembly line. That's a good enough level of "can create" to reasonably say you understand something. Nobody outside of Boeing has the built-up engineering expertise to replicate their assembly line, and any equally advanced design would have to be evolved forward over many years.
The problem with MCAS is that the abstraction combined with a lack of specific awareness of the issue made it unclear to the pilots what was going on exactly, or what that meant. Abstraction isn't the problem, but abstraction that masks relevant parts of what's going on (like how many distinct sensors are going into a reading) has to be treated with appropriate respect.
High school physics certainly does help you understand momentum, which is the cause of all crashes.
Instead humans rely on visual intuition, which everyone has with or without learning physics.
>Nobody's saying you have to build an airplane to know how it works, the point is you have to know how it works to either build it, or fly it effectively. You won't know why it stalls if you don't know what makes it stay up.
You said it. You quoted Feynman saying it. So if you didn't mean that then you made a mistake here. Ok the. I agree with the rest of your post then.
However my main point still stands the systems we build as humans are too complex for a single person to understand. In order to deal with this complexity most of programming involves investigating and testing libraries that abstract away this complexity. It is more.important to know this then it is to construct highly modular fp style code.
It is true that the fundamentals that SICP teaches will be around forever, but the fact of the matter is, if I'm an employer I'd rather hire a specialist in some arbitrary ephemeral domain relevant to my business then to hire someone who is a generalist.
see my remark above
The siphon one is funny because many people will start with air pressure, which is wrong.
My understanding is there is a rather tortuous explanation involving viscosity (for lift and wing shape)
But they can't build an airplane. This follows Your quote from Feynman.
>Feynman understood how airplanes work better than I understand how the internet works, and that's reasonably well.
Feynman can't build an airplane. Again you quoted him Admitting that if he can't build it, he doesn't know how it works.
>The way it's a technique: first understand it, then you can try to create it.
Except No pilot ever uses this technique. They fly a plane, but they mostly never build one.
>Did Feynman understand commercial jets well enough to build one from scratch? Certainly not. But if dropped off by time machine a decade before the Wright brothers, could he have saved everyone some time and gotten something off the ground, given similar resources? Yes.
What does this have to do with anything? Basically the point is the logic you following from that quote doesn't apply. A pilot CAN know how a plane works, so can Feynman, AND they both don't have to build one to know. The whole point of the plane and pilot thing is to show you the flawed logic.
>When pilots don't understand how airplanes work, you get MCAS, and we can all agree that can't be allowed to happen again (and was not entirely the pilot's fault, as they were lied to about the systems, in the service of getting one by the regulator).
They don't have to build an airplane to know about MCAS do they? That's the point here. They don't even have to know how to program. That is essentially what MCAS is: a program. Instead pilots deal with an abstraction. They have a very rough idea of how it works. Sort of like how programmers deal with libraries, but they don't have to build the libraries from scratch.
>Rust was good for Graydon Hoare, as he got his ideas about safety out into the world. Later he burned out. Mozilla is one of the champions of mismanagement and squandering of every kind of technical and non-technical opportunity, and somehow the Rust juggernaut became its own thing that's quite extraordinary and hard to characterize. I'm sure there are a lot of stories there. As to the people choosing Rust today for non-systems programming work, because of fashion, that doesn't seem to be good for anyone, but opinions obviously differ there as well.
Good for the community. Epic business mistake. A fools errand for Mozilla who basically conducted a charity for the community.
>As to the people choosing Rust today for non-systems programming work
Performance is a metric worth going after even if you're not directing calling any system calls. Honestly it's not even that hard or far away from a non-systems programming language.