Hacker News Reader

Comment by veltas | Hacker News Reader

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.

View on HN

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

I agree with you completely, and this was what I tried to convey. You have misunderstood me.

You misunderstood history.

"young people aren't interested in the fundamental abilities of computers, instead they're only interested in the application".

Young people back then were the same, but back then applications were far simpler and were built using the fundamentals of computers.

I also agree with this. You have also misunderstood me.

Yeah, you can always ship a shitty SaaS or plug libraries you don't understand into each other and still make a lot of money. But you honestly cannot do much more than that if, say, you don't know the difference between the stack and heap. Statsd is like ~4000 lines of code, which is absolutely tiny; it's a trivial codebase. You can't write fast JavaScript if you don't know how arrays are represented in memory. You can't optimize SQL queries if you don't know how a database works. Hell, you can't even create good code in general if you don't know how to compose functions properly.

The countless layers of abstraction may be useful, but without them you are basically stumbling through your day and hoping everyone else can be smart enough to let you continue to not learn anything.

> Yeah, you can always ship a shitty SaaS or plug libraries you don't understand into each other and still make a lot of money.

What you're failing to understand is that the SaaS or plug libraries are not shitty. They might even be better than anything someone who reads SICP like the bible can possibly put together. Why? Because they focus on the right level of detail and abstraction instead of wasting time and effort on irrelevant and useless details. And they deliver it far faster.

I repeat: the StatsD daemon is written in Node.js. it's a >100MB Node.js application to receive, aggregate, and send UDP packages. The StatsD daemon is perhaps the most popular metrics sidecar out there, and no one cares it's not a 1MB C app.

> Statsd is like ~4000 lines of code, which is absolutely tiny; it's a trivial codebase.

Don't you get the point? It's a Node.js app that took a few lines of code to out together to handle UDP packages. Writing the same thing in C would not be hard and it would be far more efficient, but it would be entirely pointless because slapping together a Node.js application performance wise is already good enough. What does this say about the cargo cult beliefs of SICP fundamentalists ?

> You can't write fast JavaScript if you don't know how arrays are represented in memory.

Sure you can. You just hear that arrays are faster and use those not bothering with any irrelevant low-level detail. And who exactly advocates using JavaScript for a UDP server and mention performance needs with a straight face?

> You can't optimize SQL queries if you don't know how a database works.

Don't you get the point? The point is that you don't need to waste your time bothering with performance tuning if your goal is designing a working system. Bothering about irrelevant details like that is a waste of time. Decades ago someone smart already stated that premature optimization was the root of all evil. The first rule of software optimization is "Don't". And here you are trying to argue that being bothered about low level details is relevant for the sake of optimization? Don't.

The problem is not one thing in particular, but composition of these things, which are getting more and more bloated, because no one applies the fat-reducer to them. I don't know what statsd does, but the point is, that when using it from another program, you suddenly have all that baggage of dependencies and insufficiencies as part of your program. This trend continues until things are horribly bloated. Best place to see this trend is modern websites, that merely show some static info, but require the viewer to download megabytes of JS bloat, and otherwise only show a white screen.

When composing fat, most of the result will be fat as well. Ultimately we do not gain much from our more powerful machines, because at the same time we make it so, that for the same functionality the have to process much more.

You don't realize that Scheme used a garbage collected high level language at a time when C would have been the norm. This is like having 40000 npm dependencies today, convenient and very practical.

The smart person was Knuth, who said 97% of the time, you shouldn't think about optimizations, but you shouldn't be complacent but look out for the 3%. This is the same Knuth who gives all his code examples in MIX, the assembly language he created for this purpose.

I didn't say there was anything wrong with statsd itself, just that it's not a particularly complex application. You can produce a working, useful (to some people) web application/website/whatever people call this shit nowadays but it will not be very fast if you don't optimize anything.

Slack is a web app that is incredibly slow, but still useful: yes, I can send people messages and it doesn't immediately crash, but it also takes up ~300mb of RAM on a fresh tab, which is completely absurd. I still use it because I have to but if it was optimized by people who had a clue what they were doing, it would be significantly faster, and use less memory.

Of course it's not strictly necessary to learn the various levels of abstractions in computing. But some people just do it out of curiosity and wanting to know how things work from the ground up. These people typically tend to be smarter and better, but it's true that not everyone needs to do this to have a good career and make lots of money.

> But some people just do it out of curiosity and wanting to know how things work from the ground up.

And that is perfectly fine.

Some people also get a kick out of learning Esperanto or Klingon, but that doesn't mean those are critical subject areas that you need to to excel in any professional domain.

As said young person.

The issue is:

I truly, truly, love programming and working with computers.

I truly, truly, cannot see myself writing software in a systems programming language, ever, for the rest of my career. I'll only work in GC languages.

I love reasoning about code, logically. I'm studying compilers/mathematics in night school, that's how much I love it.

But... I learnt Rust, learnt assembly. I set up a Raspberry Pi Pico as a hardware debugger as a fun project. That knowledge's usefulness is... tenuous. I appreciate the assembly mental model, but it's only a rough mental model.

I truly, truly, cannot see myself using non-garbage compiled programming languages for any of my future project ideas.

Knowledge of the underlying machine is irrelevant. Same as knowledge of the electrical resistance threshold of your transistors before a bit flip.

Computing is changing, fast, as we ascend layers of abstraction at an extraordinary pace. Most knowledge is highly specialized to your level of abstraction.

SICP/functional programming HAS to justify itself as relevant to each level of abstraction.

