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
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