Or it even uses patterns which would be considered anti patterns outside of it for the sake of optimizations.

For older languages, it’s also pretty common for some of the stdlib’s corners to be very dusty with API design, naming conventions, and coding patterns considered at best way outdated.

System.Collections.IEnumerable says hello

Optimized code is not an anti pattern! What is an anti pattern is premature optimization, code you write a certain way because you think it is optimized but because you don't understand the compiler and hardware, it is not.

Optimizations in standard libraries are generally good ones, and reading it can give a good idea of what is or isn't worth it.

I think the comment simply stated that when learning a language you should focus on idiomatic code and not optimizations. The latter which is probably present and justified in a standard library.

Very well put.

(And if the standard library doesn't represent idiomatic use of the language, that's a red flag).

Take Scala collections. These are written using builders and if-else checks of emptiness which are definitely not idiomatic. Authors of the std-lib did them for you so you do not have to. That is not a red flag.

The other way around: non-idiomatic use of a language in its standard library points to weaknesses in the language.

If emptiness is something that is so important you add extra branchpoints inside collections to check for it, there ought to be some way of disallowing emptiness or {nil,null}ness in the language itself.

Sure, it is nice for people who use the standard library, but it points to things in the language that perhaps should have been given some more thought.

I'm not sure I would call it a weakness. Performance vs expressiveness and maintainability will always be a trade off. It could be a weakness, but it's just as likely that it was a deliberate trade off.

Though this argument also supports the parent comment actually: notably, standard library has much higher than usual chance and assumption of being possibly used in tight loops - with no way to relax that assumption based on actual (often closed-source) usage. So the same optimizations done in stdlib could perfectly well be considered premature if done in non-stdlib code (even if we imagined some func was not in stdlib and one needed to write exactly same func in one's code).

A library like Java Collections API sometimes uses optimizations involving bitshift etc which is too confusing for most application level code. So your comment that it's not an anti-pattern to do such things in application code is something I have to disagree with.

You seem to be implying that it is desirable to employ programmers who would get confused over bitshifting and lack the ability to figure it out.

It's the norm to work together with people with varying skill level.

Weather people have the skill to figure it out also doesn't matter as they normally don't have time to figure it out.

And even experienced programmers can get confused about bit hacks, sure temporary but that already a step price to pay which is seldomly worth it. It always comes with the risk of accidentally introduce a bug, even if your team only consists of senior devs. And it always hampers productivity.

I am against the idea of holding back for newbies.

If you think bit hacks are bug prone, needlessly complex, and not worth it, don't use them. But if your only argument is "junior may not understand", then no.

Newbies need to learn, if they always face newbie friendly code, they will be newbies forever. So yes, it takes time understanding a new technique, but it is an investment.

Later, when not-junior-anymore has to decide on an implementation, he then can chose the most appropriate among the many he saw, including bit hacks. It doesn't mean bit hacks are the best, or that he will use them, but because of his experience, he will make a more informed decision.

Note that I assumed code intended for professional developers. The situation is different if you are targeting non-specialists (ex: macros for end users) or if you are making example code.

I agree that complex bit hacks makes code less readable and should be avoided. But that's not necessarily what we're talking about here. Most common uses I see of shift operators tend to do the opposite: they make what you are doing more explicit when you do bitwise operations.

If flipping the Nth bit inside an integer or a byte array is an "advanced" technique, unfit for "application programmers" then I'm not sure I want to work with "application programmers".

I'd go even further. As long as you want to communicate your ideas via code it does not matter whether you work with juniors or seniors. You want to limit the cognitive strain caused by unnecessarily complicated code.

Actually, this isn't so much an argument against reading the standard library as it is another reason to do so.

If the standard library is ugly and complex, it tells you something important about its design, and possibly about the language itself and its maintainers. It is a good indication of where things might well end up for you.

You should look at the ugly bits, and you should ask yourself "am I going to invest in this?"

That's why I decided not to invest in Scala. Its standard collections library was so hard to grok that I just decided to stay on Java. I must understand everything in the entire stack I'm using. If I have blind spots, it makes me nervous.

Java is pretty good in that regard, for example. I regularly browse its standard library and it's quite comprehensible. Concurrent stuff is not easy, but I guess that's the nature of underlying algorithms.

Also that's the reason that I don't like Java streams. They're as hairy as Scala collections. I'm avoiding Java streams.

IMO implementation details of any library matters as much as its public API. If library implementation is not nice to read, it's a very bad smell.

The trick is to read unfaithfully. You don't need to understand everything in the standard library. You just need to swim around in good code for a while. If you're in over your head, chances are you can skip that part.