50 ms·

> C++ is not a language I’d want to teach beginners. At no point in this post was there room for systems programming concepts, discourse on programming paradigm

> C++ is not a language I’d want to teach beginners. At no point in this post was there room for systems programming concepts, discourse on programming paradigms, computational-oriented problem solving methodologies, or fundamental algorithms. This is a ridiculous argument. The entire point of the post was, as the author even noted, purely to deep dive into a rabbit hole, get super picky & pedantic about standards wording so that you can act surprised that copy constructors exist in C++ while it was completely glossed over in the identical C example of a struct copy initialization, and almost none of this is useful to know. So don't fucking teach it and you'd have plenty of time to cover all that other stuff. Bam, problem solved. Ignore pre-C++11 entirely, and purely teach & use the new stuff which fixes all the complexity, and leave the rabbit hole for people that care about exploring the past. Oh, and don't use standards wording because those are for compilers to use to implement the language, not for programmers to understand how to use it effectively. The only time it's ever useful to know the full definition of an aggregate type or how it has changed is when you want to write a blog post calling them crazy or complex. It's never useful to know when using the language. And if you have an object that cares to enforce it just static_assert(std::is_aggregate_v<A>, "A isn't an aggregate type"); Tada, now the compiler will tell you if/when you violated the rule and you don't need to try and understand the full scope of the ruleset.

userbinator 8y ago
use the new stuff which fixes all the complexity It doesn't, unfortunately it just adds to the complexity.
- throwawaymath 8y ago
  How so? My experience has been that it actually reduces net complexity, except in the case where you need to support different versions of the language in the same codebase. Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead.
  - berkut 8y ago
    > Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead. When writing code, yes, but in my experience, it can also make interpreting what code that overuses auto is doing (especially what variables are and what functions return) an awful lot harder in many situations, and you end up jumping all over the place to work out that "auto result = ..." is actually "uint32_t result = ..." That's one of my personal pet peeves about more modern C++ (and other languages to some extent like Rust): they seem to be more optimised for writing code quickly (which generally only happens once), not understanding it later (i.e. you didn't write the code someone else did) and maintaining / altering it in the future, which generally happens a lot more over code's lifetime.
    - giornogiovanna 8y ago
      This is one of my worries about type inference (which C++ auto is not), but so far, the Rust code I've read has definitely been much easier to understand than the equivalent C code, and it's often much more generic. I like how Rust forces refuses to infer function signatures, which means you still always know the types of the inputs and outputs. I don't use IDEs, but I'd assume that they also make this whole thing a non-issue.
      - berkut 8y ago
        Relying on IDEs to do this type of thing really doesn't help for situations like merge conflicts (i.e. which merge tools understand languages fully?), and it doesn't completely solve the problem of easily understanding code just at a glance - you still need to go round mouse-overing or clicking on stuff to see extra detail.
    - mazok 8y ago
      is there a specific case that the uint32_t helps understanding the logic of the code?
      - 8y ago
DoofusOfDeath 8y ago
> This is a ridiculous argument. Please keep it civil. I'm sure you could refute the GP without expressing contempt.
MikeLui 8y ago
Hi. I appreciate your candor, although I'm not sure what I've done to inspire such contempt. You're correct that the entire point of the post was to deep dive into a rabbit hole. I acknowledged that and also acknowledged that the standardese is unnecessary most of the time, to avoid any miscommunication in my intent. I did this point out how large the language is and, more to the point, to point out how potentially complex it can be, compared to C. If you've ever had to spend entire weekends running through students' broken C code at scale, and see all the interesting ways one can complicate seemingly simple things, then I think you'd agree that giving them more ways to confuse themselves in a fast-paced academic environment is not the way forward. If you have had that experience and didn't have any problems, then you are fortunate to work with such fast learners! (Not to imply the students I've had are dumb in anyway, many are very bright!)
- umvi 8y ago
  C might be okay to learn for academic purposes but it's an absolute nightmare to use building real things. Things like strings and pointers are nightmarish in C. Segfaults aplenty. I've never encountered a segmentation fault since switching to modern C++. Just because you use C++ doesn't mean you have to use the entirety of it.
- reindeerer 8y ago
  > how potentially complex it can be Welp, time to go back to BASIC everyone. Or Go Powerful tools can be complex, who would have thought
- MichaelMoser123 8y ago
  I am not sure about the following issue: What would make your students more productive? - use C++, given that you stick to some convenient subset of C++ and can use stl - stick with C and force them to do the basics, like linked lists and string abstractions over and over again. I guess in the olden days really good students used to develop their own library of C abstractions, and reuse them with several courses; but you can't quite do that if you have C in just one course and what's the point anyway in this day and age ?
giornogiovanna 8y ago
A huge reason people teach C/++ to beginners is to understand how the "machine" works. Yes, the model C++ uses doesn't map too well to modern assemblies, and yes, it maps even worse to the actual hardware, but its abstraction is the one everyone uses, so it's worth teaching. Teaching modern C++ doesn't do that, at all. "Modern" C++ even has garbage collection (reference counting) in the form of shared_ptr! The author makes the good point that C is much better suited to this job than C++. Also, standards definitely shouldn't be inscrutable to programmers. Look at the ECMAScript and Go specifications, they're clear as day. Sometimes you just need to know exactly what your code is doing, and this only becomes more important in the low-level scenarios that C++ is often used for. I haven't read the C++ specification, but if it's as hard to read as everyone says it is, then there needs to be some other way to understand exactly what's going on. How else am I meant to precisely understand how my structs will be laid out, or which casts are guaranteed to be valid, or whether the language allows data pointers and function pointers to be interchangeable?

userbinator 8y ago

use the new stuff which fixes all the complexity It doesn't, unfortunately it just adds to the complexity.

throwawaymath 8y ago
How so? My experience has been that it actually reduces net complexity, except in the case where you need to support different versions of the language in the same codebase. Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead.
- berkut 8y ago
  > Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead. When writing code, yes, but in my experience, it can also make interpreting what code that overuses auto is doing (especially what variables are and what functions return) an awful lot harder in many situations, and you end up jumping all over the place to work out that "auto result = ..." is actually "uint32_t result = ..." That's one of my personal pet peeves about more modern C++ (and other languages to some extent like Rust): they seem to be more optimised for writing code quickly (which generally only happens once), not understanding it later (i.e. you didn't write the code someone else did) and maintaining / altering it in the future, which generally happens a lot more over code's lifetime.
  - giornogiovanna 8y ago
    This is one of my worries about type inference (which C++ auto is not), but so far, the Rust code I've read has definitely been much easier to understand than the equivalent C code, and it's often much more generic. I like how Rust forces refuses to infer function signatures, which means you still always know the types of the inputs and outputs. I don't use IDEs, but I'd assume that they also make this whole thing a non-issue.
    - berkut 8y ago
      Relying on IDEs to do this type of thing really doesn't help for situations like merge conflicts (i.e. which merge tools understand languages fully?), and it doesn't completely solve the problem of easily understanding code just at a glance - you still need to go round mouse-overing or clicking on stuff to see extra detail.
  - mazok 8y ago
    is there a specific case that the uint32_t helps understanding the logic of the code?
    - 8y ago

DoofusOfDeath 8y ago

> This is a ridiculous argument. Please keep it civil. I'm sure you could refute the GP without expressing contempt.

MikeLui 8y ago

Hi. I appreciate your candor, although I'm not sure what I've done to inspire such contempt. You're correct that the entire point of the post was to deep dive into a rabbit hole. I acknowledged that and also acknowledged that the standardese is unnecessary most of the time, to avoid any miscommunication in my intent. I did this point out how large the language is and, more to the point, to point out how potentially complex it can be, compared to C. If you've ever had to spend entire weekends running through students' broken C code at scale, and see all the interesting ways one can complicate seemingly simple things, then I think you'd agree that giving them more ways to confuse themselves in a fast-paced academic environment is not the way forward. If you have had that experience and didn't have any problems, then you are fortunate to work with such fast learners! (Not to imply the students I've had are dumb in anyway, many are very bright!)

umvi 8y ago
C might be okay to learn for academic purposes but it's an absolute nightmare to use building real things. Things like strings and pointers are nightmarish in C. Segfaults aplenty. I've never encountered a segmentation fault since switching to modern C++. Just because you use C++ doesn't mean you have to use the entirety of it.
reindeerer 8y ago
> how potentially complex it can be Welp, time to go back to BASIC everyone. Or Go Powerful tools can be complex, who would have thought
MichaelMoser123 8y ago
I am not sure about the following issue: What would make your students more productive? - use C++, given that you stick to some convenient subset of C++ and can use stl - stick with C and force them to do the basics, like linked lists and string abstractions over and over again. I guess in the olden days really good students used to develop their own library of C abstractions, and reuse them with several courses; but you can't quite do that if you have C in just one course and what's the point anyway in this day and age ?

giornogiovanna 8y ago

A huge reason people teach C/++ to beginners is to understand how the "machine" works. Yes, the model C++ uses doesn't map too well to modern assemblies, and yes, it maps even worse to the actual hardware, but its abstraction is the one everyone uses, so it's worth teaching. Teaching modern C++ doesn't do that, at all. "Modern" C++ even has garbage collection (reference counting) in the form of shared_ptr! The author makes the good point that C is much better suited to this job than C++. Also, standards definitely shouldn't be inscrutable to programmers. Look at the ECMAScript and Go specifications, they're clear as day. Sometimes you just need to know exactly what your code is doing, and this only becomes more important in the low-level scenarios that C++ is often used for. I haven't read the C++ specification, but if it's as hard to read as everyone says it is, then there needs to be some other way to understand exactly what's going on. How else am I meant to precisely understand how my structs will be laid out, or which casts are guaranteed to be valid, or whether the language allows data pointers and function pointers to be interchangeable?