As high level programming languages such as C#, Java, etc. are developing, many people claim that they will be an alternative to languages such as assembly language and C/C++, which gives you access and control to computer hardware, because programmers should focus on creating the program and solve problem, not wasting time dealing with the computer to make it work. As the hardware keeps improving, the performance difference between C/C++ and Java will not be significant, and big games might be able to be programmed in a language such as Java.

That's the general idea I briefly summarise after looking at this topic on the Internet. Do you think it will become real in the near future? Does that mean everything we learn about low level stuff is not practical for the software industry anymore? Does that mean, assembly language and C/C++ will become relevant to electrical engineers only, since they would be the only ones who needs to program for their electrical components?

How much learning is enough? If we learn too much low level stuffs, we would eventually become more oriented in electrical engineering or if we learn too much math, we could be learning to become mathematicians, not programmers. I just want to know if the Math stuffs I learned (I took a Math course which covers the material similar to this book (they used different text book): Discrete Mathematics and its application) is actually as useful as our programming skill set. Many math exercises can took most of us hours to do it, and if you're serious with it, you will have less time to study programming. In our gamedev forum, even Math and Physics only have one section for it compares to programming ones.

Right now I have just started reading "The Art of Computer Programming". Math is only covered in about quarter of the book, but the exercise is hard for us non-mathematicians. Even such "elementary" math, did we use it as much in our career? Some people would probably tell me reading the book TACOP is a waste of time and should probably spend time on something else more practical, even though the book is all about programming (a bit more academic compare to book explain similar things). But I think the author put in great time and effort to produce it. He can even write the full set of 5 books, while we - the audience - only have the mission to read it. Why not?

  • 1
    "the performance between C/C++ and Java will not be significant". If this happens soon please send me a PM to revise my Java skills. I've stopped using Java some years ago for those reasons.
    – sakisk
    Commented Mar 25, 2011 at 14:59
  • 3
    Most C/C++ code doesn't access hardware. It makes it easy, but that is usually hidden by device drivers. I would even venture to say that 95%+ of C or C++ code does not ever interact with hardware directly.
    – Pemdas
    Commented Mar 25, 2011 at 15:19
  • 1
    I'd suggest a change of title to low level languages. There are plenty of low level things (how threads work.. how your os works.. so on and so forth) that still have value even if knowing C++ or Assembly may not.
    – ShaneC
    Commented Mar 25, 2011 at 15:28
  • 2
    @faif, For long-time running applications, a Java app can keep pace with a C/C++ app. After Java has warmed up. That's due to the hot-spot technology recompiling the Java code to native code over time. However, for short running applications, the start-up time of Java is still horrendous. At some point, particularly for server apps, the communications is more your bottleneck than actual processing. Commented Mar 25, 2011 at 16:01
  • 1
    @BerinLoritsch Java is relatively fast, yes, but the memory overhead, runtime library overhead, access to low-level hardware, and VM pre-configuration before running (in order to achieve different heap limits, for instance) is all terrible, compared to just a low-level program, running on the OS. It's not all about executing instructions in the same order of magnitude.
    – user51532
    Commented May 24, 2014 at 13:31

16 Answers 16


Interesting question. I'm a long time C++ programmer who's now working in C# (with a bit of unmanaged C++ for performance critical work), and have historically had to add the occasional bit of assembly code, usually for performance reasons.

A few points in preparing a response to the question:

  • For the sake of your comparison, I suggest that the primary distinction between the languages you mention, C# and Java, from the other set, Assembly, C/C++ is that the former use a managed runtime to provide garbage-collection. There are other differences (e.g. binary portability, framework size and portability), but as you are looking at comparing performance differences, this is a (the?) major contributor.

  • Assembly, C, and C++ are far from equally "low-level". I think you're right in associating Assembly and C languages with hardware/firmware/driver developers, but C++ is typically used at a higher tier, and is still in heavy use - although clearly C#/Java are duking it out according to the TIOBE index.

  • In the C++ tier, I'd add Objective-C, as it's more akin to C++ than C#/Java. Finally, I'd note that with the addition of shared_ptr<> and other automatic resource management features, these languages have support for something close to garbage collection.

OK - on to your main question: Do software engineers really need to know low level stuff anymore?

