It's from the standard collections library, the most-used code in any language.

It is in fact representative of the vast majority of code you use.

The fact that it wasn't immediately clear to you that a lot of your code DOES use this code is probably the strongest argument I could make.

Now I love C#, but in defense of the above poster, standard library code is often pretty gnarly stuff.

C++ is the poster child for this. No one argues that C++ is a bad language just because the standard library is full of magic.

Actually, I hold exactly that opinion about C++ :)

I find the STL great! Sure, some compiler template messages can be tricky to understand but STL doesn't detract from C++ - you don't have to use the STL (but you're probably losing out if you don't use it and roll all those containers and algorithms yourself)

Oh using the STL itself is fine, but some of the code behind it looks like a completely different language!

You have inferred more about me than you are entitled, and even if you were right, your argument is still poor. Have you read the c# stdlib? It is in no way any better. Stdlibs are always more complex than the code that builds on them, and that is by design. The same code that I use for a oneliner has to be robust enough to apply to play, akka, spark, finagle, etc. That is the primary reason why StdLib documentation is made more accessible. I have never had to read the Scala StdLib source code, and likely a tiny minority of Scala devs have done so.

The internals of STDlibs tend to be nasty, but externally they're designed to be clear. The problem here is externally these interfaces are extremely messy and hard to follow, i.e. the abstraction doesn't seem to work.

That is a good distinction to make. But then, you need to consider other factors as well. How powerful is the API, how honest is the API (doesn't hide internal gimmicks), how consistent is the API across the lib, and how DRY it is (to the STDlib implementors).

Scala's STDlib might be more powerful, more honest and more consistent, and also might be striving to be DRY for the implementors.

Personally, I feel that Scala's Collections goes overboard in hitting the above goals, and the resulting signatures are too verbose. And this increases the cognitive load for the subset of people that need to bother about it (performance tuners, architects, etc). But that's not a fault of the language per se.

I inferred that you probably use standard library collections. Not really an insulting inference, it'd be insulting to assume you didn't.

Personally, I make it a habit to always read (or try to read, in this case) standard library source code that I'm depending on to be correct.

Have you read the implementation of the python collection types (list, map, etc.)?

It is not representative probably because the IDE hide the ugliness.

The official docs do to.

To get the "ugly" signature you have to look at the actual source, or example the method definition in the official docs.

They go out of their way to make sure to present an easy-to-understand version for actual users.

Which is why every actual Scala developer rolls their eyes at someone bringing up CBF. You have to go out of your way to try to be confused about it. And if that digging stops at finding the method signature, well, probably serves you right for being confused. ;-)

Is CBF amazing? Probably not. Is it some sort of confusing eternal battle for most Scala developers? Absolutely not.

I mean just look at the official docs, find out where he got these weird examples from, and then tell me this is a well reasoned argument.