8 ms·

...both of which are domain specific languages, or developed as such. I really think C++ is going to gnaw "market share" from C in any low-level domains and fi

by zxcdw 14y ago

...both of which are domain specific languages, or developed as such. I really think C++ is going to gnaw "market share" from C in any low-level domains and fight back Go and other competitors in high-level systems programming domains thanks to it's recent C++11 standard and upcoming standard library extensions which being the transition of making it much more on-par with other modern languages. Bjarne Stroustrup(the language creator) has also hinted for much faster standardization process than last time around(when it took some 13 years to come up with a new standard), and would hope for a 5 year cycle instead, so perhaps C++16 is coming up next. Oh, and the standards committee is already working on it. The only major setback I see with C++11 in comparison to many other languages aimed for large-scale software development is it's very small standard library which completely lacks support for modern technologies such as hierarchical filesystems, sockets, XML and HTTP and so on. They are coming up later on, though. The core language is very solid and doesn't lack anything special. Yet, it's not any more "bloated" or complex by it's standard(in terms of page/line/word count) than say C# 3.0 or Java 7. tl;dr: I think many people think C++ is "old" or even dead and we need something more modern, yet now C++ evolves faster than ever and tries to meet that demand.

cmccabe 14y ago
Yes, truly the only thing holding C++ back has been lack of features. Have a link: http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/
- zxcdw 14y ago
  Nice, but you're 4 years late, sir! Everything can be viewed in a bad light if it's wanted to and we both know it. So how about actually talking about the bigger picture, and problems with programming languages and the actual art of creating large-scale software rather than trying to be smart?
  - cmccabe 14y ago
    C++0x has some useful features, but it doesn't address Yossi's complaints about C++, which are at a more fundamental level.
    - zxcdw 14y ago
      Yossi, by his own words, is a whiner. The fundamental reason behind is attitude towards C++ is to stir up controversy, rather than to provide objective criticism. If his attitude was sincere, I'm sure he wouldn't have spent so much effort in mastering the language.
      - cmccabe 14y ago
        ad hominem.
        zxcdw 14y ago
        ...which is completely fine when is not used as an attempt to debunk the argument, but show that the information is biased. Any form of critique towards a biased source can always be countered with claims of it being an ad hominem argument - which it strictly speaking usually is - but that alone does not make the critique false or the original source any more reliable. As an example, many of the points Yossi makes are subjective and opinionated and as such FQA is nowhere near an unbiased and reliable source of problems within the language. Nobody who actually wants to be serious about the subject cites FQA as a whole. At best, individual points he makes with which many agree with. Including Bjarne himself.
        cmccabe 14y ago
        Any form of critique towards a biased source can always be countered with claims of it being an ad hominem argument... Well, any critique which consists solely of personal attacks can be countered that way. It's super effective!
  - deleted 14y ago
    [deleted]
grey-area 14y ago
There are plenty of companies who have spent millions on developing their websites, written in a variety of the languages you list as 'toy' languages, or even PHP. Whether they would have been better to use other languages is impossible to say of course, but these languages are being used for significant projects. The use of the pejorative 'toy' is not very useful, and likely to evoke emotional reactions. Go was inspired by a talk on the features of C++11 [1] - in despair at the addition of yet more features; the origins of the language and the philosophy behind it might make interesting reading if you use C++, because it was done directly in reaction to the (as they saw it) baroque edifice of C++. Though I agree that people should not judge languages by popularity, novelty, or coolness (though it seems many people do), that doesn't mean you shouldn't be open to looking at new languages, if only to inform how you use your favourite one. Go for example has been inspired by the languages you deride, or their precursors (Python, Ruby etc), and in fact has taken much from them in syntax and in the popularity of closures etc. I do agree with your other point though that this is an excellent area for Google to focus on, and something which will benefit a lot of domains which currently don't use scripting languages (systems programming, many large server systems, desktop apps, mobile apps). [1] http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.co.uk/2012/06/less-is-exponent...
- zxcdw 14y ago
  I'm aware of what and why Go came to be, and I can easily relate to the reasons(I've read the blog post). I am by no means saying C or C++ as languages are perfect, nothing is. However, as I mentioned in my another reply to sanderdj, there's huge investment in effort for the abstractions the two languages build. It's very hard to tackle the problem of existing codebase for example, as that requires building stuff from ground up(that happens later on), or the fact that there are far more competent C or C++ programmers than there are Go or Rust programmers(and this isn't likely to change for the next 10-15 years or so, I'd bet), or the fact that there exists practically no libraries for these languages(ports are relatively fast though, few years max.), portability is a major concern too, tools too as well as language standard and educational resources(books, uni grade education, best practices over years, ...) won't exist for years... So while I think that C and C++ will phase out eventually even in the domain of systems programming, I really don't see Go or Rust doing that for the foreseeable future, if ever. It would be really great to build trustworthy(non-leaky, efficient and secure) abstractions on top of languages like Rust and Go, but how reliable would it be? When would it be feasible? Who takes the first steps? When will the mainstream follow? Are these languages going to be relevant after 20 years? Oh, and I'm not deriding other languages in their specific domains(I'm a Ruby fan, not so much into Python), but rather the fact that I've been under the impression that many people think that soon C and C++ will phase out and become obsolete(or that they have already done so), we go higher in abstractions, Python and Haskell are the future and computers are so fast that nobody has to care about optimizing their code. Then reality and post-PC era strikes back, battery life and software power-efficiency play higher role than ever... My experience with Go and especially Rust is quite limited, but it would be really great if I could do my stuff(right now games and path tracing rendering, render times from 12 hours upwards) in either them instead of C++. I really like the ideas behind the languages and they fit my core domain just as well as C and C++ do. Though the thing is, there are no tools. No libraries. No books. Nothing. There's simply no way to jump over, even if the possible performance penalty would be tolerable. And this isn't likely to be changing much for the better for upcoming years, if even then. Perhaps when the languages get an actual standard... It's sad in a way even, but can't escape the facts which make them not viable for many domains.
