C/C++ are not the only performant languages. The software development community has, for years, labored under fallacies concerning managed languages. I'm using "managed" to describe everything from scripting languages to Java/C#/Lisp / etc.

The reason that you (and many other people) think that these languages are inherently slow is simply this -- they haven't had the same amount of time to mature as C/C++ has. C/C++ traces its roots back to languages designed and built in the 1960s -- that's 40 years of optimization, experimentation, etc.

Managed languages are catching up. Managed languages that use JIT compilers (translation to native assembly code, rather than using an interpreter) are capable of performance as good as -- and in some cases better than! -- C/C++.

Also, it is NOT the wrong attitude. Try telling your boss this: "I would rather take a risk on security holes, rather than spend $100 on more RAM." RAM is cheap. Security compromises are INCREDIBLY expensive -- not just in lost time and money, but in the perception of your company. Who trusts a company that has been compromised? Or has been compromised repeatedly, because they use (or develop) insecure software?

Security is too important to be left to humans. The more secure we can make our langauges, the better. In Java/C#, you simply eliminate huge classes of memory errors, and you eliminate precisely the ones that are so common in C/C++ development.

I have been developing software professionally for 10 years now. Jon Lasser has hit the nail on the head: It is extremely irresponsible to continue to use languages and environments (C/C++) that are KNOWN to be conducive to security bugs, when better languages and tools are available. (With the caveat -- correctly stated by Jon Lasser -- that in some cases you have no choice but to use C/C++.)



[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/150/18901#18901