Hacker News Reader

Comment by karmakaze | Hacker News Reader

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.

View on HN

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.

I'd like to take that as data but there are too many potentially confounding variables.

In the comment I agreed as much.

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.

Oh, I didn't really take it personally. And you're absolutely right, there's certainly a kind of ageism undercutting my statement.

I'll try a little to counter a little that with an observation that experience isn't always everything.

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.

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.

But "optical science" actually is taught, in the physics and engineering programs.

    students aren't actually interested in that
    but want to get a mainstream job as an
    optician

The ophthalmologist is more specialized than the optometrist.

Eye surgery has replaced the need for glasses in cases.

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

He says "like science" but he doesn't say that it is like physics. Sounds more like highly risky field xenobiology with the grabbing and poking.

The empirical process of the scientific method is what came to mind as opposed to the more mathematical theory of computation would be my interpretation.

Sussman went on to write a textbook that investigates classical mechanics starting from the Lagrangian and proceeding by way of simulation experiments in Scheme. I think the distinction is not between science and non-science, but between the "analytical-synthetic" process he mentions and the approach of understanding a living system, hence the preponderance of ecosystem metaphors (Python has the better ecosystem than Java, etc). It might be interesting to think about a science of library ecosystems (NPM, etc) but mostly this probably boils down to "exposure to the bad or inapplicable decisions of others".

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

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.

A load balancer? Operating system kernel?

A load balancer is a compiler. Instruction scheduling and register allocation are probably the most similar tasks.

An OS kernel is a database, or rather a DBMS. Query planning fits well.

Arguably, a load balancer is a primitive query planner. Perhaps DBMSes are compilers?

It seems that these arguments can also be applied in reverse, so it's quite a loose interpretation, but I do see the logic in them.

> every program is either a compiler or a database

or both!

Or it's just a CRUD website.

That's a user input to SQL compiler

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.

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.

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

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

Your comment gave me flashbacks to FORTRAN data files with fixed width data descriptors.

This is a ton of fun! If you have the double-quote escaping then you have to mutate the data in place, but if it's just a table of numbers then not.

Usually CSV parsing doesn't matter, but when it does, it matters a lot.

What's the practical difference between gluing stuff together and creating it from scratch? When we code in C, we're gluing the standard library with others, in a way.

I would put it like this: consistent small gains programming is about gluing components together. There are plenty of non-incremental (big impact or flop) programs that couldn't have been made by just gluing components together. E.g. BitTorrent, AlphaZero, and seL4.

In some ways SICP is like a medicine for left-pad-like sicknesses. By teaching how to do things oneself, it makes one less dependent on the simplest things being done by others. This in turn has the potential to avoid dependency hells and bloated software. That, in my opinion, is more needed than ever, especially in some ecosystems and states of ecosystems of programming languages which some languages are quickly approaching.

Reply on news.ycombinator.com