

Thinking Functionally with Haskell - Toshio
http://pragprog.com/magazines/2012-08/thinking-functionally-with-haskell

======
tsahyt
Interestingly I've never seen the parallels between the Unix way and
functional programming. But it makes perfect sense. Code programs/functions
that do one thing and do them well. However, that's how code should work in
general. That's what we got functions/methods for in the first place.

I agree, functional programming is great but sometimes I just see ideas being
sold as "functional" that apply to programming in general. Splitting programs
into smaller parts that are easily solvable and work in a predictable way is
one of the most fundamental parts of coding.

Sure, that's not all there is to it, but I'm a little bothered that it's being
marketed as the new thing.

~~~
samdk
The parallels to Unix are strong enough that having an actual pipe operator
can be very useful. I frequently write code that looks something like this:

    
    
        List.map data ~f:(fun elem -> ...)
        |! List.find ~f:( ... )
        |! Option.map ~f:( ... )
        

(This is OCaml, not Haskell, but the syntax is similar.) The definition of the
'|!' operator is quite simple:

    
    
        let (|!) x f = f x

~~~
IvoDankolov
Yes, in fact F# has that built in as |> , which I've taken to using in Haskell
as well. Though it's a bit more intuitive to me when it has the lowest
precedence like so:

    
    
        (|>) :: a -> (a->b) -> b
        (|>) x f = f x
        infixl 0 |>
    

There infixl 0 means infix operator with _l_ eft associativity and 0
precedence.

Then you can use all sorts of expressions inbetween:

    
    
         (5 + 3 |> show) ++ " times" |> putStrLn
    

Also, tying this back to one of the article's ideas, this piping-like syntax
for doing things really manages to take away the emphasis from the function
and put it back on the data. It isn't all about functions after all!

------
lobster_johnson
I wish PragProg would do a (whole) book one Haskell. The current ones just
aren't very good.

Books such as "Real World Haskell", the "gentle guide" and "Yet Another
Haskell Tutorial" all manage the rather unbelievable feat of making many
Haskell concepts unnecessarily complex, unintuitive and hard to understand --
not something you want for a language that is already on the complex side. For
example, RWH goes into an absurdly complicated sample scenario (a parser,
iirc) to introduce the reader to monads, and never slows down to go back to
first principles. YAHT does the same thing.

Monads have a reputation for being hard to understand, but I think this is
mostly the fault of the current literature; monads are conceptually simple,
yet every book manages to botch their explanation, making the learning curve
particularly steep for non-FP programmers.

~~~
spacemanaki
I think parsers are a decent way to introduce monads, and I really like the
way Graham Hutton's _Programming Haskell_ does it, by demonstrating parsing
without even using the word monad, and then in a later chapter on IO, saying
"oh hey and this thing is called a monad and we used it once before!"

And I disagree a bit about RWH... I'm in the middle of it now I think it's
great, filled with meaty examples that aren't too complicated at all and are
generally pretty concrete. Maybe I'm just not far enough in yet? There are
bits where it goes off into the weeds (the chapter on JSON goes so far as to
fiddle about with character encoding IIRC) but I just can't imagine a PragProg
book could do much better, without sacrificing depth.

~~~
lobster_johnson
The problem is that RWH teaches Haskell with "real world" examples that
actually do useful stuff (such as the JSON chapter), and high-level
theoretical concepts such as functors and monads are subtle and complicated
enough, especially for FP newbies, that they need to be taught from first
principles, not by wading into the deep end by showing a real-world
implementation of a parser.

Personally, my "eureka" moment was reading the "IO Inside" [1] page on the
Haskell wiki, which explains the IO monad in a way that made it click for me,
as a imperatively-trained programmer. You can think of the IO monad as a way
to force a compile-time dependency between I/O operations by having each IO-
performing function take a "baton" value (the "IO" instance) as an argument,
as well as return it. The explanation of how Haskell retains the appearance of
purity in the face of impure I/O by passing an instance of RealWorld around is
genius. That's a brilliant way to start out explaining monads, and it's
something simple that you can use to explain the other monads such as the
state monad (which the IO monad is built on).

I haven't tried the Hutton book yet.

[1] <http://www.haskell.org/haskellwiki/IO_inside>

------
3amOpsGuy
Wow, I attended a university synonymous with Haskell. 15 mins of reading here
and I've just had an epiphany that eluded me in all those years.

A most insightful post, thank you very much.

------
flazzarino
i'd like to see somebody think non-functionally with haskell

~~~
dbaupp
Like this: <http://kormacode.blogspot.se/2011/11/c-style-haskell_10.html> ?

~~~
flazzarino
i liked it, thanks

