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

We have recently delivered a two-day hands-on Haskell training at Qualcomm. As Chris points out, parsing and concurrency/parallelism are the undisputed strengths of Haskell, so we used them extensively. The first day was dedicated to writing a parser of arithmetic expressions with symbolic variables, from scratch. We started very close to imperative style, so we had a tokenizer, parser, and evaluator. They all contained a lot of boilerplate code: error testing and state passing (input string in the tokenizer, token list in the parser, and symbol table in the evaluator). So it was very natural to abstract all this boilerplate into monads. There was actually a big aha! when we abstracted all these nasty control structures into bind and return and then showed the do notation. The second day was dedicated to concurrency and parallelism, starting with forkIO and MVars, then going through the par monad (with some hands-on exercises) and Repa, and finally showing Accelerate on GPUs. The course was a great success. We didn't have to deal with any nasty questions. We explained some of the evaluation strategies (strict, head-normal, bang) and memory issue workarounds (foldl vs foldr, etc.). We also showed an example of inductive proof of a simple property to show how Haskell can help with correctness. FP Complete and Well-Typed are planning on releasing some of our training materials to the public soon (depending on how much time I have to organize them). [:Bartosz:] On 5/31/2012 18:12, Chris Wong wrote:

On Fri, Jun 1, 2012 at 6:23 AM, C K Kashyap 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 =apOutput 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe