Comment by simplotek | Hacker News Reader

Comment by simplotek | Hacker News Reader

Parent Full thread

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

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.

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.

Reply on news.ycombinator.com