[Haskell-cafe] Need inputs for a Haskell awareness presentation
C K Kashyap
ckkashyap at gmail.com
Sat Jun 2 08:19:27 CEST 2012
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
I am going to put my stuff on github .... considering markdown + pandoc.
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
> 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
> 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
> 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
> - 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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe