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<ckkash...@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 =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



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to