lmm 14y ago
JLS7 is ~600 pages; the latest draft I could find (because apparently the actual standard isn't available online, a problem in itself) for C++11 was over 1200. I very much doubt a version bump will stem C++'s decline; while it contains plenty of improvements there are no really radical changes. What are the changes that you think will make people who chose C or go over C++03 switch to C++11?
- zxcdw 14y ago
  Take a look at Herb Sutter's talk at Microsoft's GoingNative2012 conference: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond http://channel9.msdn.com/Events/GoingNative/GoingNative-2012... I really don't see where someone would pick C over C++ when starting a new project if not either due to 1) lack of (good enough) C++ implementation or 2) lack of confidence in using C++(this is personally a problem for me, as I've been programming in C much more than C++ and still feel unfamiliar with lots of things, the least not being the object oriented paradigm). Of course personal taste may differ, and this is understandable; I'd prefer more compact language but right now the domain I work in has no alternatives.
eevee 14y ago
From the outside, C++ appears to be such a mess that I actually cannot tell whether C++11 made it better or worse. I don't think systems programming is going anywhere—I mainly stick to Python, but would like something lower-level available that I actually enjoy writing. The thought of having nothing better than C++ for the next however many years is terrifying.
- zxcdw 14y ago
  > From the outside, C++ appears to be such a mess Implying that you don't exactly even know the language, if it really is such a mess you think it is. I bet a bunch it really isn't. > I actually cannot tell whether C++1 made it better or worse. This really just shows the fact that you are clueless about C++ and what C++11 brings to the table. Whatever you think has no relevance. Not because your opinion would be less valuable, but because you can't be objective about something you don't understand. You just follow what you hear from others - often times those who are in the same situation. Hooray for circle jerking over how C++ sucks. This leads nobody nowhere. This is a major problem with C++, but it's mainly a problem for people who don't write any C++. So what does C++11 bring to the table? To mention some: Safety - Standardized smart pointers, nullptr, better type-safety Performance - Rvalue references, move semantics, constant expressions with constexpr Concurrency - Standard facilities for threading, async, futures Language features - lambda expressions, support for UTF8/16/32, uniform initialization Libraries - std::chrono for various time handling facilities, standard random number engines and generators, hash tables, regular expressions, tuples There's also plans to introduce more libraries to C++ next year, and evolve the language through libraries rather than the core language specification. Many of the problems people face with C++ can be avoided, and people know it. Many of the problems in existing code bases are fault of poor design. (Blaming C++ for multiple inheritance because the designer shot themselves to the foot by not being competent at designing software is a prime example. It's not like the same functionality couldn't have been implemented via policy-based or component-based design for example. Easier to blame the tool than the user, I get that.) Of course, those who use the language just avoid them and those who don't use the language keep bitching about them. Strange.
  - eevee 14y ago

by zxcdw 14y ago

cmccabe 14y ago

Yes, truly the only thing holding C++ back has been lack of features. Have a link: http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/

zxcdw 14y ago
Nice, but you're 4 years late, sir! Everything can be viewed in a bad light if it's wanted to and we both know it. So how about actually talking about the bigger picture, and problems with programming languages and the actual art of creating large-scale software rather than trying to be smart?
- cmccabe 14y ago
  C++0x has some useful features, but it doesn't address Yossi's complaints about C++, which are at a more fundamental level.
  - zxcdw 14y ago
    Yossi, by his own words, is a whiner. The fundamental reason behind is attitude towards C++ is to stir up controversy, rather than to provide objective criticism. If his attitude was sincere, I'm sure he wouldn't have spent so much effort in mastering the language.
    - cmccabe 14y ago
      ad hominem.
      - zxcdw 14y ago
        ...which is completely fine when is not used as an attempt to debunk the argument, but show that the information is biased. Any form of critique towards a biased source can always be countered with claims of it being an ad hominem argument - which it strictly speaking usually is - but that alone does not make the critique false or the original source any more reliable. As an example, many of the points Yossi makes are subjective and opinionated and as such FQA is nowhere near an unbiased and reliable source of problems within the language. Nobody who actually wants to be serious about the subject cites FQA as a whole. At best, individual points he makes with which many agree with. Including Bjarne himself.
        cmccabe 14y ago
        Any form of critique towards a biased source can always be countered with claims of it being an ad hominem argument... Well, any critique which consists solely of personal attacks can be countered that way. It's super effective!
- deleted 14y ago
  [deleted]

grey-area 14y ago

There are plenty of companies who have spent millions on developing their websites, written in a variety of the languages you list as 'toy' languages, or even PHP. Whether they would have been better to use other languages is impossible to say of course, but these languages are being used for significant projects. The use of the pejorative 'toy' is not very useful, and likely to evoke emotional reactions. Go was inspired by a talk on the features of C++11 [1] - in despair at the addition of yet more features; the origins of the language and the philosophy behind it might make interesting reading if you use C++, because it was done directly in reaction to the (as they saw it) baroque edifice of C++. Though I agree that people should not judge languages by popularity, novelty, or coolness (though it seems many people do), that doesn't mean you shouldn't be open to looking at new languages, if only to inform how you use your favourite one. Go for example has been inspired by the languages you deride, or their precursors (Python, Ruby etc), and in fact has taken much from them in syntax and in the popularity of closures etc. I do agree with your other point though that this is an excellent area for Google to focus on, and something which will benefit a lot of domains which currently don't use scripting languages (systems programming, many large server systems, desktop apps, mobile apps). [1] http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.co.uk/2012/06/less-is-exponent...

zxcdw 14y ago
I'm aware of what and why Go came to be, and I can easily relate to the reasons(I've read the blog post). I am by no means saying C or C++ as languages are perfect, nothing is. However, as I mentioned in my another reply to sanderdj, there's huge investment in effort for the abstractions the two languages build. It's very hard to tackle the problem of existing codebase for example, as that requires building stuff from ground up(that happens later on), or the fact that there are far more competent C or C++ programmers than there are Go or Rust programmers(and this isn't likely to change for the next 10-15 years or so, I'd bet), or the fact that there exists practically no libraries for these languages(ports are relatively fast though, few years max.), portability is a major concern too, tools too as well as language standard and educational resources(books, uni grade education, best practices over years, ...) won't exist for years... So while I think that C and C++ will phase out eventually even in the domain of systems programming, I really don't see Go or Rust doing that for the foreseeable future, if ever. It would be really great to build trustworthy(non-leaky, efficient and secure) abstractions on top of languages like Rust and Go, but how reliable would it be? When would it be feasible? Who takes the first steps? When will the mainstream follow? Are these languages going to be relevant after 20 years? Oh, and I'm not deriding other languages in their specific domains(I'm a Ruby fan, not so much into Python), but rather the fact that I've been under the impression that many people think that soon C and C++ will phase out and become obsolete(or that they have already done so), we go higher in abstractions, Python and Haskell are the future and computers are so fast that nobody has to care about optimizing their code. Then reality and post-PC era strikes back, battery life and software power-efficiency play higher role than ever... My experience with Go and especially Rust is quite limited, but it would be really great if I could do my stuff(right now games and path tracing rendering, render times from 12 hours upwards) in either them instead of C++. I really like the ideas behind the languages and they fit my core domain just as well as C and C++ do. Though the thing is, there are no tools. No libraries. No books. Nothing. There's simply no way to jump over, even if the possible performance penalty would be tolerable. And this isn't likely to be changing much for the better for upcoming years, if even then. Perhaps when the languages get an actual standard... It's sad in a way even, but can't escape the facts which make them not viable for many domains.

