Managed Coders vs Native Coders

Question

I'm a coder and have experience with both native and managed code. I started out with Pascal and C, then moved into C++ and eventually into C#.

Over the last year or so, I've been coding almost exclusively in C# and have lost a lot of what used to come naturally when I was a C++ coder.

A few weeks ago when I sat down to write some native C++ code, I found myself fumbling around as I slowly got re-acquainted with the complexities, quirks, and idiosyncrasies of it all. I'm almost embarrassed to say that I had completely forgotten that passing a dynamically allocated array to a function without also passing its size would mean that the receiving function would have no way of knowing how long the array is.

There are countless articles and documents which compare and contrast managed vs unmanaged code. We all know that native code, if well optimised, can run significantly faster and lighter than managed code. On the other hand, managed code has garbage collectors and run-time CPU-specific and OS-specific optimisation which can give native code a run for its money.

Purely from a technical perspective, there is no clear winner.

There is no doubt that managed code is orders of magnitude simpler to code and understand. Just look at difference in the number of lines necessary to construct a simple GUI in Win32 C++ vs C#.

Back in my native-coding days, I mostly wrote mathematical simulations that ran on supercomputers. They had ugly CLIs and were mostly algorithm-focussed. Nowadays I write in C# and produce beautiful GUI applications, but would be lost if I had to make something of a similar calibre on a native language. Even with a framework such as QT, it would still take twice as long to produce something in C++/QT than it would in C#.

Whenever I see someone who has written a large-scale, full-featured GUI application in C/C++, I can't help but feel a sense of awe and a hint of jealousy.

I'm curious how other experienced coders see managed and unmanaged languages. Do you see managed code as amateur-ish? Do you see native coders as more hardcore?

Answer 1

My day job is currently in C++, but I've programmed in several languages long enough that I barely notice a difference anymore. Here are my observations:

• A lot of the alleged inefficiencies with other languages are frequently reimplemented by C++ programmers as best practices. We add enough null checks, array bounds checking, type checking, input validation, etc. to largely negate any execution speed advantage gained by the language not automatically doing those things, at least for code that isn't data processing intensive.
• That extra boilerplate becomes an ingrained habit after a while, so that it doesn't really feel like extra work, and sticks out like a sore thumb when it's missing.
• When I program in a "managed" language I still think about memory allocation, so as to make sure I don't create a memory leak. I may not be putting an explicit delete, but I'm still aware in my mind of the point at which the garbage collector considers it eligible for deletion. I had more difficult to solve low memory issues starting out in Java than I ever did in C++, probably because in C++ they are much harder to ignore for very long.
• Same goes for dynamic typing. I still have to keep track in my head of whether a function parameter is an array, or an int, or a string. In fact, it requires more mental effort because the type isn't plainly listed right there for me.
• Modern C++ style is very different than the pre-C# era. Rather than the language changing, people "discovered" how to use existing C++ features in unique ways to avoid much of the menial memory management of the past. Design patterns that free memory automatically are very common now.
• As far as I know, even though it's possible to make GUI applications by only writing code, graphical designers like QT designer are the vastly preferred method, with code mostly only used for event handlers or runtime customization.
• Languages you haven't used extensively in a while always feel a little clumsy, even if you mostly remember the syntax. If I don't write python for a year, there are a lot of idiosyncrasies I have forgotten, and it feels more awkward than C++ for a while, even though objectively most people consider python the "easier" language.

With the combination of all those factors, my mental model stays fairly consistent between when I program in C++ and other languages, and the differences feel mostly merely syntactic. Granted, a lot of that is a result of training, habit, coding standards, and modern design patterns rather than features intrinsic to the C++ language itself, but the comparison still stands.

I guess what I'm trying to say is that in my experience the programmer's training makes a lot more difference than the language he is using.

Answer 2

Do you see managed code as amateur-ish? Do you see native coders as more hardcore?

No.

I see the differences between an engineer and a programmer. The hardcore engineer will always choose the language/tech stack that's appropriate to get the job done in the least amount of time at an acceptable runtime standard.

With processor power these days, the frequency of actually needing to get as much as you can out of a machine by using lower level, native languages is getting less and less. There usually really just isn't a business case for it. Productivity will always trump a few milliseconds difference in execution time.

Answer 3

Sadly, Microsoft has lead us to conflate "Managed Code" with the C#/.Net class Libraries.

There are two separate and almost unrelated things at play here.

1. Cool .Net libraries.

2. Managed code.

C# offers both in a tidy, supported, easy-to-use package for one price.

C++ has numerous cool libraries that do almost everything .Net does. Rather than blame "native C++" code as being having more "complexities, quirks, and idiosyncrasies" than C#/.Net code, you could look for better C++ libraries.

Better libraries allow you to write nice C++ code, also.

Whenever I see someone who has written a large-scale, full-featured GUI application in C/C++, I can't help but feel a sense of awe and a hint of jealousy

Bad policy. Instead you should find out what libraries of class definitions they used. You, too, could use those libraries.

It's all about the tools. Without tools, we're just animals in pants.

"Native C++" does not mean you should throw away all your tools. It means you have to find good tools. Microsoft is no longer helping you, so you need to spend time finding the right mix of tools.

Answer 4

