[HN Gopher] Sussman Explains the End of SICP
___________________________________________________________________
Sussman Explains the End of SICP
Author : smitty1e
Score : 107 points
Date : 2023-02-04 19:53 UTC (3 hours ago)
(HTM) web link (irreal.org)
(TXT) w3m dump (irreal.org)
| jpe90 wrote:
| Before I read SICP I had used OOP, functional programming, and
| lazy evaluation to varying degrees.
|
| In school and independent study I learned how to use those
| concepts to write programs, but I didn't really have a clear
| conceptual understanding of what they really are or how they work
| under the hood.
|
| I read SICP to learn more about lisp and was surprised to learn a
| lot about all of those concepts as well. It's all explained very
| clearly and there are code examples you can toy with to wrap your
| head them.
|
| I found it such a gratifying book to read through. And I really
| regret spending time learning Haskell before reading it, so much
| needless head scratching.
| neilv wrote:
| A few unfortunate things about software development practice
| lately being mostly plugging together components:
|
| * People make huge things out of often poorly-chosen components
| and frameworks.
|
| * People 'engineering' the system don't actually understand how
| it works.
|
| * Much/most of your time is spent figuring out a pile of
| library/framework _bureaucracy_ that someone else created. Not
| even useful concepts that you are smarter for learning, just
| figuring out some muddled version of an old model, the particular
| forms of made-up incantations around, and discovering and working
| around the shortcomings of their design and implementation. Often
| you find the thing you 're using is actually poor design and
| implementation, and you might feel _stupider_ for having learned
| its bureaucracy.
|
| * This plugging together of components can be done well, and
| sometimes is, but it's also a little too convenient for
| developers who think software engineering is like turning in
| homework assignments in school. In which the goal is to get your
| homework (sprint task) past the grader (PR approved), and that's
| the end of it (what's analysis, planning, and architecture?). So
| you do Web searches of Stack Overflow (and maybe some Copilot
| open source laundering), to slap together some components, and no
| one even seems to expect you to know how it works. Where's the
| pressure to do software engineering?
|
| * Perhaps _some_ of the churn of these components is due not to
| technical /business merit, but to the fact that putting the
| latest possibly-rising component on your resume can improve your
| marketability in an employment environment oriented around
| frequent job-hopping. It's a symbiotic relationship between
| people who spit out "new" components to plug together, and people
| who twist projects to put the new thing on their resume.
|
| That's not exhaustive; just a few off-the-cuff that are annoying
| this weekend. :)
| klodolph wrote:
| > People 'engineering' the system don't actually understand how
| it works.
|
| The problem is that the complexity of systems is growing beyond
| the capacity for people to understand in the first place, and
| the solution is to make it possible to do meaningful work in
| systems where people only understand a part of it at a time.
|
| In a way, software engineering is catching up with the rest of
| the world, which already operates that way. When you build a
| skyscraper or a bridge, maybe you have a structural engineer
| who understands how concrete and steel work, and you have a
| geotechnical engineer who understands how soil and sand work.
|
| My personal observation is that programming has long attracted
| people who like the kind of absolute certainty that you can
| have in smaller programs, where the behavior of programs is
| known to a mathematical certainty. If you're careful, you can
| build larger and larger programs this way... but at some point,
| the program or system is too large, and you are forced to think
| about things in statistical terms. You have to accept that your
| program has bugs in it. Some people who are otherwise brilliant
| programmers are simply too uncomfortable with the jump from the
| certainty you have in small programs to the known uncertainty
| you have in large programs & systems.
|
| It used to be you could make a decent living working within the
| certainty of small programs, but nowadays you are going to
| _have_ to plug things together.
| zozbot234 wrote:
| Programming in the large does not necessarily involve
| uncertainty. A CPU microarchitecture or an OS are large,
| complex systems, but we expect them to perform reliably.
| Well-understood modularity boundaries are of course quite
| important for this. It's only when we expect systems to do
| things that they weren't designed for at the outset (such as
| keeping private data from being accessed via side-channels,
| if you're designing a modern CPU) that real problems exist.
| makeitdouble wrote:
| A CPU does error check and handle cases where it ends in a
| state that was not intended. OS do that in spades, and we
| wouldn't accept an OS that didn't embrace it has bugs and
| stuff go wrong.
|
| At that scale, the question isn't wether there's behavior
| we didn't understand, it's how to try to make the best deal
| with them.
| klodolph wrote:
| > Programming in the large does not necessarily involve
| uncertainty.
|
| Can you provide some reasoning to support this, or
| elaborate? This seems obviously false to me, maybe I don't
| understand what you're trying to say here.
|
| When we have goals like wanting to keep private data from
| being accessed via side-channels, there are some major
| problems preventing you from being certain about it. You
| are probably not going to be certain that you know which
| data is private and which data is not private. You are
| probably not going to be able to enumerate all possible
| side-channels--new ones keep getting discovered. Then,
| suppose you've found a way to mathematically express what
| data is private and what side channels are and what it
| means to leak data, do you expect to somehow apply formal
| methods to the entire damn system?
|
| Maybe someday. Not today.
|
| Today, you apply defense-in-depth strategies. Mitigations
| upon mitigations upon mitigations. You try to keep any one
| bug from bringing down the whole system. You do analyses of
| different types of bugs and see how they affected the
| system, and figure out ways to make the system more
| resilient.
| sirsinsalot wrote:
| I think this is, and bare with me, because of the infiltration
| of radical individualism since the 1960s.
|
| Donald Trump can fake his way to president, anyone can build a
| SaaS and fake their way to money with a loose collection of
| APIs. Hustle culture outweighs solid fundamentals and rigor.
|
| Superficial, yet effective. Lacking rigor but marketable.
| Become a developer in 4 weeks (seen lots of that on YouTube).
| Go to a boot camp and learn Javascript. Fake it until you don't
| need to make it. Don't learn about weights and activation, just
| load it off HuggingFace and make an amazing landing page that
| ignores accuracy.
|
| It's not a world where SICP fits. This makes me sad.
| tpmx wrote:
| Back in the mid 90s when I studied CS/EE (in Sweden) it seemed
| like LISP (and SICP) in undergrad education was primarily used as
| tool of bringing everyone down to the same base level, so that
| the 50% of students who had already spent ten years programming
| iteratively wouldn't have a gigantic advantage.
|
| I dropped out after two years partly because of this. I was
| learning so much more at my part time job - it was insane how
| good that job was at learning programming. It set me up for life.
| I can't really summarize it without it sounding made-up, I just
| realized.
|
| (This problem has nowadays been fixed at my "alma mater". I think
| they're doing Python now.)
| JW_00000 wrote:
| My experience is the opposite: I only appreciated the marvel of
| SICP (at least that's how I experienced it at the time) because
| I already knew other programming languages. Something "clicked"
| that didn't click before. I have the feeling that students with
| no previous programming experience didn't feel this.
|
| If that's true, it also makes sense to start with Python and
| move SICP to later in the program.
| lisper wrote:
| 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.
| rtpg wrote:
| 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!
| bitwize wrote:
| Because real software engineering is less about building things
| up from first principles and more about combining and integrating
| pieces of software that already exist. Sorry, but it's the way of
| the world.
| DennisP wrote:
| Maybe so, but it's starting to look like AI can take over a lot
| of that combining and integrating.
| lanstin wrote:
| It is often true, but also see http://steve-
| yegge.blogspot.com/2007/06/rich-programmer-food...
|
| I recently was with a group of dev ops folks that had written a
| 100k of terraform code. It worked great, nice improvements for
| consistency of cloud deploys, and decreased time to implement
| and all that.
|
| Problem was when terraform would implement breaking changes in
| new versions. We had so much code to fix, the group just wanted
| to stay back at version N - 1. But I knew where that would end,
| in five years they would have buggy unsupported old terraform
| needed some big heroic project to upgrade, with risk and so on.
|
| So I wrote a simple Python script that was a recursive descent
| parser/transformer patterned on expat with callbacks. It was
| able to transform all the code and bump the terraform version
| at the latest version.
|
| It took a while to write, but was tremendously fun, gave us a
| powerful tool for transforming and therefore owning the 100k+
| LOC of terraform, which other wise threatens to become a
| congealed unmaintable blob.
|
| Even writing custom off the shelf services can have big
| payoffs, in efficiency or in operational ease. There are two
| ways in which the body of existing software is full of good
| solutions; there are a ton of turn key solutions, from Hadoop
| to NoSQL to Airflow to the other fifty nine Apache projects,
| Kafka, etc. etc. etc.
|
| Also, modern languages have so many excellent facilities for
| highly scalable, cheap and reliable software that is shall we
| say designed precisely o meet a given customer need. The custom
| solution can be faster better and cheaper than the turnkey open
| source system, which usually has a high cost of complexity and
| a high cognitive burden for ops to understand the configuration
| space and so on.
| fdgsdfogijq wrote:
| Even more, usually the biggest mistakes are made by not "using
| what is standard", any type of programming from first
| principles is usually a huge mistake. People generally arent
| smart enough to build something from scratch in a way that
| beats whats already been tried and tested
| mvc wrote:
| When I was just getting started as a programmer, everyone was
| using Apache. Fortunately people who _do_ stuff don 't spend
| their time listening to the naysayers on hn.
| varjag wrote:
| To make an informed choice whether to apply a first principle
| solution you have to understand said first principles.
| Otherwise it's just an excuse for incompetence.
|
| And to internalize the principles you have to at least use
| them in a didactic setting.
| whartung wrote:
| I was talking to our junior developer one day. He was
| working on a Delphi project of some kind.
|
| I asked him how it was going, and he said it was going
| well. But that he was confused about some things.
|
| I asked them what they were.
|
| He said, paraphrasing, "What's the difference between disk
| and RAM?".
|
| On the one hand, it's great that someone without such
| fundamental understanding was able to accomplish something.
| On the other hand, it was a bit disturbing.
|
| I've run in to several folks who do not understand first
| principles, and some times are combative when I explain how
| I "know" something "can't work" or "didn't happen". I'm
| sure we've all heard those things. "What about <absurd
| thing>?" "No. Just... _sigh_...no. "
| lanstin wrote:
| Tho the difference between disk and RAM is collapsing. It
| used to be (90s) bog standard advice to never write to
| disk in the call path of a customer request. Now, there's
| hardly anything that isn't writing to disk all the time;
| but not spinning platters, just SSD.
|
| So maybe their confusion is less bad than it seems at
| first? Maybe?
| layer8 wrote:
| While the numbers are changing, there are still 2-3
| orders of magnitude between RAM and SSD latency:
| https://colin-
| scott.github.io/personal_website/research/inte...
| [deleted]
| EFreethought wrote:
| Yes, a lot of us just link black boxes together. But what about
| the people who make the black boxes? How smart are they?
|
| Maybe we all do not have to know first principles. But somebody
| does.
|
| And if MIT won't teach first principles, who will?
| vijayr02 wrote:
| This reminds me of an Asimov story:
|
| https://en.wikipedia.org/wiki/Profession_(novella)
| ThrowawayR2 wrote:
| So who are the people building the pieces of software that
| ordinary developers are combining and integrating? The next
| Linus Torvalds, Bjarne Stroustrup, John Carmack, etc. is going
| to need to know the first principles like the back of their
| hand to build the next generation of operating systems,
| languages, and platforms. That's "real software engineering";
| what most developers do is merely coding.
| klodolph wrote:
| The curriculum isn't being removed from existence, it's just
| being removed from the introductory classes. There are
| probably more people making their own OS from scratch in 2023
| than in 1993 anyway--we have many more people with access to
| computers, and tons of free resources online for people who
| want to learn computer architecture, operating systems,
| assembly language, etc. This is not some kind of hypothetical
| supposition that "there must be people out there"; I know for
| a fact these people are out there because I keep meeting
| them, and some of them are damn young.
|
| The idea of genius men making stuff from first principles is
| just some kind of Hollywood schlock version of programming
| anyway. It's the stuff you see on NCIS when they make an
| episode about hackers. All the good stuff has been a team
| effort, even if it starts out as a solo project. Maybe with a
| few exceptions like cURL.
| syntaxfree wrote:
| So people (MIT students, the elite) shouldn't learn Real
| Analysis because Wolfram Alpha?
| simplotek wrote:
| I think you're missing the point. Everyone is free to learn
| real analysis, and it's ok if it's a part of the standard
| curriculum.
|
| But if you're aiming to provide the best education to future
| professionals so that they are able to excel at their field,
| you'd serve them far better if you taught them how to
| effectively use Wolfram Alpha.
|
| The truth of the matter it that the bulk of the work in
| software development, and what makes more economic sense,
| lies in growing a system through accretion and adopting
| higher level components developed and maintained by third
| parties.
| otabdeveloper4 wrote:
| You're decribing a "trade school", not MIT. Which is fine
| too if that's what you need, but serves an entirely
| different purpose.
| simplotek wrote:
| > You're decribing a "trade school", not MIT.
|
| Nonsense. MIT engineers don't waste their time thinking
| about assembly instructions when they are tasked to
| design a distributed system. Competent engineers know how
| to switch to high-level concepts where they make sense.
| eps wrote:
| Heh, no, not nonsense.
|
| The difference between trade schools and universities is
| in the depth of fundamentals. Always has been, still very
| much is.
| andreistan26 wrote:
| Excel at what? You need to build a strong foundation in
| order to innovate and to discover new stuff.
| phlakaton wrote:
| As always, the question is: a strong foundation in what?
| And why?
| simplotek wrote:
| > Excel at what? You need to build a strong foundation in
| order to innovate and to discover new stuff.
|
| I agree. The problem is that you have a gross
| misconceptions about what "strong foundation" represents
| in this day and age.
|
| I knew guys who fail to stop and think about
| "foundations" and instead use that as a scapegoat to
| shoehorn their gatekeeping logic and as a form of ladder-
| pulling. It's the kind of character who think that
| playing trivia games is a good way of asserting whether a
| candidate is a competent engineer.
| Keyframe wrote:
| It's more like mechanical engineers shouldn't learn much/any
| about abstract algebra because now we have (newly born)
| mechanical engineering doing mechanical engineering instead
| of mathematicians doing it.
|
| You don't need to do the theory in order to understand the
| practice anymore.
| rbongers wrote:
| I definitely agree about how it may appear to young programmers
| that they're casting magic spells. I had the fortunate experience
| early on of building my own virtual CPU and RAM, then I learned
| assembly, then C, then algorithms, then OSes, then about Unix.
| I'm not trying to toot my own horn, I've always been a little
| slow and struggled through this material. However, learning from
| the bottom up has granted me a lot of insight into how things
| work and an ability to learn pretty much anything software
| development related. SCIP has a different approach to "bottom-up"
| learning than I took but I think it still applies. Maybe with all
| the tools out there not every programmer needs to learn from the
| bottom up, but _someone_ needs to learn how everything works to
| build good tools, and if you can 't learn that from MIT, I don't
| know where.
| zozbot234 wrote:
| > I had the fortunate experience early on of building my own
| virtual CPU and RAM, then I learned assembly, then C, then
| algorithms, then OSes, then about Unix.
|
| I suppose what's missing from that experience is the reality of
| programming "in the large", where modularizing code and
| creating well-defined interface boundaries becomes quite
| critical. The easiest step forward coming from C would be
| learning something like Rust - or, historically, C++. This is
| when the broad high-level patterns and approaches that SICP
| discusses at length in a theoretical way become practically
| useful.
| markus_zhang wrote:
| Maybe I'm not smart enough, but I consider building CPU from NAND
| gates, writing a simple OS for the machine and writing a complier
| for a C subset for it can do a lot more about de-mystifying
| computing. I tried twice to read SICP but I don't get the hype. I
| guess it's fine to not read it after all.
|
| Disclaimer: I still consider nand2tetris too trivial for the de-
| mystify work. A full project on the same scale of UTokyo's CPU
| project [1] is a lot better.
|
| Disclaimer: I only completed the hardware part of nand2tetris so
| I don't claim that I have done the CPU+OS+compiler stuff. But I
| do find it a lot more interesting than SICP.
|
| [1] https://www.is.s.u-tokyo.ac.jp/isnavi/practice01-01.html
| userbinator wrote:
| It could be argued that the industry does not want people to know
| too much of the foundations, because the knowledgeable are harder
| to sway with fads and superficial arguments or keep under
| control. They want programmers to become fungible "resources",
| while something like SICP espouses the complete opposite
| philosophy.
|
| That said, I think SICP preaches a bit too much about
| abstraction, although that's something a lot of programming texts
| do, and overabstraction is quite endemic in the industry even
| without SICP.
|
| The fact that SICP also became a meme --- which you'll notice if
| you search for images of it --- may be another reason why it
| seems to have a cult following. The whole "anime girls holding
| programming books" meme started with SICP.
| veltas wrote:
| This change is necessary because young people aren't interested
| in the fundamental abilities of computers, instead they're only
| interested in the applications. If you grow up playing video
| games and using social media then you won't appreciate
| programming if you're made to start from the bare metal. There is
| a certain kind of person who's interested in this, but most
| people instead are better motivated by demonstrations that relate
| to them. Robotics is cool regardless and allows the kids to
| "smell blood" early on, it lets them be dangerous, and then maybe
| one day some of them will be motivated enough to slow down and
| understand the old principles that underlie all of this.
| simplotek wrote:
| > This change is necessary because young people aren't
| interested in the fundamental abilities of computers, instead
| they're only interested in the applications.
|
| I don't think it's fair to spin this on lack of interest. My
| take is that young people are smart and they are goal-oriented,
| and their goal is to actually provide value instead of wasting
| time with irrelevant low-level details that matter nothing and
| are practically meaningless.
|
| And they do it just like the generation before them did. No one
| bothers with knowing how to put together opcodes once they got
| around to use compiled languages. Some people do quite well for
| themselves in the software engineering field without touching a
| compiled languages even once, and thus can't be bothered with
| subjects like linking, how to create and consume static lib,
| rpaths, finding symbols, etc. You can have high-paying careers
| in software engineering and never be bored with the difference
| between a stack and a heap. Popular tools like the StatsD
| daemon are written in Node.js, and no one can be bothered about
| it.
|
| So why pretend that knowing how things work from the metal up
| is relevant to get an understanding of how things operate? I
| mean, most services don't even operate on metal, but on
| interpreters running on containers launched from
| virtualizations.
|
| To each its own, but let's not fool ourselves into believing
| that in a world of countless layers of abstraction it's
| relevant to dive into the lowest of levels.
| veltas wrote:
| I agree with you completely, and this was what I tried to
| convey. You have misunderstood me.
| tremon wrote:
| _This change is necessary because young people aren 't
| interested in the fundamental abilities of computers_
|
| Respectfully, then these young people shouldn't be attending
| MIT. You go to a top university to learn about the fundamental
| principles; if you just want to build stuff by assembling
| components, go to a trade school.
| veltas wrote:
| Each generation has different motivations, regardless of our
| ideals. They can still ultimately produce many people who
| will care about the same things you do.
| yazzku wrote:
| Don't miss Sussman's talk linked from the post:
| https://www.youtube.com/watch?v=OgRFOjVzvm0
|
| This stuff resonates with me deeply. The reality of the modern
| computing world is a clusterfuck that no single person
| understands, especially because, like Sussman said, parts are
| entirely secret/proprietary anyway. Therefore I think an engineer
| should be skilled in a) removing the unnecessary bits of that
| clusterfuck that are not necessary to their problem and b)
| getting stuff done without having a complete understanding of the
| whole system. (b) sounds scary as fuck, but I think that's the
| (sad?) reality we live in in the software and hardware world.
|
| Embrace the cluster; embrace the fuck.
| strangattractor wrote:
| So should the new course be called ECEF?
| yazzku wrote:
| Abso-fucking-lutely.
| antipurist wrote:
| I find it funny that the author dislikes "casting magic spells",
| and yet cherishes the book which states that we conjure the
| spirits of the computer with our spells.
|
| What I don't find funny is that people keep suggesting SICP
| instead of a much more digestible How to Design Programs --
| https://htdp.org/
| jeff-davis wrote:
| If the fundamentals of the course change, shouldn't that be a new
| course? If the previous course existed, would that still be
| worthwhile for some students even if most move to the new course?
| klodolph wrote:
| There are negative consequences to bifurcating your students
| like that. Practically speaking, what you want is a set of
| students with common experiences for the first half of
| undergrad, which serves as the foundation for the second half
| of undergrad.
|
| You really want to think of the curriculum of the program as a
| whole, rather than focus too narrowly on individual courses.
| javamoss wrote:
| why no battery-included scheme ?
| bitwize wrote:
| I got into Scheme because of Guile.
| nequo wrote:
| Is Racket basically that?
|
| https://docs.racket-lang.org/reference/index.html
| Turing_Machine wrote:
| Sadly, no. For one thing, despite several attempts, there's
| not really any good mobile deployment story for Racket at the
| moment (especially for iOS).
|
| The Racket team appears to be more interested in (primarily)
| education and (secondarily) tinkering with programming
| language internals than making something that can be used to
| produce polished, packaged, distributable binaries (and let
| me stress here that this is _perfectly fine_... it 's not a
| criticism, just an observation. Different people are
| interested in different things, and there's not anything at
| all wrong with that).
|
| Things that would have to change in order for for me to
| consider Racket fully "batteries included":
|
| 1) Capable of building binaries for all major platforms
| (including iOS), including stuff like code signing.
|
| 2) A standard GUI and widget library that, again, works on
| all major platforms. The days when cranking out a command-
| line binary was good enough are long gone.
|
| 3) At one time there were some licensing issues that
| precluded use on iOS. I think that this may have been
| resolved by switching to the new Chez-based system, but am
| not 100% sure of that.
|
| There are probably some other things.
|
| Let me stress once again that I think Racket is great! It's
| just not something that easily be used for commercial
| software development in its present form.
| dflock wrote:
| Your point no. 2 is a rather high bar.
| benatkin wrote:
| In that case almost nothing is batteries-included. You
| can't turn a native iOS app into a web app. So the iOS SDK
| isn't a batteries included development platform.
| threatofrain wrote:
| Is there anything for mobile aside from Swift, Flutter, or
| React Native?
| Turing_Machine wrote:
| At one time there were numerous packages that let you run
| JS-based code across both mobile and desktop (e.g.,
| Cordova). These seem to be mostly moribund nowadays,
| though.
|
| I think there are a couple of options for running Python
| on mobile.
| neilv wrote:
| Starting in 2000, I decided to help build out Scheme to
| "batteries included". (Initially, portable Scheme, and then
| eventually I focused on what's now called Racket.)
| https://www.neilvandyke.org/racket/
|
| What's "batteries included" changes over time. In 2000, I
| needed batteries like Web scraping and crawling, various parts
| of a Web application server, CSV import, multimedia file
| handling, PostgreSQL access, embedded API docs, embedded unit
| tests, package tools, so I made batteries like that. (I also
| did some later non-open-source work of more specialized and
| sometimes fancier batteries.) (Racket already had portable
| desktop GUI.)
|
| The batteries I need today, I'd have to roll up my sleeves and
| build for Scheme, since they include things like: Wasm
| targeting for in-browser front-ends, polished Android and iOS
| apps (ideally doubling as desktop GUI apps, and mobile-friendly
| Web apps), GPU/TPU targeting, good interfaces to cutting-edge
| ML libraries, various data science tools integrations. I'd be
| happy to build these new batteries, except grinding Leetcode
| and copying&pasting Stack Overflow would pay the rent much
| better.
| dboreham wrote:
| Gerbil?
| eddsh1994 wrote:
| The docs for Gerbil are horrific. I tried using it the other
| day and couldn't even work out how to call a process.
| karmakaze wrote:
| I went through SiCP much later and enjoyed all the intricacies
| and discoveries while at the same time realized that it would
| have little impact on how I go about day to day problem solving.
| The video explanation very much aligns with how I see programming
| has changed. Now we have ecosystems and library managers and
| perform composition at higher levels.
|
| SiCP still has great value to those interested in program
| language development or making/using DSLs and compilers, but this
| is a minority of the general software development/engineering
| audience.
| busterarm wrote:
| My impression is that engineers who've gone through the SICP
| have a much better overall sense of the structure of things and
| how they should be built.
|
| Having worked with a lot of SICP-trained and non-SICP-trained
| engineers from MIT, I think I would prefer to work with the
| former. That said, it could completely be other factors.
|
| Computer Science's recent ascension to "prestige degree" status
| over doctors, lawyers, etc. has had and will continue to have a
| lot of negatives for our industry.
| karmakaze wrote:
| I'd like to take that as data but there are too many
| potentially confounding variables.
| busterarm wrote:
| In the comment I agreed as much.
| karmakaze wrote:
| But in phrasing it as 'prefer to work with SICP-trained'
| belies that, which might better be expressed as "were in
| CS at MIT" between 1980-2000. _Edit: sorry meant as
| clarification, not a dig._
| Barrin92 wrote:
| The trend of using Computer Science programs as software
| development vocational training is pretty terrible, in
| particular at an institution like MIT.
|
| the word 'science' is in there for a reason and SICP was
| excellent at teaching people foundational comp-sci knowledge.
| Replacing this with python because of a great library ecosystem
| is like replacing linear algebra in a maths course with numpy.
| karmakaze wrote:
| Funny you should pick out the word "science" which Sussman in
| the video @4:20 says "more like science, you grab this piece
| of library, and you poke at it..."
| jhbadger wrote:
| An analogy is that computer science is like if universities
| had an "optical science" program. The professors in this
| field would be interested in cutting edge research on
| microscopes, cameras, and telescopes. The problem is that
| most of their students aren't actually interested in that but
| want to get a mainstream job as an optician helping people
| figure out what glasses they need.
| DennisP wrote:
| But "optical science" actually is taught, in the physics
| and engineering programs.
| dragonwriter wrote:
| > SiCP still has great value to those interested in program
| language development
|
| Programming language development and implementation turns out
| to be a far more broadly useful skill than it sounds, because,
| e.g., lots of input processing turns out to be reasonably
| isomorphic to implementing a programming language with
| semantics defined by the input format and use case.
| fouronnes3 wrote:
| I've heard a joke some time ago that I can't stop thinking
| about: every program is either a compiler or a database. I
| still haven't found any counterexample.
| karmakaze wrote:
| A load balancer? Operating system kernel?
| thefaux wrote:
| > every program is either a compiler or a database
|
| or both!
| amelius wrote:
| Or it's just a CRUD website.
| otabdeveloper4 wrote:
| Programming hasn't changed, people teaching it have. There used
| to be Cobol and SQL back in the day too, they just didn't teach
| it at MIT.
| dwheeler wrote:
| I disagree, programming has changed greatly.
|
| Today programming is mostly about picking existing components
| and gluing them together. Those components are themselves
| mostly gluing together of other components, to many levels.
| While it is still possible to write code from scratch, that
| is usually not a productive use of time.
|
| SICP is an awesome book, but it is probably better for a pure
| Computer Science course after you have had other courses.
| slaymaker1907 wrote:
| Creating things from scratch is still definitely a thing,
| particularly for high performance code. Sure, there are
| plenty of data structure libraries, but squeezing out that
| last bit of performance often requires something bespoke.
|
| For example, I recently wrote a custom CSV parser because I
| needed something that did no heap allocation but without
| mutating the original character array (using explicit
| string lengths).
| dragonwriter wrote:
| > While it is still possible to write code from scratch,
| that is usually not a productive use of time.
|
| The thing you use to "glue components together" is as much
| code as the components themselves are, and the techniques
| used in connecting them run the full gamut of programming
| skills.
|
| SICP may not be the best pedagogical tool available today,
| because the space of options in programming pedagogy has
| changed, too. But the skills it teaches are no less
| relevant.
| fferen wrote:
| SICP blew my mind the first time, but I think it's most useful
| when you already have some hands-on coding experience (as I did).
| It's why we don't start teaching math with set theory.
| [deleted]
| dmix wrote:
| Yeah I taught myself how to program for about 1-2yrs, but I
| didn't really learn what it meant to be a programmer or the
| ideas unpinning programming languages until I fully dug into
| SICP and watched the classic 1980s videos of Sussman's class.
|
| But I don't think I would have appreciated without my prior
| exposure to programming. That said, I've also watched some MIT
| 101 math classes and they also seem like courses better suited
| for people who know/appreciate the basic content (beyond
| typical high school math). So maybe MIT selects for kids smart
| enough to grasp it.
| hardwaregeek wrote:
| I really liked his point about how you should find people who
| actually want to teach the course. In my experience at school,
| too many professors didn't actually like teaching and therefore
| taught a very perfunctory curriculum. The courses that I enjoyed
| were the ones where the professor had an explicit approach to the
| course that was based around their perspective vis a vis the
| material. For a course that's focused around teaching
| programming, you need a professor who has a perspective on
| programming. I remember talking to the head of undergraduate CS,
| who was frankly more of an applied mathematician than a computer
| scientist, and being frustrated because she fundamentally didn't
| get what it meant to teach programming. She complained that
| students wouldn't read the textbook, which was a rather boring
| Java textbook. She also didn't seem to understand that an intro
| course needs to be an introduction to thinking about computer
| science problems, to modeling and solving problems with
| programming, not just a literal introduction to the act of
| writing code.
|
| So unless you have a professor who is willing to devote a lot of
| time to education, which is not necessarily encouraged, and who
| has these opinions on programming, on computer science education,
| then you won't have a good intro CS class. Which really means you
| won't have a good CS program.
| jeffreyrogers wrote:
| I read SICP and never got the hype. Seems like there is a certain
| personality type who really takes to SICP but not everyone learns
| best that way. I found it much more intuitive to learn about
| computing from the hardware up rather than from the abstract,
| mathematical way of thinking SICP uses.
| kjeetgill wrote:
| Sincerely no snark intended. But this comment and another about
| "bottom-up" via Assembly and C kinda show that maybe you've
| missed the point.
|
| We can blame SICP itself for that maybe, but it's all in the
| name: Structure and Interpretation of Computer Programs. It's
| abstract because it's not about actually physical computing --
| nor is it trying to take you to the same place as learning
| computing from hardware, "bottoms-up" is meant to but via some
| other mathematical means.
|
| It's trying to teach you to reason about computer programs by
| it's structures -- that they aren't just a list of
| instructions.
|
| Reading Shakespeare won't teach you grammar but they'll help
| you be a better reader and writer in their own ways!
| jeffreyrogers wrote:
| Yes, I understand the motivation for SICP. There are similar
| trends in mathematics where some people like an abstracted,
| axiomatized presentation and others like something more
| intuitive. I'm in the later group as are many others. I don't
| think either way is superior in itself, nor do people who
| learn from one approach or the other turn into better
| programmers.
| mixmastamyk wrote:
| I don't think we can have one without the other. For example in
| Petzold's Code book there is a chapter about Boolean Algebra.
| In a following chapter, we then vastly simplify our previous
| circuits of logic gates, replacing them with other simpler
| ones. This happens after proving they are equivalent with our
| new found algebra talents.
|
| Imagine your computer being 3x (estimated?) slower and hotter
| without this advancement from the "propeller-head" pure-
| thought-stuff people. There are undoubtedly wins like this
| across the whole industry.
| sirsinsalot wrote:
| I didn't get on with SICP the first few times, but loved
| Tannenbaum's works and eventually the Dragon Book.
|
| Everyone's path through these esoteric texts looks different,
| but all these books are magic.
| rtpg wrote:
| There are SICP lectures on YouTube (I think it was classes to
| HP engineers?) that I find pretty entertaining. The flavor
| offered by the lecturers make it more worth it and can
| introduce you to some interesting vocabulary.
___________________________________________________________________
(page generated 2023-02-04 23:00 UTC)