5 ms·

> at the end of the day you're in the exact same place as if you'd never put the handcuffs and straightjacket on to begin with. Do you have any suggestions on

> at the end of the day you're in the exact same place as if you'd never put the handcuffs and straightjacket on to begin with. Do you have any suggestions on what tools the people doing 'parlor tricks' with C++11 should be using to accomplish them, then? That is, what would you suggest to get to that place without the straightjacket? Note that at a bare minimum, these supposed tools should give the ability for fine-grained manual resource control, zero-(runtime)-cost abstractions, and performance roughly on-par with C++. As evidence that these hypothetical tools work well for the purpose, we could look for some complex and high-performance software written in them: say, a browser engine, a 3d engine, a kernel, etc., but wait a minute -- these are all things that tend to be written in C++ or plain C. Instead of glibly dismissing the language that's used to implement, say, every major browser engine, wouldn't it be more productive to ask questions about why people use it? Bonus points if the answer is something more realistic than "They don't know Lisp". That way, you end up trying to figure out how to make a replacement for it that is an actual replacement -- Rust is a fantastically exciting example of this. It'll be great when we can all move away from C++, since it's a colossal clusterfuck of counterproductive complexity, but "C++ is a bad language" misses the point in a really uninteresting kind of way.

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 ago
    Non-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...
lisper 12y ago
> Do you have any suggestions on what tools the people doing 'parlor tricks' with C++11 should be using to accomplish them, then? That is, what would you suggest to get to that place without the straightjacket? Duh, Lisp of course. (Or Haskell.) > Note that at a bare minimum, these supposed tools should give the ability for fine-grained manual resource control Check. Lisp provides garbage collection, but you don't have to use it. It's perfectly possible to write Lisp programs that do manual memory management. It isn't often done because it's hardly ever a win, but if you really want to you can. > zero-(runtime)-cost abstractions a.k.a. macros > and performance roughly on-par with C++. The SBCL compiler is pretty good. But one of the reasons that Lisp code is not generally as fast as C/C++ is that Lisp code is safe by default whereas C/C++ code is not. You can make Lisp code unsafe (and hence faster) but you have to work at it, just as you can make C/C++ code safe, but you have to work at it. I submit that in today's world, being safe and a bit slower by default might not be such a bad place to be in the design space. > these are all things that tend to be written in C++ or plain C. There is a world of difference between C++ and plain C. C is actually not a bad language if you want to write fast code with relatively little effort and don't care about reliability or security. The value add of C++ over C is far from clear. (I don't know of any OS written in C++. Linus wrote a famous rant about why Linux is written in C and not C++. There are, however, examples of operating systems written in Lisp.) > wouldn't it be more productive to ask questions about why people use it? I know why people use it: it's fast, there is a huge installed base, and it's an excellent platform for studly programmers to display their studliness. That doesn't change the fact that C++ has deep design flaws which result in its being incredibly hard to use and extend. And the existence of coders studly enough to be productive in C++ does not change the fact that it imposes an extremely high cognitive load on its users.
- Jweb_Guru 12y ago
  > Check. Lisp provides garbage collection, but you don't have to use it. It's perfectly possible to write Lisp programs that do manual memory management. It isn't often done because it's hardly ever a win, but if you really want to you can. How does LISP work without a garbage collector? Closures without a garbage collector are pretty awful. Let's keep in mind that Rust gives us a pretty good idea of what a safe system without a GC looks like, and it doesn't look anything like LISP.

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 ago
  Non-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...

lisper 12y ago

> Do you have any suggestions on what tools the people doing 'parlor tricks' with C++11 should be using to accomplish them, then? That is, what would you suggest to get to that place without the straightjacket? Duh, Lisp of course. (Or Haskell.) > Note that at a bare minimum, these supposed tools should give the ability for fine-grained manual resource control Check. Lisp provides garbage collection, but you don't have to use it. It's perfectly possible to write Lisp programs that do manual memory management. It isn't often done because it's hardly ever a win, but if you really want to you can. > zero-(runtime)-cost abstractions a.k.a. macros > and performance roughly on-par with C++. The SBCL compiler is pretty good. But one of the reasons that Lisp code is not generally as fast as C/C++ is that Lisp code is safe by default whereas C/C++ code is not. You can make Lisp code unsafe (and hence faster) but you have to work at it, just as you can make C/C++ code safe, but you have to work at it. I submit that in today's world, being safe and a bit slower by default might not be such a bad place to be in the design space. > these are all things that tend to be written in C++ or plain C. There is a world of difference between C++ and plain C. C is actually not a bad language if you want to write fast code with relatively little effort and don't care about reliability or security. The value add of C++ over C is far from clear. (I don't know of any OS written in C++. Linus wrote a famous rant about why Linux is written in C and not C++. There are, however, examples of operating systems written in Lisp.) > wouldn't it be more productive to ask questions about why people use it? I know why people use it: it's fast, there is a huge installed base, and it's an excellent platform for studly programmers to display their studliness. That doesn't change the fact that C++ has deep design flaws which result in its being incredibly hard to use and extend. And the existence of coders studly enough to be productive in C++ does not change the fact that it imposes an extremely high cognitive load on its users.

Jweb_Guru 12y ago
> Check. Lisp provides garbage collection, but you don't have to use it. It's perfectly possible to write Lisp programs that do manual memory management. It isn't often done because it's hardly ever a win, but if you really want to you can. How does LISP work without a garbage collector? Closures without a garbage collector are pretty awful. Let's keep in mind that Rust gives us a pretty good idea of what a safe system without a GC looks like, and it doesn't look anything like LISP.