I think you are right. If you used something like a theorem prover as
an example, you accidentally send the messsage that Haskell is very
useful for esoteric stuff that only academics are interested in.
Now, that doesn't mean that the example has to solve a real problem,
but it does need to be something that the audience can relate to their
own problems.
There's already a lot of general buzz about functional techniques.
Closures and lambda expressions are being, or have been, added to
several imperative languages. This naturally leads to interest in
higher order functions. The concurrency revolution is driving interest
in immutable values and lockless algorithms. For people who do
transactional work, having launchTheMissiles in the middle of a
transaction be caught by the type system is incredible. At least some
of the interest in dynamic types is driven by frustration with dealing
with type annotations.
So really, the example code just has to solve a problem they
recognize. Even the sudoko solvers would be good, trite as they are.
Or, some of the unix tools in Haskell.
$0.02
-SMD
On 4/19/07, Lennart Augustsson
A theorem prover might be a really cool example, but if there's one person in the audience that cares then Simon is lucky. :) You need to have examples that people can recognize and see the utility of.
-- Lennart
On Apr 19, 2007, at 20:48 , DavidA wrote:
Simon Peyton-Jones
writes: But, just to remind you all: I'm particularly interested in
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
I have something that I think nearly fits the bill. Unfortunately, I don't think it quite works because it's a bit specialised. However, I think it suggests a possible area to look, which I'll mention at the end.
It's a theorem prover for intuitionistic propositional logic: http://www.polyomino.f2s.com/david/haskell/gentzen.html
It's much shorter in Haskell than it would be in other languages. (It's even shorter than the ML that I based it on, because of some shortcuts I can take using lazy evaluation.)
Strengths of Haskell that it demonstrates are: * How easy it is to define datatypes (eg trees), and manipulate them using pattern matching, with constructors, Eq, Show coming for free. * How lazy evaluation reduces code length by letting you write code that looks like it would do too much, and then lazy evaluate it (in the "proof" function) * The ability to extend the syntax with new symbolic operators * Use of higher order functions to simplify code (the (+++) operator)
The problem is that I think Gentzen systems are a bit obscure. But I think you could probably show most of the same strengths of Haskell in something similar: game search, eg alpha-beta algorithm. Another advantage of doing game search would be that you'd get to show off persistent data structures (so that when you make a move in lookahead, you don't need to make a copy of the game state, because when you update the game state the old state still persists).
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe