4 ms·

What's there to regret? For purely edification purposes, there isn't a better OOP language ( though it encompasses other paradigms as well and isn't purely OOP

What's there to regret? For purely edification purposes, there isn't a better OOP language ( though it encompasses other paradigms as well and isn't purely OOP ) since it doesn't have training wheels. You could hurt yourself with it but it certainly allows you to explore and learn. Also, you could "learn" it in a year, but it takes you a lifetime to master it.

tw1010 8y ago
Opportunity cost.
seanmcdirmid 8y ago
C++ is not very canonical OOP. And by that I don’t just mean it’s multi paradigm nature, but it’s realization of OOP features. Using C++ teaches you mostly about using C++ and doesn’t really transfer across the paradigm.
- vasilipupkin 8y ago
  I think that statement would have to be classified as inaccurate. using C++ teaches you mostly about general purpose programming and it's pretty easy to go from C++ to python to Java to bash, etc.
  - inetknght 8y ago
    I would say learning C++ didn't quite teach me what I needed to go to bash. Learning bash became easy when I learned pipelines and the GNU coreutils. Now I wish I could take what I'd learned from GNU coreutils and apply that to C++.
  - lmm 8y ago
    Nonsense. C++'s template system behaves unlike any other language (things like SFINAE and the techniques that use it do not transfer), C++-style RAII is relatively unusual, I don't think any other language requires the programmer to think about virtual versus non-virtual inheritance, the C-derived sequence point rules are obscure and much looser than most languages' evaluation rules, the exception-safety rules are unique to C++, most languages don't make you track the minutiae of a dozen different integer types with inconsistent promotion rules, textual macros are abominable, C++ has more obscure control flow constructs than most languages... meanwhile the language has no standard support for true sum types, garbage collection, unit testing, poor library tooling, a limited type system... which means you don't learn the general-purpose techniques that rely on these things. If all you know is C++ you will be able to produce a limited amount of working code in a handful of C++-like languages, sure - but even in Python or Java or Bash you'll produce very unidiomatic code if you write in C++ style. If you tried to work in e.g. Smalltalk or Erlang or even OCaml you'd really struggle. It is not a good way to learn general-purpose programming, because the language is hugely complicated and most of the complications are C++-specific.
    - crimsonalucard 8y ago
      I'd have to disagree with the transitions from C++ to python or java and bash. The complication is C++ specific and moving to java, bash or python is simply removing that complexity. Hence moving to C++ is easier then moving from python or another similar language because in most cases you would be adding complexity. OCaml and Erlang are too different for me to comment about a transition in the functional direction.
      - nickik 8y ago
        But then the whole argument falls appart. Sure if you learn standard boring OOP in C++ then you can apply it. Thats what Java was designed for. Hoever to even get there you first need to learn incredibly complex nonsense and waste massive amounts of time for knowlage that is virtually useless. Then you might as well pick up Java, the most popular OOP language and learn it there.
    - vasilipupkin 8y ago
      well, that's just like, your opinion, man ( big lebowski reference for those too young to know ). The reason I disagree with you is because I have never met a C++ programmer who only knew C++ and couldn't easily do work in some other language, but of course plenty of people know other languages and can't do C++. Yes, SFINAE and RAII - you can go for many years of working in C++ without writing much code using either one of those.
      - jungler 8y ago
        That is more like an example of Blub paradox in action: You can write in everything as if it were C, you can't write C as if it were everything else. Except that it makes a point that is subtly different from the one pg originally raised in discussing Blub paradox: If you only care about shipping something, you aren't inclined to think about abstraction as a goal state, and that's what these other languages are doing: handling things with a goal of adding abstraction that for a C++ user is out of reach or requires considerable knowledge of the C++ standard. Users of Python or JS don't know what a pointer is, and that's intended by design, because for most applications it is an implementation detail and automating it away is desirable. When most software was written in assembler, data structures more complex than an array were often avoided, because it was difficult to code and debug them. And if you were an assembly coder of that era, you might well say that you didn't see the point of structured programming, or that you could easily get the same effect in fewer bytes. And to some degree, you'd be right, because you would just design a smaller scope of application that makes those techniques viable. Trying to write something resembling modern C++ style in x86 assembly, in contrast, would be as fruitless as a JS coder trying to use C++ like JS, since your abstractions wouldn't be there. You'd have to learn the thought process of a lower level coder and apply those strategies instead of the ones you are comfortable with.
- porpoisely 8y ago
  I agree. I wasn't trying to say C++ is great for learning OOP. I was saying that C++ is the best OOP-style language to learn in general because it allows you to break things and it encompasses other paradigms. Ruby is great for learning OOP, but it is far less general and far more protective than C++. But I'm sure others will have their own preferences but to me the lack of training wheels in C++ almost forces you to learn. Otherwise, you simply won't progress. I guess that could be a good thing or a bad thing as it might force some people to quit early on. Ultimately, I don't think learning C++ or anything language should be something you regret.
- zwieback 8y ago
  Hmm, not my experience. C++ was my intro to OOP but I was aware of "pure" OO languages like Smalltalk. I feel like my C++ OO experience has taught me a lot although I think it's valuable to study another OO language side-by-side. A lot of OO patterns translate between languages although the implementation in C++ is often overly concerned with static types.
dkarl 8y ago
It also takes you a lot closer to learning C. Some of it doesn't directly carry over, and may even be deceptively similar without being the same, but for programmers coming from more modern languages, many of the big novelties in C and C++ are the same: - Manual memory management and direct use of pointers. - Emphasis on giving as much latitude as possible to compiler writers so they can generate fast code on obscure architectures. - Separation of header files from object files. - Explicit handling of object files and linking in the build process. In fact, I think after learning C++ you should be able to read almost any C code with no issue, which is nice for being able to peek under the hood of the infrastructure we rely on every day.

tw1010 8y ago

Opportunity cost.

seanmcdirmid 8y ago

C++ is not very canonical OOP. And by that I don’t just mean it’s multi paradigm nature, but it’s realization of OOP features. Using C++ teaches you mostly about using C++ and doesn’t really transfer across the paradigm.

vasilipupkin 8y ago
I think that statement would have to be classified as inaccurate. using C++ teaches you mostly about general purpose programming and it's pretty easy to go from C++ to python to Java to bash, etc.
- inetknght 8y ago
  I would say learning C++ didn't quite teach me what I needed to go to bash. Learning bash became easy when I learned pipelines and the GNU coreutils. Now I wish I could take what I'd learned from GNU coreutils and apply that to C++.
- lmm 8y ago
  Nonsense. C++'s template system behaves unlike any other language (things like SFINAE and the techniques that use it do not transfer), C++-style RAII is relatively unusual, I don't think any other language requires the programmer to think about virtual versus non-virtual inheritance, the C-derived sequence point rules are obscure and much looser than most languages' evaluation rules, the exception-safety rules are unique to C++, most languages don't make you track the minutiae of a dozen different integer types with inconsistent promotion rules, textual macros are abominable, C++ has more obscure control flow constructs than most languages... meanwhile the language has no standard support for true sum types, garbage collection, unit testing, poor library tooling, a limited type system... which means you don't learn the general-purpose techniques that rely on these things. If all you know is C++ you will be able to produce a limited amount of working code in a handful of C++-like languages, sure - but even in Python or Java or Bash you'll produce very unidiomatic code if you write in C++ style. If you tried to work in e.g. Smalltalk or Erlang or even OCaml you'd really struggle. It is not a good way to learn general-purpose programming, because the language is hugely complicated and most of the complications are C++-specific.
  - crimsonalucard 8y ago
    I'd have to disagree with the transitions from C++ to python or java and bash. The complication is C++ specific and moving to java, bash or python is simply removing that complexity. Hence moving to C++ is easier then moving from python or another similar language because in most cases you would be adding complexity. OCaml and Erlang are too different for me to comment about a transition in the functional direction.
    - nickik 8y ago
      But then the whole argument falls appart. Sure if you learn standard boring OOP in C++ then you can apply it. Thats what Java was designed for. Hoever to even get there you first need to learn incredibly complex nonsense and waste massive amounts of time for knowlage that is virtually useless. Then you might as well pick up Java, the most popular OOP language and learn it there.
  - vasilipupkin 8y ago
    well, that's just like, your opinion, man ( big lebowski reference for those too young to know ). The reason I disagree with you is because I have never met a C++ programmer who only knew C++ and couldn't easily do work in some other language, but of course plenty of people know other languages and can't do C++. Yes, SFINAE and RAII - you can go for many years of working in C++ without writing much code using either one of those.
    - jungler 8y ago
      That is more like an example of Blub paradox in action: You can write in everything as if it were C, you can't write C as if it were everything else. Except that it makes a point that is subtly different from the one pg originally raised in discussing Blub paradox: If you only care about shipping something, you aren't inclined to think about abstraction as a goal state, and that's what these other languages are doing: handling things with a goal of adding abstraction that for a C++ user is out of reach or requires considerable knowledge of the C++ standard. Users of Python or JS don't know what a pointer is, and that's intended by design, because for most applications it is an implementation detail and automating it away is desirable. When most software was written in assembler, data structures more complex than an array were often avoided, because it was difficult to code and debug them. And if you were an assembly coder of that era, you might well say that you didn't see the point of structured programming, or that you could easily get the same effect in fewer bytes. And to some degree, you'd be right, because you would just design a smaller scope of application that makes those techniques viable. Trying to write something resembling modern C++ style in x86 assembly, in contrast, would be as fruitless as a JS coder trying to use C++ like JS, since your abstractions wouldn't be there. You'd have to learn the thought process of a lower level coder and apply those strategies instead of the ones you are comfortable with.
porpoisely 8y ago
I agree. I wasn't trying to say C++ is great for learning OOP. I was saying that C++ is the best OOP-style language to learn in general because it allows you to break things and it encompasses other paradigms. Ruby is great for learning OOP, but it is far less general and far more protective than C++. But I'm sure others will have their own preferences but to me the lack of training wheels in C++ almost forces you to learn. Otherwise, you simply won't progress. I guess that could be a good thing or a bad thing as it might force some people to quit early on. Ultimately, I don't think learning C++ or anything language should be something you regret.
zwieback 8y ago
Hmm, not my experience. C++ was my intro to OOP but I was aware of "pure" OO languages like Smalltalk. I feel like my C++ OO experience has taught me a lot although I think it's valuable to study another OO language side-by-side. A lot of OO patterns translate between languages although the implementation in C++ is often overly concerned with static types.

dkarl 8y ago

It also takes you a lot closer to learning C. Some of it doesn't directly carry over, and may even be deceptively similar without being the same, but for programmers coming from more modern languages, many of the big novelties in C and C++ are the same: - Manual memory management and direct use of pointers. - Emphasis on giving as much latitude as possible to compiler writers so they can generate fast code on obscure architectures. - Separation of header files from object files. - Explicit handling of object files and linking in the build process. In fact, I think after learning C++ you should be able to read almost any C code with no issue, which is nice for being able to peek under the hood of the infrastructure we rely on every day.