My answer: Yes


  • Even when using C#/Java, you will likely run into framework entities that require explicit resource management, and/or run into issues of "pinned" memory graphs on any non-trivial applications. You need to understand how these systems work to effectively avoid and debug these issues.
  • Mobile platforms have more limited resources, and although there is support for limited versions of Java and .NET on some, the current dominance of iOS and Objective-C suggests a long renewed live for it.
  • Performance: anytime you hit a performance wall, you will likely need to drop into a natively compiled code chunk to get around it.
  • Legacy Support: anytime you need to interop to get access to a feature not exposed (yet) in managed code, you'll need to do the same.

Good question - but I don't see unmanaged languages going away in the near term.

  • Thanks for you response. I will keep studying more on computer foundation (such as OS, network, more Math...also just enough to understand the basic principle and not focus too much on improve just programming). Hopefully it will come in handy one day.
    – Amumu
    Commented Mar 25, 2011 at 17:40
  • 1
    Also having a deeper understanding of what's going on at the lower level will help to inform your decisions.
    – snakehiss
    Commented Mar 26, 2011 at 1:06
  • 1
    To add my 0.02, knowing how something is done when you demand it happen is usually a good thing. Can help make your demands more reasonable and efficient (applies to high-level programming and maybe bosses ;)).
    – ssube
    Commented Mar 26, 2011 at 2:57
  • That someone would legitimately not learn about and not understand lower level functionality, and still be a very productive and valuable developer, is already the case.
  • That no one will need to learn or understand lower level functionality, that it would always be a waste of time, will never be the case.

As in any engineering discipline, there are many steps to the end product, all of which are important, demand expertise, and are valuable. In software engineering in particular, we have many layers of abstraction. All are needed, and no one can be an expert on all of them.

That being said, we need more C#/Java/Ruby developers than we do Assemby/C developers. For us "higher level" developers, understanding more about what happens "under the hood" is helpful, and will make us better developers. But so does a lot of other stuff. As a .NET developer, for exmaple, there's so much that I can learn that will make me more productive, that studying our Intermediate Language (much less C++/C/Assmebly), though very helpful, often has to take a back seat.


You can make a living today as a programmer without knowing the low level stuff. I think it just makes you a better programmer to know it.

Maintaining a high level of competency with the low level stuff, however, is increasingly becoming less important. I mean, I haven't done anything in assembly in 20 years and would probably need a serious refresher before I could be productive in it again, but the overall concepts of how things work at that level are still part of my consciousness and I find it helpful from time to time even when working in higher level languages.


I don't think so, kernel developers will always need the low level stuff. It also doesn't hurt to understand how everything works, if you fundamentally understand what the code you're writing is actually doing you will learn to write better code. I think removing the low level stuff is a horrible idea as this abstract thinking is useful at times but can actually be a hindrance if you want the problem solved in the best way. For instance understanding that when you concatenate strings you actually are creating new strings is important but if you didn't understand how strings were implemented you may just concatenate away and wait the 5 minutes it takes your program to run. This is an excellent article on things such as this : http://www.joelonsoftware.com/articles/fog0000000319.html


This depends on what the software engineer is actually working on. It's possible to have a productive, happy, and profitable career without ever touching anything low-level now, but that's not all programming jobs. For there to be operating systems and compilers, there have to be engineers working on operating systems and compilers, and they'll need to know C, C++, and their machine's assembly language.

Performance can also matter. My current laptop is very roughly a million times more powerful than my first home computer, and running software can still take time. I can still get lag in video games. Of course, the video games look better, because each of over a million pixels on the screen can be given one of millions of colors (as opposed to a thousand black-and-white character positions, with some of the characters being used for graphics). I doubt we'll get another thousandfold increase in computer power in the near future, and if we do I expect it to be used by increasingly complex software.

While the bulk of business software will continue to be written in what's fastest to get produced and out the door, which usually isn't C, there will continue to be a lot of room for C and C++ experts.


"With the hardware keeps improving, the performance between C/C++ and Java will not be significant, and big game might be able to be programmed in language such Java."

I don't believe that statement will be correct any time soon. There is always a hit in the managed code because of checks done behind the scene. It's also not a matter of the hardware better, as the hardware gets better so do the apps that are expected to run on them. A system that is written in native code has to have an interface to managed code. Theres a performance hit that happens when switching between the two.

However only a generally small percentage of applications really need this optimized code. Most line of business applications are just fine with any managed code, .net, java, etc. It doesn't mean though the applications that need it will make the switch any time soon. However hand written assembly is much less used now with the optimizing C/C++ compilers being so good. There was recently an OS written entirely in assembly though, so still some are having at it. It's also quite important in the security field.

