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

[Claus Reinke]

> 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