
Hello Haskell, Goodbye Scala - nullobject
http://joshbassett.info/2013/hello-haskell-goodbye-scala/
======
amm
For personal projects or for learning the principles of FP, there is nothing
wrong with using Haskell.

From personal experience however, I will not be using Haskell again for a
larger professional project, because our team ran into too many time consuming
issues and problems that have been solved successfully in other
languages/environments (especially the JVM) like dependency management or
reasoning over runtime characteristics before deploying the application on
production systems. Especially memory consumption is very hard to predict.

Of course, the language also has its benefits and even after some years it
tickles your brain just the right way.

I like programming in Haskell very much, but in real world projects (you know
- when you work in a team not only consisting of PhDs) I prefer Scala or Java,
because getting a war file deployed or profiling an application is just so
much easier.

YMMV, of course.

~~~
lumberjack
Interestingly, despite their respective reputations Haskell is by far more
popular than Scala:

<http://www.langpop.com/>

~~~
gtani
There's lots of measures: Indeed job listings, google searches, mailing list
volume; tiobe tries to incorporate a few.

<http://www.drewconway.com/zia/?p=2892>

[http://www.wired.com/wiredenterprise/2012/06/berkeley-
progra...](http://www.wired.com/wiredenterprise/2012/06/berkeley-programming-
languages/)

------
werpon
I've invested a lot of time in trying to learn Haskell properly.

On one hand, it's incredibly rewarding when a completely new and strange
concept finally 'clicks', then you write a few lines to test your
understanding and it just works.

On the other hand, it's frustrating to realize that there are still a lot of
concepts you don't fully grasp, several libs that are still out of your reach,
yet another completely new way of structuring your code that you are yet to
unravel. Essentially, that you are (I am) still a newbie.

All in all, I find Scala better suited to learning FP and applying your newly-
acquired knowledge to develop mildly useful apps, as quick results usually
lead to more motivation. Just IMHO.

(Not to mention there are many libs that aren't yet up to par with their JVM
counterparts, but that's another can of worms.)

~~~
gosub
One of the things I like about Haskell is that there's never scarcity of new
concepts to learn: Functors, Applicatives, Monoids, Monads, Monad
transformers, Comonads, Arrows, Lenses, Foldables, Iteratees... And every one
of these has a world in itself!

~~~
codewright
On the other hand, that one time you just need a simple library for something,
you get to use some guy's pet experiment for learning one of these concepts
(Monoids, Monads, Monad transformers, Comonads, Arrows, Lenses, Foldables,
Iteratees, Functional-Reactive Programming) you haven't learned yet just to
parse some XML.

Yeah, a real productivity booster. It's like batteries included but with C4
attached to every battery.

Sometimes, people have work to do.

~~~
papsosouid
Yeah, those tricky monoids. So hard to learn, and even harder to use a library
based on them. You have a whole whopping one function to learn, that does some
incredibly convoluted and arcane nonsense called "appending"? What a horrible
language. You should definitely devote more time to complaining about
ridiculous strawmen like this, it seems like a very good use of time.

~~~
bjourne
Here is some of my code to parse html:

    
    
        tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
        (path, score) <- css "td[class~=score-time] a" >>>
            (this ! "href") &&& (getAllText >>> arr parseScore) -< el
    

So yes, you do have to learn about arrow syntax in order to use HXT
efficiently. For most newbies it is not an easy concept to grasp, not helped
by the fact that HXT isn't a very well documented library.

~~~
gosub

        tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
    

This, on the other hand, is one of the thing I don't like about Haskell: there
are 4 operators on this line, and no easy way to see, at a glance, their
precedence. Also, some operators are "mentally interpreted" as flowing data
left to right or right to left; changing the direction mid-statement, I find
confusing. I have the same problem when unix shell commands are expressed like
this:

    
    
        program < input > output

------
cduser
I learned F# as this guy learned Scala. I too dived into Haskell after a while
and learnt a lot of new things.

Having learned some great functional tips, I came back to my regular C#/Ruby
and applying LINQ and Ruby's blocks seemed more natural to me. However,
monads, monoids, functors still don't matter when you switch over.

I've used Yesod to write a small app. A typical form in Yesod (for model
binding) has this signature:

