6 ms·

Where is my C++ replacement?

31 points by ProgC 12y ago

deleted 12y ago
[deleted]
restalis 12y ago
The other HN submissions of this article: https://news.ycombinator.com/item?id=7918768 https://news.ycombinator.com/item?id=7918768 https://news.ycombinator.com/item?id=7898113 https://news.ycombinator.com/item?id=7898113
easytiger 12y ago
What a load of gibberish.
- woogle 12y ago
  This post remind me a lot https://rbt.asia/g/thread/41920845 https://rbt.asia/g/thread/41920845
- adamnemecek 12y ago
  Indeed. Tl;dr: D: kinda cool, not enough though. Rust: kinda cool, not enough though. golang: kinda cool, not enough though. Also how is D '''not a "high-performance" language'''?
  - c0de517e 12y ago
    I might have written too much about the languages I intended just to bring forward as example. D is not high-performance (I clarified that in the post) the same way as C and C++ are not. They are not meant for HPC, they are meant to be "systems" languages. The difference between the two is that HPC is usually about parallelism and has always been. Instruction level (SIMD and GPUs), threads, clusters and so on. D is a bit better than C++ as it at least standardizes SIMD a bit, but still IMHO it doesn't qualify as HPC. C++ adopted threads only in 11, doesn't have SIMD, doesn't know about GPUs, it got "restrict" only in 11 as well and so on and on. It's clearly not for HPC.
    - adamnemecek 12y ago
      So what do you consider a HPC language? > C++ adopted threads only in 11 Fair. > doesn't know about GPUs, Is there a general purpose language that has GPU support out of the box? > it got "restrict" only in 11 as well AFAIK, restrict is still not part of the standard, despite compilers implementing it.
      - easytiger 12y ago
        I still maintain he's talking nonsense. For a start most traditional HPC is done not via threads but via IPC. He's now not talking about languages but their libraries / platform offerings. Just because it is in the c++ stdlib doesn't mean you couldn't do it. Indeed the only reason it has been integrated into the standard platform the language offers is because it was proven over many many years as an external library.
        adamnemecek 12y ago
        I agree. As for the threads thing, I agree as well but there is a school of thought that believes that threads should be part of the language http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
        c0de517e 12y ago
        To both comments - it's not JUST because the lack of threads, don't take an example as the entire extent of the critique. It lacks threads. It lacks SIMD. It lacks control over pointer aliasing (restrict), something that FORTRAN did right decades before C++ and C is doing today but C++ still lacks, and it's quite fundamental to write high performance kernels. It does -NOTHING- of the things that are needed for performance, all these things had to be added by custom compiler extensions because it's a popular language and we have very, very good compilers, but the language standard itself lacks in a lot of ways for HPC
        12y ago
- tdsamardzhiev 12y ago
  Also a re-post.
ProfOak_ 12y ago
If you want a complete replacement for C++, I think you'll end up with the same complexity and rules as C++.
- deleted 12y ago
  [deleted]
- tdsamardzhiev 12y ago
  My thoughts exactly. Some people need to stop crying and start writing software.
- axilmar 12y ago
  Not really. The term "complete replacement" does not refer to the implementation details, but to the features the language provides. It's quite possible not only to offer a complete C++ replacement but to also substantially improve on C++ on all aspects.
  - mreiland 12y ago
    Not really. Probably the strongest point of C++, besides its performance, is its ability to interact with C easily and efficiently. A huge amount of C++'s complexity comes from this requirement, but the benefits are enormous. It's such a big deal that MS eventually just started recommending people use C++/CLI to interop with C instead of using the usual C# Interop methods. Too many people underestimate the extreme advantages that are still gotten today by that requirement. The rest of it, yes, you could, but not that specific requirement. Doing that efficiently and easily enforces certain restrictions on the language, and the underlying runtime.
    - alphagenerator 12y ago
      I actually think the strongest point of C++ is the nature of how template metaprogramming is done. Is there any other language that competes with C++ as effectively with templates? I feel like all these "C++ is bad" comments and articles are from people who've really only scratched the surface in C++. The expressiveness that's available to a programmer using templates in C++ is, to me, quite awesome.
