4 ms·
My best guess about why people are still using C and C++ is this: there is a massive, valuable ecosystem of software written in these languages. It is hard to
by betterunix 12y ago
My best guess about why people are still using C and C++ is this: there is a massive, valuable ecosystem of software written in these languages. It is hard to write software in one language that links with software written in other languages, especially where performance is a concern. The fact that all commonly used commercial OSes are both written in C and expose C APIs has kept C and C++ alive more than anything else.
Performance? Lisp can give you that, as can OCaml, Haskell, and other better languages. Real time system? There is a mountain of research on real-time garbage collection and on using HLLs for real-time systems. Operating system kernel? OSes were once written in Lisp, and OSes could conceivably be written in other HLLs.
Throw in a requirement to interoperate with a C library and suddenly things get ugly. Yeah, sure, you have an FFI, but debugging across a language barrier is difficult (I have had to do it, it is agony). Suddenly you need to worry about pinning objects so that the garbage collector won't move them while some C library expects them to stay still. In some cases your code basically becomes C but with the syntax of an HLL, and you start to wonder why you did not just write that routine in C to begin with (it would have made your life easier). Performance matters but your compiler needs to set up a trampoline so that your code can provide some kind of callback, and now that is a bottleneck that kills all that other optimization work. Then some joker writes some C++ code, and the rest of your week is spent writing wrapper functions because your FFI cannot deal with the name mangler.
At the end of the day there is no particular technical reason for C or C++ to remain so popular, and a big pile of technical reasons to stay away from such languages. C made a bit of sense in the 1970s when computers were small and the understanding of compilers and programming languages was less well developed. At this point C and C++ are a liability that we are all stuck with. Maybe some day the expense of sticking with C and C++ will outweigh the expense required to switch to better languages, but I am not holding my breath.
- groby_b 12y ago"Lisp can give you that performance" is, however, more an article of faith than actual reality. Yes, it comes within a 3x-5x factor, on a good day. And for many applications, that's good enough. However, for either heavy-duty computational tasks or very responsive interactive tasks with a strong computational component, it just doesn't work. If you have evidence to the contrary (for non-trivial examples), please share it. It's not my love for the exquisite language design that keeps me with C++ :)
- reikonomusha 12y agoNon-trivial examples include: * High-frequency trading [1] * 3D graphics and CAD systems by Symbolics * Operating systems by Symbolics [2] * Computer algebra [3] * Supercomputing [4] * Embedded, real-time forensic fingerprint systems (fingerprint analysis, embedded databases) [5] * High-frequency auctions * Performant compilers (most Lisp compilers) * Perl-compatible regular expressions (sometimes 2x the speed of perl) [6] And I can assure you, there are extremely many other things. Generally, if you write absolutely correct and robust C++ code (that ensures there will never be buffer overruns, integer overflow, etc.), you'll see your code will slow down a lot. Lisp ensures these things don't happen (among many other things), and only when you tell Lisp that you are absolutely sure such things cannot happen, then your Lisp code can and often will be competitive with C or C++. C++ has also benefitted from corporations funding the research and development of the compilers, whereas Lisp hasn't. So, as a result, the speed is partly an artifact of the implementation, not the language. Lastly, as my own aside, the supposed "raw speed" of C (and lesser so C++) is no excuse to architect an entire system in it. There are hot paths in code that need speed, and perhaps attention should be given to those. [1] http://www.hpcplatform.com/ http://www.hpcplatform.com/ [2] http://en.wikipedia.org/wiki/Genera_(operating_system) http://en.wikipedia.org/wiki/Genera_(operating_system) [3] http://maxima.sourceforge.net/ http://maxima.sourceforge.net/ [4] http://en.wikipedia.org/wiki/Connection_Machine http://en.wikipedia.org/wiki/Connection_Machine [5] http://arxiv.org/abs/1209.5625 http://arxiv.org/abs/1209.5625 [6] http://web.archive.org/web/20080624164217/http://weitz.de/cl-ppcre/#bench http://web.archive.org/web/20080624164217/http://weitz.de/cl...
- iopq 12y agoRust gives you guarantees at compile time that your program is correct and theoretical performance is above C/C++. I really hope people write OSes in it. Yes, you'll have to have a lot of inline assembly and "unsafe" code, but those things can be very closely looked at. The common glue code can be safe without buffer overruns.
- reikonomusha 12y agoFor what it's worth, people have said the same thing about C: "As long as (many) people look closely enough at it, it'll be fine."