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

[Bartosz Milewski]

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<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 =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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>