Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Quote from Wikipedia of the article "High-level programming language":

A high-level programming language is a programming language with strong abstraction from the details of the computer. In comparison to low-level programming languages, it may use natural language elements, be easier to use, or be more portable across platforms. Such languages hide the details of CPU operations such as memory access models and management of scope.

I.e., as the level of programming language increases, the further away the programmer goes from the hardware on which the program runs.

Now I do not know the statistics of language usages across levels, but I would suspect that the higher level languages more and more are replacing the lower level languages. If so, can this lead to a deficit of programmers with computer architecture knowledge? Would this be a problem for the industry?

share|improve this question

It can, but likely won't lead to a problem.

It's just economics. If the vast majority of people lose the ability to understand the underlying architecture, and there is still a huge NEED to understand the underlying architecture, then the ones who do will have jobs and get paid more, while those who don't will only have jobs where that is not needed (and may still get paid more...who knows?).

Is it helpful to know? Absolutely. You'll likely be better. Is it necessary in most cases? No. That's why abstraction is so great, we stand on the shoulders of giants without having to be giants ourselves (but there will always be giants around).

share|improve this answer
But all abstractions are leaky. Knowing the underlying architecture is a must if you want to be the go-to guy for troubleshooting leaky abstractions. – dsimcha Oct 20 '10 at 18:19
@dsimcha, Agreed, but to be the go-to guy you need "the others" to come-to you ;-) If everyone needs to know everything, the abstraction has failed miserably. – Preets Oct 21 '10 at 13:50
@Preets, And that is why many abstractions have failed miserably. To even have room for a go-to guy to exist is proof that an abstraction has already failed. – Pacerier Aug 27 '14 at 0:19
@Ryan, It will actually lead to a problem where in the future the world is flooded with apps full of subtle bugs due to layers upon layers of leaky abstractions. It's amazing enough now that companies like Google with infinite resources can still have bugs in their core apps. – Pacerier Aug 27 '14 at 0:29
@Pacerier google has far from infinite resources and they make applications that are several orders of magnitude more complex and that consist of several orders of magnitude more lines of code than most others. claiming everyone should know lowlevel computer stuff because all abstractions can leak is like saying everyone should know how to build a house from scratch using no tools because a storm might come and tear their home down. it's just not feasible (or smart) to spend resources like that. – kai Jun 20 at 9:52

I think so. It's a trend that has me worried. No abstraction is perfect; if there was a perfect way to simplify any complex problem, it would replace the original very quickly. (That's happened in the past, occasionally with computers, and a lot more frequently in other fields that don't worry as much about backwards compatibility as we do, such as physics.)

What this means is that every time you use an abstraction, there's some important piece of essential complexity that it's hiding from you. If you don't know what that is, why it's there and what it's doing, you end up accidentally writing big train wrecks, and not knowing how to fix them because you don't know what's really going on.

Anyone who tries to tell you otherwise is either selling snake oil or simply doesn't have much experience with serious software. At work, I work on a program that runs a good percentage of all the TV and radio stations in the USA. As stations and networks get bigger and more complex, quick and dirty techniques that worked fine for designing a product for one small station end up hitting big technical walls when implemented for a network with 50 stations and 200 channels! Without a deep understanding of how the language works, (and an efficient language in the first place,) and a deep understanding of how the database works, our coders would never have been able to make the product scale successfully.

This isn't an isolated story, either. Software continues to grow more and more complex, not simpler, and I'm afraid that this level of technical expertise is going to become something of a lost art, and tomorrow's programs will be worse than today's, not better.

share|improve this answer
I've heard it expressed as "you need to know the abstraction one layer down from where you work". Well, it was rather pithier; my memory's flawed. So if you're working in C or Delphi, you should know how assembly works. If you're working in Smalltalk or Java, you should know how your VM works. (Arguably, you should always know something about assembly!) If you're working with TCP, you should know how IP works. And so on. – Frank Shearar Oct 21 '10 at 13:12
"[every time ...] there's some important piece of essential complexity that it's hiding from you" I find this to simply not be true. this is like saying that every time you do the dishes, unless you have a solid understanding of exactly how plumbing and the city's water grid and pumping stations and the chemical reactions from your soap and the food, then you are missing out and can never do the dishes quite good enough. soap producers are not selling "snake oil" simply because they'd claim you don't need a PhD in organic chemistry to apply soap to plates. – kai Jun 20 at 10:34
I mean, you could take it even further: why should it be enough to just know assembly? that's just a hand-holding high-level abstraction over the binary CPU instructions. but wait! machine code? that's just an abstraction! you need to learn how the CPU is constructed using transistors to build logic gates! and the bus and the registers. but wait! transistors? that's just an abstraction for a certain configuration of atoms. and atoms are just an abstraction over fluctuations in quantum fields. in the end, this just makes javascript:alert("Hello world") require a PhD in string theory. – kai Jun 20 at 10:38
@kai You're being a bit ridiculous. I tend to agree with you that it's not usually the case that you need to understand several layers down for most applications. But we're talking about edge cases, not every day stuff. Sure, you don't need to know how the plumbing works to do the dishes. But if dirty water starts filling up your sink, you should probably learn a bit about it before you try to fix it. Or, you can just ram a piece of rebar down the drain until it works again, and who cares where the water goes. (cont...) – DrewJordan Jun 20 at 13:20
Or learn it first just in case. Mason's answer might be biased towards cases where performance is a more important constraint than say, time to market. There's plenty of software that goes out without being fully finished, bug free and optimized. But that doesn't mean that you shouldn't strive to understand the techniques used. You might need them someday. – DrewJordan Jun 20 at 13:28

Yes, I think people will understand hardware much less as languages progress (and, similarly, as instruction sets progress). But as has been noted many other places, the primary constraint on most programs now days is not CPU time or efficiency, but programmer time. If people who design languages keep doing their job in making the abstraction efficient, and if people keep using these abstractions properly, then an understanding of the computer architecture is not entirely necessary; at least a complete knowledge is not fundamental to being a good programmer these days.

share|improve this answer
In theory, yeah, but those are a couple of pretty big ifs. – Mason Wheeler Oct 1 '10 at 16:04

No, it won't lead to a deficit of programmers with computer architecture knowledge. Languages are used to solve problems in a particular domain. If you want to solve a particular problem, you use the appropriate language or one good enough given your resources.

In reality, what domains actually need knowledge of the computer's architecture? That need to be tied down to a particular hardware architecture? Operating Systems? Device Drivers? Sure, but even then only parts of such code need specific architectural knowledge.

Performance improvement? Yes, you can apply knowledge of the computer's architecture to improve the performance of algorithms. But two other factors have a bigger impact on performance: the use of better algorithms and knowledge of the language's runtime environment.

In essence, more abstract programming languages solve problems for which details of the computer architecture isn't necessary. They allow more problems to be solved. The people that use them aren't using them to solve machine-dependent problems. People that need to solve machine-dependent problems will continue to use machine-capable languages. This isn't a zero-sum issue.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.