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

Maybe too late but here it is: I was given a similar opportunity recently, but with only developers in the audience (no managers), so I focused on coding examples and functional programming in general rather than Haskell in particular (although all code examples were Haskell). One thing I tried to do was crushing the myth (?) that functional programming is more difficult than imperative by showing an example of typical imperative code and it's functional mate. I was afraid this would not fly well because the particular code example was the fibonacci sequence (it was the shortest most to the point example I could think of then)[1]. To my surprise it was fairly well received and I believe the point got through. Other more real world code examples where shown (counting word frequencies in a text file etc), introducing folding and mapping and the ever useful list. If I was to do this again, given the experience, I would try focus more on the types of functions, to show how much can be learned about a function's behaviour by just lookup at it's type. I feel this got lost in my presentation due to me utilising type reconstruction to show how writing code in a staticaly typed FPL like Haskell resembles coding in scripting languages (succintness) but with the compiler helping spot many errors. Time is the obvious enemy when introducing an imperative audience to FP. Code is mostly uninteresting for an audience who do not understand it, so you may need to explain HOF:s, algebraic data types, currying (for Haskell) and maybe point free style, the ring operator etc. This can easily steal the whole time slot if you are not careful. I agree that using GHCI is very good, but I think you should be careful if using emacs' ghci integration so the audience do not believe interaction is only possible through emacs. Best wishes! /Johan [1] Showing both the memoized zipWith version and the non-memoized and incredibly inefficient version, explaining the difference. 2012/6/2 C K Kashyap :

Thank you all very much,

I am sitting now and collating all your responses. I'll revert with questions if I may have.

Indeed, it may be better to have this kind of collateral ready for future use.

I am going to put my stuff on github .... considering markdown + pandoc.

Regards, Kashyap

On Sat, Jun 2, 2012 at 3:06 AM, Claus Reinke wrote:

...

...

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.

Haskell is important, but not the only way forward. Also, there have been other great languages, with limited impact - incorporating great ideas is no guarantee for takeup. If you want to be convincing, you need to be honest.

...

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.

If you approach this from the Haskell side (what is Haskell good at), you might get some people curious, but you won't connect their interest to their daily work. You don't want to give them a show, you want to inspire them to want to try coding in that language.

If you really want to understand what is good about Haskell, stop using it for a while, and work in something like Javascript (or whatever your audience is comfortable with, but for me Javascript was an eye opener).

You won't believe how basic the issues are that "conventional" coders are struggling with until you realize that you do not have them in Haskell.

If you have felt that pain, have understood that you can't make those issues go away by saying "that wouldn't be an issue in Haskell", then you can understand that their struggles and issues are real.

If you respect that, you can take one of their problems/source bases, and translate it to Haskell. That step tells them (and you!) that Haskell is adequate for their problem domains (which won't always be the case - no point showing them a wonderful language that they won't be able to apply).

The next step is to go through some of those pain points in that code and show how to get rid of them in the Haskell version. Instead of presenting ready-made solutions, show them how to work with code they understand, much more confidently than they would be used to.

Go slowly, and focus on their daily pain points (which they probably have stopped feeling because they can't do anything against them). Explain why you are confident in your modifications, compare against the obstacles that their current language would throw up against such modifications. Some examples:

- types can replace basic documentation and documentation lookup

- no need to test things that the type system can check, not in test suites   and not in the prelude of every function definition; you still need tests,   but those can focus on interesting aspects; you don't need to run 10   minutes of tests to verify that a refactoring in a large code base hasn't   broken scoping by misspelling a variable name, or that function calls   have the proper number and type of parameters

- thanks to decades of development, Haskell's static type system does   not (usually) prevent you from writing the code you mean (this is   where the proof comes in - you've rewritten their code in Haskell),   nor does it clutter the code with type annotations; types of functions   can be inferred and checked, unlike missing or outdated documentation;

  (careful here: language weaknesses are often compensated for through   extensive tool usage; some IDEs may check type annotations within   comments, or try to cover other gaps in dynamic languages)

- part of the trick is to work with the type system instead of against it:   document intentions in code, not comments

- separation of expressions and statements

- instead of every expression being a statement (side effects everywhere),   every statement is an expression (functional abstraction works   everywhere)

- since functional abstraction works everywhere, once you see repeated   code, you know you can factor it out

- you can build libraries of useful abstractions

- building abstraction libraries in the language is so easy that you   can build domain-specific abstraction libraries

- domain-specific abstraction libraries become embedded DSLs;   no need to write parsers, no risk to useful program properties   from overuse of introspection

- ..

I better stop here - I hope you can see the direction:-)

Many of these do not even touch on the advanced language features, but all of them rely on the simplicity and careful design of the core language. All of these advantages carry over to concurrent and parallel programming, without having to switch to another language.

Also, both functions and threads are so cheap (and controllable in terms of side-effects) that you do not have to break your head to avoid using them. And instead of noisy syntax, Haskell's syntax tends not to get in the way of writing in domain-specific abstractions.

The main advantages of Haskell (as I see them at this moment;-):

- fewer problems to keep track of: can focus on higher-level issues

- great support for abstraction: you can scratch that itch and don't   have to live with feeling bad about your code; over time, that   means accumulating reusable ideas and expertise, *in code*,   and concise solutions to complex problems

- domain-specific languages: the language does not get in the way

- broad base functionality to build abstractions on (graphics, speed,   concurrency, parallelism, web, ..)

Much of this has only been possible through no-compromise adherence to design principles in a from-scratch design, starting with a narrow and supportive user base. Other language committees also have very experienced members, but they can not evolve the language as they'd like without breaking real-world code.

Following the es-discuss list (EcmaScript) can be enlightening, and saddening, in this respect. Haskell has been moving out into the real world, and is now starting to feel the pains, but it has had much better starting conditions for its design, so it still comes out ahead (but it doesn't yet run everywhere Javascript runs, for instance).

None of this is tested with audiences, just personal opinions, from personal experience!-) I just wanted to offer an alternative view to the usual approach of Haskell evangelism.

I assume this isn't quite what you hoped to hear, but I hope it helps. Claus

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