Hacker News Reader

Comment by lisper | Hacker News Reader

This made me sad. Sussman is saying -- almost literally -- that MIT just threw in the towel on teaching actual understanding of how things work and instead went with treating engineering artifacts as magic black boxes that no one, including the people who created them, actually understands, and that this is OK. It is not just that no one does understand them, no one can understand them, and so we're stuck with them because if no one can understand them, no one can improve upon them.

Which is, of course, a self-fulfilling prophecy.

View on HN

I heard a story once, that for a while France was teaching math to kids from first principles. Like trying to teach about number sets before diving into other topics. It was hard and abstract. They stopped.

Instead they do what most people do: they teach concepts with a lot of papering over of the details. Then, once people have a stronger grasp on things, they go into first principles. It’s easier to understand commutativity if you can do addition already!

Similarly, you can teach people black box stuff at first, then dive into details. it’s ok to use a high level language before understanding how to run stuff on a machine.

Let’s not forget something important: Python and Lisp are basically abstracting away the important machinery anyways! Sussman has said it himself, computer science is about computers the same way that astronomy is about telescopes.

And of course it’s not like SICP is the only class all these people are taking. One intro class. Meanwhile people get to do fun and engaging shit while learning. And they will learn more stuff later!

Sure, but we're not talking about elementary school here. I think Python is a fine language for teaching first graders about programming. But this is MIT. If MIT students aren't expected to understand how things work under the hood, what hope is there for the rest of humanity?

What I lament here is not the fate of 6001 specifically. It probably was outdated and in need of a refresh of some sort. What I lament here is the rationale that Sussman gives and apparently buys into, that the new approach is acceptable, and it's acceptable because treating things as magic black boxes is an inherent feature of modern engineering. No one understands, no one can even be expected to understand, and that's Just The Way It Is, and it's OK.

Well, no, it's not OK. People can and must be expected to understand because the magic black boxes aren't actually magic. They were created by mere mortals not that long ago, some of whom went to MIT and read SICP. If SICP is dated (and it is) the thing to do is to update and improve it, not to discard it.

Isn’t this literally the first class you take? Like there are. 3.5 years left to learn all the other shit? This is a class for people with little to no programming experience. And it will include many people who will not be programmers (shocking I know).

“Give people tools to do shit” does not preclude “learning all the details”. And it’s not the last class people take!

It also expected that you have considerable earlier knowledge, just not on programming itself (For example, at least some exposure to calculus is expected, as that's what some early examples use).

The early lessons of SICP are more like teaching what's 2+2 in my opinion (substition model of function application, for example).

In terms of practicality of the content, honestly I'd say SICP was at least as bad as most intro lectures I've seen, and honestly should stay but be combined with something like companion labs with "battery included" builds to play with things.

In the OP video, Sussman mentions that SICP was one (the first) of four core courses in EECS that introduced essential concepts in programming, circuits, signals and systems, and computer architecture. I think all four completed by the end of year two and were prerequisite for all junior/senior EECS courses thereafter.

It's hard to imagine the EECS program does not still require this material to earn a BS in CS or EE, but requiring four prerequisite courses probably interfered with non-EECS students who wanted to take junior/senior level EECS courses but did not want to have to run the "gauntlet of four" before doing so.

The problem is that MIT used to be the high road for engineering and now it is a prestige degree and grants access to various roles etc. They gave in to the bureaucrats because it was inevitable that things would go that way anyway. At least they put the bullet in SICP and had a hand in the new curriculum.

Now there is a generation of software engineers worried about losing their jobs to ChatGPT because they resigned to the fact that ChatGPT can probably glue things together better than they can long before they do the necessary work to understand ChatGPT from first principles. But this is branded as elitism, highly anti-bureaucratic.

Unfortunately the view that we don't understand our own tools, while premature, will come true soon enough.

Ask somebody at DeepMind exactly how AlphaGo beat Lee Sedol. At the end of the conversation, you will get a blank look. Don't even bother asking what inspired SD or DALL-E to generate a particular image.

IIRC the quote is from Dijkstra, not Sussman?

Sorry, I believe I heard Sussman say it (and they probably correctly attributed it), you’re likely right

Do you have a source for France teaching mathematics from first principles?

Sounds like you are thinking of “New Math”, which was tried in many Western countries including the US: https://en.m.wikipedia.org/wiki/New_Math

In many ways SICP was from the same intellectual tradition as New Math.

As some one who loves SICP and first principles, I had a new math curriculum and loved it. Being able to derive the laws of arithmetic is usually a lot more useful than just knowing some particular instance of calculation.

To be sure, I also did math contests in high school to bump up my speed at math, and in software will do timed speed tests (self devised on certain types of small tasks) also to bump up my speed in a particular language.

You do know how the "first principles" came into place, right?

They had arithmetic first. People counted chickens, sheep, coins first. Then, mathematicians invented more abstract rules that incidentally were able to derive arithmetic, and called them "first" principles. Chronologically they came last.

I love axiomatic set theory and the history of maths and science. I love knowing how technology developed over the last few thousand years, Egyptian land measuring and trade accounting etc., and as much quantum field theory as I can understand (not that much, it's very hard). I like knowing about DNA and the history of animal husbandry. Deriving calculus and complex analysis from ZFC gives us tremendous intellectual power as far as the essentially and inherently true. Understanding how our culture has been lifting the vails of ignorance thru science and experiments and cultural evolution and so on is also important.

Sounds apocryphal to me.

You can read some of the story of France's experiments with Bourbakism in elementary education here, under the section about pedagogy:

https://en.wikipedia.org/wiki/Andr%C3%A9_Lichnerowicz

tl;dr: New Math began in France, and they were the first to recover from it.

I think it’s a question where do you start.

It the late 90’s computers and operating systems were already so complex that you did not start CS curriculum by understanding how they really work. You took those for granted to get to the interesting topics first and then later went for the details.

And what exactly were "the interesting topics"?

I was a grad student in the late 80s and early 90s, and I remember having classes that took this approach. It took me years to recover and repair the damage. Understanding how a real OS works is not actually that hard. It's actually easier if you start with that than what I went through, which was a bunch of abstract academic bullshit that left me with no idea how it was supposed to make contact with reality.

In the late 90s? Surely OOP, code re-use through encapsulation and inheritance, the relational model (though on the way out), and making XML of all the things should have been some of the "interesting topics" at this time.

The best way to understand how an operating system works is to build a simple one yourself. But you can't build one before you have learned how to program.

I believe it's a bit similar case with many other topics nowadays. Having some basic Python skills unlocks opportunities in other fields, such as machine learning or robotics.

Exactly this.

As a fulltime functional programmer... I cannot ask university graduates to learn functional programming to the depth of SICP teaches.

Even the "Scala redbook" is 50-100 hours of work.

Junior graduates, have so, so, so much information to cover.

Bashing a "good" development workflow/flow state into them. Communicating with correct nouns. There's SO MUCH work for them to do. Plus, output they're paid to produce.

Functional Programming, manipulating higher order functions, is useful for reasoning about truly complex concurrency.

Hard to justify the time investment otherwise.

There's SO much work to do in software development.

SICP is better for full-time programmers with some experience than it is for recent HS grads, however motivated they might be.

As I understand it, no freshman class ever made it through the full text anyway, so it was always understood that you can go further later, and come back to it, similar to how much undergrad calculus is taught.

And yet the best stuff is in the last chapter.

So true.

The part where you write a virtual machine followed by a Scheme compiler for said VM? It's so cool.

This is what everyone is saying, Sussman and MIT included... But it is not true. It is just how Windows is stitched together + no sources. And now systemd in Linux - it was just first big application of cgroups and noone else was doing serious work with them. RedHat was realy leading force.

Everything is build from pieces and pieces are explainable. Ocasionally you have hard algo but still you can understood what it do becouse it do exactly what simpler algo for that problem do.

Btw. there is not so much material in SICP - some tricks like lazy functions implementation and symbolic math. From that point of view it's good introductory course to compilers building :)

// engineering artifacts as magic black boxes ... //. Alas, that ship has sailed a long, long, time ago. As far as the average programmer goes, CPUs have been black boxes since before they were born.

There are just too many people adding too much value to keep up with everybody. Programming is changing radically (as it does every 10 years or so anyways) and I'm actually impressed that Sussman has the vision and courage to move on.

Actually, I'm not at all convinced that a lot of value is being added. Yes, there is a lot of change, but it's far from clear how much of that change represents actual progress. Instead, you get a lot of latest-and-greatest which, upon sober reflection turns out to be bullshit, to be replaced by another round of latest-and-greatest. Lather, rinse, repeat, in a cycle that takes about 5 years or so. CORBA. UML. Agile. OO. And a lot of the churn is because too few people actually understand the fundamentals, and so very few people recognize the bullshit for what it is until it has consumed vast amounts of resources.

Wait till GPT-10 comes around and the primary purpose of CS jockeys is to use it to write programs that make absolutely no sense but they just work.

Happily, the insolubility of the halting problem provides guarantees full employment for software engineers until the end of time, because "just work" is undecidable.

my junior devs have been doing that on my teams for years anyway

Sussman is wrong. Happens to the best.

I suspect Sussman told only the more palatable part of the story. Students pay for those degrees, so they have a big say in what they buy. It's likely that both EECS majors and non-EECS majors who took EECS courses believed the four course EECS basic prerequisite sequence no longer served their needs as well as it once did. Profs have only so much power to shape minds, especially if the minds are paying over a quarter of a million dollars for the only product the profs are selling.

The very way he tells the story practically lampshades all the behind-the-scenes intrigue that will never see the light of day.

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.

> 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.

It 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.

It'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.

>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.

Sometimes 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.

I 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.

The 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.

>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".

> As far as I know, engineers still learn physics.

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.

I believe engineering majors at any prestigious institution will be up to date on every one of the currently-known quarks, yes. If your point is that it's not the same as a physics major, that's also true.

Linux 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.

You 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.

Yeah, agreed, but sadly VPRI blew up for an unknown reason and the work was never completed or properly published.

I 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.

I just regurgitated Sussmans position from the article/video...

Sussman co-wrote SICP.

Your 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.

Sussman 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?

He 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.

Bro, let's say the world embraced FP and it was the dominant paradigm and the techniques and patterns of SICP were taught in EVERY computer science curriculum.

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. Speaking of C++, Rust was(and may well be) a replacement for C++ started by mozilla.

While rust was a great contribution to the community it ended up being pretty bad for mozilla from a business perspective so they dropped it. For mozilla yes it was a fools errand. For the engineers working for mozilla to develop rust it was a smart choice to work on cool shit on someone elses dime.

First of all, pilots absolutely do know how airplanes work, and they make you study the aerodynamics and pass a course before you get your first hour of flight time, even as a student going up.

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.

>First of all, pilots absolutely do know how airplanes work, and they make you study the aerodynamics and pass a course before you get your first hour of flight time, even as a student going up.

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.

Conducting a charity for the community is Mozilla's mission, so that part worked out. How good it will be for the community remains to be seen, at least it is probably replacing C++ on a lot of new projects.

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.

There's probably a million lines of code in your self driving car today. You might think knowing high school physics help you become a better driver, but you're delusional if you think you know how your modern car works.

I certainly do not own or want a self-driving car, at least not until they work!

High school physics certainly does help you understand momentum, which is the cause of all crashes.

Majority of drivers don't need to understand physics to drive. It doesn't help.

Instead humans rely on visual intuition, which everyone has with or without learning physics.

Mozilla's mission wasn't to conduct charity to the point of self annihilation which is what would've occured had they not spun off the rust division. Non-profits cannot sustain themselves without positive cash flow. Just look at Ikea, they're a non-profit.

>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 depends what you want to do. If you want to work on problems that we know how to solve and that we have solved many times, then the npm xenobiology skill set is sufficient; if you want to do things we haven't done and don't know how to do, it isn't. I've acquired knowledge by poking at libraries and databases and OSes, and those are sunk costs. Apart from the instrumental value at the time, most such knowledge has had no lasting or further use to me. I've acquired other knowledge and skills from books including SICP, and those have continued to pay lifelong dividends with compounding interest over decades.

Domain knowledge can shift but not always. npm and javascript are around to stay. Same with most of the linux API.

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.

You're in good company, that's an extremely popular perspective. Those of use who are more generalist often have to find our own ways. The rewards are usually worth it.

>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

see my remark above

Planes flying along with siphons are bad example to ask theoretical physicists - most of them wouldn't be able to give you the right answers. Feynman was closer than most because he did think about things like what would happen if a rotating sprinkler sucked in water, etc.

All you need is very rudimentary fluid dynamics, some vague idea of attack angle, and the conservation of momentum with a compressed column of air under the plane. I think most theoretical physicists could come up with that.

The siphon one is funny because many people will start with air pressure, which is wrong. I'm wondering if you have some experience asking people these questions?

Yes, first and second year undergrads when I taught intro labs and diff eq.

My understanding is there is a rather tortuous explanation involving viscosity (for lift and wing shape)

Like DOOM?

It feels good to be naïve.

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.

Well that's certainly a perspective, but you don't know what you don't know.

Those 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.

As 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.

> Sussman is saying -- almost literally -- that MIT just threw in the towel...

The truth would have been more embarrassing: he just got sick of all the fucking parentheses.

Reply on news.ycombinator.com