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

[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 <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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120602/dd414321/attachment.htm>