7 ms·

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 let

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.
      - arcticbull 7y ago
        I’ve been an iOS engineer for 7 years and I’m not exactly a fan of Objective-C. I’m good at it though, I know where all the sore spots are and part of my value is I can stop people from hurting themselves with the language. One day, inshallah, our team can eventually move on to swift (thank you ABI compatibility). Until then I work in it because my goal (and my job) is to deliver amazing products and experiences to my customers and if I had to do that in COBOL, I’d do that too. My job is not about the language for me, it’s about what I’m doing with it.
  - marcosdumay 7y ago
    Non-C++ developers are usually awed by it. The animosity comes from people with experience in C++ that decided not to use it. Pre-11 C++ was a bad language. The gains of leaving it to something like Java (that isn't even good by today's standards) were huge. The new standards are making it possible to create better code on the language, but it is still far from a modern language and the added features can not remove complexity, they can just add to it.
    - hellofunk 7y ago
      > the added features can not remove complexity, they can just add to it There are countless examples of the so-called modern C++ features reducing complexity in code. For example, it is now considered a code smell to ever write "new" or "delete" in your code. Imagine that, never using these words to manually allocate and delete memory in C++! But it's true, unique_ptr in particular makes so much simpler and safer. Type inference with auto doesn't just save typing, it improves performance in many cases and reduces a lot of complexity, while also avoiding uninitialized variables. These are just a few of at least a dozen examples that come to mind about reducing code complexity with more modern C++ features.
      - prewett 7y ago
        I hate unique_ptr and shared_ptr, using them is so glaringly inconsistent. Half the time you can’t construct a unique_ptr when it’s easy, because you don’t have the information until just enough later (like after a calculation or two in the body of your constructor) that you can’t use the easy way. So how do you transfer a unique_ptr? Well, the obvious ways don’t compile, and you eventually learn you have to move it, which involves using std::move(), but it always seems to go in the place I don’t expect it. And then how do you use a unique_ptr outside of your class? You can’t pass by value, for obvious reasons. Pass by reference, maybe? I think that’s frowned upon, I think you’re supposed to pass a naked pointer, and Modern C++ code is supposed to understand that naked pointers mean I’m loaning you this pointer. But I thought the point of Modern C++ was to get rid of pointers? Anyway, shared_ptr works completely the opposite way. You are supposed to pass the pointer by value. Now you can argue that of course it’s supposed to be that way, and the arguments are all cogent and when you spend half a day figuring it all out it makes sense. Until tomorrow when you forget it all and have to actually use the things. Plus I hate underscores with a passion, it hurts to type them. Modern C++ also seems to like making a line of code longer and longer, because you can’t just make a unique_ptr or shared_ptr with a constructor, no, you need make_unique<typename>(...), and the arguments are magically the same as the type’s constructor, even though it’s obviously a different function. Yuck! At least new and delete are pretty obvious how to use, and only have one special case to worry about ([]). Granted, the *_ptr are better, but I hate using them and wish I could use something that was shorter and easier to remember.
  - jefftk 7y ago
    I worked full-time in C++ from 2012 to 2017, and I don't like the language. I also did feel like I had to use it: I was a developer on an Apache/Nginx webserver plugin, and since those are written in C our choices were (1) C, (2) C++, or (3) a C shim that communicates with some other language. None of these options were ideal, but of them (2) was our best one.
deleted 7y ago
[deleted]
hawski 7y ago
C++ for me was and with every newer standard is really a meta language. It is used by many big projects to build their own "language". Such a language is almost completely ad-hoc and does not enjoy compiler checks, because it lives in project guidelines. It may enjoy some checks thanks to whole template machinery. But error messages barf about templates not a real intention behind them. Every big project is almost entirely different. They use different sets of features - some overlap more, some less. Many developers like to use C libraries, because they are easy to wrap in their version of C++. When you shop for libraries you often have to think if their version of C++ will work with yours. There is some consensus around STL and Boost, so at least that is relatively straightforward.
- jdsully 7y ago
  There seems to be a more modern trend of wanting all code to look the same. I've worked in large projects that have existed over many eras (including as far back as K&R C). The "Refactor when it becomes a problem" seems to work amazingly well. Global refactors and project wide styles seem to always fail miserably - inevitably a new era comes before the previous standardization effort completes. E.g. in the C->C++ transition most malloc's were left alone. If you wanted to add a ctor/dtor then you would go refactor them as necessary. It also encouraged you to encapsulate your work moreso than you would have otherwise.
  - 0815test 7y ago
    "Global refactors" work well with type system support, and not at all otherwise - and more modern languages do tend to come with better such support. Even for C++ itself, LLVM has a few bespoke tools to help you refactor old code as suggested by the semi-official C++ Core Guidelines - of course not all possible "refactors" are equally supported!
  - roca 7y ago
    A project where different modules are written in different C++ dialects is a real pain when you have to refactor code across modules or even just write or review code in different modules. And the finer the granularity at which you allow dialects to be mixed (within a module, within a file, within a function), the more horrible it gets. Every time you make a change you need to think "what dialect am I supposed to be using here?" The mental surface area required to understand code grows and grows. But it is also true that forcing all the code in a project to use a single dialect is expensive. Developers need to decide what that dialect is --- not just once, but constantly as C++ evolves. ("Is it time to use Ranges yet? Concepts?" etc.) You need to do expensive refactors every time you update the dialect. You need to enforce the dialect at code review time (harder as it changes). Every time you import third-party code into the project you need to update its dialect. A constantly evolving language that regularly deprecates commonly-used features in favour of "better" alternatives, like C++ does, is problematic. The faster pace of C++ evolution is making this problem worse.

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.
    - arcticbull 7y ago
      I’ve been an iOS engineer for 7 years and I’m not exactly a fan of Objective-C. I’m good at it though, I know where all the sore spots are and part of my value is I can stop people from hurting themselves with the language. One day, inshallah, our team can eventually move on to swift (thank you ABI compatibility). Until then I work in it because my goal (and my job) is to deliver amazing products and experiences to my customers and if I had to do that in COBOL, I’d do that too. My job is not about the language for me, it’s about what I’m doing with it.
