[Haskell-cafe] Need inputs for a Haskell awareness presentation

[Chris Wong]

On Fri, Jun 1, 2012 at 6:23 AM, C K Kashyap <ckkashyap at gmail.com> wrote:
> Hi folks,
>
> I have the opportunity to make a presentation to folks (developers and
> managers) in my organization about Haskell - and why it's important - and
> why it's the only way forward. I request you to share your
> experiences/suggestions for the following -
> 1. Any thoughts around the outline of the presentation - target audience
> being seasoned imperative programmers who love and live at the pinnacle of
>  object oriented bliss.

Rustom nailed it. Take something imperative languages are really,
really bad at and *show* how it's done in Haskell.

*   Parsing

    Haskell parser combinators make yacc look old school. By
leveraging Haskell's DSL features, parsers often end up looking like
the grammar they're implementing. Different parser combinator
libraries let you do incremental input  (Attoparsec), show clang-style
diagnostics (Trifecta), or perform crazy optimizations automatically
(uu-parsinglib).

*   Iteratee I/O

        encodeFile from to = mapOutput encode (sourceFile from) $$ sinkFile to

    It may not look like it, but the above function (using the
"conduit" package) sets up a I/O pipeline that uses constant memory.
There are HTTP, FTP, text encoding and parser libraries that can hook
into the pipeline the same way. All the resources (sockets, file
handles) tied up in the pipeline are finalized automatically when it
finishes or when an exception is thrown.

*   Epic concurrency

    GHC comes with preemptive scheduling, STM and async I/O built in.
Maybe you could demonstrate these with a ping-pong-style application.

> 2. Handling questions/comments like these in witty/interesting ways -
>     a) It looks good and mathematical but practically, what can we do with
> it, all our stuff is in C++

Anything you can do in another Turing-complete language ;)

Quite a few folks have helped push Haskell into the practical world,
with useful things like web frameworks, ByteStrings, GUI bindings...
It's suitable for practical applications already.

>     b) Wow, what do you mean you cannot reason about its space complexity?

That's not a bug, it's a feature!

C++ gives you lots of control over how your program runs.
Unfortunately, most people don't need that or don't know how to use it
effectively. So most of the time, these low-level features just add a
bunch of cruft with no real benefit to the programmer.

Haskell goes the opposite way. The Haskell standard goes out of its
way *not* to say how programs actually run -- only what the result
should be. This lets the compiler optimize much more than in other
languages.

This philosophy is reflected in a common technique called "stream
fusion". I can't be bothered writing an example for this, but Google
it and you'll find a few.

>     c) Where's my inheritance?

Right behind you ;)

>     d) Debugging looks like a nightmare - we cannot even put a print in the
> function?

Traditional debugging -- stepping through the program line by line --
fails miserably in Haskell, mostly due to (b).

Haskell programmers tend to use more "mathematical" techniques:
* Property-based testing, e.g. reverse (reverse xs) == xs. Used
extensively in Xmonad.
* Algebraic proofs (this works especially well for "framework" stuff
like the MTL).
* Sexy types: encoding invariants in the type so the compiler checks
it for you. The fb (Facebook API) package does this with the NoAuth
and Auth phantom types.

For I/O-centric code, there's the traditional HUnit and HSpec.

And as Clark said, there's always Debug.Trace.

>     e) Static types - in this day and age - come on - productivity in X is
> so much more - and that's because they got rid of type mess.

The designers of Haskell went out of their way to make sure 99% of
types can be inferred by the compiler. It's good practice to put type
annotations on things, but you don't have to.

>     f)  Is there anything "serious/large" written in it? [GHC will not
> qualify as a good answer I feel]

* Yesod and Snap and Happstack -- all mature, well documented web
frameworks. Yesod is the check-everything-at-compile-time one, Snap is
the mix-and-match one and Happstack is the use-lots-of-combinators
one.
* Warp, a simple yet full-featured web server, trashes the competition
in terms of performance -- yet consists of less than 1k lines of code.
It uses all three of the techniques I mentioned above.
* Xmonad is a window manager. I've used quite a few tiling window
managers before, and Xmonad is the only one that hasn't crashed.
* Geordi (http://www.eelis.net/geordi/), an IRC bot that compiles and
runs C++ code, is written in Haskell.

>     g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do
> AI.
>     h) Any other questions/comments that you may have heard.
> 3. Ideas about interesting problems that can be used so that it appeals to
> people. I mean, while fibonacci etc look good but showing those examples
> tend to send the signal that it's good for "those kind" of problems.
> 4. Is talking about or referring to Lambda calculus a good idea - I mean,
> showing that using its ultra simple constructs one could build up things
> like if/then etc
> I'm gonna do my bit to wear the limestone!!!
>
> Regards,
> Kashyap
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>