15 ms·

The 1998-2011 gap has made a lot of damage to c++ in term of "market share". I think it's necessary to avoid something similar happen again.

by Rexxar 7y ago

bogwog 7y ago
Alternatively, releasing new features every 3 years to an already-bloated language could cause even worse damage.
- arcticbull 7y ago
  This. They keep adding half-finished features apparently for the sake of releasing every 3 years. Move types that may not move (std::move is just a cast / suggestion that if taken leaves the receiver in an indeterminate, useable state), pattern matching that isn't (std::variant). Frankly, I wish they'd stop.
- hellofunk 7y ago
  This suggests you aren't aware of the many huge benefits that have come from introducing modern features that other languages have. C++ since 2011 is quite a different language to what it was before, and this is hardly a bad thing. So many of the challenges of writing C++ were significantly simplified with the introduction of lambdas, smart pointers, and threading primitives.
  - arcticbull 7y ago
    The issue isn't that it gets new features it's that they're half-assed because you can't impose new restrictions on old code. The power of these features in modern languages comes from their ability to protect you from yourself. That has more to do with what you can't do than what you can. Bolting more legs onto C++ doesn't protect you from anything, it just increases the surface area of the language. They haven't introduced the features other language have, they've introduced poor rip-offs that fail to work as one might expect having worked in any of the other languages they're derived from. The problem is it's not different than it used to be, the cracked foundations are exactly the same as they've always been always been but there's a bigger and more complicated house on them. C++ is starting to feel like the Winchester mystery house.
    - jdsully 7y ago
      The C++ philosophy is not about protecting you from yourself. Its about allowing you to express your idea in as low or high level terms as you require. This lets you write a highly optimized tight loop and then abstractly describe less performance sensitive parts. In the past it was thought that people would use safer high level languages and then drop down to C for performance. That vision just doesn’t seem to work out in practice - except at the cross process level. The trade off to this is language complexity. If you want a simple language C++ isn’t for you - and that’s OK.
      - marcosdumay 7y ago
        > That vision just doesn’t seem to work out in practice Well, about half of the Python ecosystem seems to disagree.
        jdsully 7y ago
        Python is likely the best example of this working, however even in Python the boundaries between high and low performance sections are very formal. It's a lot simpler to go in and optimize a piece of code the profiler has pointed out with C++. I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.
        hawski 7y ago
        I am a C++ developer by career. Me and many other C++ developers I know do not really like the language. It is what it is. It has useful parts, but complexity is a weight.
        clappski 7y ago
        How do you end up being a C++ developer that hates the language? I’m a C++ developer as well, and if I ever decided that’s I didn’t like what I was doing every day I’d learn a different language and try to get hired for that.
  - rrss 7y ago
    Those are all C++11 features, right? So they aren't much of an argument in favor of 14, 17, 20.
    - blub 7y ago
      14, 17 and 20 are full of small and big improvements: coroutines, contracts, modules, concepts, huge improvements for compile-time computation with constexpr, etc.
    - hellofunk 7y ago
      As an example, yes. Other versions offered similar benefits (C++14 in particular was a "bug fix" version for C++11, which I think most would be happy came quickly).
    - MauranKilom 7y ago
      We also got Class Template Argument Deduction, structured bindings, various syntactic sugar (if (auto var = initializer) {}, if constexpr, fold expressions...), std::variant, std::optional, and a whole POSIX-style filesystem library, to name a few. And that's just C++17 alone. It's nothing earth-shattering (that stuff is coming in C++20) but these are all features that improve the language and allow you to write better code. Consider e.g. if constexpr which can eliminate so much SFINAE cruft. Or CTAD to reduce the need for makeXYZ() functions.
0815test 7y ago
> The 1998-2011 gap has made a lot of damage to c++ in term of "market share". Not really... Rust 1.0 is from mid-2015, well past 2011.
- zone411 7y ago
  Not saying Rust is bad by any means, but it has about 20 times smaller market share than C++ according https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ and 11 times smaller according to http://pypl.github.io/PYPL.html http://pypl.github.io/PYPL.html.
  - tdsamardzhiev 7y ago
    Tiobe and PYPL are not market share indices, they're googling indices. I'd be very surprised if Rust really has 1/20 of C++'s market share as in number of companies and programmers that use it.
    - zone411 7y ago
      True, they are not great indices. Indeed.com shows me around 40 times more job openings for C++ and StackOverflow shows 14 times more C++ questions this year. Github shows 12 times more commits in C++ this year. None of these are great by themselves but a guess of around 20x seems reasonable.
      - AsyncAwait 7y ago
        Rust only reached 1.0 status in 2015, keep that in mind.
