SICP starts with abstraction, and gets there via closures, which are an abstraction that encompasses and goes beyond everything that OOP can do with regards to encapsulation. You can do as much mutation as you want in Scheme, SICP uses this to explore some ideas. It does take a primarily SSA or non-mutating approach, but it's a far cry from hairshirt-wearing pure FP. I mean, the book has you simulate a register machine. It's not afraid of mutation.
Python is fine, and if they used the Scheme-like subset of Python, it'd be a similar book. But they picked it (the committees that Sussman mockingly describes as doing the things committees do) because of the libraries. So the idea is that you'll be doing "science" on libraries, which replaces (in the 90s) having students reading man pages (look how out-of-touch Sussman already sounds here! nobody reads man-pages anymore, now SO is preferred, it being better to get a solution than to consult a reference).
Sussman is not praising the experimental approach, where you need to probe your libraries like a science experiment before you can use them, where now you need to do science before you can do science, he is mocking it.
People using shitty libraries with shitty documentation, and building systems on top of these foundations, are doing science that didn't need to be done, solving problems that didn't exist before those choices were made. It's frustrating work that gets in the way of real work, that is, work that engages with the complexity inherent in the domain. It's an inefficiency that is self-imposed, not so much by the individual programmer, but certainly by the industry as a whole deciding to go in this direction.
>Sussman is not praising the experimental approach, where you need to probe your libraries like a science experiment before you can use them, where now you need to do science before you can do science, he is mocking it.
He neither praised or mocked it. He just stated it's the status quo, and he quit teaching SICP because it was no longer relevant. If he mocks the science approach I'd imagine he'd continue teaching the course.
>People using shitty libraries with shitty documentation, and building systems on top of these foundations, are doing science that didn't need to be done, solving problems that didn't exist before those choices were made. It's frustrating work that gets in the way of real work, that is, work that engages with the complexity inherent in the domain. It's an inefficiency that is self-imposed, not so much by the individual programmer, but certainly by the industry as a whole deciding to go in this direction.
This is the only direction it can go because as frustrating as it is, it's BETTER then building from scratch. You can't hold a job without using libraries this I guarantee you, if you're building all your shit from language primitives then you're not going to employed for long.
>SICP starts with abstraction, and gets there via closures, which are an abstraction that encompasses and goes beyond everything that OOP can do with regards to encapsulation. You can do as much mutation as you want in Scheme, SICP uses this to explore some ideas. It does take a primarily SSA or non-mutating approach, but it's a far cry from hairshirt-wearing pure FP. I mean, the book has you simulate a register machine. It's not afraid of mutation.
SICP doesn't go beyond OOP at all. It's all abstractions that can be done with OOP languages. SICP overall teaches restrictive patterns of FP to promote the math like programming style. Yes it does mutation but that's not the main theme.
Closures aren't a big deal either, OOP languages have lambdas now and the pattern is more or less isomorphic to object instantiation.
He's not saying that the SICP was no longer relevant, but that the people (e.g. administrators) wanted something else.
You'd be surprised what people can do without libraries.
SICP covers patterns, like in chapter 3 with the `make-account` example, that can be used to do things that might be difficult in OOP languages. It doesn't go into much of that, because it's not what the book is about. Anyway, whether you regard the SICP style as something FP-like and restrictive is a matter of perspective, to me it's neither one.
No watch the video. He quit and then the head of the department ended up teaching it for 10 more years. The department did not force him out or force him to change.
I know tons of great things can be done without libraries. But logically speaking programming is simply too complex for most people not to use libraries in their jobs.
Sicp teaches restriction and that's better. You want to avoid mutating state in your code as much as possible..if you can't avoid it you need to scope it and segregate it. This is the ideal technique to maximize modularity and code re-use.
What I'm saying is this, although it's an ideal most programmers just end up stringing together a bunch of procedures and it still works. It's just not modular. More important for the programmer is that they can figure out how to utilize library code. Elegant code is less relevant nowadays. That's why many programmers can get away with not even knowing about sicp.
We both watched the same video. From my perspectice I see a subtext of the administration having its own (dysfunctional) process and getting a suboptimal outcome that's coming through very clearly. I mean, he admits the department still doesn't know what to do. He doesn't say that the bureaucracy went its own way and did something incoherent, because he doesn't need to. Ask any grumpy old professor to watch that video and say whether or not he's griping about his administration, and they won't even need to watch the video, it's just assumed. It's not important that you agree with me here, I'm just sharing my perspective. You can also watch the video and see that he's just repeating the departmental story, which is the first-order meaning of what he's saying, and it's not wrong.
They taught that class from 1980 to 1997. Nobody can say it didn't have a long and unexpectedly successful run. It's understandable if they were legitimately sick of teaching the same material.
Your reading too much into it. Literally they taught the SAME course for 10 years after he left? That action doesn't even MESH with your logic. MIT wand the admin WANTED to continue SICP. It's Sussman who wanted to stop.
No, they taught it from 1980-97 with the original instructors, then for ten years the department head taught the introductory course (from unspecified materials, possibly different), then they went to Python with another set of new teachers. Hard to know from the outside what the admin wanted.
Python is fine, and if they used the Scheme-like subset of Python, it'd be a similar book. But they picked it (the committees that Sussman mockingly describes as doing the things committees do) because of the libraries. So the idea is that you'll be doing "science" on libraries, which replaces (in the 90s) having students reading man pages (look how out-of-touch Sussman already sounds here! nobody reads man-pages anymore, now SO is preferred, it being better to get a solution than to consult a reference).
Sussman is not praising the experimental approach, where you need to probe your libraries like a science experiment before you can use them, where now you need to do science before you can do science, he is mocking it.
People using shitty libraries with shitty documentation, and building systems on top of these foundations, are doing science that didn't need to be done, solving problems that didn't exist before those choices were made. It's frustrating work that gets in the way of real work, that is, work that engages with the complexity inherent in the domain. It's an inefficiency that is self-imposed, not so much by the individual programmer, but certainly by the industry as a whole deciding to go in this direction.