3 ms·

Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. This is one reason why I doubt adding more featur

• stcredzero 10y ago
  Any sufficiently large project that pulls in dependencies will likely involve you dealing with all 4 of them. Which describes my current work situation. However, this would seem to imply that a startup or a small project would be able to set up a C++ project with a beautiful, cohesive subset of C++. Your point is something that people who are serious about language design for programming "in the large" should definitely pay attention to. This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs). How do you distinguish between one, two, three, or four person projects? Can you really make such a blanket statement about all the different possible codebases that exist? Methinks you exaggerate. (And I say this as a former dyed-in-the-wool minimalist Smalltalker!)
  • gcp 10y ago
    I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. (In theory of course your buddy could use a style and feature-set really close to your own and make it all a nice abstracted API so you don't need to look inside etc, but you get my point)
    • stcredzero 10y ago
      I put the distinction at "more than 1" because that's the point where you need to deal with code that isn't your own. You've never worked in a small shop where there was a good coding standard and everyone stuck to it? That sort of thing actually does pay off. I've seen this in my professional life.
      • gcp 10y ago
        We tended to use libraries or external dependencies, too. (And when that was out of the question, C++11 and later usually were as well)
        • stcredzero 10y ago
          You should be able to build facades around that stuff, so your main codebase is all C++11.
          • pjmlp 10y ago
            That doesn't scale in big code bases, or in the typical corporate culture.
            • stcredzero 10y ago
              I know for a fact this isn't necessarily true.
              • pjmlp 10y ago
                I don't mean it never works, just that is it seldom the case. I know C++ since the C++ARM days, it is one of the languages I like most despite its warts, teached it to first year students before C++98 happened. Nowadays I spend my work hours in Java and .NET stacks, but still do occasionally use it, when needed. I never worked in a company, with exception of my time at CERN, that actually followed C++ best practices. So yeah, there are lots of companies making good use of C++, as proven by CppCon and C++Now talks, but they seem to be the minority, when you take into consideration the ones whose main business is not selling software. At least I was pleased to see the BMW presentations at FOSDEM, where they mentioned moving from C to C++14, as a means to improve safety on car systems.
                • stcredzero 10y ago
                  So yeah, there are lots of companies making good use of C++, as proven by CppCon and C++Now talks, but they seem to be the minority, when you take into consideration the ones whose main business is not selling software. I should be more thankful about my current job, then. I guess a good heuristic for judging a language is to go to conferences and see what is portrayed there, then "dividing by 8." That will get you to about the level of the average shop.
• PopsiclePete 10y ago
  People keep forgetting about this. Yah, starting from scratch, using the exact compiler you want, and using only modern features is awesome. It's dealing with an existing code-base or team that doesn't agree on what "awesome" is or supporting old compiler/platforms or 3rd-party dependencies that turns C++ into a nightmare. Basically, C++14/17 is an awesome language when working on your own thing, in a vacuum, without any dependencies.
  • stcredzero 10y ago
    team that doesn't agree on what "awesome" This is the kind of team you don't want on a startup.
    • anarazel 10y ago
      Fwiw, I think a team that's too aligned in taste and similar issues tends to write bad code. Resolving differences, while sometimes painful, very often leads to better code. Both stylistically and architecturally. That does, however, require a respectful team and the ability to compromise.
      • stcredzero 10y ago
        Resolving differences, while sometimes painful, very often leads to better code If the team can resolve differences, it functions. The other commenter seemed to imply his team didn't.
• netheril96 10y ago
  On the other hand, in other languages I will be dealing with only one sublanguage, which usually happens to not have the third party libraries required for my program.
  • stcredzero 10y ago
    There's something to be said for the language designer's trick of picking a well populated language platform and either bootstrapping from that, or having easy callouts to another more popular language.