gmane.comp.lang.haskell.cafe

Don Stewart | 5 Oct 03:23

Interesting new user perspective

http://sandersn.com/blog/index.php?title=two_weeks_of_haskell

Has some good thoughts on what tripped him up in his first two weeks of
Haskell programming. Anything people want to work on there? 

Worth a read if you're thinking about how to make Haskell yet more
accessible.

-- Don

headers

Andrew Coppin | 9 Oct 22:33

Re: Interesting new user perspective

Don Stewart wrote:
> http://sandersn.com/blog/index.php?title=two_weeks_of_haskell
>
> Has some good thoughts on what tripped him up in his first two weeks of
> Haskell programming. Anything people want to work on there? 
>
> Worth a read if you're thinking about how to make Haskell yet more
> accessible.
>   

Sounds like it was written by somebody who's already used to languages 
like Lisp and Python.

As I wrote a while earlier, I recently convinced an hardent C++ 
programmer to install GHC and start coding. Aside from the endless 
stream of "minor" things that trip you over when learning any new 
language, the biggest thing he sited as being difficult is the 
"implicitness" of Haskell.

C++ is a very explicit language. If you want an integer variable, you 
say "int x". If you want a vector of integers, you say "std::vector<int> 
x". And so on. In Haskell, you just say "x" and you've got a variable. 
Maybe it's type is known at compile-time. Maybe its type is 
polymorphically determined by the caller. Maybe it's dynamically 
changable at runtime (e.g., if you're using something like existential 
quantification). And you can write entire Haskell programs with not a 
single type signature in sight. (Until you grok how parametric 
polymorphism and Haskell's non-traditional type syntax work, this is 
probably the easiest way to program.) If you write a class instance, you 
define a whole bunch of functions who's types are implicitly fixed by

(Continue reading)

headers

Iain Barnett | 10 Oct 20:08

Re: Interesting new user perspective

On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote:

>  I think it's just the teaching of the language that needs work,  
> not so much the language itself.

As a newer user myself, I'd agree with this statement. I'd like to  
see far more mundane tasks solved in tutorials. The number of times  
building a parser or generating prime number is used as an example is  
out of proportion to the times you'd use these things[1]. Just  
simple, *really* easy things would be better. Maybe it's just me, but  
if I wanted to learn perl or ruby or python or C# I'm not sure I'd  
ever see a _tutorial_ containing a prime number.

Haskell is can obviously do some really interesting things, but  
constantly having wikipedia open so I can look up whatever  
mathematical doodah has just been mentioned can get draining. Even  
Real World Haskell suffers a bit from this.

Iain

[1] In years of programming (other languages) I've never had to  
generate my own primes or build a compiler or a parser. I may have  
parsed things, but that's different to building an entire parser, if  
you get my drift.

Actually, tell a  lie. I have built a parser, but it's still not  
stuff for a beginner's tutorial IMHO.

headers

Jonathan Cast | 10 Oct 20:05

Re: Interesting new user perspective

On Fri, 2008-10-10 at 19:08 +0100, Iain Barnett wrote:
> On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote:
> 
> >  I think it's just the teaching of the language that needs work,  
> > not so much the language itself.
> 
> 
> As a newer user myself, I'd agree with this statement. I'd like to  
> see far more mundane tasks solved in tutorials. The number of times  
> building a parser or generating prime number is used as an example is  
> out of proportion to the times you'd use these things[1]. Just  
> simple, *really* easy things would be better. Maybe it's just me, but  
> if I wanted to learn perl or ruby or python or C# I'm not sure I'd  
> ever see a _tutorial_ containing a prime number.
> 
> Haskell is can obviously do some really interesting things, but  
> constantly having wikipedia open so I can look up whatever  
> mathematical doodah has just been mentioned can get draining. Even  
> Real World Haskell suffers a bit from this.
> 
> 
> Iain
> 
> 
> [1] In years of programming (other languages) I've never had to  
> generate my own primes or build a compiler or a parser. I may have  
> parsed things, but that's different to building an entire parser, if  
> you get my drift.
> 
> Actually, tell a  lie. I have built a parser, but it's still not

(Continue reading)

headers

Iain Barnett | 10 Oct 20:27

Re: Interesting new user perspective

On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote:

> On Fri, 2008-10-10 at 19:08 +0100, Iain Barnett wrote:

> In Haskell it is.
>
> Parsec makes recursive descent parsers as easy to use in Haskell as
> regexps are in Perl.  No reason not to expose newcomers to Haskell to
> the thing it does best.
>
> jcc
>
>

Regex tends to come after things like basic I/O, even in Perl. I've  
got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
how to open a file!

Just because it can be done, or it's easy(ier) doesn't mean that's  
where you should start.

Iain

headers

Jonathan Cast | 10 Oct 23:29

Re: Interesting new user perspective

On Fri, 2008-10-10 at 19:27 +0100, Iain Barnett wrote:
> On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote:
> 
> > On Fri, 2008-10-10 at 19:08 +0100, Iain Barnett wrote:
> 
> > In Haskell it is.
> >
> > Parsec makes recursive descent parsers as easy to use in Haskell as
> > regexps are in Perl.  No reason not to expose newcomers to Haskell to
> > the thing it does best.
> >
> > jcc
> >
> >
> 
> Regex tends to come after things like basic I/O, even in Perl.

Why would I want to do I/O, when I don't know how to do anything
interesting with the input yet, or how to generate interesting output?
I think the `I/O comes first' attitude is *precisely* the difference
between mainstream programmers and Haskellers.  The goal should be to
create more Haskellers, not just more people whose code happens to be
accepted by GHC.

> I've  
> got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
> how to open a file!

That short, and you expect minor features like that (that not every
program even needs) to be squeezed in?

(Continue reading)

headers

Andrew Coppin | 10 Oct 23:43

Re: Interesting new user perspective

Jonathan Cast wrote:
> Why would I want to do I/O, when I don't know how to do anything
> interesting with the input yet, or how to generate interesting output?
> I think the `I/O comes first' attitude is *precisely* the difference
> between mainstream programmers and Haskellers.  The goal should be to
> create more Haskellers, not just more people whose code happens to be
> accepted by GHC.
>   

So we need to teach these people not just about the syntax of the 
language, but the high-level game plan for how to use Haskell 
effectively. (Since it's SO different from normal languages.)

Trouble is, as soon as you attempt to write a chapter like that, guess 
how many people are gonna actually read it? :-/

>> I've  
>> got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
>> how to open a file!
>>     
>
> That short, and you expect minor features like that (that not every
> program even needs) to be squeezed in?
>   

See, now it's things like that which stop more people attempting to 
learn Haskell. Most programmers would consider this an extremely basic 
and important thing to know, but Haskellers say "oh, THAT... it's not 
really important" and the newbies go "wuh? Which planet are you from? 
I'll go learn something less crazy, thanks."

(Continue reading)

headers

Jonathan Cast | 11 Oct 00:08

Re: Interesting new user perspective

On Fri, 2008-10-10 at 22:43 +0100, Andrew Coppin wrote:
> Jonathan Cast wrote:
> > Why would I want to do I/O, when I don't know how to do anything
> > interesting with the input yet, or how to generate interesting output?
> > I think the `I/O comes first' attitude is *precisely* the difference
> > between mainstream programmers and Haskellers.  The goal should be to
> > create more Haskellers, not just more people whose code happens to be
> > accepted by GHC.

> So we need to teach these people not just about the syntax of the 
> language, but the high-level game plan for how to use Haskell 
> effectively. (Since it's SO different from normal languages.)

Right.  I think what we're doing now *is* an effective program for doing
this --- for programmers who are willing to learn --- and what y'all are
proposing *isn't*.  I think most programmers, looking at the first
chapter of the tutorial you want, would be less inclined to learn
Haskell than they are now.  If they want to write ugly, unmaintainable
code, they can always use C++ or Perl, after all.  No need to learn
Haskell for that.

> Trouble is, as soon as you attempt to write a chapter like that, guess 
> how many people are gonna actually read it? :-/

Presumably, everyone who knows Haskell now, and programs well in it,
*has* read such a chapter.  

> >> I've  
> >> got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
> >> how to open a file!

(Continue reading)

headers

John Goerzen | 11 Oct 01:13

Re: Interesting new user perspective

On Fri, Oct 10, 2008 at 02:29:54PM -0700, Jonathan Cast wrote:
> > I've  
> > got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
> > how to open a file!
> 
> That short, and you expect minor features like that (that not every
> program even needs) to be squeezed in?

Uh... yes.  Opening and closing files, command-line parsing, etc --
needed by almost every program.  Aside from some very simple
stdin-to-stdout filters, it is difficult to imagine a program where
you don't need to open a file!

headers

Jonathan Cast | 13 Oct 03:39

Re: Interesting new user perspective

On Fri, 2008-10-10 at 18:13 -0500, John Goerzen wrote:
> On Fri, Oct 10, 2008 at 02:29:54PM -0700, Jonathan Cast wrote:
> > > I've  
> > > got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
> > > how to open a file!
> > 
> > That short, and you expect minor features like that (that not every
> > program even needs) to be squeezed in?
> 
> Uh... yes.  Opening and closing files, command-line parsing, etc --
> needed by almost every program.  Aside from some very simple
> stdin-to-stdout filters, it is difficult to imagine a program where
> you don't need to open a file!

Again, you need a bigger imagination.  My day job is almost entirely
DB-centric; code that uses file I/O is very much a special case.

jcc

headers

John Goerzen | 13 Oct 04:34

Re: Interesting new user perspective

On Sun, Oct 12, 2008 at 06:39:58PM -0700, Jonathan Cast wrote:
> On Fri, 2008-10-10 at 18:13 -0500, John Goerzen wrote:
> > On Fri, Oct 10, 2008 at 02:29:54PM -0700, Jonathan Cast wrote:
> > > > I've  
> > > > got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
> > > > how to open a file!
> > > 
> > > That short, and you expect minor features like that (that not every
> > > program even needs) to be squeezed in?
> > 
> > Uh... yes.  Opening and closing files, command-line parsing, etc --
> > needed by almost every program.  Aside from some very simple
> > stdin-to-stdout filters, it is difficult to imagine a program where
> > you don't need to open a file!
> 
> Again, you need a bigger imagination.  My day job is almost entirely
> DB-centric; code that uses file I/O is very much a special case.

Not saying that it doesn't exist (though of course most databases
still use file I/O at some level, even if abstracted).  Just that it's
very, very common.  I wouldn't support at all teaching database
interactions or network programming before file I/O.

-- John

headers

Jonathan Cast | 13 Oct 04:41

Re: Interesting new user perspective

On Sun, 2008-10-12 at 21:34 -0500, John Goerzen wrote:
> On Sun, Oct 12, 2008 at 06:39:58PM -0700, Jonathan Cast wrote:
> > On Fri, 2008-10-10 at 18:13 -0500, John Goerzen wrote:
> > > On Fri, Oct 10, 2008 at 02:29:54PM -0700, Jonathan Cast wrote:
> > > > > I've  
> > > > > got a Haskell book here (Hutton, 170 pages) that doesn't even mention  
> > > > > how to open a file!
> > > > 
> > > > That short, and you expect minor features like that (that not every
> > > > program even needs) to be squeezed in?
> > > 
> > > Uh... yes.  Opening and closing files, command-line parsing, etc --
> > > needed by almost every program.  Aside from some very simple
> > > stdin-to-stdout filters, it is difficult to imagine a program where
> > > you don't need to open a file!
> > 
> > Again, you need a bigger imagination.  My day job is almost entirely
> > DB-centric; code that uses file I/O is very much a special case.
> 
> Not saying that it doesn't exist (though of course most databases
> still use file I/O at some level, even if abstracted).  Just that it's
> very, very common.  I wouldn't support at all teaching database
> interactions or network programming before file I/O.

I'm not advocating that.  But I do think demanding the teaching of *any*
interface issues before you've shown enough Haskell to write interesting
logic to tie to the interface is backwards.

jcc

(Continue reading)

headers

Steve Schafer | 10 Oct 23:13

Re: Interesting new user perspective

On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote:

>No reason not to expose newcomers to Haskell to the thing it does best.

This is precisely why newcomers flounder. Yes, there certainly should be
a "Haskell for experienced Java/C++ programmers : All of the advanced
things you can do more easily than you ever thought possible." But
that's not the way to attract Joe Programmer, who has never had to write
a parser. Joe Programmer needs to be shown how Haskell can solve _his_
problems. That might mean that you need to start with an extremely
non-idiomatic Haskell program, one that has some of the "look and feel"
of what programmers from other languages are comfortable with. And then
transform that program, step-by-step, into something that takes
advantage of Haskell's strengths.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/

headers

Andrew Coppin | 10 Oct 23:35

Re: Interesting new user perspective

Steve Schafer wrote:
> On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote:
>
>   
>> No reason not to expose newcomers to Haskell to the thing it does best.
>>     
>
> This is precisely why newcomers flounder. Yes, there certainly should be
> a "Haskell for experienced Java/C++ programmers : All of the advanced
> things you can do more easily than you ever thought possible." But
> that's not the way to attract Joe Programmer, who has never had to write
> a parser. Joe Programmer needs to be shown how Haskell can solve _his_
> problems. That might mean that you need to start with an extremely
> non-idiomatic Haskell program, one that has some of the "look and feel"
> of what programmers from other languages are comfortable with. And then
> transform that program, step-by-step, into something that takes
> advantage of Haskell's strengths.
>   

Seconded.

On the one hand, "Haskell makes difficult things easy, and impossible 
things possible". This is what's cool about the language. On the other 
hand, an introductory text ought to start with something simpler and 
_more familiar_ to get people used to the language first. Haskell is a 
simple language, but there's an awful lot of new stuff to learn - new 
language rules, and new techniques for structuring your code, and even 
*thinking about* what code "is".

And another problem. I've written a few "intro to Haskell" documents

(Continue reading)

headers

John Goerzen | 11 Oct 01:12

Re: Interesting new user perspective

On Fri, Oct 10, 2008 at 10:35:05PM +0100, Andrew Coppin wrote:
> OTOH, it's easy to criticise what somebody else wrote. Much harder to  
> write something better yourself... :-/
>
> PS. I'm curios to see what happens when the book gets to the  
> "interesting stuff". The intro seems to promise that Haskell has  

I'm equally curious to see what happens when you get there 

> libraries for all kinds of cool stuff - database access, sound, etc. But  
> IME it isn't true. I have tried and tried to make accessing a database  
> work from Haskell; the necessary libraries simply refuse to compile.  

Well, it compiles out of the box for me.  Which may or may not be
saying much.  Have you posted your compile errors here so that we can
help you?

> work.) I want to see what the hell everybody else is doing differently  
> that makes this stuff actually work for them when it fails miserably for 
> me!

Start by showing us what exact commands you're running and what errors
you get.  Also what version of GHC you have and your platform would be
helpful.

So anyhow... when I started using Haskell, it was *despite* the state
of libraries.  I found that I was so much more productive in Haskell
in the long run that I could sometimes write the library and solve the
original problem in less time than it took to just solve the original
problem in Python or OCaml.  Obviously this doesn't always hold.  But

(Continue reading)

headers

Jonathan Cast | 10 Oct 23:31

Re: Interesting new user perspective

On Fri, 2008-10-10 at 17:13 -0400, Steve Schafer wrote:
> On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote:
> 
> >No reason not to expose newcomers to Haskell to the thing it does best.
> 
> This is precisely why newcomers flounder.

Newcomers flounder because they expect to keep programming the same way
they always have.  They should be (and *are*) taught better ways of
doing things.

> Yes, there certainly should be
> a "Haskell for experienced Java/C++ programmers : All of the advanced
> things you can do more easily than you ever thought possible." But
> that's not the way to attract Joe Programmer, who has never had to write
> a parser. Joe Programmer needs to be shown how Haskell can solve _his_
> problems. That might mean that you need to start with an extremely
> non-idiomatic Haskell program, one that has some of the "look and feel"
> of what programmers from other languages are comfortable with.

Try it.  I guarantee you, it'll turn people *off* Haskell, and they'll
never see your more elegant replacement, because they'll never read the
fifth chapter where you stop fighting the language and start working
with it.

jcc

headers

Martin DeMello | 10 Oct 23:43

Re: Interesting new user perspective

On Fri, Oct 10, 2008 at 2:31 PM, Jonathan Cast
<jonathanccast <at> fastmail.fm> wrote:
> On Fri, 2008-10-10 at 17:13 -0400, Steve Schafer wrote:
>> On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote:
>>
>> >No reason not to expose newcomers to Haskell to the thing it does best.
>>
>> This is precisely why newcomers flounder.
>
> Newcomers flounder because they expect to keep programming the same way
> they always have.  They should be (and *are*) taught better ways of
> doing things.

http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem
is a brilliant example of a common workaday problem found in other
languages, and solved elegantly in Haskell

martin

headers

Andrew Coppin | 10 Oct 23:57

Re: Interesting new user perspective

Martin DeMello wrote:
> http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem
> is a brilliant example of a common workaday problem found in other
> languages, and solved elegantly in Haskell
>   

Oh, hey, that's pretty nice...

headers

apfelmus | 11 Oct 19:34

Re: Interesting new user perspective

Andrew Coppin wrote:
> Martin DeMello wrote:
>> http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem
>>
>> is a brilliant example of a common workaday problem found in other
>> languages, and solved elegantly in Haskell
>>   
> 
> Oh, hey, that's pretty nice...

... and a solution to a problem that you souldn't have in the first
place. I mean, if you want to construct XML or SQL statements, you ought
to use an abstract data type that ensures proper nesting etc. and not a
simple string.

Regards,
apfelmus

headers

Iain Barnett | 11 Oct 21:30

Re: Re: Interesting new user perspective


On 11 Oct 2008, at 6:34 pm, apfelmus wrote:

> Andrew Coppin wrote:
>> Martin DeMello wrote:
>>> http://blog.moertel.com/articles/2006/10/18/a-type-based-solution- 
>>> to-the-strings-problem
>>>
>>> is a brilliant example of a common workaday problem found in other
>>> languages, and solved elegantly in Haskell
>>>
>>
>> Oh, hey, that's pretty nice...
>
> ... and a solution to a problem that you souldn't have in the first
> place. I mean, if you want to construct XML or SQL statements, you  
> ought
> to use an abstract data type that ensures proper nesting etc. and  
> not a
> simple string.

Do you have an example of what you mean?

Personally, I use stored procedures with a database as they protect  
from sql injection attacks (unless you write some really stupid  
procedures).

Iain

headers

Svein Ove Aas | 11 Oct 22:02

Re: Re: Interesting new user perspective

On Sat, Oct 11, 2008 at 9:30 PM, Iain Barnett <iainspeed <at> gmail.com> wrote:
>
> Personally, I use stored procedures with a database as they protect from sql
> injection attacks (unless you write some really stupid procedures).
>
Isn't this what parametrized queries are for?

headers

Iain Barnett | 11 Oct 22:15

Re: Re: Interesting new user perspective


On 11 Oct 2008, at 9:02 pm, Svein Ove Aas wrote:

> On Sat, Oct 11, 2008 at 9:30 PM, Iain Barnett <iainspeed <at> gmail.com>  
> wrote:
>>
>> Personally, I use stored procedures with a database as they  
>> protect from sql
>> injection attacks (unless you write some really stupid procedures).
>>
> Isn't this what parametrized queries are for?

they will also work (at least in MS SQL Server), but you'd lose some  
of the performance and organisational benefits.

And it stops people littering code with badly written SQL statements  
- at least I can keep track of the procedures! :)

Iain

headers

Andrew Coppin | 11 Oct 23:56

Re: Re: Interesting new user perspective

Svein Ove Aas wrote:
> On Sat, Oct 11, 2008 at 9:30 PM, Iain Barnett <iainspeed <at> gmail.com> wrote:
>   
>> Personally, I use stored procedures with a database as they protect from sql
>> injection attacks (unless you write some really stupid procedures).
>>
>>     
> Isn't this what parametrized queries are for?
>   

Yes. (And it also improves DB performance since it doesn't have to 
continually reparse the query and rebuild the query plan.)

Now consider dynamically constructing HTML and avoiding HTML injection 
attacks. There isn't an easy machine fix for that one.

headers

apfelmus | 12 Oct 20:24

Re: Interesting new user perspective

Iain Barnett wrote:
> apfelmus wrote:
>>> Martin DeMello wrote:
>>>>
>>>> http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem
>>>>
>>>> is a brilliant example of a common workaday problem found in other
>>>> languages, and solved elegantly in Haskell
>>
>> ... and a solution to a problem that you souldn't have in the first
>> place. I mean, if you want to construct XML or SQL statements, you ought
>> to use an abstract data type that ensures proper nesting etc. and not a
>> simple string.
> 
> Do you have an example of what you mean?

Ah, yes, let me explain.

Tom Moertel's post introduces two use cases, namely generating SQL
statements and HTML documents from a template and some parameters (the
latter are given as  String ). Representing all of them as String is
prone to bugs concerning escaping, so he uses a custom string type
instead, namely one that indicates whether it was an SQL statement or
HTML document. So far so good.

Now note that I kept saying "HTML document" or "SQL statement" instead
of "HTML string" or "SQL string" because, and that's my point, why on
earth would you want to think of them as strings in the first place? I
mean, a HTML document is a DOM-tree and an SQL statement is a logical
formula. Just like a Haskell module is a set of function, type and class

(Continue reading)

headers

Andrew Coppin | 11 Oct 23:57

Re: Re: Interesting new user perspective

apfelmus wrote:
> ... and a solution to a problem that you souldn't have in the first
> place. I mean, if you want to construct XML or SQL statements, you ought
> to use an abstract data type that ensures proper nesting etc. and not a
> simple string.
>   

Right. And if you have 25 KB of HTML data, you're *really* going to 
transform all of that into an abstract data type just to avoid injection 
problems, right?

headers

apfelmus | 13 Oct 08:43

Re: Interesting new user perspective

Andrew Coppin wrote:
> apfelmus wrote:
>> ... and a solution to a problem that you souldn't have in the first
>> place. I mean, if you want to construct XML or SQL statements, you ought
>> to use an abstract data type that ensures proper nesting etc. and not a
>> simple string.
>>   
> 
> Right. And if you have 25 KB of HTML data, you're *really* going to
> transform all of that into an abstract data type just to avoid injection
> problems, right?

Yes. "Just" an injection problem is an understatement. And its the
implementation of the abstract data type that determines how fast things
are. Who said that it may not simply be a newtyped String ?

Regards,
apfelmus

headers

Devin Mullins | 13 Oct 09:30

Re: Re: Interesting new user perspective

On Mon, Oct 13, 2008 at 08:43:48AM +0200, apfelmus wrote:
> Yes. "Just" an injection problem is an understatement. And its the
> implementation of the abstract data type that determines how fast things
> are. Who said that it may not simply be a newtyped String ?

I think the attraction to the SafeString example is that it's simple and
effective for the task at hand -- in other words, pragmatic. Suggesting
that in order to avoid HTML injection people re-read the HTML spec and
invent a complete ADT to represent all the little corner cases they
probably won't ever use is exactly the kind of answer that would scare
Joe Six-Pack Hockey Programmer away.

headers

apfelmus | 13 Oct 12:50

Re: Interesting new user perspective

Devin Mullins wrote:
> apfelmus wrote:
>> Yes. "Just" an injection problem is an understatement. And its the
>> implementation of the abstract data type that determines how fast things
>> are. Who said that it may not simply be a newtyped String ?
> 
> I think the attraction to the SafeString example is that it's simple and
> effective for the task at hand -- in other words, pragmatic. Suggesting
> that in order to avoid HTML injection people re-read the HTML spec and
> invent a complete ADT to represent all the little corner cases they
> probably won't ever use is exactly the kind of answer that would scare
> Joe Six-Pack Hockey Programmer away.

/me shrugs. Can't help it that HTML is crazily complex.

But what I wanted to say is not that you should create an algebraic data
type that exactly represents valid HTML but rather that the basic idea
underlying SafeString, namely using an abstract (≠ algebraic) data type
for HTML should be a no-brainer and the first thing to do.

To demonstrate, here's a 27 line HTML module. It's really simple, even
simple-minded and still bug-prone, yet it already eliminates escaping
and nesting bugs.

    module HTML (Html, Attr(..), toString, tag, text) where

    newtype Html = Html { toString :: String }

    data Attr = String := String

(Continue reading)

headers

Ryan Ingram | 13 Oct 15:30

Re: Re: Interesting new user perspective

Normally I agree with you, apfelmus, but here at least I have to differ!

On Mon, Oct 13, 2008 at 11:50 AM, apfelmus <apfelmus <at> quantentunnel.de> wrote:
>  *HTML> toString $ tag "b" [] [tag "i" [] [text "<>"], text "test"]
>  "<b><i>&lt;&gt;</i>test</b>"

I'd say the big problem is that your embedded language for describing
HTML is way more complex for a domain expert than

doc = renderHTML $(q "<b><i>#{v1}</i>#{v2}</b>")
   where
       v1 = "<>"
       v2 = "test"

which, while somewhat error-prone in the HTML string itself, is much
more likely to get used than an embedded language.  One thing that
"ideal in theory" solutions seem to miss out on a lot is usability;
SafeString seemed to strike a great balance there, which is why I
think it has been brought up as a great example of solving this
problem in the real world.

There's a reason why Ruby is taking off despite its complete lack of
safety; writing code using it is genuinely enjoyable and Rails solves
a lot of problems elegantly.  I wouldn't want to use it for a big
project; I have performance and reliability concerns, but attempts to
"ruby-ify" bits of Haskell where safety can be validated via a small
amount of inspection are welcome!

  -- ryan

(Continue reading)

headers

Niklas Broberg | 13 Oct 16:17

Re: Re: Interesting new user perspective

>  >  *HTML> toString $ tag "b" [] [tag "i" [] [text "<>"], text "test"]
>  >  "<b><i>&lt;&gt;</i>test</b>"
>
> I'd say the big problem is that your embedded language for describing
>  HTML is way more complex for a domain expert than
>
>  doc = renderHTML $(q "<b><i>#{v1}</i>#{v2}</b>")
>    where
>        v1 = "<>"
>        v2 = "test"

How about using Haskell Server Pages[1] and get both?

doc = <b><i><% v1 %></i><% v2 %></b>
  where
      v1 = "<>"
      v2 = "test"

No more error-prone than apfelmus' embedded language (it *is* an
embedded language), and no more complex to write than the SafeString
example (less in fact). And a lot more enjoyable than Ruby (ok, I
admit, that's not an objective statement).

Cheers,

/Niklas

[1] http://haskell.org/haskellwiki/HSP

headers

apfelmus | 14 Oct 11:51

Re: Interesting new user perspective

Ryan Ingram wrote:
> Normally I agree with you, apfelmus, but here at least I have to differ!

/me considers  map crushToPurée . filter disagrees  ;)

> On Mon, Oct 13, 2008 at 11:50 AM, apfelmus <apfelmus <at> quantentunnel.de> wrote:
>>  *HTML> toString $ tag "b" [] [tag "i" [] [text "<>"], text "test"]
>>  "<b><i>&lt;&gt;</i>test</b>"
> 
> I'd say the big problem is that your embedded language for describing
> HTML is way more complex for a domain expert than
> 
> doc = renderHTML $(q "<b><i>#{v1}</i>#{v2}</b>")
>    where
>        v1 = "<>"
>        v2 = "test"
>
> which, while somewhat error-prone in the HTML string itself, is much
> more likely to get used than an embedded language.  One thing that
> "ideal in theory" solutions seem to miss out on a lot is usability;

Ok, syntactic considerations.

Why again would I want to bother memorizing HTML syntax?

I know the Haskell syntax, in particular the space for function
application and lowercase identifiers for variables. I care little about
the myriad of other notations for function application and variables
that people have invented, for that's - in a sense - what all languages
boil down to. How is remembering more arcane syntax more usable?

(Continue reading)

headers

Andrew Coppin | 10 Oct 23:49

Re: Interesting new user perspective

Jonathan Cast wrote:
> Newcomers flounder because they expect to keep programming the same way
> they always have.

_Some_ newcommers flounder because they expect Haskell to be just 
another VB / C++ / Java / whatever. (Do we really want to encourage 
these people to be learning Haskell in the first place?) Others it seems 
flounder simply because Haskell completely changes almost all the rules 
about programming, and they end up not knowing which way is up. I have 
far more sympathy with these latter people.

As I say, teaching the language syntax and the standard library 
functions it's going to help much on its own. You need to give these 
people some idea of what the high-level game plan is. I think you need 
to show people that you can use Haskell to do normal, ordinary stuff 
before you start showing off the more exotic things. (Obviously, you 
need to choose your examples carefully. Anything moderately complex is 
probably going to be approached from a totally different angle in 
Haskell, so the parallel won't be as helpful.)

headers

Jonathan Cast | 11 Oct 00:07

Re: Interesting new user perspective

On Fri, 2008-10-10 at 22:49 +0100, Andrew Coppin wrote:
> Jonathan Cast wrote:
> > Newcomers flounder because they expect to keep programming the same way
> > they always have.
> 
> _Some_ newcommers flounder because they expect Haskell to be just 
> another VB / C++ / Java / whatever. (Do we really want to encourage 
> these people to be learning Haskell in the first place?)

Absolutely not.  That's my point.

> Others it seems 
> flounder simply because Haskell completely changes almost all the rules 
> about programming, and they end up not knowing which way is up.

Are you sure teaching I/O first (or starting with an ugly, unreadable
heavily imperative straight translation of C++/Perl/Ruby) is the best
way to help these people?

The Haskell community *is* committed to teaching people good functional
design.  You can see it every day on this list.  But I don't really see
the relevance here.

> I have 
> far more sympathy with these latter people.
> 
> As I say, teaching the language syntax and the standard library 
> functions it's going to help much on its own. You need to give these 
> people some idea of what the high-level game plan is.

(Continue reading)

headers

Mauricio | 13 Oct 19:02

Re: Interesting new user perspective

> _Some_ newcommers flounder because they expect Haskell to be just 
> another VB / C++ / Java / whatever. (Do we really want to encourage 
> these people to be learning Haskell in the first place?) (...)

I hope so. One of my most important motivations to try
Haskell was that I thought it was radically drived by
some ideas that were only beggining to show up in C++,
and I'm happy to know I was right :)

(And, really, I was scared by how much time is lost with
misinformed critics about other languages.)

My begginer problem: syntax was a *major* issue, and I
only could overcome it with a lot of love for this
language. The best reference I was able to find is this:

http://www.hck.sk/users/peter/HaskellEx.htm

and it's not exactly for begginers.

Best,
Maurício

headers

Ryan Ingram | 13 Oct 19:24

Re: Re: Interesting new user perspective

On Mon, Oct 13, 2008 at 6:02 PM, Mauricio <briqueabraque <at> yahoo.com> wrote:
> On Fri, Oct 10, 2008 at 10:49 PM, Andrew Coppin <andrewcoppin <at> btinternet.com> wrote:
>> _Some_ newcommers flounder because they expect Haskell to be just another
>> VB / C++ / Java / whatever. (Do we really want to encourage these people to
>> be learning Haskell in the first place?) (...)
>
> I hope so. One of my most important motivations to try
> Haskell was that I thought it was radically drived by
> some ideas that were only beggining to show up in C++,
> and I'm happy to know I was right :)

I would go further than that.  To Andrew's question, I say:

Yes, we want to encourage "these people" to learn Haskell.  We want to
smash all their expectations into tiny little pieces.  We want their
brains to explode.  And after that, we want to take what is left, pick
it up off the floor, and put it back in as something new and better!

People who didn't realize just what it was that they were getting
into, once they come around, tend to be even more vocal supporters
among their peers.  They've finally "gotten it" and want to share that
experience with others.

We just need to communicate that learning Haskell will make you a
better programmer, no matter what expectations you have going in.

  -- ryan

headers

Andrew Coppin | 13 Oct 19:38

Re: Re: Interesting new user perspective

Ryan Ingram wrote:
> I would go further than that.  To Andrew's question, I say:
>
> Yes, we want to encourage "these people" to learn Haskell.  We want to
> smash all their expectations into tiny little pieces.  We want their
> brains to explode.  And after that, we want to take what is left, pick
> it up off the floor, and put it back in as something new and better!
>
> People who didn't realize just what it was that they were getting
> into, once they come around, tend to be even more vocal supporters
> among their peers.  They've finally "gotten it" and want to share that
> experience with others.
>
> We just need to communicate that learning Haskell will make you a
> better programmer, no matter what expectations you have going in.
>   

Trouble is, certain programmers expect to master everything in 20 
seconds flat ("Learn C++ in 21 days", anyone?), and if they try to learn 
an "obscure" and "irrelevant" language like Haskell and don't "get it" 
in 20 seconds flat, they'll go "bah, stupid language" and move on. I'm 
pretty sure there's no way to simplify Haskell to the point where people 
can master it in 20 seconds, so these people are pretty much a lost cause.

Thus, I would concentrate my efforts on people who are actually willing 
to make the effort required to learn. Maybe that's just me...

headers

Jonathan Cast | 13 Oct 19:34

Re: Re: Interesting new user perspective

On Mon, 2008-10-13 at 18:38 +0100, Andrew Coppin wrote:
> Ryan Ingram wrote:
> > I would go further than that.  To Andrew's question, I say:
> >
> > Yes, we want to encourage "these people" to learn Haskell.  We want to
> > smash all their expectations into tiny little pieces.  We want their
> > brains to explode.  And after that, we want to take what is left, pick
> > it up off the floor, and put it back in as something new and better!
> >
> > People who didn't realize just what it was that they were getting
> > into, once they come around, tend to be even more vocal supporters
> > among their peers.  They've finally "gotten it" and want to share that
> > experience with others.
> >
> > We just need to communicate that learning Haskell will make you a
> > better programmer, no matter what expectations you have going in.
> >   
> 
> Trouble is, certain programmers expect to master everything in 20 
> seconds flat ("Learn C++ in 21 days", anyone?), and if they try to learn 
> an "obscure" and "irrelevant" language like Haskell and don't "get it" 
> in 20 seconds flat, they'll go "bah, stupid language" and move on. I'm 
> pretty sure there's no way to simplify Haskell to the point where people 
> can master it in 20 seconds, so these people are pretty much a lost cause.
> 
> Thus, I would concentrate my efforts on people who are actually willing 
> to make the effort required to learn. Maybe that's just me...

See, now *this* I agree with completely.

(Continue reading)

headers

Anton Tayanovskyy | 13 Oct 23:14

Re: Re: Interesting new user perspective

If you want to make Haskell more widely used, do pick a name for
Haskell Prime that starts with an A. I first heard of Haskell when
exploring the list of computer languages that Gedit could highlight.
Just imagine going through all those A,B,C,D,E,F,G before I came to
Haskell.

Those programmers who just want to earn their bread will not care if
Haskell tutorials are relevant or irrelevant. They would rather ask
how much a Haskell job pays and how many positions are there. The
Haskell audience is more likely to be people who are either interested
in programming languages in general or greatly dissatisfied with those
languages they work with. For them, the stranger the better.

My brain hurt a lot at first because of the compiler error messages
but I liked the challenge.

>> Trouble is, certain programmers expect to master everything in 20
>> seconds flat ("Learn C++ in 21 days", anyone?)

Just couldn't resist:

http://norvig.com/21-days.html

--A

headers

Claus Reinke | 13 Oct 23:37

Re: Re: Interesting new user perspective

> If you want to make Haskell more widely used, do pick a name for
> Haskell Prime that starts with an A. I first heard of Haskell when
> exploring the list of computer languages that Gedit could highlight.
> Just imagine going through all those A,B,C,D,E,F,G before I came to
> Haskell.

That is a simple sorting error in Gedit, just submit a patch. As 
professor 'iggins pointed out long ago, speakers of the English
language drop their 'H's anyway, so 'askell should come long
before 'A'.

Couldn't resist not resisting,-)
Claus

headers

Tommy M. McGuire | 10 Oct 22:00

Re: Interesting new user perspective

Iain Barnett wrote:
> On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote:
> 
>>  I think it's just the teaching of the language that needs work, not 
>> so much the language itself.
> 
> 
> As a newer user myself, I'd agree with this statement. I'd like to see 
> far more mundane tasks solved in tutorials. 

I would agree as well.  My own flailings led to Software Tools in 
Haskell[1], which taught me more about how to actually do things[2] than 
the textbooks that I have read.

> Haskell is can obviously do some really interesting things, but 
> constantly having wikipedia open so I can look up whatever mathematical 
> doodah has just been mentioned can get draining. Even Real World Haskell 
> suffers a bit from this.

The mathematical doodahs are *very* useful, much more so than any other 
language I have used, but it helps to have some kind of foundation to 
understand how and why.  I am frequently reminded of a "How to Draw" 
page from the Tick[3] comic, which went something like:

Step 1: Draw a large oval.
Step 2: Draw the Tick holding the oval.

On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote:
 > Parsec makes recursive descent parsers as easy to use in Haskell as
 > regexps are in Perl.  No reason not to expose newcomers to Haskell to

(Continue reading)

headers

Jonathan Cast | 10 Oct 22:28

Re: Interesting new user perspective

On Fri, 2008-10-10 at 15:00 -0500, Tommy M. McGuire wrote:
> On 10 Oct 2008, at 7:05 pm, Jonathan Cast wrote:
>  > Parsec makes recursive descent parsers as easy to use in Haskell as
>  > regexps are in Perl.  No reason not to expose newcomers to Haskell to
>  > the thing it does best.
> 
> Is it wrong to use Parsec to parse regular expressions for a really 
> simple regex engine[4]?

That looks about right.  And, as you point out, it's easier to
understand than a direct parser.  I would also re-code the engine itself
in Parsec, though (probably using a finite state machine implementation,
which (I think; I haven't tried it yet) would end up looking rather like
a manual unfolding along the lines of Koen Claessen's parallel parsing
process [1]).

jcc

[1] http://www.cs.chalmers.se/~koen/Papers/parsing-pearl.ps

headers

Justin Bailey | 10 Oct 22:38

Re: Interesting new user perspective

On Fri, Oct 10, 2008 at 1:00 PM, Tommy M. McGuire <mcguire <at> crsr.net> wrote:
> I would agree as well.  My own flailings led to Software Tools in
> Haskell[1], which taught me more about how to actually do things[2] than the
> textbooks that I have read.

I found it really hard to just look up the syntax of the language when
I had a question (e.g. how does case work?). I haven't advertised it
much yet, but I created a PDF cheatsheet to help in those situations.
It's on hackage[1], available via 'cabal install cheatsheet' or direct
download. I'd be interested to hear what you think.

Justin

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet

headers

Jason Dusek | 10 Oct 22:48

Re: Interesting new user perspective

Tommy M. McGuire <mcguire <at> crsr.net> wrote:
> Is it wrong to use Parsec to parse regular expressions for a
> really simple regex engine[4]?

  I sometimes think it is better, from a maintainability
  standpoint, to just use Parsec for all that stuff and forget
  about regular expressions. There are many proficient
  application programmers and system programmers who are
  unfamiliar with regexen which, even if they weren't arcane,
  are still so balkanized.

  At first, I found writing Parsec for argument/option
  processing to be almost offensive -- so many lines for so
  little action! -- but it's clear as day to a lot of people and
  that is a real mark in its favor.

--
_jsn

headers

Don Stewart | 10 Oct 22:50

Re: Interesting new user perspective

jason.dusek:
> Tommy M. McGuire <mcguire <at> crsr.net> wrote:
> > Is it wrong to use Parsec to parse regular expressions for a
> > really simple regex engine[4]?
> 
>   I sometimes think it is better, from a maintainability
>   standpoint, to just use Parsec for all that stuff and forget
>   about regular expressions. There are many proficient
>   application programmers and system programmers who are
>   unfamiliar with regexen which, even if they weren't arcane,
>   are still so balkanized.
> 
>   At first, I found writing Parsec for argument/option
>   processing to be almost offensive -- so many lines for so
>   little action! -- but it's clear as day to a lot of people and
>   that is a real mark in its favor.
> 

And for true regular expression problems, we have regex libs, dozens.

They're just not the only tool for text manipulation, and Haskell makes
constructing true parsers just as easy, so may as well do it right, and
do it well.

-- Don

headers

Jason Dusek | 10 Oct 22:51

Re: Interesting new user perspective

Tommy M. McGuire <mcguire <at> crsr.net> wrote:
> The mathematical doodahs are *very* useful, much more so than
> any other language I have used, but it helps to have some kind
> of foundation to understand how and why. I am frequently
> reminded of a "How to Draw" page from the Tick[3] comic, which
> went something like:

  http://i36.tinypic.com/wlcghf.jpg

--
_jsn

headers

Iain Barnett | 10 Oct 23:24

Re: Interesting new user perspective


On 10 Oct 2008, at 9:00 pm, Tommy M. McGuire wrote:

> Iain Barnett wrote:
>> On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote:
>>>  I think it's just the teaching of the language that needs work,  
>>> not so much the language itself.
>> As a newer user myself, I'd agree with this statement. I'd like to  
>> see far more mundane tasks solved in tutorials.
>
> I would agree as well.  My own flailings led to Software Tools in  
> Haskell[1], which taught me more about how to actually do things[2]  
> than the textbooks that I have read.

That looks like a really useful resource, thanks. I've just read the  
introduction and that is the same experience I've been having,  
(ending up with bits of programs and nothing really practical). I'm  
currently trying to write some simple games in Haskell, and learning  
a lot along the way.

>
>> Haskell is can obviously do some really interesting things, but  
>> constantly having wikipedia open so I can look up whatever  
>> mathematical doodah has just been mentioned can get draining. Even  
>> Real World Haskell suffers a bit from this.
>
> The mathematical doodahs are *very* useful, much more so than any  
> other language I have used, but it helps to have some kind of  
> foundation to understand how and why.  I am frequently reminded of  
> a "How to Draw" page from the Tick[3] comic, which went something

(Continue reading)

headers

Jonathan Cast | 10 Oct 23:26

Re: Interesting new user perspective

On Fri, 2008-10-10 at 22:24 +0100, Iain Barnett wrote:
> On 10 Oct 2008, at 9:00 pm, Tommy M. McGuire wrote:
> 
> > Iain Barnett wrote:
> >> On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote:
> >>>  I think it's just the teaching of the language that needs work,  
> >>> not so much the language itself.
> >> As a newer user myself, I'd agree with this statement. I'd like to  
> >> see far more mundane tasks solved in tutorials.
> >
> > I would agree as well.  My own flailings led to Software Tools in  
> > Haskell[1], which taught me more about how to actually do things[2]  
> > than the textbooks that I have read.
> 
> That looks like a really useful resource, thanks. I've just read the  
> introduction and that is the same experience I've been having,  
> (ending up with bits of programs and nothing really practical). I'm  
> currently trying to write some simple games in Haskell, and learning  
> a lot along the way.
> 
> >
> >> Haskell is can obviously do some really interesting things, but  
> >> constantly having wikipedia open so I can look up whatever  
> >> mathematical doodah has just been mentioned can get draining. Even  
> >> Real World Haskell suffers a bit from this.
> >
> > The mathematical doodahs are *very* useful, much more so than any  
> > other language I have used, but it helps to have some kind of  
> > foundation to understand how and why.  I am frequently reminded of  
> > a "How to Draw" page from the Tick[3] comic, which went something

(Continue reading)

headers

Andrew Coppin | 10 Oct 23:40

Re: Interesting new user perspective

Iain Barnett wrote:
> On 10 Oct 2008, at 9:50 pm, Don Stewart wrote:
>>  Haskell makes
>> constructing true parsers just as easy,
>>
>
> You're not speaking for me there! :)  I really like regex. It's a 
> domain specific functional language, so why rewrite the wheel?

Because it's a wheel that looks like the wrong end of a dog? :-}

headers

Jonathan Cast | 10 Oct 23:46

Re: Interesting new user perspective

On Fri, 2008-10-10 at 22:40 +0100, Andrew Coppin wrote:
> Iain Barnett wrote:
> > On 10 Oct 2008, at 9:50 pm, Don Stewart wrote:
> >>  Haskell makes
> >> constructing true parsers just as easy,
> >>
> >
> > You're not speaking for me there! :)  I really like regex. It's a 
> > domain specific functional language, so why rewrite the wheel?
> 
> Because it's a wheel that looks like the wrong end of a dog? :-}

  identifier = lexeme $ match "[[:lower:]_][[:alphanum:]_]*"

(pretending match :: String -> Parser String is a regex engine).

vs.

  identified = lexeme $ do
    c <- satisfy isLower <|> satisfy (=='_')
    s <- many $ satisfy isAlphaNum <|> satisfy (=='_')
    return (c:s)

I'm not sure I follow you here...

jcc

headers

Sterling Clover | 11 Oct 01:54

Re: Interesting new user perspective

On Oct 10, 2008, at 5:46 PM, Jonathan Cast wrote:

>
>   identifier = lexeme $ match "[[:lower:]_][[:alphanum:]_]*"
>
> (pretending match :: String -> Parser String is a regex engine).
>
> vs.
>
>   identified = lexeme $ do
>     c <- satisfy isLower <|> satisfy (=='_')
>     s <- many $ satisfy isAlphaNum <|> satisfy (=='_')
>     return (c:s)

lexeme $ (:) <$> (lowerChar <|> char '_')  <*> (many $ alphaNum <|>  
char '_') ?

or (since we're not really talking about full fledged parsers that  
need lexemes here or such, but usually interpreting a single string,  
otherwise regexes will quickly become atrocious)

foo (x:xs)  | isLower x || x == '_', (xs', rest) <- break  
alphaOrUnder xs = Just (x : xs', rest)
                   | otherwise = Nothing
   where alphaOrUnder = liftM2 (||) isAlphaNum (=='_')
foo [] = Nothing

A bit more verbose, sure, but operating on text functionally makes it  
really easy to reason about what your parser is actually doing,  
unlike the mysteries of a regex.

(Continue reading)

headers

Simon Michael | 10 Oct 23:43

Re: Interesting new user perspective

> [4] http://www.crsr.net/Programming_Languages/SoftwareTools/ch6.html 

Hi Tommy,

I had never seen this before. It nicely fills a gap, and I really like 
the format and the writing. Bookmarked. Thanks!

-Simon

headers

Ryan Ingram | 11 Oct 12:38

Re: Interesting new user perspective

If you want quick examples of idiomatic haskell including stdin/stdout
I/O, I like this page:
    http://www.haskell.org/haskellwiki/Simple_unix_tools

  -- ryan

On Fri, Oct 10, 2008 at 7:08 PM, Iain Barnett <iainspeed <at> gmail.com> wrote:
> On 9 Oct 2008, at 9:33 pm, Andrew Coppin wrote:
>
>>  I think it's just the teaching of the language that needs work, not so
>> much the language itself.
>
>
> As a newer user myself, I'd agree with this statement. I'd like to see far
> more mundane tasks solved in tutorials. The number of times building a
> parser or generating prime number is used as an example is out of proportion
> to the times you'd use these things[1]. Just simple, *really* easy things
> would be better. Maybe it's just me, but if I wanted to learn perl or ruby
> or python or C# I'm not sure I'd ever see a _tutorial_ containing a prime
> number.
>
> Haskell is can obviously do some really interesting things, but constantly
> having wikipedia open so I can look up whatever mathematical doodah has just
> been mentioned can get draining. Even Real World Haskell suffers a bit from
> this.
>
>
> Iain
>
>

(Continue reading)

headers

Donn Cave | 11 Oct 03:31

Re: Interesting new user perspective

Quoth John Goerzen <jgoerzen <at> complete.org>:

| Uh... yes.  Opening and closing files, command-line parsing, etc --
| needed by almost every program.  Aside from some very simple
| stdin-to-stdout filters, it is difficult to imagine a program where
| you don't need to open a file!

That's how it seems to me, too, and moreover maybe the most generally
recognizable API.  With a GUI or a database, you're going to need to
present a fair amount of background to just about everyone, but files,
command lines etc. are common to nearly every programming language.
If the virtues of Haskell can't be presented in this context, then maybe
it isn't such a generally useful language that people ought to be worried
about learning it.

	Donn Cave, donn <at> avvanta.com