4 ms·

I am happy about the 'demise of low level programmer'. Why? Because for me programming is more about algorithms/data structures than circuits, microprocessors a

by rednum 15y ago

I am happy about the 'demise of low level programmer'. Why? Because for me programming is more about algorithms/data structures than circuits, microprocessors and caches. I am happy that I didn't have to write mouse handlers, keyboard handlers - because have I started doing that, I'd either got bored before managing to do something useful, or changed my passion towards low-level stuff before writing my first quicksort. I am also happy that I can write something without understanding all mechanismes behind it - that I can build some site with django not even knowing how http works, or play with some graphics having no idea about graphic cards. Sure, all of this stuff is interesting - but it's just too much! 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. I don't want to praise ignorance - probably I will read some of the stuff he linked under the article - I just think it's ok that people can do something useful with computer not knowing all the details about it. It's worth knowing though - but just as you can have no idea about physics of sound and how piano works and write nice songs, you can build nice stuff with high level tools not knowing low level.

baddox 15y ago
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.
reemrevnivek 15y ago
> 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.
Peaker 15y ago
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.
makmanalp 15y ago
The problem is the law of leaky abstractions: http://www.joelonsoftware.com/articles/LeakyAbstractions.html 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.
- Daishiman 15y ago
  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.
Turing_Machine 15y ago
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.
brianpane 15y ago
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 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.

by rednum 15y ago

baddox 15y ago

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.

reemrevnivek 15y ago

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

Peaker 15y ago

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.

makmanalp 15y ago

The problem is the law of leaky abstractions: http://www.joelonsoftware.com/articles/LeakyAbstractions.html 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.

Daishiman 15y ago
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.

Turing_Machine 15y ago

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.

brianpane 15y ago

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