asveikau 7y ago
I kind of see it differently, that the 98 and 03 standards had a lot of mileage and as necessary as the more recent changes may have been, people felt the old standard pretty usable for a long time. C++11 was a really big shakeup. In contrast, C11 isn't a major difference over C99. Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast, as large chunks of the community have not even caught up with what is already there.
- fredophile 7y ago
  I think it's worth noting that up until 2010 C++11 was known as C++0x. Everyone knew it was coming. You could get a good idea of what it was going to contain by looking at things like Boost. C++03 wasn't some abnormally stable version, it just took a longer than expected time to write the standard for C++11.
  - asveikau 7y ago
    Yes I remember. Also, by the time c++0x seemed "right around the corner" for several years, a lot of the library features like smart pointers were already common practice, the standard just, well, standardized them. It was possible and common to have pretty "modern" styles in c++03, you'd just have to do without lamdbas etc. and be using less of the 'std' namespace.
    - humanrebar 7y ago
      Strong disagree. The nonsense needed for "variadic" templates in C++03 isn't "just do without lambdas". You basically have to walk on eggshells to get the equivalent of unique_ptr. Not having to type std::vector<SomeTypeName, WhateverBuffer>::const_iterator changes the way you write code, too. The stronger guarantees on copy elision lets you skip return by reference nonsense more aggressively.
- pingyong 7y ago
  > Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast Sure there are a lot of small accumulating changes, but they can easily be caught up on by reading the documentation when you actually need those features. On the other hand, I've been waiting for modules, concepts and networking literally since 2012 - and I only started using C++ in 2011, with around 2 years of experience in C. I don't think anyone is moving too fast in that direction. Edit: I still remember the graphic from the committee/Herb, which showed 2014 for the networking TS, and 2017 for concepts/modules. The "networking TS" then ended up being like one .pdf file with functions for LE/BE conversion, and well obviously concepts and modules aren't in C++17. (Neither is any actual networking.) And while concepts look to be on a fairly good path for C++20, I'm going to be very surprised (and happy) if they'd manage to get modules in, too.
gurkendoktor 7y ago
This was also the timeframe in which boost::shared_ptr, boost::filesystem, boost::variant, and boost::thread have matured to the point where they could be imported into the standard, and when people discovered all these dark corners like SFINAE. The C++ language was frozen, but the C++ ecosystem never really stopped moving. I actually think that the lack of a popular cross-platform package manager is much more harmful. It's amazing what GitHub and CocoaPods did to the niche Objective-C community in such a short time, while C++ still isn't a language where people celebrate cool open source libraries.
- prewett 7y ago
  Maybe this is my old skool C++ bias, but every time I’ve inherited a project using CocoaPods I’ve found the code to be of poor quality and the Pods to be either corporate libraries (third-party analytics, crash logs, etc.) or wrapper code of questionable quality that hasn’t really provided any benefits over a couple of hours of writing some simpler code yourself. And you yourself mentioned Boost, which is kind a code ecosystem of its own, all open source. But I think C++ has problems with libraries because it’s such a pain to add a library to C++. If the library is C++, you can’t ship a binary and header file like with a C library because the ABI needs to match, so you have to compile the thing. And then people like Boost do template wizardry that consumes compile time to produce magic, but some developers value the compilation speed over magic, so they don’t use anything heavily templated. But if it isn’t templated, it likely could be written in C if it isn’t a big UI framework, and be available for everyone. So, no C++ library ecosystem.
  - gurkendoktor 7y ago
    Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem. This is precisely the thing that a standardized package manager can establish. I think it's a bit of a catch-22. C++ projects are so rare and monolithic that reinventing the wheel every now and then. But maybe more (smaller) projects would happen in C++ if there were polished libraries for reasonably common requirements like sending a SOAP request.

