seems Simon has got himself a tricky problem. i was about to hit reply to his first call, but then i browsed through the oscon site, and thought that perhaps my background isn't close enough to the intended audience to make useful suggestions, not to mention the concrete examples asked for. but while there have been good suggestions, i still feel there are some general trends/ideas missing: - oscon seems to be a huge event. on the negative side, that means that if the pre-talk advertising isn't good enough (mainly abstract and general buzz, i guess), there won't be much of an audience, as there are too many other things going on. on the positive side, that means that almost no advertising should be needed in the talk itself - if people aren't interested, they won't be there. that kind of breaks the usual strategy for talking to non-haskellers. - it will still be necessary to convince the attendees, not that haskell is worth looking into, but that their first 3 hours of doing so has been time well spent, and a quick rehash of all the other wonderful things haskellers have been up to might be a small part of that, but it won't be sufficient. - 3 hours is long for a talk, but distressing for a tutorial: too short to really get the functional style of programming across to imperative/oo programmers, yet too long to stay within small and safe examples (thereby avoiding explanations of haskells more complicated sides). - i would expect the audience to be a similarly mixed blessing: imperative mindsets liable to stumble over even simple functional programming patterns, but at the same time too experienced to be impressible with toy examples. in light of all this, Simon's approach seems promising:
concrete examples (pref running code) of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language
working code for one or two compelling examples, engagingly presented, should have a chance of giving that audience some value for money. and perhaps it is best not to dwell on how different functional programming is - given that there isn't all that much time to get acquainted, it might be best to jump right in with "here's what you can do, and this is how you do it". people who pick up weird things like ajax, .. must be used to getting into strange lands, as long as they have good guidance, and useful examples. don't get bogged down in language features (there's reference manuals and tutorials for that), but focus on techniques and on achieving things. still, the central issue remains: how to present them with something that their current background tells them would be interesting, useful, and understandable, while at the same time presenting something that demonstrates haskell's advantages and culture. as i said, i can't offer concrete examples for that kind of audience, but let me report one experience that might be helpful: how i got into perl;-) at the time, i was doing lots of shell-scripting, and i thought that awk was about the most wonderful unix tool ever. what i was actually using awk for were two features: sets of rules triggered by pattern matching, and associative arrays for storing away the information extracted using those patterns. if you could express your problem in terms of these two, it would just disappear into thin air (clever storage tricks obviated any need for further processing). but if you couldn't, things would get awkward: processing data within awk's programming language wasn't fun, processing data within some shell wasn't much better (and at the time there were just too many shells, all with their own community, advantages and shortcomings). but the worst thing of all was passing data between scripts written in different tools (shell, awk, sed, make, ..), integrating the whole mess, maintaining and extending it. then someone suggested perl4, and i had to figure out whether i wanted to know more about it (new syntax, new concepts, and all that..). fortunately, there was a little tool for converting awk scripts to perl, allowing me to compare my old scripts with the new syntax. that immediately got me into a little of perl's control structures, and it was clear that perl's syntax for pattern processing was inspired by sed, just as its associative arrays were inspired by awk. so i could dump my awk, my sed, and my shells, and do it all in perl - i was convinced. i still use shells and sed for small things, and make for what it is good at, but i stopped using my favourite awk, and when multiple tasks needed to be integrated, i started to prefer perl. if i extrapolate from this experience to Simon's current adventure: powerful examples showing off perl's/haskell's features would sail right by me ("nice, but what does that have to do with me?" at best, "aargh, that looks very complicated; perhaps another time" at worst); small examples showing that perl/haskell can do what my current tools can already do just as well or better wouldn't even elicit much interest ("oh, yeah? so what?"). what would convince me to get started are two things: a general pattern showing me how to address my typical problems in perl/haskell, and the realisation that my hacking life would become simpler by integrating the work of different tools into one. for perl, the pattern was roughly: take your awk scripts, split them into pattern matching and associative array access, then write a perl loop to do just that; take your sed scripts and just inline the commands into your perl script; take the logic you were trying to express in your shell, and express it in a proper imperative language in perl (that was before oo perl); once you've done all that, forget the complexities of integrating all the pieces/syntaxes/string escape variants/pattern format differences/.. just manage it all in one script [that this was actually a step forward is all the more impressive given the unix shell philosphy of being a framework in which to integrate/compose lots of little tools]. for haskell, what would be the equivalent patterns, integration, and simplification advantages? my personal favourite would have to be domain-specific languages: to solve a problem, iteratively design the constructs/functions/data structures that make up a suitable language for describing said problem, all the while prototyping that domain-specific language in haskell; once you have the dsl, model your problem, and run it; if you have different kinds of problems, you'll have different dsls, but they'll all be embedded into the same general purpose language, so they'll share some features, and models in different dsls can fairly easily be integrated. dsl modelling is not unlike oo modelling, but instead of expressing everything as objects and classes, you express everything as whatever concepts are relevant to your domain, and haskell also provides an executable meta-modelling and integration language. now, whether this personal favourite is of any use with the oscon audience is another question, and the general interest has certainly shifted from local network scripting with shells to www scripting with browsers. we are still talking about pattern extraction/data storage/data processing/result presentation, but haskell's standard library support for www programming is still not quite up to the same levels as perl's (practical extraction and report language, well targetted). perhaps, i'd suggest a local scripting example to start with, followed by a www scripting example to build on; in both cases, i'd emphasize the embedded dsl approach. select or define suitable edsls for each of the phases/aspects of your typical problem: regular expressions/ parser combinators for the pattern extraction aspect; algebraic data types for data representation; Data.Map or a functional database interface for the data storage aspect; functional and monadic programming for the sequential data processing aspect; concurrent haskell, stm, and nested parallelism for non-sequential processing; pretty-printing and gui libraries for the result presentation aspect. it doesn't matter much what the two examples are, as long as they exhibit the haskell edsl approach to problems, and some generally useful edsl examples, rather than details of complicated language features. as the examples need to fit into the 3 hours, preferably with some interaction, they need to give a lot of bang for the buck. so instead of politically correct XML processing of well-formed RSS feeds (hah!-), one might take something radically simple, like Neil's tagsoup, then focus on the points one would want to demonstrate, rather than the example itself: http://www-users.cs.york.ac.uk/~ndm/tagsoup/ the source code for that library is almost criminally simple (and might need some minor improvements before demonstrating it), yet it allows us to approach web-scripting with the same level of intentional ignorance that made awk and perl so successful ("what do you mean, parsing? the world is based on regular expressions, all the way down!"). spice that up with proper regexps, some minimal parsing and pretty printing (gui, if you dare;-), some concurrency for tracking different sites, a little bit of data representation and processing, all expressed in their own dsls, all of which embedded in haskell, simply imported as modules, integrated in functional monadic code, and you might have the core of a small but useful example? definitely do a little daring online rewriting, just to demonstrate that the type-system tells you that the interface of a component allows it to be moved without unexpected side-effects. and since its a demo, be prepared for unexpected side-effects anyway!-) good luck! hth, claus