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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