deleted 12y ago
[deleted]
kentonv 12y ago
The idea that OOP is a fad and that everyone is abandoning it is... absurd. I think that the author thinks OOP means ObjectListenerBuilderProviderFactoryAdpterImpls and repeated use of words defined by Gamma et al. Actually, OOP is just the practice of encapsulation and abstraction, and the avoidance of globals/singletons* in favor of infinitely instantiable instances. These are not a fad, they are necessary components of all large-scale software. The Linux kernel, which is entirely written in C, is a fine example of object-oriented programming. File descriptors are object references. The filesystem is a beautiful heirarchy of polymorphic nodes. There simply is no non-OOP way to implement these things. * I cannot mention singletons without linking this essay of mine, even though I'm somewhat embarrassed that I never found time to fill in the rest of the site: http://www.object-oriented-security.org/lets-argue/singletons http://www.object-oriented-security.org/lets-argue/singleton...
- axilmar 12y ago
  Neither debug logging nor any other unique system resource has to be passed as a singleton. All that is needed is the appropriate ApplicationContext structure to be passed to each object that needs these facilities, and the ApplicationContext will contain all the singleton instances that are required.
  - kentonv 12y ago
    Yes, you can do that, it just gets tiring, because now you have a boilerplate parameter being passed everywhere. It really has to be passed everywhere, because you never want to get stuck without the ability to debug some function just because you didn't pass in the debug logger object. The environment pattern effectively makes this context implicit.
  - c0de517e 12y ago
    The solution is - more objects wrapping more objects. I can already imagine people doing exactly that. Dependency injection is the name of the game right? That's what videos on youtube are advocating... But it's also a pain to pass everything that is needed down to functions, so let's stuff all the global state in a class and pass that class down! I hope I just didn't get the sarcasm, really.
charlieflowers 12y ago
Tremendously insightful post. Sometimes the writing is a little rough ... don't let that fool you. Ultimately, I think he's right: what we need is to be able to invent and use high-level languages and DSL's that are wonderfully expressive for our domain (with fast iteration and all that), but also to be able to control the low-level run-time code that gets executed as a result, so it can be fast and efficient. That's the holy grail as I see it. And LLVM is a key contender to provide the backend of that vision. (TFA talks about a lot of other things, but this is pretty much how I interpreted its conclusion, and I agree).
yoanizer 12y ago
(Repost) Really we should stop talking so much about tools, and what tool/language/ide/whatever is best. Many years ago people didn't have half the tools we have now, and they still did amazing things. Most of what we have today is very good already. IMO focus on building products, not on bashing the tools. checkout http://prog21.dadgum.com/51.html http://prog21.dadgum.com/51.html
chris_wot 12y ago
Seems like a big whine. Every time I read one of these, I see a few good points, but then I think to myself "I wonder what they are programming in". I then wonder how long it will be before they get upset about some feature they consider to be inelegant and try to find the next fad or old language they had previously discarded. I really wish people would stop doing this. They like to tear down, without really building anything! It's sort of a whinge to tear things down without really understanding why certain concepts or ideas were invented. Kind of lame.
- c0de517e 12y ago
  Nowadays most of the code I have to deal with and that I write myself is very "c-like" C++. For personal projects I usually use C# instead.
  - chris_wot 12y ago
    I'm assuming you mean it uses less class heirachies and more composition. Is this correct?
    - c0de517e 12y ago
      Really I don't often use classes, unless they are providing a benefit. Just using them to group some state with some functions is not great because they have lots of drawbacks for that, I find an opaque pointer and C functions to be better at hiding implementation details and so on. I use classes basically when I need destructors and constructors, so for things that need to go in collections really. http://c0de517e.blogspot.ca/2012/09/follow-up-why-classes.html http://c0de517e.blogspot.ca/2012/09/follow-up-why-classes.ht...
      - chris_wot 12y ago
        Why not use a pimpl?

