[pkinsky]

>With Scala you feel smart having just got something to work in a beautiful way but when you look around the room to tell your clojure colleague how clever you are, you notice he left 3 hours ago and there is a post-it saying use a Map

I don't get this. Scala has a great collections library, including a Map type. What, exactly, is the author complaining about?

[nickik]

His point is that Scala and the Scala community dont just use maps, they always want everything in types and that is why every library does it that way. Its bad practice just to use a map. In Clojure land its the other way around even if we put something in a type (deftype) we right interface to make it look like its not (defrecord).

Its not what is possible, but what is. And the fact is that all the Clojure web framework and library's use the same data structure even if the underlying implementation is different. See how ring uses much of the same thing as the pedestal service.

[yummyfajitas]

Yes, and there is a good reason why Scalaland uses types. Consider a Spray-like API using only maps:

    val cookies = Map("sessionid" -> "1234567")
    val headers = Map("Content-Type" -> "application/javascript")

    setCookies(headers) {
      setHeaders(headers) {
        complete { obj }
      }
    }

With Scala's "make everything a different type" approach, that's a compile error - setCookies will expect a List[Cookie], not a List[HttpHeader].

Those of us living in Scalaland are not as smart as the Clojure guys. We make mistakes sometimes and find it handy when the compiler yells at us.

[kasey_junk]

This is actually a good example of something I don't like in Scala. They don't make this sort of differentiation easy enough. Adding a Haskell style newtype would be really, really useful.

[yummyfajitas]

Scala has value types.

    case class MyNewType(x: String) extends AnyVal

What do you want to do that that isn't sufficient for?

[kasey_junk]

AnyVal's would probably be sufficient except for the following: - Instantiation of the MyNewType happens all the time and is not obvious from inspection of the code (generics, use as another type if we implement a trait, etc). - If we want to call any of the methods on the wrapped type we have to call directly to the wrapped type violating Demeter. - Verbosity.

[yummyfajitas]

If we want to call any of the methods on the wrapped type we have to call directly to the wrapped type violating Demeter.

You can also use tagged types:

http://eed3si9n.com/learning-scalaz/Tagged+type.html

But most of the methods will untag the type. I.e., ("foo" @@ ValidJsonString).substring(3,7) will be a String, not a String @@ ValidJsonString.

[noelwelsh]

Unboxed tagged types to the rescue:

http://etorreborre.blogspot.co.uk/2011/11/practical-uses-for...

Scalaz implements this, so you can use it straight away. We use it mostly to control implicit selection.

[kasey_junk]

Tagged types also have their problems.

1st they don't propagate, call a function on the tagged type and it returns the underlying type.

2nd they aren't type safe against the tagged type, so you can pass tagged types into functions that take the underlying type by default.

3rd in practice my code with tagged types ends up having lots of boilerplate and/or magic code that is hard to understand.

4th there are some pretty heinous compiler bugs that you will encounter with tagged types.

[noelwelsh]

It seems you've done a lot more with them than I have. I'm looking forward to crashing the compiler -- the true badge of honour amongst Scala developers ;-)

[yummyfajitas]

They absolutely shouldn't propagate.

    val x = 1.0 @@ Kilograms
    val y = x*x

y is not a Double @@ Kilograms.

[laureny]

Value classes make tagged types obsolete:

http://docs.scala-lang.org/overviews/core/value-classes.html

[noelwelsh]

They still have uses for disambiguating implicits. There are at least four monoids for the Int: 0/+, 1/*, MinValue/Max, and MaxValue/Min. It is useful to tag them so one can specify which monoid one wants.