1. 9

Paul Phillips (formerly a core dev on scalac) points out some problems with the Scala Collections Library and proposes some solutions.

GitHub repo here: https://github.com/paulp/psp-view

  1.  

  2. 1

    I have an ongoing love/hate relationship with Scala.

    I find it incredibly complex, often hard to reason about, I semi-regularly hit issues where I am rewritting code because the type inference gets confused. I often find it harder to understand other people’s scala code than even some of the more obscure mixin ladden ruby code that I’ve seen (my previous high watermark for code I regularly interacted with that left me scratching my head.) I maintain some legacy scala code that code work just as well as Java code. And on and on. I could write/talk about the issues I have with scala and the tradeoffs in it and how it used. All of those things aside, there is a core of goodness in scala.

    I wish there was a simpler, easier to reason about, type safe, flexible, functional friendly, well supported jvm language. Perhaps someday there will be but at the moment, the closest thing to my ideal for the tool I need when I reach for Scala, is currently Scala, warts and all because nothing else tops it on the “well supported” front.

    I’m also interested in knowing what are the alternatives if you want:

    runs on jvm statically typed (w/ a powerful type system rather than a weak one like java’s) good jvm interop functional friendly, ideally also oo friendly well supported simple core to the language

    and what of those you give up with the various alternatives.

    Anyone care to comment on the strengths/weaknesses in the general categories above of any languages they use?

    1. 4

      I don’t believe Scala has “good” JVM interop:

      • Full interop to awful Java code is not a part of what I consider being good
      • Interop shapes Scala and causes Scala to not be able to do good things and requires it to do very bad things
      • It’s not safe, e.g. I think NullPointerExceptions should be handled at every interop point (into OptionT)

      Scala’s interop with Java is just a cost. I’d much prefer an FFI:

      • I’d write a quick and sensible Java API wrapper around any nonsense Java API
      • Scala language could change independent to FFI
      • We could encode null and exceptions in the types!

      Frege, Ermine and Idris all provide something like what I want. The “well supported” part is a question, but I don’t even know what I’d consider to be a “well supported” language.

      Also, I think the JVM is extremely overrated. People often say they use it because it’s fast - but they only consider that Java-like code on the JVM is fast - so far, functional code is often quite slow on the JVM.

      So, we want fast, functional and the JVM - it might eventually be possible to achieve all three but without much development, we can really only choose two. My pick is moving Scala code to Haskell.

      1. 2

        emphatic agreement about the horror / pain that is every Scala value being nullable by default. That alone has kept me from really trying to write good code in scala