31 points by ProgC 12y ago

deleted 12y ago

[deleted]

The other HN submissions of this article: https://news.ycombinator.com/item?id=7918768 https://news.ycombinator.com/item?id=7918768 https://news.ycombinator.com/item?id=7898113 https://news.ycombinator.com/item?id=7898113

easytiger 12y ago

What a load of gibberish.

woogle 12y ago
This post remind me a lot https://rbt.asia/g/thread/41920845 https://rbt.asia/g/thread/41920845
adamnemecek 12y ago
Indeed. Tl;dr: D: kinda cool, not enough though. Rust: kinda cool, not enough though. golang: kinda cool, not enough though. Also how is D '''not a "high-performance" language'''?
- c0de517e 12y ago
  I might have written too much about the languages I intended just to bring forward as example. D is not high-performance (I clarified that in the post) the same way as C and C++ are not. They are not meant for HPC, they are meant to be "systems" languages. The difference between the two is that HPC is usually about parallelism and has always been. Instruction level (SIMD and GPUs), threads, clusters and so on. D is a bit better than C++ as it at least standardizes SIMD a bit, but still IMHO it doesn't qualify as HPC. C++ adopted threads only in 11, doesn't have SIMD, doesn't know about GPUs, it got "restrict" only in 11 as well and so on and on. It's clearly not for HPC.
  - adamnemecek 12y ago
    So what do you consider a HPC language? > C++ adopted threads only in 11 Fair. > doesn't know about GPUs, Is there a general purpose language that has GPU support out of the box? > it got "restrict" only in 11 as well AFAIK, restrict is still not part of the standard, despite compilers implementing it.
    - easytiger 12y ago
      I still maintain he's talking nonsense. For a start most traditional HPC is done not via threads but via IPC. He's now not talking about languages but their libraries / platform offerings. Just because it is in the c++ stdlib doesn't mean you couldn't do it. Indeed the only reason it has been integrated into the standard platform the language offers is because it was proven over many many years as an external library.
      - adamnemecek 12y ago
        I agree. As for the threads thing, I agree as well but there is a school of thought that believes that threads should be part of the language http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
        c0de517e 12y ago
        To both comments - it's not JUST because the lack of threads, don't take an example as the entire extent of the critique. It lacks threads. It lacks SIMD. It lacks control over pointer aliasing (restrict), something that FORTRAN did right decades before C++ and C is doing today but C++ still lacks, and it's quite fundamental to write high performance kernels. It does -NOTHING- of the things that are needed for performance, all these things had to be added by custom compiler extensions because it's a popular language and we have very, very good compilers, but the language standard itself lacks in a lot of ways for HPC
        12y ago
tdsamardzhiev 12y ago
Also a re-post.

ProfOak_ 12y ago

If you want a complete replacement for C++, I think you'll end up with the same complexity and rules as C++.

deleted 12y ago
[deleted]
tdsamardzhiev 12y ago
My thoughts exactly. Some people need to stop crying and start writing software.
axilmar 12y ago
Not really. The term "complete replacement" does not refer to the implementation details, but to the features the language provides. It's quite possible not only to offer a complete C++ replacement but to also substantially improve on C++ on all aspects.
- mreiland 12y ago
  Not really. Probably the strongest point of C++, besides its performance, is its ability to interact with C easily and efficiently. A huge amount of C++'s complexity comes from this requirement, but the benefits are enormous. It's such a big deal that MS eventually just started recommending people use C++/CLI to interop with C instead of using the usual C# Interop methods. Too many people underestimate the extreme advantages that are still gotten today by that requirement. The rest of it, yes, you could, but not that specific requirement. Doing that efficiently and easily enforces certain restrictions on the language, and the underlying runtime.
  - alphagenerator 12y ago
    I actually think the strongest point of C++ is the nature of how template metaprogramming is done. Is there any other language that competes with C++ as effectively with templates? I feel like all these "C++ is bad" comments and articles are from people who've really only scratched the surface in C++. The expressiveness that's available to a programmer using templates in C++ is, to me, quite awesome.

