Can people really not decouple the words "for" and "yield" from other languages and just understand how a scala for-yield is desugared? Writing Scala and avoiding for-yield for the reason of it being superficially confusing to someone from another language doesn't really make sense to me.

Imagine if we also changed "while," "return" (which btw scala did), or "if" and made it do something different or similar. Would you still feel that way?

Part of the reasons people can learn new langagues "easily" is that there are universal concepts. When you don't change words but change the meaning then that creates unnecessary difficulty.

In my opinion if you want to introduce a new concept, also introduce a new vocabulary to address it.

We should strive for programming to be easier and more user friendly, and things like this do the opposite. Especially for people like me who switch between multiple languages in a day, it can be mentally taxing to make that context switch.

I've never understood ppl on HN defending things being optionally harder. Such is the CS mindset.

Completely agree w/ you here in terms of language design.

OTOH what's done is done and I don't think one needs to eschew an idiomatic concept just because the people who designed it suck at naming.

Another example is 'case class', because of its heritage I have colleagues who insist it should only be used for pattern matching purposes. I strongly suspect that if the designers were to do things over again that what we know as 'case class' would just be called 'class'

I haven't heard about "it should only be used for pattern matching." Is there a performance reason or something more stylistic?

I use them all the time because of all the convienence associated with them. I'm not really aware of the downsides except for the ~22 parameter limit (I hit it when deserializing JSON that represents many possible Option(al) keys... And named parameters are awesome).