Comment by yearolinuxdsktp

Comment by yearolinuxdsktp 3 days ago

2 replies

Scala’s downfall is the culture of writing libraries with the most esoteric syntax imaginable. It’s the opposite of Ruby’s “program with pleasure”—-it is “program with maximum cleverness” and “if it doesn’t look like an obscure math equation or symbol soup, it’s probably not idiomatic Scala.” Java’s designers were opposed to operator overloading due to potential for abuse, and did Scala deliver living proof/nightmare scenario of that.

Now I still want operator overloading, because I favor enabling instead of disabling approaches, and I want, for example, new numeric types to have natural syntax that blends in with built-ins, or an equality operator that works consistently. I’ll even settle for += append to strings and collections.

But even Scala standard libraries take operator use to wild extremes. Apparently it’s not enough to use + to append collections, you must use ++. Except Vec you can add with +. There’s ++= and ++=:, and /: and :: and ::: and ?^ and ?^.

Spark Scala interface introduces =!= for inequality comparison. There’s |@| from Cons library. Don’t get me started on Akka. SBT introduces <++=

Surprisingly you can’t override ==, so Spark implements ===. And specs2 testing library implements ====.

hocuspocus 3 days ago

I've onboarded experienced and inexperienced developers to fairly big Scala codebases for the best part of a decade and I can't think of a single time symbolic operators were brought up as a source of complexity of confusion. Sbt deprecated <++= 10 years ago.

  • bearforcenine 3 days ago

    Agreed. There was a period of time roughly 10-15 years ago where symbolic operators in Scala were very en vogue. That fell out of style in a big way and I haven't encountered symbol soup in a very long time.

    Most of the conversations I have with folks about Scala issues these days center around implicits, tooling, and its decline/lack of popularity.