Do software engineers really need to know low level stuff anymore?

Question

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?

Answer 1

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

Answer 2

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

Reasons:

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

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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