Slashdot Mirror
C++ 2011 and the Return of Native Code
snydeq writes with an editorial in InfoWorld about the resurgence of native code. From the article: "Modern programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net, which shield them from some of the drudgery of memory management and input validation. Others are willing to sacrifice some performance for the syntactic comforts of dynamic languages such as Python, Ruby, and JavaScript. But C++11 arrives at an interesting time. There's a growing sentiment that the pendulum may have swung too far away from native code, and it might be time for it to swing back in the other direction. Thus, C++ may have found itself some unlikely allies."
Native was never away. It always has its place. It is just that performance/efficiency is not always top priority.
The larger picture is fucking use the right tool for the job already.
Java has its purposes. Write-once, Run-Almost-Anywhere is a good concept. Likewise, some of the other tools in other managed frameworks make certain things really simple.
And when you need power and speed at the expense of having to do things a lot more exact yourself, then go to a language that'll work that way.
The problem is not that one or the other is "bad." The problem is that too many programmers are golden-hammer morons who think their favorite tool is the only correct way to do everything on the goddamn planet, which is why you get Java applications running a chip on little mini kids games to do something that could have been done with a 5-cent microchip.
Yes, because managed code has no memory leaks. Please. I work on a mixed C++/Java Android codebase. I haven't found a memory leak on the C++ side in months. The Android framework decides to hold onto random references every new version.
Quite frankly, memory management is not hard. If you don't understand the simple idea of allocate, use, release, then you are a complete incompetent and should not be programming professionally. I'll go so far as to say it's better for a language NOT to automatically manage your memory- in general the first sign of a bad or failing architecture is that object life cycles and memory allocation start to be non-trivial. Managing your own memory catches those architecture bugs and leads to cleaner, easier to understand code. And the cost is absolutely minimal, I doubt I've spent 10 minutes in the past 2 or 3 years actually debugging memory problems in C++.
I still have more fans than freaks. WTF is wrong with you people?
...choose the tool that's best for the job, don't choose the job that's best for the tools you know already.
Game developers, for instance, are among the guys who write the most performance sensitive code out there, and they use a mix of C, C++, C#, Lua/Python for the various parts of the game. Usually the inner, tight loop is written in C/C++, higher level modules are written in C# and designer/modder scripts are written in a very high level language such as Lua. There is no best language in general, and whoever says otherwise is often an idiot.
My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
I think there was a hope that computing power would catch up and make VMs a competitive alternative to native code.
While you're right there's a computing power issue here, the issue is battery life not lack of CPU cycles. VMs add overhead, as you add overhead you'll run longer and burn more power on the CPU. If you want to squeeze all you can out of a limited battery you need to optimize your code and in the end that's going to mean native code with very explicit memory management. VMs just don't play well in embedded environments.