
Take on Haskell vs Scala - rohshall
http://jnordenberg.blogspot.sg/2012/05/my-take-on-haskell-vs-scala.html
======
tikhonj
It's a good comparison of the two languages.

Regarding type classes, I personally like Haskell's approach more. I haven't
used Scala, so I'm assuming that objects there behave the same as modules in
OCaml (at least in practice for this particular purpose). Essentially, Haskell
makes the right compromise: the most common case (having one instance per
type) is easy while the less common case (explicitly specifying the instance)
is less easy. The core difference is this: when you want to use a different
"instance" in OCaml, you just pass in a different module; in Haskell, you have
to create a new type.

Happily, creating a new type is easy, especially with newtype deriving which
lets you bring instances you don't want to change over to your new type for
free. This has some advantages: the instance is now encoded in the type, so
that you cannot mix different ones by accident. This is useful because it's
quite easy to have code that depends on, for example, a consistent compare
function in different places on the same type. This also lets the choice of
implementation be implicit at the call site, so you only have to specify the
instance once rather than repeatedly in different places.

I think there is also a good case for type classes not being reified as
modules or dictionaries or objects or what have you: they essentially exist
exclusively at the type level. That is, the instances are a property of each
type, not part of a module or anything like that. This also makes the syntax
for types clearer: the => acts as implication and the type class acts as a
predicate on the type.

In summary: type classes _are_ more restrictive than first-class modules, but
this is a good compromise. You can get the same effect with newtype, with the
added bonus of having the difference reflected in the type system.

I'm afraid I have not managed to make my thoughts on type classes too clear.
I've been thinking about that particular design trade-off (type classes vs
first-class modules) and writing this has probably helped me get my thoughts
together far more than it will help any readers :P. Maybe I'll write a blog
post about it--I've been meaning to start a blog for a while now...

Some other thoughts: I think laziness is a good thing because you trade
performance for simplicity and expressiveness. It's easier to add strictness
to a lazy language than vice-versa. But I essentially use Haskell where others
would use something like Python, so its _relative_ performance is well beyond
satisfactory even with plenty of space leaks :P.

As far as developer tools go, Scala has Ensime [1] and Haskell has Scion [2]
but I've used neither. OCaml has TypeRex [3], which I _have_ used and is
pretty cool. Assuming that Ensime and Scion are similar to TypeRex, they're
certainly good enough. You never have to leave Emacs :).

[1]: <https://github.com/aemoncannon/ensime/>

[2]: <http://code.google.com/p/scion-lib/>

[3]: <http://typerex.org/>

Coincidentally, OCaml has some of the advantages the author found in Scala
while being more like Haskell. I would certainly consider at least playing
around with it a bit--it's a very nice language. I still prefer Haskell, but
not by too large a margin.

~~~
chrismonsanto
(shameless plug) If you're into alpha code, you should check out my hie [1]
(haskell-in-emacs). When I wrote it, ghc-mod and scion only supported show-
type-at-point when the file typechecks, which is more or less useless when
refactoring. Pretty sure that is still the case.

hie actually parses the file (using a modified version of haskell-src-exts to
support more extensions), and gives show-type-at-point, goto definition, and
auto complete with inline haddock documentation. Its autocomplete is context
sensitive--for instance, if you type "import " you will only see modules. It
also works somewhat incrementally and on-the-fly. YMMV, and it isn't
documented well, but I use it every day and haven't had any problems.

If you want to try it out, you'll probably need Emacs 24. It might work on
Emacs 23. Use hie-fetch.py to fetch the source for all of the packages you
have installed, and "hie-hackage.py cachedir" to pre-cache your libs. First
time import of Prelude will be slow, but afterwards should be instantaneous.

If you have problems the code is pretty self-explanatory IMO, but feel free to
e-mail me (addr in the .el file) with comments and concerns.

[1]: <https://github.com/monsanto/hie>

~~~
tikhonj
That looks really nice--I'll have to try it soon. I like your commit messages
there, coincidentally :P.

------
vorg
A comparison between two languages only makes sense if the purpose of each
language is the same, e.g. if the purpose of both Scala and Haskell is to
enable programmers to build stuff easily, or if it was to build performant
code, or whatever.

But if the purposes are different, then comparing Scala and Haskell is like
apples and oranges. If Scala's purpose is, say, to introduce Java programmers
to Haskell, then a comparison would even be part of the purpose of Scala.
Moving Java programmers to Haskell could very well be Odersky's real motive
behind building and marketing Scala. He could actually be a hero of the
programming ecosystem instead of a former academic who started a company to
milk a software product he got grad CS students to build for free. This talk
about exploring functional/object fusion could be bogus, a cover story for
showing programmers how easy typed functional can be, and prompting them to
consider a full move to Haskell.

In fact, Clojure looks like a similar case of introducing something to Java
programmers. What with Clojure for Javascript coming out, and now even a
C-target version, Clojure's looking more and more like an underhanded way to
move Java programmers to Lisp. Surely Hickey's finishing the job, started back
in 1995 when Java "moved C++ programmers half way to Lisp".

~~~
IsTom
"Sometimes comparing apples to oranges is all you can do."

------
MaleKitten
I think the "final words" are the definition of 'obsequious'. Say something of
real substance, and commit to it:

"Haskell and Scala are both very powerful and practical programming languages,
but with different strengths and weaknesses. Neither language is perfect and I
think there is room for improvements in both. I will definitely continue to
use both of them, at least until something better shows up. Some new
interesting ones on my radar are Rust, ATS and Idris."

~~~
dan00
"I think the "final words" are the definition of 'obsequious'. Say something
of real substance, and commit to it:"

Because someone isn't a fanboy and isn't just stupidly commiting himself to
one thing, than he's obsequious? Well, I would call this a smart person.

------
dkhenry
The only disagreement I would have is that while the JVM is a great runtime, I
would love the ability to compile to native code to get faster start up times.

Also I know its a preference thing, but I like curly braces. It makes an old C
programmer feel more at home.

~~~
pjmlp
There are some commercial solutions that compile bytecode to native code, but
they are a bit on the expensive side.

Aonix and JET are two of them.

Sadly, GCJ is dead even though is still part of GCC.