I would say though, to be a really good developer, one should understand what is going on at a low level. It helps in troubleshooting some difficult issues, especially when calling into native code.

  • @Adam Tuliper "an OS written entirely in assembly" Interesting. Can you give me the name of the OS? You made a good point about troubleshooting.
    – Amumu
    Commented Mar 25, 2011 at 14:58
  • @Adam: An assembly-only "OS" probably don't have many bells and whistles (such as fancy animated GUI and a paint program), rather it might only be able to run one or two user-mode processes...
    – Macke
    Commented Mar 25, 2011 at 15:12
  • @Macke: You're kidding? More multitasking operating systems have been written in assembly language than have been written in C. The operating system from which NT (the Windows kernel) was cloned was written primarily in Macro-32 assembly language. Commented Mar 25, 2011 at 18:48
  • 1
    @bit-twiddler: Are you sure? Most of the sources I saw were in BLISS...
    – TMN
    Commented Mar 25, 2011 at 19:34
  • @TMN: BLISS was only used for higher-level OS stuff. The entire VMS kernel was written in Macro-32. I kept a listing of the fork-level processing code for years because I thought it was such a cool idea. Fork-level processing was a mechanism by which an interrupt handler could schedule the non-time-critical portion of its code to run at a lower interrupt priority level. Fork-level processing was renamed to Deferred Procedure Calls in the NT kernel. Commented Mar 26, 2011 at 3:44

I think knowing some low level stuff is very helpful for debugging, like for instance with Embedded programming most of it is done with C, however when debugging knowing assembly for that particular Micro controller is extremely useful.

  • Agree. I've been doing embedded programming for some 30 years, and while I don't find myself having to write assembly code very much anymore (everything is in C), I often step through a program on an instruction by instruction basis.
    – tcrosley
    Commented Mar 25, 2011 at 18:23
  • Heck, I often debug C and C++ code in CPU mode on Windows. Knowledge of the architecture and the instruction set for the processor as well as the run-time organization of the compiler in use is a powerful set of skills to have in one's bag. Please see the following programmers.stackexchange.com question where I detail GCC generated code: programmers.stackexchange.com/questions/59880/… Commented Mar 26, 2011 at 3:59

When computers were first invented only a few people knew how to use them. Now, most any home in a wealthy country has 1 or more computers that are usable by the average person. Many common people have jobs working on computers daily. The average person has the ability to use a computer, but we still need programmers.

Similarly, the average programmer does not need to know or regularly program in assembly language. This is just as much a condition of marketable skills as it is a salute to how far we have come in the world of technology. Business needs computers to automate tasks. Therefore, programmers who can program in .NET/Java are in great demand.

The tasks which can be automated, will be automated. Not all tasks can be automated. Not all automation is perfect. So, is assembly important? Of course. Is it required to be a "programmer". Of course not.


Hmmm I actually enjoy learning low-level stuff.

Maybe it's not the most accurate simile, but to me it's like learning the machinations inside a car. I may not know how all the pieces work against each other, but it's fun to know that there's an engine, a crankshaft, cylinders, differentials, cranes, brakes, oil, combustion, refrigeration, and then friction, stress, heat, forces, science—thermodynamics, physics, fluid mechanics...

Maybe not very useful (I won't be able to fix a car by knowing all of this), certainly not professionally practical, but, well, fun. L'art pour l'art: la connaissance pour la connaissance.


I think a useful rule of thumb is - the faster it needs to be, the lower level you need to get.

So your graphics intensive first person shooter, or your algorithmic FX trade system, they're still fairly low level (C++, etc) because speed is key. But the web app that spits out a sales report on time? Hell, you could write that in Sinclair BASIC, and it'd still be acceptable.

  • 1
    -1: I think a useful rule of thumb is - the faster it needs to be, the lower level you need to get. - Just curious, how old are you? Better algorithms, better architecture, and better hardware will accelerate most modern software applications. Computer games and embedded systems are exceptions to this rule.
    – Jim G.
    Commented Jan 13, 2012 at 5:34
  • Far too old!:-) You mention better algorithms, better machine architecture, better hardware - but to my mind these have a equivalent impact on process execution speed. Increase processor speed then every process (ought to) run faster regardless of language it was developed in. Use a slow sort algorithm and your application runs slower than need be, no matter what you wrote it in. I posit the choice of low level or high level programming language still makes a relative difference to execution speed. If milliseconds are important, go low. Algorithmic trading systems aren't written in Java. Commented Feb 27, 2012 at 16:48

Not all software engineering jobs are the same. The folks working on operating systems, compilers, frameworks, device drivers, embedded systems, and high-performance scientific computing darn well need to know 'low-level stuff'. The folks writing Access CRUD forms, or PHP shopping-carts for Mom and Pop stores, maybe not so much. What kind of software engineering do you want to do, and do you want to do it the rest of your life?

My opinion is that you need to learn at least one level of abstraction below the one you usually work in. If you work in C/C++ then you should pick up some machine architecture and assembly. If you work in PHP then you should understand HTTP and a little C/C++ or Perl. If Access is your bread and butter then you'd better know some RDB theory, and maybe a little bit about COM or .Net. Sometime in your career you will eventually get stopped dead in your tracks by a problem at a lower level of abstraction, and you'll need to be able to communicate at least a little with someone who's an expert in that area. Can you 'get by' without this stuff? Sure, but planning to just 'get by' in a competitive job market is hazardous.


I myself work extensively in C# .NET and have always steered away from C, C++. Recently started to look for job and was surprised to see how many job are available and require experience for C, C++. I initially though that C, C++ were becoming outdated but looking at the available jobs, it does not look like that is the case.


All of the managed languages that you listed have interpreters or virtual machines written in C/C++. With out those two, most managed or interpreted languages would not even exist. I would say that you underestimate their value.


I really hate the very notion of a "practical" knowledge. Everything you ever learn is equally practical. It does not matter if you will not be operating at a level of abstraction close to hardware, simply knowing the concepts from that domain is always beneficial for constructing new knowledge at another level of abstraction. The more related concepts you know, the better.

For what I normally do, C# is a very low-level language, and I consider it as something very close to a hardware. But still I believe that even my rudimentary, rusty knowledge of the digital electronics, CPU design, etc., is very useful for everything I'm ever doing.

  • @Amumu said: You made a good point. People usually associate knowledge which earn themselves lots of money is "practical knowledge". However, they do have a point. At the very least, we expect and are expected to contribute something to society if we don't earn any money from the things we learnt, especially things that's not benefit our life. For example, we may want to learn philosophy or ways to help our life more meaningful. But if we spend time studying mathematics, electric but just half way, we can do nothing, and waste your time.
    – Adam Lear
    Commented Mar 25, 2011 at 21:01
  • @Anna Lear, the problem is that one cannot master a "practical", directly applicable skill without a very broad coverage of "non-practical". Simply because all the knowledge in this world is tightly connected. No knowledge can be a "waste of time", no matter how far it is from any possible practice.
    – SK-logic
    Commented Mar 27, 2011 at 16:03
  • 1
    -1: Everything you ever learn is equally practical. - Wow. Maybe I should memorize the answers to all of my 'Trivial Pursuit' question cards! ;)
    – Jim G.
    Commented Jan 13, 2012 at 5:24
  • @Jim G., yes you should, as long as you've got enough free time and it won't be at a cost of not learning something that would advance you more than this. Memorising "useless" things is in fact a very robust way of improving your memory.
    – SK-logic
    Commented Jan 13, 2012 at 8:05

No the majority don't need to. Although practicing low level techniques gives a developer better knowledge of what could affect the cycle as a whole, nowadays developer could make use of that time to study newer technologies, which in turn required knowledge of low level stuff to be developed but not to be relied on.


In my view, when you use a word "Engineer", you mean the man/woman is the one who design & build the things from very scratch. A Software Engineers' real problem is to solve a problem, but what problem? It's a big question.

A Developer is different from an Engineer in many ways. A "Developer" is a person who usually build things on already existing platforms. He develop the existing platforms or builds new platform inherits from older ones certainly using it's parent system's component.

A Developer usually thinks from a business perspective, he's not a Scientist. :) Developer is more close to user of the system, they think things from a user perspective and hence end up solving user problems using technology.

An Engineer a smart one. He's a Scientist, he resolves a very genuine issue. Most of the issues, which computer itself has it as a feature.. We user never get close to that problem, it's encapsulated. Engineers are the one who leave their studies behind after researching a lot on existing system and come up with something new to resolve the issue, if solution demands, if their system needed new language they invents new language because the existing system isn't capable of resolving that issue.. Engineers ended up building a system on which Developers build their system.

Indeed, a Software Engineer needs to learn and be well versed with low level stuff... :)

Whereas a Developer, it's completely depends on his interest. :)

  • 1
    -1: Umm... Job titles are meaningless, dude.
    – Jim G.
    Commented Jan 13, 2012 at 5:27

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