[Haskell-cafe] How Albus Dumbledore would sell Haskell

[Claus Reinke]

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