- marcosdumay 7y ago
  Non-C++ developers are usually awed by it. The animosity comes from people with experience in C++ that decided not to use it. Pre-11 C++ was a bad language. The gains of leaving it to something like Java (that isn't even good by today's standards) were huge. The new standards are making it possible to create better code on the language, but it is still far from a modern language and the added features can not remove complexity, they can just add to it.
  - hellofunk 7y ago
    > the added features can not remove complexity, they can just add to it There are countless examples of the so-called modern C++ features reducing complexity in code. For example, it is now considered a code smell to ever write "new" or "delete" in your code. Imagine that, never using these words to manually allocate and delete memory in C++! But it's true, unique_ptr in particular makes so much simpler and safer. Type inference with auto doesn't just save typing, it improves performance in many cases and reduces a lot of complexity, while also avoiding uninitialized variables. These are just a few of at least a dozen examples that come to mind about reducing code complexity with more modern C++ features.
    - prewett 7y ago
      I hate unique_ptr and shared_ptr, using them is so glaringly inconsistent. Half the time you can’t construct a unique_ptr when it’s easy, because you don’t have the information until just enough later (like after a calculation or two in the body of your constructor) that you can’t use the easy way. So how do you transfer a unique_ptr? Well, the obvious ways don’t compile, and you eventually learn you have to move it, which involves using std::move(), but it always seems to go in the place I don’t expect it. And then how do you use a unique_ptr outside of your class? You can’t pass by value, for obvious reasons. Pass by reference, maybe? I think that’s frowned upon, I think you’re supposed to pass a naked pointer, and Modern C++ code is supposed to understand that naked pointers mean I’m loaning you this pointer. But I thought the point of Modern C++ was to get rid of pointers? Anyway, shared_ptr works completely the opposite way. You are supposed to pass the pointer by value. Now you can argue that of course it’s supposed to be that way, and the arguments are all cogent and when you spend half a day figuring it all out it makes sense. Until tomorrow when you forget it all and have to actually use the things. Plus I hate underscores with a passion, it hurts to type them. Modern C++ also seems to like making a line of code longer and longer, because you can’t just make a unique_ptr or shared_ptr with a constructor, no, you need make_unique<typename>(...), and the arguments are magically the same as the type’s constructor, even though it’s obviously a different function. Yuck! At least new and delete are pretty obvious how to use, and only have one special case to worry about ([]). Granted, the *_ptr are better, but I hate using them and wish I could use something that was shorter and easier to remember.
- jefftk 7y ago
  I worked full-time in C++ from 2012 to 2017, and I don't like the language. I also did feel like I had to use it: I was a developer on an Apache/Nginx webserver plugin, and since those are written in C our choices were (1) C, (2) C++, or (3) a C shim that communicates with some other language. None of these options were ideal, but of them (2) was our best one.

deleted 7y ago

[deleted]

hawski 7y ago

C++ for me was and with every newer standard is really a meta language. It is used by many big projects to build their own "language". Such a language is almost completely ad-hoc and does not enjoy compiler checks, because it lives in project guidelines. It may enjoy some checks thanks to whole template machinery. But error messages barf about templates not a real intention behind them. Every big project is almost entirely different. They use different sets of features - some overlap more, some less. Many developers like to use C libraries, because they are easy to wrap in their version of C++. When you shop for libraries you often have to think if their version of C++ will work with yours. There is some consensus around STL and Boost, so at least that is relatively straightforward.

jdsully 7y ago
There seems to be a more modern trend of wanting all code to look the same. I've worked in large projects that have existed over many eras (including as far back as K&R C). The "Refactor when it becomes a problem" seems to work amazingly well. Global refactors and project wide styles seem to always fail miserably - inevitably a new era comes before the previous standardization effort completes. E.g. in the C->C++ transition most malloc's were left alone. If you wanted to add a ctor/dtor then you would go refactor them as necessary. It also encouraged you to encapsulate your work moreso than you would have otherwise.
- 0815test 7y ago
  "Global refactors" work well with type system support, and not at all otherwise - and more modern languages do tend to come with better such support. Even for C++ itself, LLVM has a few bespoke tools to help you refactor old code as suggested by the semi-official C++ Core Guidelines - of course not all possible "refactors" are equally supported!
- roca 7y ago
  A project where different modules are written in different C++ dialects is a real pain when you have to refactor code across modules or even just write or review code in different modules. And the finer the granularity at which you allow dialects to be mixed (within a module, within a file, within a function), the more horrible it gets. Every time you make a change you need to think "what dialect am I supposed to be using here?" The mental surface area required to understand code grows and grows. But it is also true that forcing all the code in a project to use a single dialect is expensive. Developers need to decide what that dialect is --- not just once, but constantly as C++ evolves. ("Is it time to use Ranges yet? Concepts?" etc.) You need to do expensive refactors every time you update the dialect. You need to enforce the dialect at code review time (harder as it changes). Every time you import third-party code into the project you need to update its dialect. A constantly evolving language that regularly deprecates commonly-used features in favour of "better" alternatives, like C++ does, is problematic. The faster pace of C++ evolution is making this problem worse.