8 ms·

I tend to disagree. (Modern) C++ is an incredibly powerful programming language. Contrary to some other languages it gives the developer maximal freedom and doe

by mem0r1 5y ago

I tend to disagree. (Modern) C++ is an incredibly powerful programming language. Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer.

stevekemp 5y ago
In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.
- vnorilo 5y ago
  Practical, old languages tend to do this. In C++ or Common Lisp, which share little other than being multi-paradigm (unopinionated), it is fairly common to have house styles or accepted subsets. Languages that try to build in some "house style" are my personal dystopia - such as early Java or current Go. Which does not say they ate not effective, just that I personally hate the philosophy.
  - dan-robertson 5y ago
    Both C++ and Common Lisp suffer a huge accumulation of historical baggage. It is this that makes the languages problematic, not being multi-paradigm. Common Lisp has first/rest as well as car/cdr. It has streams and numbers and the functions on them seem generic but aren’t (always) generic functions. It still has rplca despite (setf car) being a valid function name.
    - vnorilo 5y ago
      Sure; but "historical baggage" is a function of multi-paradigm and outliving multiple generations of computer architecture. I would not view baggage as necessarily problematic. What makes C++ problematic is that template metaprogramming evolved in a very ad hoc way, and now we need to backwards compatible all of it.
      - dan-robertson 5y ago
        My claim is that these multi-paradigm languages may be better thought of as a core plus some paradigm-specific sublanguages, all jammed into the same syntax and glued together in random places. A better multi-paradigm language could avoid having separate parts that poorly work together. The thing that the comment I first replied to called ‘multi-paradigm’ is I think really the bad glue job like a plate that was smashed, glued together, smashed, and then glued together a second time. I don’t think it is an essential quality of multi-paradigm languages. For example Raku (fka perl6) fits different paradigms together more smoothly, and Julia can be used in a procedural or functional way as well as a more object-oriented way (though Julia’s objects tend not to contain as much state as a typical object-oriented language)
- otabdeveloper4 5y ago
  I don't think this is true. My experience hiring C++ developers does not confirm.
- jcelerier 5y ago
  > In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". Almost never seen that in practice. I always see people talking about it in forums, but in real-world gigs I don't know people who artificially restrict their codebase with braindead rules like that.
  - pjmlp 5y ago
    Enjoy the source code of Android, Windows and macOS frameworks. In fact probably yet another reason why Apple and Google aren't in an hurry to improve clang to latest ISO, and other companies in clang ecosystem even less.
  - jstimpfle 5y ago
    Are there any usable linters around to enforce such rules?
    - jeffreygoesto 5y ago
      Static Analysers like Coverity, KlocWork, QA-C++ will do. Usability is... Well... Subjective.
      - pjmlp 5y ago
        More than the usability, the biggest problem is getting everyone onboard.
  - jeffreygoesto 5y ago
    You haven't seen safety relevant code then. High SIL and ASIL levels (combined with those systems being embedded) result in such rule sets for a good reason. I have yet to see more than "print and bail out" in catch blocks. In embedded there is nobody who can read your cry for help and especially in fail-op systems this is just not an option. Herbceptions are just not there yet and until then we help ourselves with things like "expected" for example.
- fivea 5y ago
  > (...) such as Google's famous "no exceptions". If I recall correctly, Google's rationale regarding exceptions is that their legacy code is not exception-safe, and so they were faced with the choice of either rewriting critical parts of their legacy code to handle exceptions, or don't use them. Also, their "no exceptions" rule only applied to work involving their legacy code. I'm too lazy to find the source, but that bit of trivia was already discussed ad nauseum even in HN. The morale of the story is that you should not mindlessly repeat any opinion without knowing the rationale and instead pulling appeals to authority to cover up the logical hole. That's how you end up contradicting even your source, just because you believed that's how the cool kids do things.
  - pjmlp 5y ago
    I guess we can consider AOSP legacy code then, given how they use C++.
    - ncmncm 5y ago
      Yes. Legacy in every sense, including "abandonware".
      - pjmlp 5y ago
        Educate yourself on Android source code. You can even start by the new entries related to Rust. https://source.android.com/setup/build/rust/building-rust-modules/overview https://source.android.com/setup/build/rust/building-rust-mo...
        ncmncm 5y ago
        Why would I care about anything on that page? I have no need to read hype about Rust, regardless of where it might run. And, I have no desire to build Android apps, in any language.
        pjmlp 5y ago
        To educate yourself about what ISO C++ companies are actually doing with the language. The reference to Rust was just an example on how such members are also looking for alternatives, other big names are looking into Swift, C#, whatever. Meanwhile clang crawls along on its support for newer ISO C++ features, as the biggest contributors now have their focus elsewhere.
