5 ms·

At the risk of getting downvoted for what could be a humongous display of ignorance, although the theoretical grounding of the article seems interesting, I fail

At the risk of getting downvoted for what could be a humongous display of ignorance, although the theoretical grounding of the article seems interesting, I fail to see how any of this can get applied to "real-life" applications when this is basically ten pages of content to get to apply this to addition operation and for other problems which are, for most day-to-day practice, already solved quite succintly. Perhaps it's just me, but it seems like an awful lot of conceptual baggage to do things that can be expressed with much greater simplicity and without resorting to concepts that need multiple years of expert knowledge of the language to get this "elegance". And i understand the theoretical elegance, it's just that I have to ask myself if this truly makes an actual difference in code style, simplicity, and clarity of language.

lisper 13y ago
No, you are exactly right. The C community and its progeny has, over the years, dug itself into a deep, deep syntactic and semantic hole. It is now coming to realize that the Lisp folks had some good ideas after all, but because of the sunk cost fallacy the C folks are unwilling to just back out of the hole. Instead, they keep digging the hole deeper and deeper in the hopes that some day it will emerge into the light. C++11 is interesting in the same way that Brainfuck is interesting: it's remarkable that you can take such a horrible mess and make it do cool things. But it's just a parlor trick, kind of like escaping from a straightjacket while handcuffed. It's challenging, and it requires skill, but 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.
- nickbauman 13y ago
  Here I was thinking that they finally read the memo.
- hdevalence 13y ago
  > 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 13y 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 13y 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++ :)
- jasonzemos 13y ago
  The problem I have with this class of critical analogies is that they don't recognize the underlying goal of all this lipstick on the pig. The parlor tricks being done here combine the benefits of other language concepts with the strict efficiency and deterministic overhead of traditional C. Contrast with other languages that might provide a more elegant interface- but with what kind of indirection? And what sacrifices over full-stack control of that indirection? That's why what gets added to the C++ standard -- specifically the philosophy of that process -- has tangible value and purpose that shouldn't be dismissed by simply saying it's better to throw it all away.
- austinz 13y ago
  To be fair, the C community doesn't see the relative simplicity of C as a liability, and believes that there's an argument to be made that, in the hands of a competent and careful engineer, C is a good choice of language for certain specific problem domains. There's a related but distinct community that believes that stuffing as many features into their language of choice as possible can only make it better.
- comex 13y ago
  That may be true, but the article certainly doesn't prove it. The article repeatedly mentions C++11, but as mentioned elsewhere [1], C++11 has lambdas; even if you want to do the partial binding thing, there is no need for a struct, and obviously a static "add one" function can just be declared as a regular function. So what's the point of the struct declaration other than making C++ look bad? Another sign of the lack of coherence of the article is that it displays unoptimized assembly output for the C++ example, then goes on to praise Lisp for being around as good. The optimal assembly is actually two instructions: 0000000000000000 leal 0x1(%rdi), %eax 0000000000000003 ret Not that it really matters, since it will be inlined into any hot loop in both cases. [1] https://news.ycombinator.com/item?id=7619116 https://news.ycombinator.com/item?id=7619116
  - nkurz 13y ago
    Sorry to quibble about details, but doesn't "leal 0x1(%rdi), %eax" actually add one to the address %rdi and not to the contents of (%rdi)? It's usefulness for trick additions is because of its origins as "Load Effective Address": it doesn't actually access memory. Their stack gymnastics are silly, but I think you may be stuck with "mov (%rdi), %eax; add $1, %eax; ret" or some other 3 instruction equivalent.
    - pbsd 13y ago
      You're right, it does add 1 to RDI, but this is exactly what we want. This is x86_64 calling convention, where arguments come on registers, not the stack. On 32-bit x86 you'd do something like mov eax, 1 add eax, [esp + 4] ret

lisper 13y ago

No, you are exactly right. The C community and its progeny has, over the years, dug itself into a deep, deep syntactic and semantic hole. It is now coming to realize that the Lisp folks had some good ideas after all, but because of the sunk cost fallacy the C folks are unwilling to just back out of the hole. Instead, they keep digging the hole deeper and deeper in the hopes that some day it will emerge into the light. C++11 is interesting in the same way that Brainfuck is interesting: it's remarkable that you can take such a horrible mess and make it do cool things. But it's just a parlor trick, kind of like escaping from a straightjacket while handcuffed. It's challenging, and it requires skill, but 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.

nickbauman 13y ago
Here I was thinking that they finally read the memo.
hdevalence 13y ago
> 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 13y 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 13y 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++ :)
jasonzemos 13y ago
The problem I have with this class of critical analogies is that they don't recognize the underlying goal of all this lipstick on the pig. The parlor tricks being done here combine the benefits of other language concepts with the strict efficiency and deterministic overhead of traditional C. Contrast with other languages that might provide a more elegant interface- but with what kind of indirection? And what sacrifices over full-stack control of that indirection? That's why what gets added to the C++ standard -- specifically the philosophy of that process -- has tangible value and purpose that shouldn't be dismissed by simply saying it's better to throw it all away.
austinz 13y ago
To be fair, the C community doesn't see the relative simplicity of C as a liability, and believes that there's an argument to be made that, in the hands of a competent and careful engineer, C is a good choice of language for certain specific problem domains. There's a related but distinct community that believes that stuffing as many features into their language of choice as possible can only make it better.
comex 13y ago
That may be true, but the article certainly doesn't prove it. The article repeatedly mentions C++11, but as mentioned elsewhere [1], C++11 has lambdas; even if you want to do the partial binding thing, there is no need for a struct, and obviously a static "add one" function can just be declared as a regular function. So what's the point of the struct declaration other than making C++ look bad? Another sign of the lack of coherence of the article is that it displays unoptimized assembly output for the C++ example, then goes on to praise Lisp for being around as good. The optimal assembly is actually two instructions: 0000000000000000 leal 0x1(%rdi), %eax 0000000000000003 ret Not that it really matters, since it will be inlined into any hot loop in both cases. [1] https://news.ycombinator.com/item?id=7619116 https://news.ycombinator.com/item?id=7619116
- nkurz 13y ago
  Sorry to quibble about details, but doesn't "leal 0x1(%rdi), %eax" actually add one to the address %rdi and not to the contents of (%rdi)? It's usefulness for trick additions is because of its origins as "Load Effective Address": it doesn't actually access memory. Their stack gymnastics are silly, but I think you may be stuck with "mov (%rdi), %eax; add $1, %eax; ret" or some other 3 instruction equivalent.
  - pbsd 13y ago
    You're right, it does add 1 to RDI, but this is exactly what we want. This is x86_64 calling convention, where arguments come on registers, not the stack. On 32-bit x86 you'd do something like mov eax, 1 add eax, [esp + 4] ret