lmm 14y ago

JLS7 is ~600 pages; the latest draft I could find (because apparently the actual standard isn't available online, a problem in itself) for C++11 was over 1200. I very much doubt a version bump will stem C++'s decline; while it contains plenty of improvements there are no really radical changes. What are the changes that you think will make people who chose C or go over C++03 switch to C++11?

zxcdw 14y ago
Take a look at Herb Sutter's talk at Microsoft's GoingNative2012 conference: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond http://channel9.msdn.com/Events/GoingNative/GoingNative-2012... I really don't see where someone would pick C over C++ when starting a new project if not either due to 1) lack of (good enough) C++ implementation or 2) lack of confidence in using C++(this is personally a problem for me, as I've been programming in C much more than C++ and still feel unfamiliar with lots of things, the least not being the object oriented paradigm). Of course personal taste may differ, and this is understandable; I'd prefer more compact language but right now the domain I work in has no alternatives.

eevee 14y ago

From the outside, C++ appears to be such a mess that I actually cannot tell whether C++11 made it better or worse. I don't think systems programming is going anywhere—I mainly stick to Python, but would like something lower-level available that I actually enjoy writing. The thought of having nothing better than C++ for the next however many years is terrifying.

zxcdw 14y ago
> From the outside, C++ appears to be such a mess Implying that you don't exactly even know the language, if it really is such a mess you think it is. I bet a bunch it really isn't. > I actually cannot tell whether C++1 made it better or worse. This really just shows the fact that you are clueless about C++ and what C++11 brings to the table. Whatever you think has no relevance. Not because your opinion would be less valuable, but because you can't be objective about something you don't understand. You just follow what you hear from others - often times those who are in the same situation. Hooray for circle jerking over how C++ sucks. This leads nobody nowhere. This is a major problem with C++, but it's mainly a problem for people who don't write any C++. So what does C++11 bring to the table? To mention some: Safety - Standardized smart pointers, nullptr, better type-safety Performance - Rvalue references, move semantics, constant expressions with constexpr Concurrency - Standard facilities for threading, async, futures Language features - lambda expressions, support for UTF8/16/32, uniform initialization Libraries - std::chrono for various time handling facilities, standard random number engines and generators, hash tables, regular expressions, tuples There's also plans to introduce more libraries to C++ next year, and evolve the language through libraries rather than the core language specification. Many of the problems people face with C++ can be avoided, and people know it. Many of the problems in existing code bases are fault of poor design. (Blaming C++ for multiple inheritance because the designer shot themselves to the foot by not being competent at designing software is a prime example. It's not like the same functionality couldn't have been implemented via policy-based or component-based design for example. Easier to blame the tool than the user, I get that.) Of course, those who use the language just avoid them and those who don't use the language keep bitching about them. Strange.
- eevee 14y ago