1. 4
  1.  

  2. 4

    The debunked myths didn’t really sound like debunked myths to me, but rather “I don’t write my Scala like this”. I have had people complain to me about sbt being a bunch of random symbols just this (apparently ~ vs no ~ in some part of a file makes a massive semantic difference). It’s not a debunked myth if you just happen to not use Scala in a particular way.

    1. 1

      Just as abstraction bears the possibility of over-abstraction, the simplicity of symbolic methods bear the risk of overuse. I think what the author wants to say that it doesn’t matter in practice, regardless of what the they-sky-is-falling proponents claim on the internet.

      1. 3

        I think what the author wants to say that it doesn’t matter in practice, regardless of what the they-sky-is-falling proponents claim on the internet.

        Oh, I can’t speak for everyone that talks about the complexity fo Scala, but the ones I can come from a position of complexity being the slow death of a good idea. Hardly alarmist and usually something people are willing to give lipservice to.

    2. 4

      In Haskell, which frequently bears the blame for symbol overuse in the Scala community (those damn Haskell wannabes in scalaz!), symbolic operators are very frequent, but they tend to have extremely well-defined semantics, are usually built on mathematical notation, must be explicitly imported, and cannot be complicated by implicits. In Scala, on the other hand, you get this. Combined with Scala’s conceptual overload (Java-style OO and all its ceremony, FP and all its ceremony), its overly flexible syntax, and lack of established best practices, it became very difficult to read my own code if I happened to use a library or technique that was more complex than the most simplistic examples.

      I left Scala and started to learn Haskell at that time.

      EDIT: Actually, looking back at Scala, I remember the insanity a bit better. Dispatch isn’t the best example because it is, after all, an optional library. Things like this in the standard library are the worst offenders:

      val xs = List(1, 2, 3, 4)
      val product = (xs :\ 1)(_ * _)
      

      The use of this type of unnecessary operator may be discouraged in style guides, but they’re available in the standard library and, just like C++, you end up having to read code written using them. Compare the equivalent Haskell:

      let xs = [1, 2, 3, 4]
      let product = foldr (*) 1 xs
      

      The Haskell version is actually just as short despite not engaging in operator golf.

      EDIT #2: Okay, apparently I have stumbled upon a pet peeve I didn’t know I had!

      In Scala, the foldLeft and foldRight products for a given list:

      (xs :\ 1)(_ * _)
      (1 /: xs)(_ * _)
      

      In Haskell, the same:

      foldr  (*) 1 xs
      foldl' (*) 1 xs
      

      (There is a bit of history behind foldl' instead of foldl, but it comes down to backward compatibility.)

      1. 1

        they tend to have extremely well-defined semantics, are usually built on mathematical notation, must be explicitly imported, and cannot be complicated by implicits

        You are aware of the fact that you can define operator associativity and precedence on each operator definition in Haskell? The only well-defined thing about that is that there is no well-defined semantics at all.

        I’m not going to defend /: and :/ [sic], because it’s stupid to have redundant methods if everyone could just use foldLeft and foldRight, but if this and a out-dated legacy version of some obscure library are your best points, it’s no surprise that Scala people stopped caring about these things.

        1. 3

          Yes, of course you can define operator associativity and precedence. However, the operators are usually defined mathematically in the context of a given concept, which itself is well-defined. There is less action at distance, too: you have to import operators and there are no implicit conversions, so it’s usually obvious where a given operator comes from and what it means in a given context.

          The operator overloading and bizarre DSL phenomena in Scala libraries is not past, though. Although some of the most egregious offenders (namely dispatch and sbt) have walked their design back after some “lessons learned,” there are still things like specs2’s hideous string-based testing DSL, or Argonaut’s operator-soup for JSON parsing and presentation (I particularly like -->>?:).

          It’s subjective, but I would also say the communities play a role: the Haskell community has been nothing but helpful to me. Scala was not as pleasant.

          Good catch on the :/ typo.

          1. 2

            There is less action at distance

            You can always just click on the method to see where it is defined. It’s not a big deal.

            Argonaut’s operator-soup for JSON parsing and presentation

            http://argonaut.io/#developers

            Scala was not as pleasant.

            I can only encourage you to try again! After certain Haskell people have been ejected, things have become a lot more pleasant recently.