deleted 12y ago

[deleted]

kentonv 12y ago

The idea that OOP is a fad and that everyone is abandoning it is... absurd. I think that the author thinks OOP means ObjectListenerBuilderProviderFactoryAdpterImpls and repeated use of words defined by Gamma et al. Actually, OOP is just the practice of encapsulation and abstraction, and the avoidance of globals/singletons* in favor of infinitely instantiable instances. These are not a fad, they are necessary components of all large-scale software. The Linux kernel, which is entirely written in C, is a fine example of object-oriented programming. File descriptors are object references. The filesystem is a beautiful heirarchy of polymorphic nodes. There simply is no non-OOP way to implement these things. * I cannot mention singletons without linking this essay of mine, even though I'm somewhat embarrassed that I never found time to fill in the rest of the site: http://www.object-oriented-security.org/lets-argue/singletons http://www.object-oriented-security.org/lets-argue/singleton...

axilmar 12y ago
Neither debug logging nor any other unique system resource has to be passed as a singleton. All that is needed is the appropriate ApplicationContext structure to be passed to each object that needs these facilities, and the ApplicationContext will contain all the singleton instances that are required.
- kentonv 12y ago
  Yes, you can do that, it just gets tiring, because now you have a boilerplate parameter being passed everywhere. It really has to be passed everywhere, because you never want to get stuck without the ability to debug some function just because you didn't pass in the debug logger object. The environment pattern effectively makes this context implicit.
- c0de517e 12y ago
  The solution is - more objects wrapping more objects. I can already imagine people doing exactly that. Dependency injection is the name of the game right? That's what videos on youtube are advocating... But it's also a pain to pass everything that is needed down to functions, so let's stuff all the global state in a class and pass that class down! I hope I just didn't get the sarcasm, really.

charlieflowers 12y ago

Tremendously insightful post. Sometimes the writing is a little rough ... don't let that fool you. Ultimately, I think he's right: what we need is to be able to invent and use high-level languages and DSL's that are wonderfully expressive for our domain (with fast iteration and all that), but also to be able to control the low-level run-time code that gets executed as a result, so it can be fast and efficient. That's the holy grail as I see it. And LLVM is a key contender to provide the backend of that vision. (TFA talks about a lot of other things, but this is pretty much how I interpreted its conclusion, and I agree).

yoanizer 12y ago

(Repost) Really we should stop talking so much about tools, and what tool/language/ide/whatever is best. Many years ago people didn't have half the tools we have now, and they still did amazing things. Most of what we have today is very good already. IMO focus on building products, not on bashing the tools. checkout http://prog21.dadgum.com/51.html http://prog21.dadgum.com/51.html

chris_wot 12y ago

Seems like a big whine. Every time I read one of these, I see a few good points, but then I think to myself "I wonder what they are programming in". I then wonder how long it will be before they get upset about some feature they consider to be inelegant and try to find the next fad or old language they had previously discarded. I really wish people would stop doing this. They like to tear down, without really building anything! It's sort of a whinge to tear things down without really understanding why certain concepts or ideas were invented. Kind of lame.

c0de517e 12y ago
Nowadays most of the code I have to deal with and that I write myself is very "c-like" C++. For personal projects I usually use C# instead.
- chris_wot 12y ago
  I'm assuming you mean it uses less class heirachies and more composition. Is this correct?
  - c0de517e 12y ago
    Really I don't often use classes, unless they are providing a benefit. Just using them to group some state with some functions is not great because they have lots of drawbacks for that, I find an opaque pointer and C functions to be better at hiding implementation details and so on. I use classes basically when I need destructors and constructors, so for things that need to go in collections really. http://c0de517e.blogspot.ca/2012/09/follow-up-why-classes.html http://c0de517e.blogspot.ca/2012/09/follow-up-why-classes.ht...
    - chris_wot 12y ago
      Why not use a pimpl?