- FpUser 5y ago
  >"In practice few people use C++ fully" Because there is no need to. C++ is vast and there is no point in exploring all possible ways of doing something once decent path exists.
pjmlp 5y ago
Ideally yes, in practice there are all kinds of idioms on the wild.
naasking 5y ago
> Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer You seem to be implying that's a good thing. It's literally not. Imagine if I created a programming language where every random string of characters was a valid program (cue the Perl jokes). Clearly this language permits even more freedom than C++, but this would be a nightmare for programming. Constrained structure is essential to programming. Sometimes you need to beyond the constraints of a more common language, in which case C++ might be a good choice, but that's the exception not the rule.
- FpUser 5y ago
  >"You seem to be implying that's a good thing. It's literally not." I think it is.
  - ncmncm 5y ago
    - naasking 5y ago
      TIL that "engineering" is "cult thinking".
      - ncmncm 5y ago
        Engineering is an activity, not a restriction on activity.
- creatornator 5y ago
  Your assumption seems to be that if: 1) an existing language has finite utility 2) a language where any string is a valid program has no utility , that it must be true that utility decreases with the unconstrained-ness of a language (and thus increases with more constraint). However, this is not true. You only have to look to the other extreme to see there must be a middle ground. A language where there is only one valid program has no more utility than one where any string is a valid program. Because this relationship of constraint and utility is clearly not simple, we can't use those extrema to judge if C++ is less useful because it gives so much control. There might be some "local extrema" where a language fits a niche. C++ might fill that niche, or it might not, but I think it needs a bit more of a nuanced consideration than "less constraint, bad".

by mem0r1 5y ago

stevekemp 5y ago

In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.

vnorilo 5y ago
Practical, old languages tend to do this. In C++ or Common Lisp, which share little other than being multi-paradigm (unopinionated), it is fairly common to have house styles or accepted subsets. Languages that try to build in some "house style" are my personal dystopia - such as early Java or current Go. Which does not say they ate not effective, just that I personally hate the philosophy.
- dan-robertson 5y ago
  Both C++ and Common Lisp suffer a huge accumulation of historical baggage. It is this that makes the languages problematic, not being multi-paradigm. Common Lisp has first/rest as well as car/cdr. It has streams and numbers and the functions on them seem generic but aren’t (always) generic functions. It still has rplca despite (setf car) being a valid function name.
  - vnorilo 5y ago
    Sure; but "historical baggage" is a function of multi-paradigm and outliving multiple generations of computer architecture. I would not view baggage as necessarily problematic. What makes C++ problematic is that template metaprogramming evolved in a very ad hoc way, and now we need to backwards compatible all of it.
    - dan-robertson 5y ago
      My claim is that these multi-paradigm languages may be better thought of as a core plus some paradigm-specific sublanguages, all jammed into the same syntax and glued together in random places. A better multi-paradigm language could avoid having separate parts that poorly work together. The thing that the comment I first replied to called ‘multi-paradigm’ is I think really the bad glue job like a plate that was smashed, glued together, smashed, and then glued together a second time. I don’t think it is an essential quality of multi-paradigm languages. For example Raku (fka perl6) fits different paradigms together more smoothly, and Julia can be used in a procedural or functional way as well as a more object-oriented way (though Julia’s objects tend not to contain as much state as a typical object-oriented language)
