No, it isn't. And this is exactly the kind of throwing-in-the-towel that I'm talking about.
The other way to manage complexity is to include it as one of the considerations when designing a system. You can design for simplicity just as you can design for any other desirable feature (speed, cost, power consumption). Complexity is not an unavoidable consequence of the laws of physics, it a consequence of poor choices and complacency.
Imagine if you were designing an operating system: GNU Linux.
There is no one person in the entire world who understands All of GNU Linux as a whole. Most people understand what they need and everything else is an abstraction. Sussman was right.
Treating everything as "magic" black boxes as you want is tantamount to sweeping dirt under a rug. It doesn't address the problem, it just creates a wrinkle for you to trip over later.
No it's not. Why do game developers often not write an entire game engine from scratch? Instead they use out of the box solutions like unity and or unreal?
Because they cannot hope to build an entire game engine that is as complex as existing commercial solutions within the available time and budget.
This isn't just software engineering. All forms of engineering work this way. Not just engineering either. Society works this way.
But you are correctly repeating the standard wisdom of the day, which is that first-principles understanding is inefficient (because people don't have time for it) and the best thing is to treat software as pluggable units.
> All forms of engineering work this way.
As far as I know, engineers still learn physics.
The way I see it is this. Sicp is good to know. But as an introduction to programming python and applications are more relevant to the modern age.
>As far as I know, engineers still learn physics.
So? Human society is overwhelmingly made up of specialists. Engineers who learn physics doesn't change the fact that within engineering, there are specialties.
The standard wisdom tends to keep the bureaucratic beast in control, not you. That is why it is the standard wisdom, and not the outsider minority opinion. That is why increasing your professional competence, year over year, with SICP and similar courses of study, is anathema to any engineering culture that has been totally taken over by bureaucracy, which is a majority. That is why there is a consulting industry serving Uncle Bob's ideas that comp-sci is not actively harmful to know about but certainly not something you need to be encouraged to learn. According to this school, anyone making a claim that "every programmer should study X" would make their co-workers uncomfortable, and this is the kind of toxicity that must be managed out of a modern (that is, bureaucratically-controlled) company.
The standard wisdom is not for you if you want to look back on your career and say that you did meaningful work, that you tried to advance your field, even if you failed, or that you worked on one of the hard problems of your time. If you want to look back and say that you navigated FAANG and retired early, then the standard wisdom and making yourself amenable to the super-organism may be just the ticket.
SICP, by the way, isn't something good to know, because it's not something you know. It's something you do, and the experience (all the exercises) will rewire your brain, unless you've already had sufficient experience so that those patterns are already wired in, in which case you may find it kind of trivial and beginner-ish. The difference is whether you're oriented towards things like writing compilers as scary and best left to specialists, or whether you regard them as basic tools of any programmer, which is more empowering for you, not for the bureaucracy, which diminishes in purpose as individual variance in competence grows.
The point about engineering is that there's no movement saying that engineers should stop studying physics, and consume physics knowledge in special packets prepared for the use of the "engineering industry" by physicists. Yet this absolutely fantastical idea is how the work done by computer scientists is supposed to be distributed to software engineers. They need not study the fundamentals, because they need not understand them, just consume the artifacts produced by those who do. Most of the low standards of modern software can be traced directly to this attitude.
Do whatever you want. Nobody is stopping people from studying multiple fields. The main point is that the human brain has limitations. In general the majority of people can master only a few specialties. This is the MAIN reason behind the "standard wisdom".
That's interesting, do they learn about all the properties of newly discovered quarks and derive Newtonian physics from quantum theories? Because if that's what they do, it's new to me.
Look at Alan Kay's work with VPRI to see what a few brilliant minds can accomplish when looking at things from radically new perspectives.
Good design can only lower complexity. Complexity itself cannot be negated. I can point to a million more examples, here's one:
Red Dead Redemption 2 the video game. Name one programmer who understands every single system in that game.
Sussman co-wrote SICP.
Perhaps the words are too harsh. But is there any other way to build something more complex then you can understand? Using pre-existing libraries is the only way.
Additionally if you tried to say build a triple A game without using any libraries would that not be a fools errand?
The story here isn't that a course that had been the same for over a decade was out-of-date, the story is that the organization didn't know where to go from there, they still don't know, and the people that were originally passionate about teaching the class were of retirement age, and both the profs and the textbook were retired from the class at the same time. If you want to read more into it than that, then we're reading the tealeaves of university administration decisions that not even the people making them are often in a position to understand.
How do you know that building something more complex than you can understand is necessary, or is a good idea? Feynman said "What I cannot create, I do not understand," which seems like a better approach to me.
I recently ran across Jonathan Blow's effort to create a new programming language, because he noticed that C++ is bloated to the point of buing unfit for purpose, and supposed that he could do better, despite being just one person (or perhaps, because of that). As I understand it, he's interested in working on games with the engine that he's writing in his new language. So the jury is still out on that fool's errand. Of course, he's still using the standard libraries provided by the OS, and he is after all writing an engine (and not just a standalone game) so your point stands.
The change Sussman described that happened in engineering WILL STILL occur. He stated it didn't just happen with programming. It happened across the entire stack from the hardware all the way to software. What happens in this parallel universe? Most people won't spend the majority of there time using the techniques they learned in SICP.. instead they'll be trying to figure out how to get all these arcane libraries to work.
>How do you know that building something more complex than you can understand is necessary, or is a good idea? Feynman said "What I cannot create, I do not understand," which seems like a better approach to me.
How is what Feynman said a technique? He stated a fact about himself. If he can't create it, he can't understand it. So I'm pretty sure Feynman doesn't fully understand how an airplane works because he's never created one. This is not a technique this is fact. That being said, pilots ALSO don't understand how airplanes work. But that doesn't mean pilots can't use an airplane; in the same way I can use a library.
>I recently ran across Jonathan Blow's effort to create a new programming language, because he noticed that C++ is bloated to the point of buing unfit for purpose, and supposed that he could do better, despite being just one person (or perhaps, because of that). As I understand it, he's interested in working on games with the engine that he's writing in his new language. So the jury is still out on that fool's errand. Of course, he's still using the standard libraries provided by the OS, and he is after all writing an engine (and not just a standalone game) so your point stands.
It's a bit of a fools errand depending on how you look at it. If he had a boss, and was working for a company he'd be fucked because it'd take too long. Let's be real... he's more doing that for fun. If your goal was to fly an airplane, do you start off by building one? The only type of person who would do this is someone who does it as a sort of "fun" project.
We all know C++ is a gigantic piece of garbage and we all can sort of visualize the better way in our imagination, but it doesn't change the fact it is still the most practical choice for many applications.
Feynman understood how airplanes work better than I understand how the internet works, and that's reasonably well.
The way it's a technique: first understand it, then you can try to create it.
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.
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).
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.
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.
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)
It bogles my mind how, after years of learning about complexity theory, people who learned CS cannot comprehend the fact that maybe this wonderful world is perhaps more complex than a single person could comprehend.
Do you honestly think someone who just learns python really well without touching SICP can't build a library?
They can. It's just they can't build the library in the idealized lego like modular way that SICP is promoting. This style is definitively better, but it is in no way required.
I think the course has merits. BUT treating engineering artifacts as magic black boxes is the ONLY way we can manage complexity. Attempting to engineer something highly complex while trying to understand everything is a fools errand.