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?

  • Why do you think machine language accurately represents the underlying hardware? Modern cpus are doing a lot under the hood. Dec 21, 2023 at 23:44

4 Answers 4


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

  • 4
    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, 2010 at 18:19
  • 5
    @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, 2010 at 13:50
  • 1
    @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, 2014 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, 2014 at 0:29
  • 3
    @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.
    – sara
    Jun 20, 2016 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.

  • 5
    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. Oct 21, 2010 at 13:12
  • 1
    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.
    – sara
    Jun 20, 2016 at 10:38
  • 1
    @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, 2016 at 13:20
  • 1
    @DrewJordan my point is just that: unless you are a professional who needs to know about and fix a certain class of issues (or just have a keen private interest), then it's quite frankly absurd to claim that you need to know the inner workings and weird subtleties of every tool you're using. I merely drew the standpoint to it's logical conclusion. sure, knowing how an ethernet cable is built would allow you to build a new one, given the right tools when your internet connection fails, but spending time and money on gaining the knowledge when you work 20 layers above is just wasteful.
    – sara
    Jun 20, 2016 at 13:59
  • 1
    @DrewJordan of course SOMEONE needs to know all this stuff so someone can fix it when an abstraction breaks, but the whole POINT of abstractions is to keep the number of people who need to know the details to a minimum so the vast majority can focus on getting stuff done. where you arbitrarily draw the line of where things get "too low level" just depends on what you personally happen to work with, as illustrated with my argumentum ad absurdium (which isn't a fallacy, I'll have you know!)
    – sara
    Jun 20, 2016 at 14:01

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.

  • 2
    In theory, yeah, but those are a couple of pretty big ifs. Oct 1, 2010 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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