Hmm I guess they have been actively shrinking the jar (it isn't 4 megs but ~5.5... still a massive improvement [1]).
As far as kitchen sink I'm still not sure what idiomatic Scala is especially with the likes of Scalaz. Maybe modern Scala is finally abandoning the OOP fusion.
Of course my biggest reason of not liking Scala is completely arbitrary and almost illogical (of course most reasons to (dis)favor things are arbitrary). If I write in an FP language I hate using curly braces. I prefer Haskell, OCaml, and even Lisp syntax for FP. For some reason curly braces makes me think hmm imperative shit. Not to mention Scala has lots of scoping and closure use so you see lots of curly braces.
And that brings me to another point. Scala code isn't really that much more compact (lines of code or even compressed size) to Java 8 (compared to Haskell or OCaml).
I would disagree with the comment on verbosity compared to Java 8/Haskell/Ocaml.
Most of the things I do regularly in Scala would require a magnitude of more code.
Ocaml doesn't even have higher-kinded types or implicits, so I don't think it can win much on that front (except of saving a line where Scala's curly brace might be).
With Haskell it really depends. There are certainly ways to write much more succinct code, but what I see in practice is that it's not that much different from Scala. Haskell has it's own unsolved issues though: broken typeclasses, lacking module system, poor tooling, and a weekly-changing, terrible dependency management.
I'm not sure I like implicits as for HKT... "with great power comes...".
HKTs are great for a generic library writer (aka standard library) but I think the over abstract nature ends up confusing your average developer. You basically have your type aficionados obfuscating the codebase for developers who can barely handle generics. It is sort of analogous to using massive reflection / meta-programming in scripting language (albeit far more safe).
Being extremely implicit and abstract comes with a cognitive load.
OCaml's Functors (ie super strict and explicit) on the other hand can get massively repetitive.
I vaguely remember HKTs being expensive compile time. Is that still the case?
I think they're a necessary evil. I need extension methods, ad-hoc polymorphism, and a way to use ad-hoc polymorphism while still writing nice DSLs (i.e. what spray calls the magnet pattern). I'm nervous about implicits, but I haven't seen a better solution.
> HKTs are great for a generic library writer (aka standard library) but I think the over abstract nature ends up confusing your average developer.
There are few things more frustrating than having to copy-paste because your language can't handle the abstraction. There are less cases where you need HKTs than where you need basic generics, sure, but sooner or later you do need them. And since everyone hates copy-paste, they end up using annotations or reflection or string-based templating to generate code, all of which end up more confusing to the average developer. At least with HKTs you still have ordinary values that follow the rules of the language, rather than wondering whether you can still factor out a common method because it's called from an annotated method and an unannotated method, and what annotations you need to put on it to make that work.
> I vaguely remember HKTs being expensive compile time. Is that still the case?
HKTs per se are not expensive. Type inference in the presence of HKTs can be expensive (though note that even in OCaml or pure ML there are pathological cases for type inference - http://cs.stackexchange.com/questions/6617/concise-example-o... ). Scala implicit resolution can be expensive especially when used with recursion; global-uniqueness constraints a la Haskell typeclasses would be one solution, but arguably introduce more trouble than they're worth. One way or another, Scala compilation ends up being pretty slow, which is unfortunate.
The great about types in Scala is that complex solutions to complex problems can be contained and don't infect the rest of the codebase.
The average programmer can enjoy completely consistent names and signatures across different libraries, without having to know that the consistency comes from one method being applicable to various types, not manual labor repetitiously adding the same method to different types which can drift apart at any time without anyone noticing.
HKTs are not that expensive. Slow compile times are usually caused by people doing Prolog at the typelevel in Scala.
As far as kitchen sink I'm still not sure what idiomatic Scala is especially with the likes of Scalaz. Maybe modern Scala is finally abandoning the OOP fusion.
Of course my biggest reason of not liking Scala is completely arbitrary and almost illogical (of course most reasons to (dis)favor things are arbitrary). If I write in an FP language I hate using curly braces. I prefer Haskell, OCaml, and even Lisp syntax for FP. For some reason curly braces makes me think hmm imperative shit. Not to mention Scala has lots of scoping and closure use so you see lots of curly braces.
And that brings me to another point. Scala code isn't really that much more compact (lines of code or even compressed size) to Java 8 (compared to Haskell or OCaml).
[1]: https://mvnrepository.com/artifact/org.scala-lang/scala-libr...