newPostForm :: Html -> MForm Blog Blog (FormResult (Text,Text,Text), Widget)

Even after learning Yesod for a while, I wasn't able to completely reason with
that signature. Why bother with all the name of the application, sub site,
formresult, widget when all you want is just three simple form fields? Rails
gives it to you in params[:form]. It's just too easy in Rails with a lot of
gems lying around for every task you decide to do. And when you're stuck,
you're just a google away from getting your answer.

So my question is: after learning Haskell, do you intend to stick to it? Did I
make a wise decision in ditching Haskell?

~~~
Peaker
Why not define a type alias?

    
    
      type AppForm a = Html -> MForm Blog Blog (FormResult a, Widget)
    

And then you get:

    
    
      newPostForm :: AppForm (Text, Text, Text)

~~~
svachalek
The real fun with type aliases is that GHC rarely uses them in error messages.
So you get about 20 lines of type vomit whenever something refuses to compile
and then you get to try to piece it back together into a level of abstraction
that humans can handle.

~~~
Peaker
Well, it isn't the case here, is it?

------
dkhenry
I can respect and applaud the man for wanting to learn, When I picked up scala
I had the same experience he did. When I went to solve a problem I immediately
fell back to the imperative style of programming since that's how my brain has
worked for a decade. It has taken real time and effort to _try_ and solve
problems in a functional manner. Turns out that's a really good and elegant
solution for some problems and a skill that's worth developing. If another
language makes that training easier then by all means use it. One of the real
benefits of scala is you can be useful in it ( just solving the problem )
while you have all the tooling necessary to make those elegant solutions when
you have the requisite skill set to implement them. It would be handy if
scalac has a setting like -Werror in C land where non-functional constructs
would be flagged in the codebase.

------
rauljara
If anyone wants an introduction to functional programming using Scala, I
really recommend Martin Odersky's coursera course
(<https://class.coursera.org/progfun-2012-001/class>). He restricts you to
functional Scala; there isn't a mutated variable in the whole course. It isn't
officially a course right now. You won't get a certificate for taking it, and
I don't think the grader is turned on, but the other materials are still
there.

In my mind, the really mind altering thing was seeing not just that Object
Oriented and Functional programming styles could be compatible, but that they
were in many ways complementary. Good OO design, particularly the idea of
small single responsibility classes, is kind of enforced by functional style.
If you need to pass around fifty variables just to increment a counter, you'd
go crazy. So writing functionally forces you to figure out ways to split
things up. Similarly, its easy to convert well small, single responsibility OO
objects into functional ones, and just a nightmare otherwise.

I was just blown away at how much a course on functional programming helped me
to understand OO design.

~~~
metaguri
Does the course cover Functors, Applicatives, Monoids, and Monads? What about
other higher-level functional constructs (Arrows, Zippers...)?

From what I've seen, I think Scala is a nice language. One thing I don't like
is particularly that it's a bit kitchen-sink-ish: there's a whole lot of
syntax and semantics to learn, seemingly due to the OO side of the language.
By comparison Haskell is quite simple. All the higher-level constructs are
implemented in plain Haskell, so you can easily understand them but thanks to
a flexible, uniform syntax, using them doesn't feel clunky.

To me the main reason for not learning FP through Scala, however, is that the
community isn't organized around teaching FP in the same way that Haskell is.
It sounds like this course is an exception. But otherwise, I found that trying
to learn about Monads from the scalaz documentation was not satisfying, and we
all know that "A Monad is a Sheep with Curly Hair" blog posts are a dime a
dozen (in Haskell and Scala). Learn You a Haskell made the concepts, and also
their benefits, clear to me for the first time. Now I'm working through Real
World Haskell to build my chops and reinforce my understanding.

While trying out both languages and picking which one to learn, I came across
an interesting post on Gilad Bracha's blog which had a lively discussion
including a comment by the [claimed] original author of Scalaz [1], which made
it clear to me that it would be easier to start in Haskell and move to Scala
than vice versa. I think I (and the OP) are both seeking to gain a strong
foundation in FP concepts. To summarize, in my experience most Scala resources
on the internet (blog posts that come up, etc.) aren't quite as good in this
regard; at this point a lot of the Scala programmers using these techniques
are probably Haskell programmers anyway.

That being said, the internet is a huge place. If there's a Scala equivalent
of this post [2] please do share it! I agree with other posters here that
Scala has quickly gained a significant amount of industrial acceptance. I'd
imagine that I'm more likely to write Scala professionally in my lifetime than
Haskell. But I also believe I'll be better off approaching it having learned
the FP concepts in Haskell first.

[1] [http://gbracha.blogspot.com/2011/01/maybe-monads-might-
not-m...](http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-
matter.html?showComment=1295940865245#c7260381172547454562)

[2] [http://stackoverflow.com/questions/1012573/getting-
started-w...](http://stackoverflow.com/questions/1012573/getting-started-with-
haskell)

~~~
rauljara
>Does the course cover Functors, Applicatives, Monoids, and Monads? What about
other higher-level functional constructs (Arrows, Zippers...)?

Nope. It's very intro level, though the students basically begged Odersky for
a part II, and he seemed very open to it.

And I totally didn't mean to imply that I thought people should learn Scala
instead of Haskell. I was just sharing a FP resource I found helpful.

Not actually having mastered the higher level functional constructs yet
myself, I really don't have a firm opinion about which is the "better"
approach. Personally, I've looked at both languages and I know that each
helped me understand the other. So if I have any opinion, it's that if you get
stuck, it's probably a good idea to approach it from another angle, like the
author is doing.

------
pohl
My own approach to learning FP has been "Hello Haskell", "Hello Scala", "Hello
ML", "Hello Clojure", "Hello Rust",...

I don't know why you say goodbye, I say hello.

~~~
DannoHung
Maybe you should actually learn something about FP rather than trying to learn
a bunch of languages?

~~~
pohl
I think you'll discover that languages are actually much smaller than they
appear in your mirror.

~~~
DannoHung
That's my point. You're talking about jumping around from language to
language, but Functional Programming techniques tend to be applicable across
all of them. My personal angle is that Haskell puts up less bullshit in your
path while you're learning stuff about type based reasoning at the cost of
being much less like things you may have seen before.

Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum
isn't going to get you any deeper understanding of techniques. At most you'll
understand how some very basic concepts work in different languages.

~~~
pohl
I wouldn't call opening myself to multiple languages "jumping", and it seems a
bit of a leap that you assume so. (Note that I said nothing of the proportions
invested in each.) The only point of my post was that one does not need to
wall oneself off from one language in order to open oneself to another.

 _Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum
isn't going to get you any deeper understanding of techniques._

I suppose that's a fair view if one starts from the assumption that techniques
are all that is worthy of pursuit.

But there is also comparison of priorities implicit in different design
choices. There is also an appreciation of history (ML is a good example of
that) and an appreciation for industrial frontiers (Rust is a great example
there: if you're not following Graydon Hoare you're missing out). Each
language also has its own unique traits that don't readily map to others.
Haskell's lazy evaluation and monadic IO are a great example there. Want to
wield the sword of homoiconicity? Better learn a LISP.

Moreover, learning Haskell prepares you to read a lot of literature. ML
prepares one to read Chris Okasaki's book on purely functional data
structures. (Yes, there is a Haskell appendix in the back of the book, but
knowing both means you can compare them!). Scala is worth study as a case
study in the tradeoffs of making on object/functional hybrid.

The human brain is an associative machine, you know. Sometimes the act of
broadening has the consequence of strengthening (or even deepening), because
you're giving your melon more things to interrelate.

~~~
DannoHung
Learning any one of these, if they have a strong type system and an emphasis
on immutable data are going to prepare you for the literature.

Comparative language evaluations are fine, but don't tell me that you made
that clear that that was what you were after in your original comment.

~~~
pohl
You're a strange chap. If you agree that languages are small – so much that
you insist it was your point when, in fact, it was mine – then why do you
think there's such a large cost to picking up another one?

I also don't understand why I needed to make it clear that language
comparisons are beneficial. Was someone trying to assert that they're not?

~~~
DannoHung
You said, 'My own approach to learning FP has been "Hello Haskell", "Hello
Scala", "Hello ML", "Hello Clojure", "Hello Rust",...' and I thought to
myself, "Well, that's not going to really help you learn Functional
Programming techniques and design strategies". You really have to use a
language for a while to understand how to make a good software design inside
of it. It's not the cost of learning the language, it's the cost of not
spending enough time working with the language.

Now on the other hand, if you just like looking at a lot of languages and
seeing the design tradeoffs, you can spend a lot less time using each one to
get that perception.

But you _only_ mentioned learning FP in the first place. I didn't divine that
comparing the language design was your reason for not picking one and sticking
with it.

~~~
pohl
_...and I thought to myself, "Well, that's not going to really help you learn
Functional Programming techniques and design strategies"_

That's where you went wrong, then, because it doesn't in any way rule out the
possibility of learning it either.

In your initial response, you said " _Maybe you should actually learn
something about FP..._ ". Let's make this clear: you don't know me.

Pro tip: if you have to make assumptions about other people, then it's
possible to make a wrong assumption. In these cases, it's often better to ask
a question than to launch into criticism based on assumptions.

~~~
DannoHung
Pro tip: Don't make glib comments and be surprised when people respond
brusquely.

Also, Pro Tip: Assumptions are necessary in order to have reasonable
conversations. People aren't inference engines.

~~~
pohl
That word doesn't mean what you think it means. My initial post is sincere
wisdom.

And your initial brusqueness didn't bother me, FWIW. The determined obstinance
does a bit, but no worries.

~~~
DannoHung
<http://www.merriam-webster.com/dictionary/glib>

Nah, fits what I meant.

~~~
pohl
That which does not conform to your world view must be disparaged, because
you'd feel embarrassed to be caught red handed in the process of learning. I
get it.

~~~
DannoHung
Yeah, well, y'know... that's just, like uhh... your opinion man.

------
richo
I enjoyed the read, but I borked at your suggestion that not being purely
functional, and the language barking at you if you break that convention stops
you learning functional programming.

Take most Lisps (I'll assume scheme, because it's what I'm most familiar
with), which give you more than enough side-effecty rope to hang yourself with
should you so desire- but you won't get far unless you're coding functionally.

~~~
agentultra
Sometimes you need side-effects. The world is far from pure. I think Common
Lisp gives you exactly the tools you need and gets out of your way. Dynamic
variables (a very specific term in CL) are simply _awesome_. You need side-
effects when you're dealing with I/O -- sockets, files, shells, etc. I prefer
languages that make it as painless as possible when I need it.

Purity, IMO, is over-rated. You can write pure FP code in C++, Java, or CL if
you wanted to. It doesn't matter whether you _can_ write imperative code with
side-effects and doesn't make those languages any less useful. This _purity_
thing that the Haskell-zealots are on about just stinks of bullish*t and it's
not good for you.

That being said, Haskell does do some neat things and there is a lot to learn
from it. It's type-inference lets it do some neat things like parallel maps
and so forth. It also shows us that laziness is not always a good default. I'm
not hating on Haskell but anyone who drools over its, "purity," is not saying
much at all. Purity is not an attribute that wins you any battles.

~~~
riffraff
> Dynamic variables (a very specific term in CL) are simply awesome.

I may be wrong but I think the name is rather common outside CL too (assuming
you refer to "variables with dynamic scope rather than lexical"). E.g. as we
are talking of scala

[http://www.scala-
lang.org/api/current/scala/util/DynamicVari...](http://www.scala-
lang.org/api/current/scala/util/DynamicVariable.html)

~~~
agentultra
Sorry, didn't mean to imply it was a feature unique to CL.

------
happywolf
Anybody here has developed and deployed a Scala-based or/and Haskell-based
project for production? I mean systems for business purpose where rubber meets
the road with timeline to hit and budget to meet. Far too often the stories
are shared by people who learned a new language for 3 months and implemented a
pet system where only a few real users. Definitely I respect their zeal and
curiosity, but I am more interested to know what the veterans are thinking

~~~
carterschonwald
I know of a few strong mostly Haskell places in NYC alone. Likewise I'm
actually bootstrapping a biz where I've spent most of the past year building
the tech where some of the things I'm doing are only tractable to build _by_
using Haskell.

~~~
slurry
> I know of a few strong mostly Haskell places in NYC alone.

Hedge funds? Or something else?

~~~
carterschonwald
Both! more precisely, at least one large quant shop, at least one normal hedge
fund (apparently theres a difference!). Probably others in the finance space.

Theres at least 2 not finance enterprise focused haskell shops in NYC that are
currently profitable and growing, theres at least 1-2 other places that have a
smidge of haskell here and there.

Oh, and theres my place, Wellposed, which is pre launch but for the first
product, only Haskell is used, and if it works out, the # of (partially)
haskell shops will increase quite nicely :)

------
digitalzombie
Yeah I've tried learning Scala for a year.

It was painful, real painful and I felt like I didn't learn much from it.

Now I'm learning Erlang and I'm applying what I've learned from Scala to
Erlang and wow. I'm glad I took at stab at Scala. Erlang is wonderful btw,
it's so simple there are some minor drawback like no string primitive... I
also love the fact that there is no loop, it forces me to think recursively. I
guess because it's so simple I can just focus on learning the functional part
instead of other stuff such as new objects paradigm (traits, etc..), design
pattern ("pimp my whatever"), and type. I'm guess once I'm done with this I'll
focus on type, thinking Haskell...

------
aangjie
While i liked his gumption, I personally thought god i don't want to do that..
I have been playing around haskell on and off, in my free time, and have come
to a conclusion that while it's a fun and cool language to play around, it may
not be useful(as in career) hobby. It might be categorized as pure fun
language learning.

------
owenjones
Haskel/Scala has Learn You a Haskell/Scala for Great Good! and Lisp has The
Land of Lisp.

Are there any _why-esque guides to Clojure and FP in general like these other
languages have? I'm unaware of any and consider it surprising given the
Clojure communities passion.

------
willvarfar
I find it unconvincing. That Haskell deemed is better for learning functional
programming for the sake of learning functional programming does not really
say much about general usefulness.

~~~
koide
And the OP is talking only about learning FP, not about general usefulness.

Not sure what you are unconvinced about.

~~~
willvarfar
The title and the first few paragraphs gave the impression that this was an
article about the general utility of the two languages. Only half-way down did
the truth out.

~~~
koide
Maybe one shouldn't make general comments about a piece one hasn't read in its
entirety.

Especially for an 11 small paragraphs piece.

~~~
willvarfar
I did read it fully. Then I commented that I found it unconvincing, which in
my book is one step below misleading.

~~~
koide
I then find unconvincing your usage of the word unconvincing.

------
deltasquared
Nice choice! Learn You a Haskell for great good is an excellent book, I
learned a lot reading it.

------
SkyMarshal
_> For christmas I bought myself a copy of Learn You A Haskell For Great Good
by Miran Lipovača. Apart from being a great Haskell learning resource, it’s
one of the best programming books I have ever read._

I second that. Miran is a superb technical writer. He also annotates the book
with little excerpts from all my favorite movies.

------
vorg
Perhaps Scala was built for introducing functional programming gently to Java
programmers, with the intention to make them switch to Haskell.

------
gesman
Obsessive, compulsive, pure functional disorder. Now drop it all and go and
build something.