The 1998-2011 gap has made a lot of damage to c++ in term of "market share". I think it's necessary to avoid something similar happen again.

by Rexxar 7y ago

The 1998-2011 gap has made a lot of damage to c++ in term of "market share". I think it's necessary to avoid something similar happen again.

bogwog 7y ago

Alternatively, releasing new features every 3 years to an already-bloated language could cause even worse damage.

arcticbull 7y ago
This. They keep adding half-finished features apparently for the sake of releasing every 3 years. Move types that may not move (std::move is just a cast / suggestion that if taken leaves the receiver in an indeterminate, useable state), pattern matching that isn't (std::variant). Frankly, I wish they'd stop.
hellofunk 7y ago
This suggests you aren't aware of the many huge benefits that have come from introducing modern features that other languages have. C++ since 2011 is quite a different language to what it was before, and this is hardly a bad thing. So many of the challenges of writing C++ were significantly simplified with the introduction of lambdas, smart pointers, and threading primitives.
- arcticbull 7y ago
  The issue isn't that it gets new features it's that they're half-assed because you can't impose new restrictions on old code. The power of these features in modern languages comes from their ability to protect you from yourself. That has more to do with what you can't do than what you can. Bolting more legs onto C++ doesn't protect you from anything, it just increases the surface area of the language. They haven't introduced the features other language have, they've introduced poor rip-offs that fail to work as one might expect having worked in any of the other languages they're derived from. The problem is it's not different than it used to be, the cracked foundations are exactly the same as they've always been always been but there's a bigger and more complicated house on them. C++ is starting to feel like the Winchester mystery house.
  - jdsully 7y ago
    The C++ philosophy is not about protecting you from yourself. Its about allowing you to express your idea in as low or high level terms as you require. This lets you write a highly optimized tight loop and then abstractly describe less performance sensitive parts. In the past it was thought that people would use safer high level languages and then drop down to C for performance. That vision just doesn’t seem to work out in practice - except at the cross process level. The trade off to this is language complexity. If you want a simple language C++ isn’t for you - and that’s OK.
    - marcosdumay 7y ago
      > That vision just doesn’t seem to work out in practice Well, about half of the Python ecosystem seems to disagree.
      - jdsully 7y ago
        Python is likely the best example of this working, however even in Python the boundaries between high and low performance sections are very formal. It's a lot simpler to go in and optimize a piece of code the profiler has pointed out with C++. I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.
        hawski 7y ago
        I am a C++ developer by career. Me and many other C++ developers I know do not really like the language. It is what it is. It has useful parts, but complexity is a weight.
        clappski 7y ago
        How do you end up being a C++ developer that hates the language? I’m a C++ developer as well, and if I ever decided that’s I didn’t like what I was doing every day I’d learn a different language and try to get hired for that.
- rrss 7y ago
  Those are all C++11 features, right? So they aren't much of an argument in favor of 14, 17, 20.
  - blub 7y ago
    14, 17 and 20 are full of small and big improvements: coroutines, contracts, modules, concepts, huge improvements for compile-time computation with constexpr, etc.
  - hellofunk 7y ago
    As an example, yes. Other versions offered similar benefits (C++14 in particular was a "bug fix" version for C++11, which I think most would be happy came quickly).
  - MauranKilom 7y ago
    We also got Class Template Argument Deduction, structured bindings, various syntactic sugar (if (auto var = initializer) {}, if constexpr, fold expressions...), std::variant, std::optional, and a whole POSIX-style filesystem library, to name a few. And that's just C++17 alone. It's nothing earth-shattering (that stuff is coming in C++20) but these are all features that improve the language and allow you to write better code. Consider e.g. if constexpr which can eliminate so much SFINAE cruft. Or CTAD to reduce the need for makeXYZ() functions.

0815test 7y ago

> The 1998-2011 gap has made a lot of damage to c++ in term of "market share". Not really... Rust 1.0 is from mid-2015, well past 2011.

