5 ms·
This is sad But not because of What you say. I think the course has merits. BUT treating engineering artifacts as magic black boxes is the ONLY way we can mana
by kilgnad 4y ago
This is sad But not because of What you say.
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.
- lisper 4y ago> treating engineering artifacts as magic black boxes is the ONLY way we can manage complexity 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.
- kilgnad 4y agoIt is the only way. 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.
- Jtsummers 4y agoIt's not the only way. The alternative is to recognize when complexity is a consequence of extraneous structure versus the things actually needed for the system. Rube Goldberg devices are complex, and the bulk of their complexity is spent (though intentionally humorously) to accomplish simple tasks. Many, if not most, real world software systems are the same way. They're Rube Goldberg devices but done accidentally rather than intensionally through the accrual of many decisions (both good and bad) over years and decades with no or insufficient effort to distill and simplify them. 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.
- kilgnad 4y ago>Treating everything as "magic" black boxes as you want is tantamount to sweeping dirt under a rug. 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.
- inimino 4y agoSometimes you don't need something as complex as existing commercial solutions. 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.
- kilgnad 4y agoI mean is the standard wisdom wrong? The standard wisdom is right. 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.
- inimino 4y agoThe standard wisdom is absolutely right. 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.
- armitron 4y agoLinux is a bad example, complexity-wise, being based on the behemoth of terrible design that is Unix. 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.
- kilgnad 4y agoYou think elegance in design can negate complexity? Complexity has no ceiling. 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.
- wrycoder 4y agoYeah, agreed, but sadly VPRI blew up for an unknown reason and the work was never completed or properly published.
- inimino 4y agoI think this is a reasonable position, but the reason people are downvoting you is it's a defeatist position, and there's reason to be more optimistic.
- kilgnad 4y agoI just regurgitated Sussmans position from the article/video... Sussman co-wrote SICP.
- inimino 4y agoYour words were "the only way" and "fools errand", what I actually see in the clip is that the course was due for a refresh, both the original professors quit, the administration had no idea what to do after that, and the department head had to teach it while they figured it out, meanwhile committees were formed and in the end Python won because ("for reasons no-one understands") it had all of the libraries.
- kilgnad 4y agoSussman exactly said what I said. He quit because engineering changed, the course was no longer relevant. 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?
- inimino 4y agoHe says "although still important intellectually, it was no longer relevant to the kinds of things people needed." What people? The students? Working programmers? Companies? The university administration? Notice how he tells the anecdote about quitting "I suppose Hal and I basically walked into the department head's office sometime in the end of 97 and said, 'We quit. On this. Okay? Figure out what to do'.", and then the department couldn't figure out what to do. 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.
- JonChesterfield 4y agoThose magic black boxes need to be implemented too. Relying on the strategy "someone built them in the before times so we don't need to worry" has severe failure modes.
- kilgnad 4y agoAs if the techniques in SICP was the only way to build those black boxes? 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.