
Becoming Productive in Haskell - pieceofpeace
http://mechanical-elephant.com/thoughts/2015-04-20-becoming-productive-in-haskell/index.html
======
QuantumRoar
Scripting languages try to seduce you to just fiddle around until the output
looks like something you want. While that quickly gives you some results, I
think it's a huge roadblock in the mid- to longterm. Especially when
programmers are only familiar with "easy" scripting languages, there are
rarely insights about the general approach to the problem until the project
already grew to become an abomination.

While fiddling around is still somewhat possible in Haskell, the language
itself makes it quite difficult. Haskell kind of forces you right at the
beginning to pause and think "Well, what is it that I'm actually trying to do
here?" It let's you recognize and apply common patterns and implement them in
abstract ways without having to think about what kind of values you actually
have at runtime. In that way Haskell is the most powerful language I know.

Have a tree/list/whatever? Need to apply a function to each of the elements?
Make your tree/list/whatever an instance of the Functor type class and you're
done. Need to accumulate a result from all the elements? Make it foldable.

Something depends on some state? Make it a Monad.

You either get a result or you don't (in which case any further computations
shouldn't apply)? Use the Maybe Monad.

You need to compute different possible results? Use the List Monad.

Need to distinguish three different possible values that are different
compositions of elementary types? Make yourself your own type and pattern
match the behavior of applying functions.

Need to output in a certain way? Make it an instance of the Show class.

Most concepts that are used every day have some kind of idea behind them that
is abstract and implementation independent. Haskell kind of forces you to
reference those ideas directly. The downside is that you actually have to know
about those concepts. However, knowing about the such concepts makes you also
a better programmer in other languages, so it's not like it's a bad thing.

~~~
1971genocide
And what makes the model of haskell any more superior to models developed in
any other field like accounting, physics or chemistry ?

I am sorry, haskell is just a huge roadblock to get things done in the real
world.

In the real world proffesional need to juggle all sorts of models. Haskell
just says "Fcuk you ! its my way or the gonadway !".

I need to juggle between json, matrix, html, etc. Each of them have hundreds
of expections.

You can say my model is imperfect but guess what buddy, every model is. The
only models that will work for all cases is prolly einstein's equations but
even that has exceptions when dealing with blackholes !

I tried writing a music library in haskell and haskell makes it really hard to
create rules that are expections to the model. Apparently the models developed
by 1000s years of music theory is not good enough for haskell !

I cannot even image what it must to be code chemical rules using hakell that
have hundreds of expections, or biologial models ! Oh My !

I am sorry haskell just gets makes computation much more difficult. Apparently
mutation is a crime even though god himself thought it was okay as a rule for
everything in the universe.

my anecdotal experience.

((

btw i really like the concepts in haskell. I read two of its famous books -
LYAGH and RWH. And use all haskell concepts almost daily in production.
However the implementation of haskell is not really ready for production or
useful enough for the average developer. Its also not easy for the average
developer to put food on the table using haskell

))

~~~
QuantumRoar
I didn't try to say that Haskell is the best language for everything. I also
wouldn't want to do everything in Haskell. But as you are pointing out, you
learned a lot from Haskell and you are using its lessons in production.

The best a language can do is to fill a niche and to be very good at that
particular thing. You should always use the language that is most suited for
your problem, whatever that is. But there are many languages that let you get
away with being a terrible programmer. Haskell just isn't like that and I want
to point out that you can learn a great deal from being forced to think in
more abstract ways, just like you did.

In programming, we often encounter the temptation to just mutate everything
and to use side-effects since it's quite convenient to do so in the short-
term. In the long-term, these things will come back and bite us. I argue that
it is important that a programmer should have experienced what it is like to
simply not have the option to do so. After learning Haskell, I tried to avoid
side-effects in other languages as much as possible and to use them
consciously. That was something I didn't even consider before learning
Haskell. And, obviously, the less side-effects you have, the easier it is to
maintain or exchange parts of your program.

I currently use Haskell to calculate probably a hundred analytical derivatives
for a large sparse array that is used in a simulator written in Fortran. And
it's very good at that. For quickly writing some evaluations of output of this
simulator I use Python, because Python is better suited.