I had a similar trajectory, but would not describe that learning as useless or irrelevant. That knowledge informs my every decision, and understanding hardware or algorithms is why I'm sometimes able to find a better technique or abstraction for a project than other folks. Plus it's just more satisfying.

This is the right perspective, and you should continue to pursue your own projects using the languages that make you most productive. Don't study what does not interest you.

The problem is if you change majors to engineering, the first courses are not going to teaching you what is exciting and flashy, they are going to teach you the very boring, mostly unmotivated maths that you need later to build bridges that won't collapse. SICP represented the engineering approach, by starting from first principles (more logical than mathematical, but appealing for similar reasons) and then proceeded to an understanding of interpreters, compilers, register machines, and so on. Giving up on SICP meant giving up on the engineering approach which produces programmers, to the software engineering approach, which leaves out the hard parts of engineering and produces software users, who plug together libraries that are written by others.

> Knowledge of the underlying machine is irrelevant.

As you look back on your assembly experience later, you'll realize this is false.

I agree.

I simply think, the assembly model will be replaced.

There will eventually be a new, "better," set of principles. For reasoning about library gluing.

> Knowledge of the underlying machine is irrelevant.

> As you look back on your assembly experience later, you'll realize this is false.

Better to clarify: truly deep knowledge of the underlying machine is irrelevant.

At this point, I'd say I'm immensely richer from "thinking" about assembly. Nowhere else would I have truly learnt about CPU cycle times to copy data from register to register to call stack, and back. The concept of "time to copy data" is highly present in networking and other fields.

Important to know that "C" and other high level languages abstract over it.

I'm not entirely sure my knowledge of JTAG debugging/Rust borrow checker is ever going to be substantially useful. The time/benefit equation of doing all that work was... less than ideal.

In hindsight, maybe an afternoon of assembly copying data from place to place, seems like "all" the big picture learning I needed?

Then again. Maybe I invested far more time than undergraduate courses spend on the topic, regardless.

On the JTAG points, I (sadly) don't have enough hardware hobbies under my belt to appreciate that pain. On the Rust borrow checker front, I too share this same sunk cost and the have the same lingering regret. Uniqueness types have been done before and better, but it's interesting for systems programming, and already better than C++. Just don't do applications work in it, unless you would pick C or C++ for the same job.

> I truly, truly, cannot see myself using non-garbage compiled programming languages

Unfortunate typo.

For me, an older dev, I felt that knowing assembly and other "not useful" techs had a general positive effect on my skill as a dev.

Does that still resonate at all?

Yes, this fits my understanding and know I'm not judging you or people like you. I understand this because I'm the same way, but from my own era.

In truth, I don't hold my view strongly.

Software is a YOUNG field.

An undiscovered ocean of knowledge absolutely awaits us.

Far more knowledge remains to be found. Far more focused on "what haven't I learnt."

I don't like "shaming" people for not learning "fundamentals", and I believe people should learn whatever they want to at their own pace, but since you asked --

Sometimes you run into bugs (or leaky abstractions) that force you to go down a couple layers. Perhaps you run into a bug in the C/C++ code of your language's compiler. Sometimes a dependency (written in C of course) of your stack gets a nasty CVE and you need to figure out the implications (often being able to read the patch will help). Ever heard of "Meltdown" and "Spectre"? Those were bugs in CPU design which require understanding of how low level operations work.

In junior roles nobody will bother you with these questions, but senior devs are expected to know how to understand and deal with these issues if relevant, even if they're normally using a super high level language, because they don't exist in a vacuum, they depend on these low level things to form the whole "stack" so to speak.

In terms of education in schools, time is limited, so there's obviously a need to choose the most relevant topics to focus on. Learning fundamentals has always been at least occasionally useful though. I mean, you could probably do 99% of your job without knowing this stuff and you'll probably even have a great career. Personally, I just hate to feel ignorant about the things I do for a living...

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.

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.

That's not how tertiary education works.

University is where students choose the classes they want to take.

Students are 100% responsible for their learning. They vote with their feet.

Faculty must JUSTIFY why the knowledge they teach is relevant to undergraduates.

To students, and increasingly, the external advisory board of the faculty.

To the administration, yes. Not to the students (except perhaps morally).

The University decides what you are required to learn to get the credential, the wider society determines what the credential is worth, and influences the institution to produce more or fewer graduates of the various specializations.

The students get to pick which institution they go to and which credential they will try to get, and then they must learn the material that is required. The computer science department is not trying to get students to "vote", in fact their interests generally align with having fewer, but more promising, students.

The institution, to the degree that it desires revenue, generally desires more graduates, because each pays tuition, but as highly qualified graduates as possible, so as not to tarnish the brand.

I agree, elite schools (like MIT) have traditionally grounded their curricula upon a basis set of essential principles like "great books". At MIT, those were calculus through diff eq, physics, and engineering basics like statics and dynamics.

However, since around 1990, I suspect high school AP courses routinely overlap with said principle courses. So dropping MIT's four course intro to EECS probably became unavoidable after so many freshmen with AP course credits expressed frustration that taking those four EECS courses ("the MIT way") duplicated courses they'd already taken for credit in high school.

That is probably true. I think this is always a problem for elite schools, because you will always get the really motivated students who started a subject early and had a genuine interest in it, and these kids will never need what you are teaching in the introductory courses. The SICP approach was deep enough that anyone could find something to learn in it, if the teachers were willing to let the students run ahead at their own pace.

They also could have taken it as an inspiration to really make those courses advanced introductions to basic topics again (starting from counting, for example), and show that the AP course still had to leave out one or two interesting things, and how wide each of those fields really is.

SICP is the opposite of starting from the bare metal.

Reply on news.ycombinator.com