Hacker News Reader

> Low level guys did their job well, so now people who don't like machines so much can build cool stuff on top of that.

Did, and are doing, and, optimistically, will continue to do. The job is not done, in fact, it will never be over.

I think that what is happening is that the low-level programmers are becoming outnumbered by you high-level programmers. That's OK, and, in fact, that's how it should be.

The problem is the law of leaky abstractions:

http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

I agree with you on most counts, but when you traverse your 2d array one way versus the other and are left scratching your head as to why one of them is slower, it's usually because something is going on in there that you don't know about, that the abstraction didn't make clear.

We need those low level programmers. We also need high level programmers to know a little about this stuff. However, we don't need everyone to be a low level programmer, and that's why the current state is an improvement over the past.

Knowning the proper way to traverse an array is basic knowledge that can be explained in 10 minutes. Seriously, cache theory is not complicated and even the highest-level programmer ought to know about it.

That's a huge step from knowing the number of instructions that fit in a trace cache of a CPU or when loop unrolling becomes optimal. Cache theory and understanding how IEE 754 are basics and are fairly universal. It's completely different from programming a fast subroutine in assembly optimized for a specific processor generation.

Yes, this is exactly the point of abstraction layers, and abstraction layers are precisely why I love computer science and software engineering so much. With abstraction layers, we can create, maintain, and use systems that are inconceivably complex.

In my experience, it's useful, even when writing high-level applications, to be aware of the relative cost of low-level operations. The "Numbers Everyone Should Know" slide from this deck is a reasonable starting point: http://research.google.com/people/jeff/stanford-295-talk.pdf To generalize a bit, the small numbers at the top of that chart are mostly a concern for people doing systems programming, but as you progress down the list you'll find operations costly enough to have a noticeable impact on application programs. E.g., if you build a typical web application in a high-level language, your user won't be able to tell if you add a hundred prediction-resistant conditional branch instructions or a hundred L1 cache misses per page view; but if you add a hundred network round trips per page view they'll observe a measurable slowdown. Similarly, if you're making a game and you want to display graphics at 60 frames per second, you can do quite a large amount of computation per frame, but you can't read a file from disk on every frame.

Abstractions are awesome. But when you tune for performance, the abstractions break down.

This is not inherent, as abstractions could have fully specified the performance characteristics of their primitives. However, most don't, so to get great performance out of your tools, you typically have to see directly through the abstraction layers.

When you write a quicksort algorithm, it is pretty important that you know about cache lines and the relative costs, or your quicksort will not be nearly as good as the one that does take that into consideration.

Of course, what counts as "low level" depends on your perspective. There are plenty of programmers today who don't spend much time working on data structures or fundamental algorithms (e.g., quicksort). Most commonly used languages have a decent sort routine in the standard library(or at least one that isn't horrible). Unless it's so slow that it forms a bottleneck, there's no reason to treat it as anything other than a black box. The same is true of data structures. Today's languages come equipped with tons of collection types (queues, vectors, hash tables, sets...), interfaces to SQL (and noSQL) databases and key-value stores, and so on. The days when all you had were arrays with integer indices are past.