Pick a language based on the problem. Don't just use one language because you
know it. In my experience, Haskell is very well suited for a lot of
mathematical stuff.

\------

Off topic:

By the way, Einstein's field equations will work for gravity in the classical
regime, not in all cases. But still, if you simply want to calculate how far
you'll throw a ball, you really should take another model based on Newtonian
gravity or simply take a constant gravitational force. Planetary movements are
also fine with Newtonian gravity (except when you really need it accurately.
E.g. for the precession of the perihelion of mercury). However, GPS
calculations are terribly inaccurate without general relativity (time flows
differently if you are close to a big gravitational potential well). So, pick
your model based on what you want to do, just like you pick your programming
language based on what you want to do.

~~~
krick
> I also wouldn't want to do everything in Haskell.

Examples, please? And why?

~~~
QuantumRoar
If you have an array that fills a significant fraction of your memory (say,
tens of Gigabytes), you don't have another choice but to use mutation (Haskell
doesn't support that).

While quite fast, it is not in the league of low level programming languages.
If you need ridiculous speeds, you don't have another choice but to use C, C++
or Fortran.

Python has a lot of very useful modules. If I can solve my problem with
basically a few import statements and don't care about performance or
anything, I find Python to be better suited.

Erlang's light-weight threads are a boon. Having a webserver written in Erlang
and using Erlang as a server-side language, you can support a lot of sessions
at once.