zone411 7y ago
Not saying Rust is bad by any means, but it has about 20 times smaller market share than C++ according https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ and 11 times smaller according to http://pypl.github.io/PYPL.html http://pypl.github.io/PYPL.html.
- tdsamardzhiev 7y ago
  Tiobe and PYPL are not market share indices, they're googling indices. I'd be very surprised if Rust really has 1/20 of C++'s market share as in number of companies and programmers that use it.
  - zone411 7y ago
    True, they are not great indices. Indeed.com shows me around 40 times more job openings for C++ and StackOverflow shows 14 times more C++ questions this year. Github shows 12 times more commits in C++ this year. None of these are great by themselves but a guess of around 20x seems reasonable.
    - AsyncAwait 7y ago
      Rust only reached 1.0 status in 2015, keep that in mind.

asveikau 7y ago

I kind of see it differently, that the 98 and 03 standards had a lot of mileage and as necessary as the more recent changes may have been, people felt the old standard pretty usable for a long time. C++11 was a really big shakeup. In contrast, C11 isn't a major difference over C99. Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast, as large chunks of the community have not even caught up with what is already there.

fredophile 7y ago
I think it's worth noting that up until 2010 C++11 was known as C++0x. Everyone knew it was coming. You could get a good idea of what it was going to contain by looking at things like Boost. C++03 wasn't some abnormally stable version, it just took a longer than expected time to write the standard for C++11.
- asveikau 7y ago
  Yes I remember. Also, by the time c++0x seemed "right around the corner" for several years, a lot of the library features like smart pointers were already common practice, the standard just, well, standardized them. It was possible and common to have pretty "modern" styles in c++03, you'd just have to do without lamdbas etc. and be using less of the 'std' namespace.
  - humanrebar 7y ago
    Strong disagree. The nonsense needed for "variadic" templates in C++03 isn't "just do without lambdas". You basically have to walk on eggshells to get the equivalent of unique_ptr. Not having to type std::vector<SomeTypeName, WhateverBuffer>::const_iterator changes the way you write code, too. The stronger guarantees on copy elision lets you skip return by reference nonsense more aggressively.
pingyong 7y ago
> Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast Sure there are a lot of small accumulating changes, but they can easily be caught up on by reading the documentation when you actually need those features. On the other hand, I've been waiting for modules, concepts and networking literally since 2012 - and I only started using C++ in 2011, with around 2 years of experience in C. I don't think anyone is moving too fast in that direction. Edit: I still remember the graphic from the committee/Herb, which showed 2014 for the networking TS, and 2017 for concepts/modules. The "networking TS" then ended up being like one .pdf file with functions for LE/BE conversion, and well obviously concepts and modules aren't in C++17. (Neither is any actual networking.) And while concepts look to be on a fairly good path for C++20, I'm going to be very surprised (and happy) if they'd manage to get modules in, too.

gurkendoktor 7y ago

This was also the timeframe in which boost::shared_ptr, boost::filesystem, boost::variant, and boost::thread have matured to the point where they could be imported into the standard, and when people discovered all these dark corners like SFINAE. The C++ language was frozen, but the C++ ecosystem never really stopped moving. I actually think that the lack of a popular cross-platform package manager is much more harmful. It's amazing what GitHub and CocoaPods did to the niche Objective-C community in such a short time, while C++ still isn't a language where people celebrate cool open source libraries.

prewett 7y ago
Maybe this is my old skool C++ bias, but every time I’ve inherited a project using CocoaPods I’ve found the code to be of poor quality and the Pods to be either corporate libraries (third-party analytics, crash logs, etc.) or wrapper code of questionable quality that hasn’t really provided any benefits over a couple of hours of writing some simpler code yourself. And you yourself mentioned Boost, which is kind a code ecosystem of its own, all open source. But I think C++ has problems with libraries because it’s such a pain to add a library to C++. If the library is C++, you can’t ship a binary and header file like with a C library because the ABI needs to match, so you have to compile the thing. And then people like Boost do template wizardry that consumes compile time to produce magic, but some developers value the compilation speed over magic, so they don’t use anything heavily templated. But if it isn’t templated, it likely could be written in C if it isn’t a big UI framework, and be available for everyone. So, no C++ library ecosystem.
- gurkendoktor 7y ago
  Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem. This is precisely the thing that a standardized package manager can establish. I think it's a bit of a catch-22. C++ projects are so rare and monolithic that reinventing the wheel every now and then. But maybe more (smaller) projects would happen in C++ if there were polished libraries for reasonably common requirements like sending a SOAP request.