otabdeveloper4 5y ago
I don't think this is true. My experience hiring C++ developers does not confirm.
jcelerier 5y ago
> In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". Almost never seen that in practice. I always see people talking about it in forums, but in real-world gigs I don't know people who artificially restrict their codebase with braindead rules like that.
- pjmlp 5y ago
  Enjoy the source code of Android, Windows and macOS frameworks. In fact probably yet another reason why Apple and Google aren't in an hurry to improve clang to latest ISO, and other companies in clang ecosystem even less.
- jstimpfle 5y ago
  Are there any usable linters around to enforce such rules?
  - jeffreygoesto 5y ago
    Static Analysers like Coverity, KlocWork, QA-C++ will do. Usability is... Well... Subjective.
    - pjmlp 5y ago
      More than the usability, the biggest problem is getting everyone onboard.
- jeffreygoesto 5y ago
  You haven't seen safety relevant code then. High SIL and ASIL levels (combined with those systems being embedded) result in such rule sets for a good reason. I have yet to see more than "print and bail out" in catch blocks. In embedded there is nobody who can read your cry for help and especially in fail-op systems this is just not an option. Herbceptions are just not there yet and until then we help ourselves with things like "expected" for example.
fivea 5y ago
> (...) such as Google's famous "no exceptions". If I recall correctly, Google's rationale regarding exceptions is that their legacy code is not exception-safe, and so they were faced with the choice of either rewriting critical parts of their legacy code to handle exceptions, or don't use them. Also, their "no exceptions" rule only applied to work involving their legacy code. I'm too lazy to find the source, but that bit of trivia was already discussed ad nauseum even in HN. The morale of the story is that you should not mindlessly repeat any opinion without knowing the rationale and instead pulling appeals to authority to cover up the logical hole. That's how you end up contradicting even your source, just because you believed that's how the cool kids do things.
- pjmlp 5y ago
  I guess we can consider AOSP legacy code then, given how they use C++.
  - ncmncm 5y ago
    Yes. Legacy in every sense, including "abandonware".
    - pjmlp 5y ago
      Educate yourself on Android source code. You can even start by the new entries related to Rust. https://source.android.com/setup/build/rust/building-rust-modules/overview https://source.android.com/setup/build/rust/building-rust-mo...
      - ncmncm 5y ago
        Why would I care about anything on that page? I have no need to read hype about Rust, regardless of where it might run. And, I have no desire to build Android apps, in any language.
        pjmlp 5y ago
        To educate yourself about what ISO C++ companies are actually doing with the language. The reference to Rust was just an example on how such members are also looking for alternatives, other big names are looking into Swift, C#, whatever. Meanwhile clang crawls along on its support for newer ISO C++ features, as the biggest contributors now have their focus elsewhere.
FpUser 5y ago
>"In practice few people use C++ fully" Because there is no need to. C++ is vast and there is no point in exploring all possible ways of doing something once decent path exists.

pjmlp 5y ago

Ideally yes, in practice there are all kinds of idioms on the wild.

naasking 5y ago

> Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer You seem to be implying that's a good thing. It's literally not. Imagine if I created a programming language where every random string of characters was a valid program (cue the Perl jokes). Clearly this language permits even more freedom than C++, but this would be a nightmare for programming. Constrained structure is essential to programming. Sometimes you need to beyond the constraints of a more common language, in which case C++ might be a good choice, but that's the exception not the rule.

FpUser 5y ago
>"You seem to be implying that's a good thing. It's literally not." I think it is.
- ncmncm 5y ago
  - naasking 5y ago
    TIL that "engineering" is "cult thinking".
    - ncmncm 5y ago
      Engineering is an activity, not a restriction on activity.
creatornator 5y ago
Your assumption seems to be that if: 1) an existing language has finite utility 2) a language where any string is a valid program has no utility , that it must be true that utility decreases with the unconstrained-ness of a language (and thus increases with more constraint). However, this is not true. You only have to look to the other extreme to see there must be a middle ground. A language where there is only one valid program has no more utility than one where any string is a valid program. Because this relationship of constraint and utility is clearly not simple, we can't use those extrema to judge if C++ is less useful because it gives so much control. There might be some "local extrema" where a language fits a niche. C++ might fill that niche, or it might not, but I think it needs a bit more of a nuanced consideration than "less constraint, bad".