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

[Johan Holmquist]

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 <ckkashyap at gmail.com>:
> 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 <claus.reinke at talk21.com>
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>