The issue here isn't about hardcore programming or anything like that, it's about control. The fact is that C# offers productivity at a cost of control. If you're writing a program that needs a high amount of control (this memory is deallocated exactly now), then you have no choice but to use C++. If you need to get it done quickly, then you may need to use C#. The issue is that the supporting libraries for C# are much better and more recent than provided for C++. For example, MFC is very, very old and it's practices are known to be terrible, it was mostly written long before Standardisation. If Microsoft put some effort into providing new C++ libraries, for example, check out the new PPL in Visual Studio 2010, then strangely enough, that task becomes easy in C++. And I think that they are migrating that way, because they realized that managed code doesn't solve every task.

On the other hand, managed code has garbage collectors and run-time CPU-specific and OS-specific optimisation which can give native code a run for its money.

I've heard many managed language proponents say this, but I've pretty much never actually seen it to be true. The fact is that the new CPU instructions available in newer CPUs simply don't offer that much of an advantage unless you're doing very hardcore mathematics, in which case you can't afford the overhead of having to compile or interpret it at run-time and you could just use Intel's C++ compiler to use the latest and greatest in SSE anyway. The scope of C++'s compiler optimizations is massive compared to what the JIT can do, because the JIT has to execute in a fraction of the time whilst the program is running, whereas C++ compilers are pretty legendary for taking their sweet time to compile.

Garbage collection is not some kind of magically great thing or something like that- it's an algorithm choice. Is it appropriate for all situations? Not by far- look at the IDisposable mess in C# and how Java didn't even bother to try with that issue, whereas C++'s destructors will close your files and free your memory and close your sockets, etc etc. GC is great for some programs, and not for some others.

Answer 5

In my opinion native C/C++, comparing to C#, looks like assembler to C/C++ itself. Another complex layer of abstraction (not exctly true, but let's say so) as always, gives you easier development, but some reduction in speed and some excessive memory usage. So, as I see it, it's just splits to different categories, thus creating new subtypes of programmers.

Btw for it's level of abstraction C# is incredibly fast, microsoft did an excellent job.

Answer 6

There are amateurish programmers, not amateurish languages. Languages they have all (well, most of them at least) their purpose.

I am currently co-working on a insurance calculating engine used to test the production system. The production system has been made in C, our engine is done in Java and since longer time we outperform the C engine, being at the same time much more productive. Not because Java per se is faster than C, it is just fast enough and our algorithms are better, we have implemented them more easily, we could faster and better test and refactor our code.

I also wrote testing code to compare calculation results with the content of production database: not in C, not in Java but in Ruby. Again, it is fast enough and needs much less code so is easier to implement, easier to test, easier to expand.

And I don't feel amateurish no matter what language I use, I feel that way only if I make a stupid bug that shouldn't have happened.

Answer 7

Last year the firm I work at were reverse engineering a communications CRC code by brute force (we got it eventually). 3 Developers each had there own version, Borland C, C#.Net 2008, VB6. VB6 was obviously slow, Borland C was quick but the C#.net just flogged it by 12 times the speed. Wasn't what we expected at all.

Answer 8

It depends on a mix of things, but basically, all else being equal, yes, native code is more "hardcore" than managed code.

I guess that's usually a bad thing, though, for a normal business application, because it means the average developer must put more mental energy into non-business aspects of their code.

Answer 9

My program is what could be best described as C++ like Java. My opinion is you can achieve the same low level programming in Java, but it is much harder than low level programming in C++. However, you usually need this low level programming in a small fraction of your code and where it is not required a managed language is more productive.

Answer 10

Native developers usually get the reputation for being more hardcore because they feel more hardcore and act that way. Native developers are trained in a system not tolerant of any mistakes because they inevitably lead to hard crashes or unbounded memory leaks. In particular, .NET allows lazy hacks like putting try/catch around everything, saving the developer from thinking they have to understand the core issue ("sometimes, it just throws InvalidOperationException. I can't explain it, let's just catch everything. This code is critical!"). This isn't at all black and white, but are my observations having grown up in the unmanaged world and now working in managed code full time.

In addition, managed developers also tend to have access to far cleaner and more organized BCL's. This often encourages them from exploring what actually happens under the covers. True, the same can be said for, say, STL or Boost, but the .NET class library is often good enough to make us intellectually lazy at times.

That said, writing a good, shippable managed program takes a lot of work. That means doing memory and CPU profiling, unit tests, and code analysis in similar ways that unmanaged developers do it. Unmanaged developers tend to understand this going in, and managed developers tend to include more of those who don't.

Again, not black and white. There are many intellectually lazy unmanaged developers and hardcore managed developers. Neither is by definition more elite than the other.

Answer 11

Do you see managed code as amateur-ish? Do you see native coders as more hardcore?

There's a gap between the two world, and I can't see why: managed systems are somewhere written in native code (as final, everything runs "in assembly"). What I want to see (yet in my life) is an application constructing system, where all the sub-task of the application will be written in the right language type.

Answer 12

Native code got easier since Go was released. I find it easier to both read and write than Java and C#. Although GUI programming with Go, as of now, is not very nice (I took a quick look at the options).
Try not to judge it for it's lack of large community and variety of libraries compared to C# (for example), because it's still considered new.