~~~
carterschonwald
i write incredibly mutation heavy code in haskell on a nearly daily basis.
I've even added compiler support for doing hardware prefetch to the most
recent version of ghc
[https://downloads.haskell.org/~ghc/7.10.1/docs/html/librarie...](https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/GHC-
Prim.html#g:29)

there are many lovely mutable data structuers in haskell
[http://hackage.haskell.org/package/vector-0.5/docs/Data-
Vect...](http://hackage.haskell.org/package/vector-0.5/docs/Data-Vector-
Storable-Mutable.html) is one for unboxed C-struct style arrays,

[http://hackage.haskell.org/package/hashtables](http://hackage.haskell.org/package/hashtables)
is a super mature stable mutable hashtable library, that is used, among other
places, in agda!

..... please fact check your feelings in the future :)

~~~
QuantumRoar
Sorry. I seriously didn't know. I only ever used the immutable parts of
Haskell. Thanks for the correction.

------
david-given
The author's comments on noise chime true with me: every time I give Haskell a
try I end up struggling with frustrating and opaque vocabulary, sometimes
completely at odds with the way other languages use them: e.g. C++ also has
functors, and they're completely unrelated to Haskell functors.

I really like the author's suggestion of mentally translating Functor to
Mappable. Are there any other synonyms for other Haskell terms of art?

What I'd really like, I suppose, is a complete overhaul of Haskell syntax to
modernise and clarify everything: make it use actual _words_ to describe
things (foldl vs foldl'? BIG NO). Put in syntax redundancy and visual space to
avoid the word soup effect: typing is cheap, understanding is expensive.
Normalise and simplify terminology. Fix the semantic warts which make hacks
like seq necessary --- if I need to worry about strictness and order of
evaluation, then the language is doing lazy wrong. etc.

Basically I want language X such that X:Haskell like Java:K&R C.

This will never happen, of course; the people who have the knowledge to do
such a thing won't do it because they are fully indoctrinated into the Haskell
Way Of Life...

~~~
dllthomas
As others pointed out, the way Haskell uses the term "functor" is related to
the way mathematicians had been using it for at least a decade before cfront.

I agree that a shared vocabulary is important, but standardizing in a way that
makes the mathematical writings on the topic more accessible seems a big win.
Moreover, "functor" is a bit more precise than "mappable" \- a functor is a
mapping that preserves structure. In what sense? The math can guide you. In
this case, it means the functor laws.

That's not to say that coming up with other associations to help ease
understanding is a problem - I have no problem with saying, "for now, think of
Functor as 'mappable'". The equivalent for Monad would probably be
"flatMappable", and Monoid would be "appendable".

~~~
ihm
> As others pointed out, the way Haskell uses the term "functor" is related to
> the way mathematicians had been using it for at least a decade before
> cfront.

Rather a bit more than that. Eilenberg and Maclane's original paper defining
the basic notions of category theory was published in 1945!
[http://www.ams.org/journals/tran/1945-058-00/S0002-9947-1945...](http://www.ams.org/journals/tran/1945-058-00/S0002-9947-1945-0013131-6/S0002-9947-1945-0013131-6.pdf)

~~~
dllthomas
Thanks! I suspected that was the case, but the looser bound was much easier to
be confident in with the level of effort I could spare.

------
cies
Great article. I do think a better "Getting started with Haskell" guide is
Chris Allen's:

[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

OP's article is still a great way of wetting appetite, and sharing insights;
but moving on from there is better facilitated by Chris Allen's
recommendations.

There is also the IDE issue; FPComplete has a web-based IDE that is good for
beginners, and it is possible to setup Emacs to be a very helpful IDE (though
this is by no means simple). With Haskell an IDE is really helpful: see the
errors as you type, and resolving them before running into a wall of compile
errors.

Anyway: go Haskell. I'm looking forward to a less buggy future :)

~~~
octatoan
I think you meant "whetting". :)

~~~
AnimalMuppet
I don't know about that. Haskell can be rather sink-or-swim...

;-)

------
LukeHoersten
I've been programming Haskell for quite a while now and find that many of
these types of articles don't capture what I really value in the language. The
author really captured what I love about Haskell excellently! It's super
terse, (really) readable, and the barriers to entry people worry about are
more in their minds than in reality. It's a great language and a great
article!

------
windlep
I really like Haskell, but one of the main problems I've had (that I don't see
many people cite) is that the libraries just aren't made for use under serious
load/concurrency. Many of the people that have written these libraries, and
use them are not using them in high-performance, memory-sensitive areas
(production use at companies).

There are Haskell libs of course that _are_ used in these environments, and
the companies usually end up fixing them such that they're quite good. Most
libs used by pandoc are likely to be great, and there's a few dozen others of
the same caliber (its useful to search around and see what libs are used by
the other few companies using Haskell since they have likely been vetted as
well).

The other largest issue to actually using Haskell is that all the knowledge
your ops team has of running a production system are essentially null and
void. All your existing knowledge of how to fix performance issues, null and
void. Learning Haskell and becoming productive in it almost starts to look
like the easy part compared to effectively running a Haskell (dealing with
space leaks, memory fragmentation issues, and ghc tuning for stack sizes,
allocations, etc).

~~~
LukeHoersten
I've actually found the exact opposite. The library ecosystem is rich and
mature. Haskell is, by default, "concurrency safe" because of referential
transparency. You can safely "async" and compose almost any library in the
Haskell ecosystem without worrying about shared memory etc underneath.

Also, a lot of the really common libraries like text, attoparsec (parsers),
aeson, networking, etc are highly tuned for low latency and performance. Many
use compiler rewrite rules and techniques called stream-fusion to compact a
lot of the machine code away. Also aggressive inlining etc can be done.

I'm sure there are some memory-heavy or poorly optimized libraries out there
but that's certainly not the norm. I've had no problems with the libraries
off-the-rack.

~~~
windlep
I actually thought that too, but I guess that's not the case. I helped write
some HTTP2 frame-parsers for Haskell using attoparsec, but apparently it
wasn't fast enough as the lib author later rewrote all the attoparsec code to
use pointers to the underlying byte buffers.

[https://github.com/kazu-
yamamoto/http2/commit/0a3b03a22df1ca...](https://github.com/kazu-
yamamoto/http2/commit/0a3b03a22df1cabb984a0640320d8553cd33d64d)

The stream fusion stuff is sweet, but not exactly unique to Haskell since any
language with good iterator/generator abstractions have similar constant-time
memory characteristics.

~~~
zoybert
I believe you're misunderstanding what stream fusion is. A language compiler
does not really need "good iterator/generator abstractions" more than a
guarantee of side-effect free transformations in order to be able to de-forest
the intermediate data structures.
[http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7...](http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7401)

~~~
windlep
I meant more that languages with an iterator/generator usually have similar
constant space usage. That is a drastic oversimplification of stream fusion
and fails to mention other practical outcomes as you mention, along with a
variety of optimizations.

I found this posting a little more approachable to seeing the various
optimizations possible with stream fusion:
[https://donsbot.wordpress.com/2008/06/04/haskell-as-fast-
as-...](https://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c-working-
at-a-high-altitude-for-low-level-performance/)

------
estefan
Nice article. I find FP incredibly elegant and I'd like to learn Haskell, but
every time I search, there are never any jobs in it, so it seems like Scala is
the better choice for where I live...

Speaking of which, I found "Functional Programming in Scala" excellent for
teaching someone with an imperative background how to "think functionally".
Monads are explained in an easy to understand way. I can imagine that without
reading that book I'd have been looking at a couple of years of coding before
I started to see the abstractions, etc. By contrast "Learn You a Haskell" lost
me part way through both times I tried to read it...

~~~
mightybyte
If you wait for the jobs to come, you'll be late to the party. Very few people
will want to hire someone who doesn't know Haskell for a Haskell development
position. Learn it now so you'll be up to speed when more jobs start
appearing. Or better yet, learn it and then create the Haskell jobs yourself.

~~~
akurilin
Your last sentence is basically what we did. It's hard, but it's doable.

------
lmm
> So, I started calling it Mappable. Mappable was easy for me to remember and
> was descriptive of what it did. A list is a Functor. A list is Mappable.

I wish there was a language or library that was willing to take the Haskell
functionality and just give it all names like this.

~~~
DanWaterworth
This is actually possible with the ConstraintKinds extension in GHC.

    
    
        type Mappable = Functor
        type NotScaryFluffyThing = Monad
    

This makes Mappable a synonym for Functor and likewise for Monad. (This is not
necessarily a good idea; it goes against the principle of least surprise, but
it'll work).

~~~
TazeTSchnitzel
Isn't aliasing types a core language feature?

~~~
lclarkmichalek
Functor and Monad are technically not types but type classes (i.e. interface
vs an implementing class), hence why simple/naive type aliasing is not enough.

------
kwindla
Learning enough Haskell to feel "productive" is an incredibly good way to
deepen your understanding of programming, even if you've been programming for
years.

Two things, in particular, stand out for me when thinking about Haskell this
way (as a "tool for thinking" language).

First, unless you're a mathematician, you probably haven't thought very deeply
about algebraic data types, and how useful and expressive it is to build up a
program representation from a collection of parameterized types. The article
touches on this a little bit in noting that Haskell teaches you to think about
data types first.

But it's more than just "data first," for me, at least. Grokking Haskell's
type system changed how I think about object-oriented programming. Classes in,
say, Java or C++ or Python are a sort of weak-sauce version of parameterized
abstract types. It's kind of mind-blowing to make that connection and to see
how much more to it there is.

Second, monads are a really, really powerful way of thinking about the general
idea of control flow. Again, the most useful analogy might be to object-
oriented programming. When you first learn to think with objects, you gain a
flexible and useful way of thinking about encapsulation. When you learn to
think with monads, you gain a flexible and useful way of thinking about
execution sequencing: threads, coroutines, try/catch, generators,
continuations -- the whole concurrency bestiary.

I think monads are hard for most of us to wrap our heads around because the
languages we are accustomed to are so static in terms of their control flow
models, and so similar. We're used to thinking about control flow in a very
particular way, so popping up a meta-level feels crazy and confusing. But it's
worth it.

For example, if you do much JavaScript programming, and are ever frustrated
translating between callbacks and promises, having a little bit of Haskell in
your toolkit gives you some mental leverage for thinking about how those two
abstractions relate to each other.

------
harry8
I don't think I have ever used a haskell program written by someone else that
wasn't ghc. Is that usual? Are there now a bunch of .debs for useful things
other than writing haskell that are actually written in Haskell? I'm not
trolling, it's just a good test of what something is useful for when it's been
around a while is to ask "Well, what has it actually been used for?"

~~~
nathankleyn
The Haskell wiki has a page called "Haskell in industry" [0] which lists all
the people using Haskell in the real-world.

Some notable ones include:

* Facebook Haxl, an abstraction around remote data access [1]

* Microsoft Bond, a cross-platform framework for working with schematized data [2]

* Google Ganeti, a cluster virtual server management tool [3]

* Intel Haskell research compiler, a custom Haskell compiler used internally at Intel Labs [4]

\---

[0]:
[https://wiki.haskell.org/Haskell_in_industry](https://wiki.haskell.org/Haskell_in_industry)

[1]:
[https://code.facebook.com/projects/854888367872565/haxl/](https://code.facebook.com/projects/854888367872565/haxl/)

[2]: [https://github.com/Microsoft/bond](https://github.com/Microsoft/bond)

[3]: [https://code.google.com/p/ganeti/](https://code.google.com/p/ganeti/)

[4]: [http://www.leafpetersen.com/leaf/publications/hs2013/hrc-
pap...](http://www.leafpetersen.com/leaf/publications/hs2013/hrc-paper.pdf)

~~~
jayvanguard
Anytime a technology needs to publish a list of "who's actually using this in
the real world" the answer is not all that many (relative to other peer
technologies). Most projects in those lists fall into the following
categories:

1\. It is just a small team or even one person using it and they're doing it
because they really want to use that technology badly.

2\. The project is some side research thing or trivially small that it could
have been done using any technology.

3\. It is actually just a tool or sub-system of the main system that was low
risk enough.

4\. The project is no longer operational, if it ever made it to that stage.

~~~
Guvante
While your point isn't invalid it is important to keep in mind that popularity
is not a valid proxy for quality.

Also he is focusing on large companies who have huge reasons they can't use
Haskell, mostly related to internal resources. If you have several hundred
Java engineers (for example) you literally cannot just switch to Haskell, it
wouldn't work.

~~~
jayvanguard
Completely agreed about quality. Popularity is highly correlated to actual
utility though.

Lisp falls into the same category. High quality and very interesting but it
will never, ever gain widespread use. Don't believe me? A half century of
proof exists. Haskell is already at a quarter century.

Both are very cool and everyone should learn them to some degree because they
will make you a better programmer but neither will ever be used widely. They
just aren't appropriate for most general purpose programming tasks.

~~~
dasil003
I would be wary of painting Haskell and Lisp with the same brush. Yes, on
first glance they both appear to be "difficult" languages that are over the
heads of the average programmer. However they take very different approaches.

Lisp gives the programmer maximum raw expressive power. This appeals to lone
wolves and autodidacts, but it completely punts on the issues of standards,
teamwork and maintainability.

Haskell on the other hand, promises a direct solution to a huge swath of
problems that are experienced across the board in software development today.
The pitch is essentially an extension of what Sun used to sell Java in the
90s: it makes your code safer and more maintainable. Except Java only really
did that for memory management in a C-dominated world, the type system gives
you barely anything in that regard, so you still have just as many
NullPointerExceptions as you suffer from lack of types in languages like Ruby.
Haskell type system gives you infinitely more meaningful safety, but with
suitable state-of-the-art functional abstractions to minimize the pain of
acquiring it.

The only catch is the learning curve is steep, but as more and more
programmers scale that wall, the benefits to performance and maintainability
will become apparent to the pointy hairs. Lisp never really had an equivalent
value proposition, except in a few narrow fields where its expressiveness and
plasticity were key.

------
pubby
Whenever I try to be productive in Haskell I end up taking the research phase
too far and end up over-my-head in category theory that I don't understand.
I'm never productive in Haskell.

~~~
boothead
You might not be productive in the traditional sense of "delivering business
value". However over the years of letting Haskell change my brain a little
piece at a time, the results have accumulated. I wouldn't swap that deeper
understanding for all the productivity in the world. :-)

~~~
glutamate
Haskell is a great language for delivering business value. The typed FP
paradigm encourages reusable code much more than any other paradigm I have
tried.

~~~
boothead
Yes, absolutely agree with you. I wish I was writing Haskell day to day.

My point was that it takes a long trivial amount of time to learn Haskell
during which you might feel "unproductive" by that measure. I feel that it's
during that period that the magic happens :-)

------
TheSmoke
excellent article, thanks.

it's comforting -for me- to see that almost everybody is going through the
same phases while learning haskell. i believe that should say something to
haskell community.

i've recently started learning haskell. it's been 25 days. (so says cabal) i
was reading a book and struggling to build a web app. (why web app?) i was so
close to quitting. later i decided this is not the way to learn haskell. one
simply does not read the book and try stuff. that was not enough. at least for
me. so i changed my method.

my new method of learning haskell is:

\- read the book.

\- find one or more mentors (i have two) that are really good at haskell and
can answer all kinds of impatient questions you have.

\- watch people doing and explaining haskell stuff.

\- join #haskell-beginners on freenode and ask your questions.

\- create something small first that you can turn into something big later.

online haskell resources are surprisingly deficient however #haskell-beginners
community is awesome when it comes to helping n00bs like me and "learn you a
haskell" book is an excellent book.

one more resource that i use as reference material is the "haskell from
scratch" [0] screencast series by chris forno (@jekor).

before you begin, make sure you checkout chris allen's (@bitemyapp) "learn
haskell" [1] guide.

we'll get there people, we'll get there. :)

[0] [https://www.youtube.com/playlist?list=PLxj9UAX4Em-
Ij4TKwKvo-...](https://www.youtube.com/playlist?list=PLxj9UAX4Em-Ij4TKwKvo-
SLp-Zbv-hB4B)

[1]
[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

------
kitd
> After writing a parser with them, I began to understand other code that used
> them. I then started to understand the abstract nature of them…but that
> abstractness was a lesson for another day, not for starting out.

This definitely helped me too. I started out looking at functions and monads
as 2 'types' of function that could only be mixed in certain ways, and didn't
bother with the gory details at first. IME It's only when you experience
monads and their effects that the gory details make perfect sense.

------
pjungwir
I've got a side project webapp I'd like to use to learn some Haskell. What is
the most mainstream Rails-like web application framework out there? By Rails-
like I mostly mean convention-over-configuration, with a strong ecosystem of
plugins so I don't have to re-invent the wheel for auth, file uploads, etc. So
far I've seen:

\- Yesod

\- Snap

\- Happstack

\- Scotty

\- Spock

Right now I'm learning Yesod, but I don't feel confident that's really what I
want. Which of these are closest to Rails? Which are closest to Sinatra?

~~~
creichert
Yesod would be the closest to Rails.

Scotty would be closer to Sinatra and Flask. Spock is similar to Scotty but
comes with a few more built-in features like type-safe routing, sessions, etc.

I recommend Yesod but there are certainly some advanced metaprogramming
features (routing, models).

Have you checked out the Yesod scaffold site?
[https://github.com/yesodweb/yesod-
scaffold](https://github.com/yesodweb/yesod-scaffold)

------
x0054
Could you guys explain to me what Haskell would be mostly useful for. For
instance, can it be used to make a web app backend or a GUI app? Or is it
mostly for mathematical calculations and such. I tried to pick up Haskell
once, but I guess I just couldn't get it. I mean, I got the core concepts,
wrote a bunch of starter code, like prime checker and the like. But after
going through several tutorial chapters, I still could not figure out how I
would use Haskell in the real world.

I don't mean to criticize or anything, just mean to understand. There are so
many people who are very passionate about Haskell that it makes me think that
it must be worth while to learn. But I just don't get how it would be useful
for things that I do most with programming: writing Web/Desktop/Mobile apps in
Swift, Python, and PHP.

Also, can you recommend a good book or resource that uses real world examples
to teach Haskell?

~~~
dragonwriter
> Could you guys explain to me what Haskell would be mostly useful for. For
> instance, can it be used to make a web app backend or a GUI app?

Yes, and yes.

> Also, can you recommend a good book or resource that uses real world
> examples to teach Haskell?

The obvious thing to recommend here is _Real World Haskell_ [0], which
directly addresses some of the areas you raise.

Also, _Write Yourself a Scheme in 48 Hours_ [1] is more in-depth and real-
world than most tutorials (writing a Scheme interpreter isn't exactly a common
real-world application, but its more real-world _scale_ than most tutorials
address, and it uses a lot of things that are of concern in many real-world
apps.)

[0]
[http://book.realworldhaskell.org/read/](http://book.realworldhaskell.org/read/)

[1]
[http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H...](http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours)

~~~
x0054
Thanks, I think Real World Haskell was the resource I was looking for. I'll
try to get through it in the next month and see how it goes.

~~~
iand675
It's worth noting that it was written quite a while ago, so while it's still a
great book, there are portions that have a wee bit of code rot. In the event
that one of those sections trips you up, I'd encourage you to visit the
#haskell IRC channel!

------
outworlder
Got sidetracked by this:

> "We store memories by attaching them to previously made memories, so there
> is going to be a tendency for your brain to just shut off if too many of
> these new, heavy words show up in a sentence or paragraph."

That has always been my belief. I don't have anything else to back it up, only
that my own speed of learning seems to increase for new subjects with time.
The more I know, the easier new concepts seem. Very few things are completely
new, unless I start delving into subjects I'm completely unfamiliar with. Say,
Quantum Mechanics.

With most programming languages, I (and probably many here) can learn enough
to start creating something useful in a weekend. Haskell always gave me
trouble because it seems to take longer than that.

Then again, so does Prolog. I'll try yet again.

------
julian_perrott
Nice article, i've been learning Haskell for about a month solving kata on
[http://www.codeswars.com/](http://www.codeswars.com/) using
[https://www.fpcomplete.com/](https://www.fpcomplete.com/) as my IDE. I'm
finding it quite a learning curve understanding what library functions there
are and how to use them. The code I write often ends up being quite different
to the other solutions on codewars.

I'm missing Visual Studio, are there any realy good Haskell IDEs out there?
for example ones which allow debugging.

~~~
grp
Haskell with Emacs is awesome! There's a few modes available to have a
powerful IDE. I don't remember which ones as xmonad + yi (or vi) is enough for
me now.

~~~
gallabytes
How've you liked actually using yi? My only experience with it was rather
frustrating.

~~~
grp
My main reason of change is because emacs was getting too slow and buggy.
After trying a few hacks in 'init.el' and co, it was getting worse...
Suddendly Yi!

As I code only in haskell, it's perfect fun for me. Now, maybe a good way to
start is using/practicing their Vimgolf client. [0]

In emacs, as I didn't use any others modes (except haskell-mode ...), I don't
need their wonderful package managers any more.

[0] [https://yi-editor.github.io/pages/vimgolf/](https://yi-
editor.github.io/pages/vimgolf/)

------
__Joker
Kind of agree with refactoring with python. While prototype building was
easier with python, I used to have lot of changes and always has this nagging
problem that something is not right.

------
IanCal
I really liked this article, in particular the sections around learning things
like Functor and Monad (if you haven't read the article, don't worry, it's not
a list of new explanations that's why I like it).

A minor wording recommendation:

> better in every measure(lower complexity, speed, readability, extensibility)

Apart from a missing space before the parenthesis, this reads like there was
lower complexity, lower speed ...

~~~
danneu
Could just change "lower complexity" to "simplicity".

------
cies
Find more discussion on this article over at /r/haskell:

[http://www.reddit.com/r/haskell/comments/33mnlc/becoming_pro...](http://www.reddit.com/r/haskell/comments/33mnlc/becoming_productive_in_haskell_coming_from_python)

------
musername
> Composing functions out of other, smaller functions offers a big reduction
> in complexity. If they’re named well, this allows you to write functions
> that are easy to read.

 _there are only two problems in CS, cache invalidation and naming things_ \-
phil karlton

------
prajjwal
As someone who recently groked some of the higher order Haskell concepts, I
found myself nodding at everything this says.

An RSS feed would be great.

Also, does anyone know what colorscheme this is using for the code samples?
Looks nice.

------
solaris999
Thanks for this, I really appreciate the section at the end on a suggested
learning process. Looks like I've got my weekend planned!

------
michaelochurch
OP: Thanks for this. I'm teaching a class on Haskell for my company's interns
this summer and I'm trying to come up with a syllabus and a plan for it. This
really helped.

