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.rei...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe