[tialaramex]

"Do as I say, not as I do" is known to be poor pedagogy.

If you find that expert practitioners don't do the things you think students should be doing, it suggests that something is wrong and needs fixing. In the standard library implementations it's very obvious that something is badly wrong, and yet for decades C++ has resisted the hard work of fixing it.

[jcelerier]

Yet thousands of people learned C++ well enough to use it in a professional setting, so surely << "Do as I say, not as I do" is known to be poor pedagogy. >> does not hold in the general case.

> If you find that expert practitioners don't do the things you think students should be doing, it suggests that something is wrong and needs fixing

It does not and is a very naïve world view. In any trade expert practitioners' way of working is wildly different from what you would learn in a classroom (and generally makes said student's hair raise on their head when they see. This is not too relevant with C++ though as the std implementation "ugliness" is mainly driven by material constraints.

Besides in general in programming this is not even possible. Like, from your argument one wouldn't be able to learn how to use the Win32 API or Cocoa API since the operating systems using them are closed-source and you cannot see how they are implemented & used by the teams who develop these APIs.

[tialaramex]

No, I reject the claim that "my argument" (not in fact mine) says you can't learn an API unless you can see how it's implemented. I don't think that's a remotely plausible reading of what was written. Instead I agree with the claim they actually wrote that since software is intended first and foremost to be read, it makes sense that the standard library, software you'll be using as a programmer should be a positive example and not a horrible distorted mess.

[josephg]

> This is not too relevant with C++ though as the std implementation "ugliness" is mainly driven by material constraints.

These "material constraints" are clearly completely artificial - since they don't show up in other languages (rust, go, swift, haskell, etc etc). For example, in C++'s std header files:

- Symbols are hand-mangled. (Why? Wasn't that the whole point of C++ namespaces?)

- There are no comments. I'm guessing the reason for this is that C++'s idiotic build process dedicates an insane amount of CPU time to redundantly reparsing the std header files over and over, forever. This has a very real performance impact across the ecosystem. Either that or the authors just don't believe in commenting their code.

- Templating seems to make the code even more unreadable. Which is strange, because rust's standard library also uses generics and yet it is totally readable.

- Different C++ compilers have different implementations of the standard library, with different performance profiles and quality standards. There is no good reason for this.

> Like, from your argument one wouldn't be able to learn how to use the Win32 API or Cocoa API since the operating systems using them are closed-source and you cannot see how they are implemented & used by the teams who develop these APIs.

This wasn't the central argument, but you're still kinda right about this!

I don't have much experience with windows, but I can tell you from my personal experience that it is significantly harder to understand Apple's platform APIs because the code is closed source. There are lots of important methods in Apple's APIs with obscure, technical names and next to no documentation. You have no idea what they do, or if they'll solve the problem you're facing. Its crazy frustrating. When working with opensource code (eg rust, javascript, java, etc) I'm constantly reading the source code of library functions I call to understand how they work and what they do. Its like a backstop for documentation. If the docs are missing or not good enough, having the code available means I can still almost always figure out how to solve my problem.

I can't find it now, but there was a comment thread about windows engineers a few decades ago admitting they made some APIs obscure and badly documented on purpose so they could make money writing and selling technical books on the side on "Windows Internals". Because the source code wasn't available and documentation was shoddy, you needed to buy those books in order to understand and use some of the windows APIs correctly.

So yes, library code should be readable. When you can't read the libraries you're using, it causes all sorts of problems.