Skip to content

Instantly share code, notes, and snippets.

@tonymorris

tonymorris/haskell-scala.html

Created June 4, 2014 02:07
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tonymorris/c6472603e1fb9401b12a to your computer and use it in GitHub Desktop.
Save tonymorris/c6472603e1fb9401b12a to your computer and use it in GitHub Desktop.
Download ZIP
Raw
haskell-scala.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet" href="/stylesheets/export.css"/>
<link rel="shortcut icon" type="image/x-icon" href="/favicon.ico"/>
<link rel="canonical" href="http://www.stackprinter.com/export?service=programmers.stackexchange&amp;question=51245&amp;printer=false&amp;linktohome=true"/>
<title>What kind of things are easy in Haskell and hard in Scala, and vice versa?</title>
<script type="text/javascript" src="/javascripts/jquery-1.4.2.min.js"></script>
<script type="text/javascript" src="/javascripts/main.js"></script>
<script type="text/javascript" src="/javascripts/prettify/prettify.js"></script>
<link rel="stylesheet" href="/stylesheets/prettify.css">
<script type="text/javascript">jQuery(document).ready(function(){StyleCode();});</script>
</script>
</head>
<body>
<div id="home">
<a href="/"><img title="Back to home" width="20px" height="20px" src="/images/icon_home.png" style="border:0"/></a>
<a href="http://www.stackprinter.com/export?format=HTML&amp;service=programmers.stackexchange&amp;printer=false&amp;question=51245"><img title="Link to this printed question" width="20px" height="20px" alt="share" src="/images/Share.gif" style="border:0"/></a>
</div>
<div id="question-block">
<div id="question-title">
<img alt="Programmers" src="http://cdn.sstatic.net/programmers/img/apple-touch-icon.png"/>What kind of things are easy in Haskell and hard in Scala, and vice versa?<br/>
</div>
<div class="question-details">
[+64] [7]
Daniel C. Sobral
</div>
<div class="question-details">
[2011-02-24 02:02:00]
</div>
<div class="question-details">
[
programming-languages
functional-programming
scala
haskell
]
</div>
<div class="question-details">
[ http://programmers.stackexchange.com/questions/51245/what-kind-of-things-are-easy-in-haskell-and-hard-in-scala-and-vice-versa ]
[DELETED]
</div>
<div id="adsense">
<script type="text/javascript"><!--
google_ad_client = "pub-3296756901484166";
/* 728x90, created 9/8/11 */
google_ad_slot = "7129208720";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</div>
<div id="question">
<p>There has been some intermingling of Scala and Haskell communities, and I have noticed now and then people commenting on stuff that's supposed to be easy in Haskell and hard and Scala. Less often (maybe because I read Scala questions, not Haskell ones), I see someone mentioning that something in Scala is easier than in Haskell.</p>
<p>So. I'd like to know from people who are knowledgeable in both what kind of things are easy in Haskell and hard in Scala, and, conversely, what kind of things are easy in Scala and hard in Haskell.</p>
<div id="question-links">
</div>
</div>
<div class="question-comments">
<div class="comment">
(5)
Functional programming is easier in Haskell. Object oriented programming is easier with Scala... Just kidding! I don&#39;t know much about Haskell. - <b> huynhjl</b>
</div>
<div class="comment">
(1)
8 upvotes - no answers. Interesting :) - <b> Idsa</b>
</div>
</div>
<div class="answers">
<div class="answer-details">
[+86]
[2011-02-24 11:07:14]
Tony Morris
</div>
<div class="answer">
<p>Daniel,
As you know my day job is primarily writing Haskell and secondarily Scala. I have also used both languages for teaching, though not in universities (I use other languages there), but mostly for voluntary teaching that I still do today. Very rarely, I use Java or Javascript. I work for a product company. </p>
<p>I am pleased to see that my prediction is false -- your question has not provoked a slew of misinformation as I thought it would. As a result, I am compelled not to ignore it :) So here goes.</p>
<p>At a somewhat superficial level, Haskell has significantly superior tool support over Scala and Java. For non-exhaustive example, Haskell has hoogle, djinn and pl; three tools that alone are extremely useful for which there is no equivalent for Scala. These tools exist and are as useful as they are, because of certain fundamental properties of Haskell itself. Here I mean, the hoogle function is only as useful as it is because Haskell tags IO effects in the type delineating values with types IO t and t, so hoogling for say, [a] -> Int eliminates a lot of candidate functions that would have this type in other environments. In Scala, without the delineation between an Int that has been computed with its arguments, and an Int that has been computed with the entire universe, a hoogle-equivalent would not be as useful -- nevertheless, it would be somewhat useful were it to exist.</p>
<p>Haskell's hlint is also superior to say, Java's CheckStyle. Included in GHC is a warning system, which when coupled with hlint is far more comprehensive. I've not seen anything like this for Scala.</p>
<p>Haskell has cleaner syntax and superior type inference. Very rarely is it the case that we must type-annotate our Haskell. This is not to say that we do not type-annotate our Haskell, just that we have the choice. As you know, this is not so with Scala. However, on an extremely superficial level, I prefer Scala's lambda syntax to Haskell's, which requires a pseudo-lambda symbol (\). In any case, I aim for point-free style where appropriate, making this already-weak point moot. I use Haskell's clean syntax to appeal to children in the challenges of teaching. Children take very easily to Haskell's syntax, since there is far less redundant, "off to the side", "let's take a little excursion to nowhere", ceremony (so to speak). As you might guess, children are easily distracted -- Haskell helps me as a teacher to keep this in check.</p>
<p>On to the fundamentals. As you know, Haskell is call-by-need by default, where Scala is the other way around. This is, of course, a very contentious issue. Nevertheless, I admit to falling very strongly to one side: call-by-need by default is the most practical and Scala's evaluation model is a very far-away second place. I have never seen a legitimate argument that comes close to swaying my position on this, though I do invite it (not here please). To summarise, I think Haskell has a superior evaluation model. There are also nuances in Scala's laziness. For example, while Scala unifies lazy values, it does not do so for those in contravariant position. i.e. a (Int => Int) is not a ((=> Int) => Int).</p>
<p>This contentious issue aside, Haskell's effect-tracking (by the way, which is a consequence of its evaluation model), is overwhelmingly practical to every-day software tasks. The absence of same or similar is quite devastating as many users of Scala have become aware (by wishing for a solution). I cannot emphasise how important this form of static type-check is to typical business programming in terse form, so I won't try here.</p>
<p>Haskell has far superior library support than Scala and Java. You and I have discussed this before. Scala lacks some of the most fundamental functions in its standard libraries and the higher-level ones are even more scarce. For example, there are fundamental properties of Scala making good library support more difficult (strict evaluation, Java interop), however, neither of these incur such a penalty as to produce what can only be described as an unfortunate catastrophe as the Scala standard libraries. That is to say, the Scala standard libraries could easily be miles ahead of where they are today, but they are not and you (I) are left with ponderances as to why -- something about third lumbar vertebrae and expert levels or something I suppose.</p>
<p>To help emphasise this point, there are times in my day job when I come off a project from using Haskell to Scala. This comes with some consequences that I feel immediately with a very sharp contrast; I then use intellij idea which is slow, cumbersome and full of bugs, the Scala type inferencer is less robust and difficult to prototype with (I may make a type-error and it all just carries on as if nothing happened), but there is nothing more disappointing than having to spend (waste) a few hours implementing a library that really should already be there -- what a waste of my time and probably the next guy who has to implement such fundamental library abilities. Talk about shaving yaks. In my opinion, this is the most disappointing part of Scala, especially since there is nothing stopping it from having a useful library besides skill and absence of ability to recognise what a useful library even is. This happens for Haskell too, but to a far lesser extent. I digress in frustration.</p>
<p>The GHC REPL (GHCi) has better support for every-day programming. More useful tab-completion, :type, :info and :browse commands are heavily missed when in Scala. It's also much faster, but Scala can be forgiven given the JVM.</p>
<p>Why use Scala? I can call the Java APIs, even the most ridiculous, yet popular, APIs ever written. I can call WebSphere methods and I can write servlets. I can write a Wicket application, or use the Play framework or I can do something outragoeus with a database and hibernate. I can do all those things that our industry seems to think are useful, though I secretly contend are pathetic, and I hope our children do too. I can completely avoid the arguments and discussions associated with the merits of these issues, and get on with the job, while still getting the benefits of a language that is vastly superior to Java. This might seem like a cheap stab, though I am sincere when I say that is a true benefit that I value a lot.</p>
<p>Scala's module system is superior to Haskell's, almost. That is, it has some things that are very useful that Haskell does not, but also vice versa -- for example, Haskell allows a module to export other modules. Scala requires you to stick your finger in your left ear to do this; oh and intellij idea stops working -- I exaggerate, but you get the point. Scala has package objects and and first-class module niceties. Haskell lacks here.</p>
<p>Scala also has the ability to namespace a function by giving special status to one of its arguments (some people call this OO, then don't, in the very next breath -- I never get it). What I mean is, you may have two functions with the same name, which are disambiguated at the call site by the type of the argument to the left of the dot. I am deliberately not calling this by any special name, but rather focussing on its utility -- Haskell can do this with qualified imports -- not quite so nice. I am usually, though not always, particularly unimaginative when it comes to inventing function names -- allowing me to reuse one without a penalty is very handy indeed. Note here I do not mean overloading -- I think the Scala community has worked out that overloading is just not worth it -- do not do it, ever.</p>
<p>In my experiences, Scala appeals to existing programmers, who can usually get up and running quicker than with Haskell. In contrast, non-programmers get up and running with Haskell far quicker than with Scala. As a teacher, I used to think this was a great attribute of Scala, then I tried it, then I thought it was just good. Today, I think it is just not worth it -- I have seen too many catastrophes when programmers who are familiar with degenerate problem-solving techniques (ala Java) are handed such things as Scala. Call me pessimistic or some-such, but I wish to remind you that a few years ago, I was handed an already-failed project written in Scala by the Java guys, which I was supposed to "save" because I was the "Scala expert." I'm sure you can guess how that turned out. I have many (many) anecdotes like this, though most of those are confirmed each time I try to use Scala for teaching existing programmers, rather than in industry (perhaps this is my selection bias, given my extreme apprehension). Nevertheless, my experiences aside, you may call this a benefit over Haskell -- there is no doubting that existing programmers get up and running much quicker with Scala.</p>
<p>I can think of a few other tid-bits, but hopefully this satisfies your curiosity. I don't know how many people are in my position of using both languages extensively in a commercial environment, but I'd truly love to hear from someone who does -- especially if they take strong objection to my opinions. That is to say, I invite (and truly yearn for) well-informed peer review of these opinions.</p>
<p>Hope this helps.</p>
<br/>
</div>
<div class="answer-comments">
<div class="comment">
(8)
&quot;I am deliberately not calling this by any special name, but rather focussing on its utility&quot; -- How about &quot;<i>dynamic single-dispatch ad-hoc subtype polymorphism</i>&quot;? That should clear it right up :-) - <b> Jörg W Mittag</b>
</div>
<div class="comment">
(4)
Wow... just WOW. - <b> soc</b>
</div>
<div class="comment">
@Tony Looks like your registered account is separate from the unregistered account that you originally wrote this answer from. Would you like the two to be merged? - <b> Anna Lear</b>
</div>
<div class="comment">
Yes, thanks Anna. - <b> Tony Morris</b>
</div>
<div class="comment">
hi, can you provide some references/explanations to claims that you do? I&#39;m interested in the topic. Particularly, what is catastrophic about Scala Std API? And what does the term <code>effect tracking</code> mean? Googling it only yields your posts :-). - <b> coubeatczech</b>
</div>
<div class="comment">
Hi coubeatczech, Doing a complete critique of disasters in the Scala library would be quite an essay on its own and not one that is particularly appealing to me, sorry. I&#39;d prefer to just move on. - <b> Tony Morris</b>
</div>
<div class="comment">
Effect tracking is where you use types to statically-enforce properties about functions that perform such things as IO effects. Haskell uses a type constructor called IO (often confused with its monad implementation) and Clean uses uniqueness typing. These are two examples of effect tracking. Scala, like many languages, does not allow the programmer to delineate here, making it very restrictive. - <b> Tony Morris</b>
</div>
<div class="comment">
&quot;...I can do something outragoeus with a database and hibernate. I can do all those things that our industry seems to think are useful, though I secretly contend are pathetic...&quot;: Do you mean the possibility of using Hibernate is not useful? - <b> Giorgio</b>
</div>
<div class="comment">
More to the point, not using hibernate is useful -- an enormous improvement by its absence alone. Not to pick on hibernate -- I can say that about a lot of Java garbage. - <b> Tony Morris</b>
</div>
</div>
<div class="answer-pagenumber">1</div>
<div class="answer-details">
[+21]
[2011-02-25 14:26:12]
oxbow_lakes
</div>
<div class="answer">
<p>Surely the obvious (pro-Scala) answer is also the most one which you were <em>not really looking for</em>. Consider <strong>X</strong>, who works for a company who have 5 years' accumulated effort of developing Java libraries. Each of the 20 developers has an average of 8 years' Java experience.</p>
<ul>
<li>No one has ever used Haskell</li>
<li>No knows anyone who has ever used Haskell</li>
<li>No one has ever heard of any company/team developing any commercial Haskell product in their "business" space</li>
<li>No one has any experience of the Haskell community, libraries, how to even begin to discover things in Haskell </li>
<li>No one knows anything about Haskell executables, IDEs</li>
<li>No one want to throw away 160 man-years worth of accumulated Java effort</li>
</ul>
<p>X and his colleagues are getting a bit sick of Java and want to code in a better language without it being too much of a strain on the company. Scala does <em>this</em> better.</p>
<br/>
</div>
<div class="answer-comments">
<div class="comment">
(2)
I can even say &quot;No one has ever heard of Haskell&quot;... When a co-worker used loccount on our project, everybody (beside me...) wondered what was this Haskell language that was reported (it was actually .hs files for the JavaDoc sub-project...). - <b> PhiLho</b>
</div>
</div>
<div class="answer-pagenumber">2</div>
<div class="answer-details">
[+14]
[2011-02-27 12:33:42]
Martin Ring
</div>
<div class="answer">
<p>Haskell is a pure functional programming language whereas Scala is a pure object oriented one which also supports the functional paradigm on top of that. </p>
<p>For pure functional programming Haskell defenetely has less overhead and is much more compact. Scala doesn't support pointfree notation very well, and has a kind of bulky syntax for partially applied functions for example in Haskell you can write:</p>
<pre>
plus5 = 5+
</pre>
<p>and now <code>plus5</code> is a function which takes a number as parameter and returns a number. No need for types or anything, because everything is inferred. If you want to achieve something like that in scala you run in all sorts of problems... lets see:</p>
<pre>
def plus5 = 5 + _
error: missing parameter type for expanded function ((x$1) => 5.+(x$1))
def plus5 = 5 + _
</pre>
<p>ok so we have to include a type for the parameter because it cannot be inferred... </p>
<pre>def plus5 = (i: Int) => 5+i</pre>
<p>this function compiles ok but it only takes parameters of type <code>Int</code> so what type should we include? <code>+</code> is defined on all sorts of types both in Haskell and Scala. The above Haskell function works for all these types. If we want to achieve that in Scala we need to use a very special feature, namely the implicit <code>Numeric</code>.</p>
<pre>def plus5[T](i: T)(implicit numeric: Numeric[T]) = numeric.plus(numeric.fromInt(5), i)</pre>
<p>You will agree, that the above code is totally unreadable for beginnners. We also have to take the parameter to the left side because otherwise the implicit parameter would be the first and you couldnt call the function without supplying a Numeric object. I actually believe that is the "simplest" way of writing an equivalent to the Haskell function in Scala. Also this only works for the special case of numerics where a special Trait has been added.</p>
<p>Another Advantage in Haskell is lazy evaluation. Consider this function which returns an infinite list of all fibbonacci numbers:</p>
<pre>fibs = 0 : 1 : zipWith (+) fibs (tail fibs)</pre>
<p>Some explanation: The <code>:</code> is the List constructor it takes an element on the left and a list or Nil on the right. <code>zipWith</code> is a function that takes two lists and joins them by applying a function to every both elements of each list (ie the fist of first list and fist of second list ...). in this case we apply <code>+</code> to the fibonacci numbers and the tail (the list starting from the second element) of the fibonacci numbers. Think about it for a second... The maths behind it is quite easy once you understood the double recursion. But nothing proves it better then trying:</p>
<pre>>take 15 fibs
result: [0,1,1,2,3,5,8,13,21,43,55,89,144,233,377]</pre>
<p>Well now I leave it up to you to implement that in Scala. Yes I know there are Streams in scala which can be infinite. <s>But you will run into a lot of other problems.</s></p>
<p><em>Edit: I have to take that one back. Thanks to Daniel for providing the Scala equivalent:</em></p>
<p><code>def fibs: Stream[Int] = 0 #:: 1 #:: (fibs zip fibs.tail).map(Function.tupled(_+_))</code></p>
<p><em>Well that proves that implementing that in Scala is also easy, but there still is a big problem: In Scala the above code runs in polynomial time, because fibs and fibs.tail is computed everytime from the start in every step of the recursion which also means it takes a vast amount of heap space. In Haskell the equivalent function runs in linear time, beacause every computation that has allready been made is cached. (My Core i7 + 8GB crashes when trying to call <code>fibs(50)</code> in Scala while it returns a 2090 digit Integer within a second when calling <code>fibs !! 10000</code> in GHCi). That is only possible because in Haskell there are no mutables and side effects, so the compiler knows that a function allways returns the same when its called with identical parameters.</em></p>
<p>But there are downsides to everything, so I have to admit, that lazy evaluation gets in your way as soon as you do real world stuff and not only computations. For example I have spent quite a while on finding a bug once when I wrote some Haskell code where I opened a file handle, read the contents, computed all sorts of stuff, then closed the handle and printed the results. Well the problem is, that due to lazy evaluation all computation and file reading wouldnt take place until I acutally called the result for the first time in the print function, so I got an error because I tried to read on a file for which i had no handle.</p>
<p>I love Haskell and have been doing lots of work with it. Lately I have used Scala a lot and actually love the way it immitates dynamic typing with structural types and implicits but sometimes i miss the clear and strong type system of Haskell. In the moment I use allmost only Scala, because it gets work done. I think Haskell is a beatiful language wheras Scala is a compromise between everything, which is not necessarily negative. It supports creativity. But unfortunately leads to "incompatible" programming styles and makes documentation very hard. (Where should you document which package to include, to have an implicit function in scope which is needed for many other things in other packages...? think about is ;))</p>
<br/>
</div>
<div class="answer-comments">
<div class="comment">
(1)
+1, clear examples and clear writing, thank you. - <b> limist</b>
</div>
<div class="comment">
(2)
<code>def fibs: Stream&#91;Int&#93; = 0 #:: 1 #:: (fibs zip fibs.tail).map(Function.tupled(_+_))</code>. Please, no &quot;run into a lot of problems&quot;. You gave an example which is easily reproduced in Scala. Either give an example of something which is actually hard to do in Scala, or edit that argument out. - <b> Daniel C. Sobral</b>
</div>
<div class="comment">
(4)
Your laziness problem with the file handle is due to lazy I/O, not due to lazy evaluation. There appears to be a growing consensus that lazy I/O is a harmful, bad idea. Iteratees are a much safer way to perform streaming I/O properly. See the enumerators package. - <b> Peaker</b>
</div>
<div class="comment">
(1)
Argh. I should have made <code>val fibs</code> instead of <code>def fibs</code>. Silly mistake. Of course, it only matters <i>because</i> Scala is strict by default. - <b> Daniel C. Sobral</b>
</div>
<div class="comment">
This comes a year later, but (based on Daniel&#39;s code) <code>val bigFibs: Stream&#91;BigInt&#93; = BigInt(0) #:: BigInt(1) #:: (bigFibs zip bigFibs.tail).map(Function.tupled(_+_))</code> behaves as expected and within a second too. This might still be an argument against Scala, btw :P - <b> kaoD</b>
</div>
</div>
<div class="answer-pagenumber">3</div>
<div class="answer-details">
[+13]
[2011-02-24 07:48:26]
vegai
</div>
<div class="answer">
<p>ghc compiles Haskell programs into binaries which are launched without the burden of a heavy VM. Also, it carries extensive POSIX and Unix libraries. Therefore, making well-behaving system scripts (or in general, short-living programs) is easier in Haskell.</p>
<p>I find Haskell to be much more clear semantically. Perhaps this is due to my much longer experience with Haskell, but it also might be because Haskell is not trying to be everything at once: it's quite clearly defined whereas Scala includes several different paradigms in one package.</p>
<p>Scala seems like it's easier to sell because it looks familiar, and also because people tend to trust the JVM. If you've put yourself in a box where you can only think in OO terms, you will of course feel more at home when designing Scala applications. </p>
<p>Haskell's type inference is more perfect than Scala's, i.e., it can infer more.</p>
<p>Scala is not by default lazy, and default laziness is a common source of space leaks in some class of Haskell programs. Without prior experience, their debugging is not easy, but the profilers help a lot.</p>
<p>Haskell imposes referential transparency and it has typed effects system. Therefore, writing buggy programs is more difficult in Haskell. </p>
<p>Scala's class variance system is complex.</p>
<br/>
</div>
<div class="answer-pagenumber">4</div>
<div class="answer-details">
[+12]
[2011-02-24 09:50:12]
Andrey
</div>
<div class="answer">
<p>It appears to be very difficult to start using Scala at my work.</p>
<p>It is completely impossible even to propose to use Haskell at my work.</p>
<br/>
</div>
<div class="answer-pagenumber">5</div>
<div class="answer-details">
[+4]
[2011-03-07 22:17:18]
Apocalisp
</div>
<div class="answer">
<p><strong>Rank-2 types</strong> make tracking resource deallocation in the type system easy in Haskell. The lack thereof makes this impossible in Scala.</p>
<p>For example, it is not possible to express this type in Scala:</p>
<pre><code>runST :: (forall s. ST s a) -&gt; a
</code></pre>
<p>Think of a value of type <code>ST s a</code> as a stateful computation in the context of some resource <code>s</code>. Because the type <code>s</code> is bound by the <code>forall</code> quantifier, it cannot escape. So letting the resource escape this context would be a <em>type error</em>.</p>
<p><strong>EDIT:</strong> It actually <em>is</em> possible, on closer investigation: <a href="http://apocalisp.wordpress.com/2011/03/20/towards-an-effect-system-in-scala-part-1/" rel="nofollow">http://apocalisp.wordpress.com/2011/03/20/towards-an-effect-system-in-scala-part-1/</a></p>
<p><strong>Type families</strong> are another feature of Haskell that I often find myself wanting in Scala. For example, they would obviate all the horrendous <code>CanBuildFrom</code> nonsense in the standard Scala library.</p>
<p>Type families let you do things like this:</p>
<pre><code>data family Elem c
data instance Elem String = Char
data instance Elem ByteString = Byte
data instance Elem [e] = e
</code></pre>
<p>It's like having type aliases where the expanded type depends on the type arguments.</p>
<br/>
</div>
<div class="answer-comments">
<div class="comment">
(1)
I have never heard of type families before. On the first look they look like fundeps on steroids, and it seems they could also replace some usages of abstract types in Scala. - <b> missingfaktor</b>
</div>
</div>
<div class="answer-pagenumber">6</div>
<div class="answer-details">
[+2]
[2011-10-03 20:01:47]
missingfaktor
</div>
<div class="answer">
<p>I am a Scala programmer working with the language since over a year. I have been learning myself some Haskell lately, and here are a few observations so far:</p>
<ol>
<li><p>Scala is strict by default, and does not have polymorphic first class values. This can sometimes lead to disasters such as <a href="http://apocalisp.wordpress.com/2010/04/21/a-proper-constant-function-in-scala/" rel="nofollow">
this
</a>
<sup style="font-size:9px">[1]</sup>. Compare the Scala code in that post with this Haskell: </p>
<pre><code>const :: a -&gt; b -&gt; a
const x _ = x
</code></pre></li>
<li><p>Being curried by default, and not having a function-method dichotomy makes Haskell more amenable to pure function composition.</p>
<p>A few examples: </p>
<pre><code>xsSorted = sortBy (compare `on` fst) xs -- observe the `on` combinator
(largest, smallest) = (maximum &amp;&amp;&amp; minimum) xs
allCombinations = sequence . (replicate =&lt;&lt; length)
</code></pre>
<p>And here is one I just posted at StackOverflow. Here is the Scala code:</p>
<pre><code>def range(xs: List[Int], ys: List[Int]): List[List[Int]] = {
(xs, ys).zipped.map((x, y) =&gt; List.range(x, y + 1)).sequence
}
</code></pre>
<p>Compare this with following Haskell:</p>
<pre><code>range :: [Int] -&gt; [Int] -&gt; [[Int]]
range = (sequence .) . zipWith enumFromTo
</code></pre>
<p>All of these are contrived examples, but I hope they help get the point across.</p></li>
<li><p>In Scala, ADTs are represented with classes and objects. This leads to problems such as <code>Some(3)</code>'s type is inferred as <code>Some[Int]</code>. So you end up adding extraneous type annotations such as <code>Some(3) : Option[Int]</code> or using some utility function such as <code>some(3)</code> (defined in Scalaz). In Haskell, <code>Just 3</code> has a type <code>Maybe Int</code>. (<code>Just</code> merely is a value constructor, not a type.)</p></li>
<li><p>The "problem" I discussed in above bullet point has a small advantage too. Consider the following Haskell ADT:</p>
<pre><code>data D = A { a :: Int, b :: Int }
| C { c :: Int }
aob = A 4 5
cob = C 9
</code></pre>
<p>And here is the corresponding Scala:</p>
<pre><code>sealed trait D
case class A(a: Int, b: Int) extends D
case class C(c: Int) extends D
val aob = A(4, 5)
val cob = C(9)
</code></pre>
<p>In Haskell version, <code>c aob</code> will compile but fail at runtime, as function <code>c</code> has type <code>D -&gt; Int</code>, and not <code>C -&gt; Int</code> (because <code>C</code> is not a type). On the contrary, an invocation such as <code>aob.c</code> in Scala will fail at compile time as type <code>A</code> does not have a field named <code>c</code>. So this provides an extra bit of typesafety.</p></li>
<li><p>In Haskell, <code>Either a b</code> has a kind <code>*</code>, <code>Either a</code> has kind <code>* -&gt; *</code>, <code>Either</code> has kind <code>* -&gt; * -&gt; *</code>. So in Haskell, type constructors are curried. That's not the case with Scala, and so we need to resort to notoriously ugly type lambda. For a one level partial application on <code>Either[A, B]</code> in Scala, you have to write <code>({type L[X] = Either[A, X]})#X</code>. This also has a small advantage that you can choose which type parameters you want to partially apply. For example, <code>(type L[X] = Either[X, A])#X</code>. They can be chosen arbitrarily, unlike in Haskell where type constructors being curried can be partially applied only in a sequential manner. For arbitrary partial type application in Haskell, you have to introduce a type synonym. </p></li>
<li><p>Similar to bullet number 5. Scala's partial application syntax for functions has a similar advantage over Haskell's curried by default scheme. No flips, instead just a few underscores sprinkled here and there.</p></li>
<li><p>Unlike in Haskell, typeclasses in Scala are types themselves, and the typeclass instances are first class values. This allows for some interesting things such as one described here. In Scala, you can make instances of one typeclass implement another typeclass. For example, Scalaz makes <code>Show</code>, <code>Equal</code>, <code>Resource</code> typeclasses implement typeclass <code>Contravariant</code>. This allows you do stuff like:</p>
<pre><code>implicit val s: Show[Dog] = implicitly[Show[Int]] contramap ((_: Dog).age)
</code></pre></li>
<li><p>Typeclasses in Scala are more powerful than those in Haskell in a few more respects. You can have multiple instances of one typeclass for the same type. Instances can be passed at call-site. You can precisely control the precedence level of typeclass instances by putting them in different traits and mixing them in appropriate order. </p></li>
</ol>
<p>A subjective closure: When you are programming in a pure functional style, it's bounds more easier to do so with Haskell. However when your problem is more amenable to OO (i.e. can be solved better with subtyping), and requires a fair bit of mutability, you are better off with Scala.</p>
[1] http://apocalisp.wordpress.com/2010/04/21/a-proper-constant-function-in-scala/<br/>
<br/>
</div>
<div class="answer-comments">
<div class="comment">
7) Now ghc has constraint kinds, so we can do that too now. - <b> Tyr</b>
</div>
<div class="comment">
@Tyr: Cool! Can you show a code example? - <b> missingfaktor</b>
</div>
<div class="comment">
Well, for example, Set should be a monad, like the list monad, but because of the Ord constraint on Set, it didn&#39;t work out. Now we can make a Monad with parametric constraints, so it all works out. It&#39;s rather new still, and I haven&#39;t used it myself, but you will begin to see it pop up in places soon - <b> Tyr</b>
</div>
<div class="comment">
@Tyr: That&#39;s a great feature! Thanks for the info. - <b> missingfaktor</b>
</div>
</div>
<div class="answer-pagenumber">7</div>
</div>
</div>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-4276204-5");
pageTracker._trackPageview();
} catch(err) {}
</script>
<script src="http://static.getclicky.com/js" type="text/javascript"></script>
<script type="text/javascript">clicky.init(250663);</script>
<noscript><p><img alt="Clicky" width="1" height="1" src="http://in.getclicky.com/250663ns.gif" /></p></noscript>
</body>
</html>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment