Yep, its similar to the elevator pitch, but a little shorter, and mentions why as a programmer this is worth your time. I'm not sure "monadic effects" is terribly motivating for someone who's heard about Haskell, and just wants to get things done faster, and more reliably -- which is really what Haskell can be about. -- Don wagner.andrew:

Wasn't this the point of the "elevator speech" thread a few weeks ago? Saying in 30 seconds why haskell is good and what it can do for you?

On 10/4/07, Don Stewart wrote:

...

It was raised at CUFP today that while Python has:

Python is a dynamic object-oriented programming language that can be used for many kinds of software development. It offers strong support for integration with other languages and tools, comes with extensive standard libraries, and can be learned in a few days. Many Python programmers report substantial productivity gains and feel the language encourages the development of higher quality, more maintainable code.

With the links from the start about using Python for various purposes, along with reassuring text about licenses and so on.

Note its all about how it can help you.

The Haskell website has the rather strange motivational text:

Haskell is a general purpose, purely functional programming language featuring static typing, higher order functions, polymorphism, type classes, and monadic effects. Haskell compilers are freely available for almost any computer.

Which doesn't say why these help you.

Any suggestions on a 2 or 3 sentence spiel about what's available?

Here's some quick points:

General purpose: applications from OS kernels to compilers to web dev to ... Strong integration with other languages: FFI, and FFI binding tools Many developer tools: debugger, profiler, code coverage, QuickCheck Extensive libraries: central library repository, central repo hosting Productivity, robustness, maintainability: purity, type system, etc Parallelism!

-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Henning Thielemann wrote:

...

...

...

Productivity, robustness, maintainability: purity, type system, etc. Parallelism!

'type system' is something where C derivatives and scripting languages are weak - but their users count this as advantage.

Rarely (maybe in the 70's but not since C89). They count as an advantage simplicity, portability and efficiency. If you can provide a better type system to C while keeping these points, you are welcome. Still, it is easy to make your code strongly typed in C with some discipline.

I want to raise the question again, whether it is reasonable to move convinced C and Perl programmers to Haskell - They will want to write C and Perl style programs using Haskell.

Not necessary. I am coming from C/C++ and I use Haskell for what I like it, that is functional programming.

I think it is better to attract the people who find 'filter' and 'map' good in Python and want to get to know the original language.

filter and map exist also in non functional languages. lambda and composition are much more uncommon outside the FPL world and much more difficult to 'emulate'.

On Thu, 4 Oct 2007, Don Stewart wrote:

...

Yep, its similar to the elevator pitch, but a little shorter, and mentions why as a programmer this is worth your time.

I'm not sure "monadic effects" is terribly motivating for someone who's heard about Haskell, and just wants to get things done faster, and more reliably -- which is really what Haskell can be about.

My experience is, that 'purely functional' made me curious because I wanted a nice, elegant language which is not cluttered with much patches. 'Monadic effects' sounded strange and made me even more curious.

Exactly the same for me but I prefer arrows to monads ;-) BTW, I do not understand why Arrow does not have a delay operator which would store its input and return its previous input. This would be quite helpful to describe signal processing and control system with SF (this question came to mind while reading the draft of H.Liu and P.Hudak on space leaks). What bother me about Haskell is that unfortunately I cannot use it in my work (numerical analysis) because of its lack of _efficiency_ and to a lesser extend of stability and portability. Despite that I am pretty sure that it will be solved in some future. a+, ld.

Henning Thielemann wrote:

On Fri, 5 Oct 2007, Laurent Deniau wrote:

...

Henning Thielemann wrote:

...

...

...

...

Productivity, robustness, maintainability: purity, type system, etc. Parallelism!

'type system' is something where C derivatives and scripting languages are weak - but their users count this as advantage.

Rarely (maybe in the 70's but not since C89). They count as an advantage simplicity, portability and efficiency. If you can provide a better type system to C while keeping these points, you are welcome. Still, it is easy to make your code strongly typed in C with some discipline.

If this would be true,

it is true and a good practice.

they would have switched to Modula II quickly ...

Everybody is free to move from one language to another but Ada could be a more attractive target.

I know that C programmers also like the concise/cryptic/inconsistent syntax.

Syntax is often a matter of taste. Every languages look cryptic for unfamiliar people. Haskell has itself some conventions in notation which allows concise coding. Do you have an example of syntax inconsistency in C? regards, ld.

On Oct 5, 2007, at 12:33 , Henning Thielemann wrote:

http://www.henning-thielemann.de/CHater.html#CvsM3_ControlFlow

I can has English? :) If the first large table is any indication, though, we may need to define "inconsistent". C syntax shown there is quite consistent; what it isn't, is designed to keep humans from making certain kinds of mistakes. I'm rather mixed on that goal: on the one hand, C does attract certain errors due to its syntax, but on the other, a language designed to coddle the programmer also tends to keep the programmer from doing useful things. (What's the last practical application you've seen in Logo? Or un-extended Pascal?) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brandon S. Allbery KF8NH wrote:

I can has English? :)

This comment inspired what could be either the beginning of an infectious Haskell recruitment campaign, or just a sign that some of us are mad. I present the lambdacats: http://arcanux.org/lambdacats.html -- Alex Tarkovsky

On Sat, Oct 06, 2007 at 01:26:18PM -0500, Alex Tarkovsky wrote:

...and the silliness continues:

In which case: http://pics.livejournal.com/resiak/pic/00019kx6/ Will

Alex Tarkovsky wrote:

Brandon S. Allbery KF8NH wrote:

...

I can has English? :)

This comment inspired what could be either the beginning of an infectious Haskell recruitment campaign, or just a sign that some of us are mad. I present the lambdacats:

http://arcanux.org/lambdacats.html

The above site is now blogified, with RSS 2.0 feed madness: http://arcanux.org/lambdacats-feed.xml -- Alex Tarkovsky

Brent Yorgey wrote:

Aren't you going to make one featuring a "catamorphism"? =)

Done, thanks for the contribution! ;) -- Alex Tarkovsky

On 10/9/07, Henning Thielemann wrote:

On Tue, 9 Oct 2007, Alex Tarkovsky wrote:

...

Brent Yorgey wrote:

...

Aren't you going to make one featuring a "catamorphism"? =)

Done, thanks for the contribution! ;)

I wish concat or concatMap :-)

ask and ye shall receive! =) http://wso.williams.edu/~byorgey/concatMap.png

On 10/9/07, Andrew Coppin wrote:

Brent Yorgey wrote:

...

On 10/9/07, *Henning Thielemann* mailto:lemming@henning-thielemann.de> wrote:

I wish concat or concatMap :-)

ask and ye shall receive! =)

http://wso.williams.edu/~byorgey/concatMap.png http://wso.williams.edu/%7Ebyorgey/concatMap.png

Where do you guys find so many strange cat pictures?!

well, I don't know where everyone else finds theirs, but I found mine on flickr. It turns out that cat owners with cameras are physically unable to resist uploading pictures of their cats in every imaginable situation. All you have to do is type something like 'cat banana' or 'cat map' into the search field, and voila! -Brent

On 09/10/2007, Alex Tarkovsky wrote:

Brent Yorgey wrote:

...

Aren't you going to make one featuring a "catamorphism"? =)

Done, thanks for the contribution! ;)

Goes to look... ...oh, very impressive! ;-) Lolcats seem to have reached a terrifying new nadir. D.

catamorphism:

On 10/4/07, Don Stewart wrote:

...

It was raised at CUFP today that while Python has:

Python is a dynamic object-oriented programming language that can be used for many kinds of software development. It offers strong support for integration with other languages and tools, comes with extensive standard libraries, and can be learned in a few days. Many Python programmers report substantial productivity gains and feel the language encourages the development of higher quality, more maintainable code.

With the links from the start about using Python for various purposes, along with reassuring text about licenses and so on.

Note its all about how it can help you.

The Haskell website has the rather strange motivational text:

Haskell is a general purpose, purely functional programming language featuring static typing, higher order functions, polymorphism, type classes, and monadic effects. Haskell compilers are freely available for almost any computer.

Which doesn't say why these help you.

Any suggestions on a 2 or 3 sentence spiel about what's available?

Here's some quick points:

General purpose: applications from OS kernels to compilers to web dev to ... Strong integration with other languages: FFI, and FFI binding tools Many developer tools: debugger, profiler, code coverage, QuickCheck Extensive libraries: central library repository, central repo hosting Productivity, robustness, maintainability: purity, type system, etc Parallelism!

Can't we embrace the power of 'and'? It's wonderful that Haskell is seeing more practical use, but we shouldn't forget the foundations, either. Maybe we should put your second description first, and *then* have a paragraph saying, "and, for those who know what these are, polymorphism, monadic effects, etc."? Only describing Haskell in terms of software engineeering doesn't seem right to me.

Yes, I think that's the best step. Combine both why you'd use it, with what unique features enable this. -- Don

On Oct 5, 2007, at 1:59 AM, Bayley, Alistair wrote:

So the question becomes: do you want to attract/seduce this kind of programmer? Let's assume the answer is yes :-)

Hmm...

... Then what sort of language should you use in your promotional paragraph? I don't think "polymorphism", "monads/monadic effects", "higher order functions", and even "type classes" should be used. These terms will be universally unfamiliar to the target audience, and will alienate them.

Maybe. Good. Some readers will say to themselves `this language appears to have many unfamiliar features ... I must look into this!' At this point, these are only ones who are going to thrive anyway. From what I've seen, the greatest hurdle is the features that ARE familiar, particularly strong static typing. Everyone knows static typing from Pascal, C, C++, Java ... know what I'm saying? If there's some way to defeat this false recognition, that should help a lot. Or maybe that's good too, for more survivor self selection. Maybe a good slogan would be `like LISP, but with strong static typing!' Donn Cave, donn@drizzle.com

On 2007-10-05, Peter Verswyvelen wrote:

But where is the great IDE Haskell deserves??? :-) Seriously, 99% of the programmers I know don't want to look at it because when they see Emacs or VIM, they say "what the f*ck????, I don't want to go back to the stone age". If you want to attract more people that are inside the "imperative-OO-with-nice-IDE-blob", create a great looking and functional IDE.

Bluntly, I don't see why the Haskell community needs those sorts of programmers. I like Haskell with a big enough community to have useful libraries, but a small enough community such that the language can readily evolve and serve as a useful research platform.

An IDE that integrates the existing tools. That shows you graphical pictures of the graph rewriting process,

There is a tool that does this for a Haskell dialect.

potential space leaks,

That's a hard problem.

profiling bottlenecks, etc.

I'm not entirely sure what you mean here, but people are researching good ways of profiling and presenting the results to programmers.

Heck, why not introduce pictures as symbols and values, as in DrScheme.

Or as in Mathematica 6, to be a bit more mainstream.

Or UNICODE fonts.

GHC already supports UTF-8. Vim and Emacs already support UTF-8. Done. -- Aaron Denney -><-

On 2007-10-05, Aaron Denney wrote:

On 2007-10-05, Peter Verswyvelen wrote:

...

But where is the great IDE Haskell deserves??? :-) Seriously, 99% of the programmers I know don't want to look at it because when they see Emacs or VIM, they say "what the f*ck????, I don't want to go back to the stone age". If you want to attract more people that are inside the "imperative-OO-with-nice-IDE-blob", create a great looking and functional IDE.

Bluntly, I don't see why the Haskell community needs those sorts of programmers. I like Haskell with a big enough community to have useful libraries, but a small enough community such that the language can readily evolve and serve as a useful research platform.

This is not say that nice tools aren't useful or that we should be less than welcoming to anyone interested in Haskell. But the best tool that makes a language more useful is the language itself. If I don't have as much boilerplate all over the place, then I don't need a tool that goes and finds all this boilerplate and changes it. When the language manages memory for me, I don't need valgrind. If I write a program that can't crash, I don't need crash-analysis tools. If my programs minimize state-change, I have less need of traditional debuggers with watchpoints and breakpoints. If my functions are guaranteed by the compiler to be pure, /semantic/ debuggers, that algebraicly manipulate definitions and can iteratively zero in on meanings being wrong rather than just implementations "glitching" become useable. When I can autogenerate test data for my functions based solely on the type, testing can be much easier. We already have a lot of nice tools that do what we want. Slapping a GUI on them and maintaining integration while they're evolving is less useful to me than programmers exploring other additional useful tools. -- Aaron Denney -><-

On 10/5/07, Don Stewart wrote:

It has been suggested we could just sit DrScheme in front of ghc/ghci. Anyone with experience who'd like to step up for this?

Note that there's a DrOCaml, which might be a good starting point. martin

On 05/10/2007, Andrew Coppin wrote:

...

So the question becomes: do you want to attract/seduce this kind of programmer? Let's assume the answer is yes :-)

Um... that assumpion troubles me. ... I think if we want to get anywhere we need to look at targeting people whom Haskell actually has something to offer. Now, if I could just figure out who those are... :-/

And: On 05/10/2007, Jonathan Cast wrote:

On Fri, 2007-10-05 at 20:19 +0000, Aaron Denney wrote:

...

On 2007-10-05, Peter Verswyvelen wrote:

...

If you want to attract more people that are inside the "imperative-OO-with-nice-IDE-blob", create a great looking and functional IDE.

Bluntly, I don't see why the Haskell community needs those sorts of programmers.

Hear, hear. At the company I work for, all the code is perl/web development --- and we wouldn't dream of hiring one of those programmers.

I posed the question: do we want to attract this kind of programmer? My personal opinion, which some of you obviously don't share, is yes. It isn't about whether or not the Haskell community needs those sorts of programmers. It's whether or not those sorts of programmers need Haskell. For me, a large part of Haskell's attraction are the features which reflect good engineering practice: strong, static type checking; purely functional code; good FFI. It should be easier to write simple, reliable software in Haskell than in most other languages; IMO, getting the unwashed hordes to use Haskell would be a great improvement in software industry productivity. I realise that a large influx of mediocre programmers will have a negative effect on the community, but is that a reasonable price to pay? I understand that may of you love a small, intimate, high-quality community, but perhaps that will have to evolve if we really want to conquer the world. Alistair

On 08/10/2007, Henning Thielemann wrote:

You cannot turn any programmer into a disciplined programmer just by giving him a well designed language. I you try so, they will not like to use that language, will leave that language as soon as possible or they try to adapt the language to their style of programming.

Well, I wasn't suggesting you'll create great programmers overnight, but you might expect that their appreciation of good design might improve after some Haskell exposure. Also, Haskell simply doesn't support some of the things that are common causes of errors in the enterprisey-language world. I recall reading something about one of the most common causes of errors in novice programs being type errors (presumably, once they'd got the program to compile i.e. there were no syntactic errors). And I'm under the (possibly mistaken) impression that some of the common errors non-novice programmers make are aliasing bugs, and/or use of global variables. Does anyone have references to studies confirming (or refuting) this?

People who are used to weak typing will use a type like data Number = Int Int | Float Float | ... for numbers, or even String for everything, they will use numbers, where enumerations are more appropriate and so on.

I think that the ease with which you can create a new type in Haskell (and derive useful classes like Enum, Show, etc) makes it more likely that a programmer will use an appropriate domain-specific type, rather than just reuse String, Int, or Float.

In my experience only the other way round works: Let people use C, Perl and Python until they find their programs unmaintainable. Then they will become interested in style and discipline and programming languages which _support_ good style.

Well, yes. Or have them learn Haskell, and *then* C/C#/C++/Java/Perl etc, and see if the experience for those languages is as good. I like to think they'll come running back to Haskell's warm bosom. Alistair

On 10/8/07, Henning Thielemann wrote:

Thus, what happens today? People ask Haskell-Cafe how to implement global variables and they are advised to use IORefs and unsafePerformIO, although the better answer is: "Why do you want to do this?" Even "Tackling the awkward squad" considers unsafePerformIO an acceptable tool for handling global configuration files.

One problem here is that the Haskell-style alternatives to global parameters aren't as convenient as to use. We should consider stealing Agda's module system for Haskell 2.0. -- Dave Menendez http://www.eyrie.org/~zednenem/

On 2007-10-10, Andrew Coppin wrote:

(Indeed, the number of times my Haskell programs have locked up due to me accidentally writing let x = foo x...)

For me, that's small. I have seen useful program not lock up that depend on let x = foo x though. -- Aaron Denney -><-

On 9 Oct 2007, at 9:10 am, jerzy.karczmarczuk@info.unicaen.fr wrote:

* Scheme is very different from what we practice (C++, Fortran, etc., you know the song...) It may slow down the *adaptation* of students. They *will need* all that imperative stuff you hate. But, as a first language, the FLs condition the young minds in a way we do not appreciate.

The only empirical evidence I'm aware of about this comes from Monash University, Caulfield campus, in Melbourne, Australia. (A former polytechnic amalgamated with a university.) If memory serves me correctly, students there used to do 3 semesters of COBOL. Rob Hagan changed this to 1 semester of Scheme followed by 1 semester of COBOL. (It is about 10 years since I last saw him, so my memory is getting fuzzy. I'm sure about 1 semester of Scheme.) The interesting thing is that with *less* time spent on COBOL, his students mastered *more* COBOL. So in the one case that I have any personal knowledge of, learning Scheme first *speeded up* the adaptation of students. Three things may be of particular interest here. 1. Scheme has set! and vector-set!, so it is closer to the imperative world than Haskell; not least in I/O. 2. Rob Hagan put a lot of effort into providing a single-stepper on PCs that showed exactly what a Scheme program was doing. Here again, insight gained into execution of strict functional code can be expected to carry over to insight into the execution of C, or Fortran, or Java. Haskell would not help here. 3. Rob Hagan encouraged (no, in some cases *required*) students to include test cases in their source files and had a simple test harness for using them. Incredibly easy to use. There *is* a Haskell equivalent of this, namely QuickCheck.

There is no lazy untyped language.

Yes there is. S. There is an open source version of S called R. S(R) is dynamically typed. Function arguments are *always* passed unevaluated. It looks imperative, but if you ignore S4 objects it's basically functional. An assignment like a[i] <- x is defined to have the meaning a <- "[<-"(a, i, x) and if you have previously done b <- a, b will not be changed. S has been enormously successful in its application area (statistics programming).

On 10 Oct 2007, at 12:49 pm, jerzy.karczmarczuk@info.unicaen.fr wrote:

No, I am sorry, I know a little bit "R". This is not a functional language. There is some laziness (which looks a bit like macro-processing), sure.

There is no macro processing in R (or S).

The manual speaks about promises and about forcing them. But, at the same time we read that the call by value IS the protocol.

That is a misreading. Paragraph 2 of 4.3.3 says The semantics of invoking a function in R argument are call-by-value. ... But that is NOT to be read as "strict", but as contrasting with "call-by-reference". The very next paragraph makes this clear: R has a form of lazy evaluation of function arguments. Arguments are not evaluated until needed. It is important to realise that i some cases the argument will never be evaluated. ... A promise is forced when its value is needed. "Promises" in R are part of the underlying implementation; they are not (as in Scheme) a data type that the programmer can ever see or deal with. They are, in fact, just the same as unevaluated arguments in Haskell.

And the language is impure, with reassignments.

You were happy enough with Scheme. And you didn't say that there were no *pure* lazy dynamically typed languages, only that there were no lazy dynamically typed languages. If you think of R as a lazy and somewhat purer Scheme with lots of number-crunching support and C-like syntax, you won't go far wrong.

I don't see how to make co-inductive constructions, infinite streams, etc. (Perhaps I didn't hard enough?...)

I don't know what co-inductive constructions are. At first sight it looks to be very easy to make infinite streams in R, but it isn't, for an interesting reason. R doesn't evaluate function *arguments*, but it does fully evaluate function *results*, so that returning something that hasn't been fully evaluated requires you to return a function. Fortunately, R is a higher order language (S isn't) so any stream implementation in Scheme has a natural analogue in R. Can we agree that the existence of R shows that a practically useful programming language with dynamic typing and lazy argument evaluation is possible, and that it isn't quite what you had in mind because it evaluates function results in full?

On 11 Oct 2007, at 1:00 pm, jerzy.karczmarczuk@info.unicaen.fr wrote:

An anonymous called ok writes:

I am not anonymous. That is my login and has been since 1979.

...

jerzy.karczmarczuk wrote [about "R"]:

...

... This is not a functional language. There is some laziness (which looks a bit like macro- processing), sure. There is no macro processing in R (or S).

I know I've been superficial, but, please, *try* to understand my point.

Before anyone can try to understand a point, it has to be made.

There is a cheap (not always) way of making everything "lazy", by rewriting. If an expression is the argument of a function, what is passed is the representation of this expression. This gets evaluated in the context of the caller function, although perhaps in the environment of the argument itself, if there are external references. It is something *similar* to macros, and it is more or less what I understood from my - admittedly weak - knowledge of R, S, etc. (Frankly, I do not know them enough to make the difference). But this is not the same as the laziness - realization of the normal order of evaluation, call by name (need), etc.

First off, as someone who has implemented a couple of macro processors, I completely fail to see any similarity between S/R arguments and macro processing. YES an (expression, environment) pair is passed. But can you try to see *my* point? HOW THE THING IS IMPLEMENTED is completely unimportant (except that the approach S and R take makes strictly more things possible than the approach that GHC takes). What matters is WHAT THE BEHAVIOUR IS. And what you get is *precisely* call by need.

There is a difference between call by name, and by reference.

I know that; the implementors of R (one of whom I know) know that also. The contrast is precisely a contrast against call by *reference* because the *language* contrast that was salient for most S users was the contrast between S and Fortran, and it is pass by reference that Fortran has, not call by name.

Right. But then, laziness *AND* side effects may put you in a nice mess...

Indeed it does. I didn't say I thought it was a *good* mix, just that it *exists*. Now, the discussion

began with ideas how to advertize *functional* languages, not packages with dangerous, non-formalizable semantics,

I do not know where you get the idea that S semantics is not formalisable. The principal S reference contains a meta-circular interpreter. "Can lead the unwary into traps" is not at all the same as "cannot be formalised".

OF COURSE, there are untyped languages with suspended evaluation. Snobol had "unevaluated expressions", Icon has "co-expressions", etc.

This is once again to evade the point. (As it happens, I have, and occasionally use, both Icon and SNOBOL. I wonder how many other SNOBOL users remain.) In SNOBOL and Icon these things are *exceptions*; the normal argument passing convention is otherwise. In S (and therefore R), there is, as in Haskell, only ONE way to pass arguments, and that is call by need. Call by need in R is *not* exceptional. It isn't even just the norm. It is the *only* argument passing technique on offer.

But if the merits of FL include some protection against errors, issued from enforcing a concrete programming discipline, "R" doesn't seem to me a good example.

I was on the R mailing list for a couple of years. What a torrent of messages that was! Interestingly, the troubles you fear (with a mix of imperative actions and call by need) do not seem to be troublesome in practice. There really doesn't seem to be much if any need to protect against *those* errors. One of the commonest mistakes is using "&" (or "|") where "&&" (or "||") should have been used, and this is something that a type system might have helped with. But it is precisely a dynamically typed lazy language you were after, so "the lack of a static type system has more to do with errors than the possibility of mixing imperative actions with laziness" is probably something you do not want to hear. I wrote:

...

I don't know what co-inductive constructions are.

OK, try to code in R the list [0,1,2,3, ...] using a co-recursive data definition,

You can safely assume that someone who doesn't know what co-inductive constructions are also doesn't know what co-recursive data definitions are. ("doesn't know" as in "is unfamiliar with the jargon", not as in "has never met the concept".)

in Haskell: integs = 0 : (ones + integs) where ones = 1 : ones and where (+) acts on lists element-wise.

I believe I already explained the reason that this is hard in R: it doesn't evaluate *arguments* but it does fully evaluate *results*. I think that's a much more insightful thing to say about R than to go on misleadingly about macros. Let's leave R behind. If one wants a lazy dynamically typed programming language that lets you construct "infinite lists" by using the basic language mechanisms in a simple and direct way, there's always Recanati's Lambdix, which is a lazy Lisp. I don't know whether that ever saw serious use, but it does show that the thing can be done.

G'day all. Quoting jerzy.karczmarczuk@info.unicaen.fr:

Or perhaps I am again completely wrong, as in the case of "R" not being something I ever wanted?

This is off-topic, but the email address "r" at google.com is Rob Pike. Only someone a similar stature (e.g. Richard O'Keefe) could get away with that. Cheers, Andrew Bromage

ok wrote:

If one wants a lazy dynamically typed programming language that lets you construct "infinite lists" by using the basic language mechanisms in a simple and direct way, there's always Recanati's Lambdix, which is a lazy Lisp. I don't know whether that ever saw serious use, but it does show that the thing can be done.

There is also the "Lazy Scheme" language level in recent releases of DrScheme. http://www.ccs.neu.edu/scheme/pubs/fdpe05-bc.pdf It is syntactic sugar over promises, so its primary use would be in education. It would make a lovely segue between Scheme and Haskell. --PR

On Tue, 9 Oct 2007, Seth Gordon wrote:

Henning Thielemann wrote:

...

In my experience only the other way round works: Let people use C, Perl and Python until they find their programs unmaintainable. Then they will become interested in style and discipline and programming languages which _support_ good style.

Perhaps this could be the kernel of a slogan: "If you're having trouble maintaining your code because ..., perhaps you should try Haskell."

"Nervous? Anxious? You found an irreproducable bug in your program and have to fix it until tomorrow? You feel that your code needs essential cleanup, but you postponed it for long in order to not introduce new bugs? You can hardly maintain the code as it grows and grows? Pause a minute! Maybe we can help. Try Haskell. Its effect is immediate and long-lasting. There are warrantedly no side effects. It's scientifically approved. Available without prescription."

Henning Thielemann wrote:

It's scientifically approved. Available without prescription."

Doctor doctor, can you curry me? Okay, I'm gonna stop now :-)

Aha! Instead of the lambda surrounded by mathematical stuff as the haskell.org logo, we need a picture of a medicine bottle.

"Haskell. Fewer headaches. No side effects."

Alternatively, a picture of a red pill with an embossed lambda...

I haven't been following this discussion closely, but here's an idea: use reverse psychology. "Haskell -- You're probably not smart enough to understand it." Nothing like appealing to people's machismo to get them interested. Mike Seth Gordon wrote:

...

Aha! Instead of the lambda surrounded by mathematical stuff as the haskell.org logo, we need a picture of a medicine bottle.

"Haskell. Fewer headaches. No side effects."

Alternatively, a picture of a red pill with an embossed lambda... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, 2007-10-10 at 21:45 -0400, Brandon S. Allbery KF8NH wrote:

On Oct 10, 2007, at 20:14 , Michael Vanier wrote:

...

I haven't been following this discussion closely, but here's an idea: use reverse psychology.

"Haskell -- You're probably not smart enough to understand it."

Nothing like appealing to people's machismo to get them interested.

Haskell already has that reputation, and so far as I've seen most programmers conclude they shouldn't waste time on it when "any half- trained monkey can write Java/Perl/Python".

And regularly does. Unfortunately, American culture is such that most people *aspire* to being half-trained monkeys... jcc

Michael Vanier wrote:

I haven't been following this discussion closely, but here's an idea: use reverse psychology.

"Haskell -- You're probably not smart enough to understand it."

Nothing like appealing to people's machismo to get them interested.

Oooo! +15

Tim Newsham wrote:

You are not expected to understand this. http://swtch.com/unix/

Hehehe! Elite system programmers understand it. If it is rephrased in terms of continuations, elite lambda calculus programmers will also understand it. You are not expected to be convinced this, but it seems continuations completely characterize system programming. :)

On Fri, 2007-10-12 at 19:33 -0400, Brandon S. Allbery KF8NH wrote:

On Oct 12, 2007, at 18:35 , Albert Y. C. Lai wrote:

...

You are not expected to be convinced this, but it seems continuations completely characterize system programming. :)

Didn't someone already prove all monads can be implemented in terms of Cont?

Well, ContT exists, which includes an isomorphic copy of its argument. So, yeah. But not all of system programming is captured by monads. jcc

On Wed, 10 Oct 2007, Seth Gordon wrote:

...

Aha! Instead of the lambda surrounded by mathematical stuff as the haskell.org logo, we need a picture of a medicine bottle.

"Haskell. Fewer headaches. No side effects."

Alternatively, a picture of a red pill with an embossed lambda...

A snake enwinding an Aesculambda.

"Nervous? Anxious? You found an irreproducable bug in your program and have to fix it until tomorrow? You feel that your code needs essential cleanup, but you postponed it for long in order to not introduce new bugs? You can hardly maintain the code as it grows and grows?

Pause a minute!

Maybe we can help. Try Haskell. Its effect is immediate and long-lasting. There are warrantedly no side effects. It's scientifically approved. Available without prescription."

I don't think it's so important to promote Haskell as to promote language diversity. In most environments, industrial or academic, people usually have to use one language because it's the standard language in the place. Once I had to use Fortran to write code just because teachers in that university believed Fortran is the best tool for numeric programming (and we can understand that, since they were never exposed to anything else). It would be nice if people understand that it's better to have one group using C++, other using Python and other using Haskell than a lot of people using the same language. Best, Maurício

On 10/8/07, Alistair Bayley wrote:

For me, a large part of Haskell's attraction are the features which reflect good engineering practice: strong, static type checking; purely functional code; good FFI. It should be easier to write simple, reliable software in Haskell than in most other languages; IMO, getting the unwashed hordes to use Haskell would be a great improvement in software industry productivity.

I recently put it thus to a friend: When it's hard writing a program in Haskell, it is usually because Haskell makes you think about what you are doing, and as a consequence you end up doing your thinking sooner rather than later. This usually ends with better software with fewer bugs. cheers, T. -- Thomas Conway drtomc@gmail.com Silence is the perfectest herald of joy: I were but little happy, if I could say how much.

Don Stewart wrote,

catamorphism:

...

On 10/4/07, Don Stewart wrote:

...

It was raised at CUFP today that while Python has:

Python is a dynamic object-oriented programming language that can be used for many kinds of software development. It offers strong support for integration with other languages and tools, comes with extensive standard libraries, and can be learned in a few days. Many Python programmers report substantial productivity gains and feel the language encourages the development of higher quality, more maintainable code.

With the links from the start about using Python for various purposes, along with reassuring text about licenses and so on.

Note its all about how it can help you.

The Haskell website has the rather strange motivational text:

Haskell is a general purpose, purely functional programming language featuring static typing, higher order functions, polymorphism, type classes, and monadic effects. Haskell compilers are freely available for almost any computer.

Which doesn't say why these help you.

Any suggestions on a 2 or 3 sentence spiel about what's available?

Here's some quick points:

General purpose: applications from OS kernels to compilers to web dev to ... Strong integration with other languages: FFI, and FFI binding tools Many developer tools: debugger, profiler, code coverage, QuickCheck Extensive libraries: central library repository, central repo hosting Productivity, robustness, maintainability: purity, type system, etc Parallelism!

Can't we embrace the power of 'and'? It's wonderful that Haskell is seeing more practical use, but we shouldn't forget the foundations, either. Maybe we should put your second description first, and *then* have a paragraph saying, "and, for those who know what these are, polymorphism, monadic effects, etc."? Only describing Haskell in terms of software engineeering doesn't seem right to me.

Yes, I think that's the best step. Combine both why you'd use it, with what unique features enable this.

I also agree that this is the right way to go. FWIW, the CUFP talk that started this discussion took the current text out of context. It is one thing to have the fp-speak description of Haskell in isolation (as in the CUFP talk) and another to have it on the wiki front-page, where the side bar advertises libraries, applications, etc. and the middle has news items and so forth. Manuel

On Fri, 5 Oct 2007, Albert Y. C. Lai wrote:

Granted, perhaps your perspective is, if every other company is shouting "customers are number one", then ours must too, and who actually lives up to it is the non-sequitur here. You're in the buzzword war, not the evidence war. OK, then make sure you include executability, as the Python guys in their infinite wisdom have forgotten that one. You'll trump them on that point, ha!

me too

To exemplify, I now analyze the Python statement under my glass:

"dynamic object-oriented": Good, informative, I know those words and I am the one to decide its implications to me.

To be honest - I do not know exactly what is meant with 'dynamic' here. I know Python is dynamically typed - is this meant? Or 'dynamic' in the sense of 'can alter data at run-time', or 'can run programs' at all?

Henning Thielemann wrote:

On Fri, 5 Oct 2007, Albert Y. C. Lai wrote:

...

Granted, perhaps your perspective is, if every other company is shouting "customers are number one", then ours must too, and who actually lives up to it is the non-sequitur here. You're in the buzzword war, not the evidence war. OK, then make sure you include executability, as the Python guys in their infinite wisdom have forgotten that one. You'll trump them on that point, ha!

me too

...

To exemplify, I now analyze the Python statement under my glass:

"dynamic object-oriented": Good, informative, I know those words and I am the one to decide its implications to me.

To be honest - I do not know exactly what is meant with 'dynamic' here. I know Python is dynamically typed - is this meant? Or 'dynamic' in the sense of 'can alter data at run-time', or 'can run programs' at all?

all of that, plus the ability to change the objects' types (hierarchies) at runtime like in most dynamically typed languages. a+, ld.

The Hackathon is a good opportunity to collect preliminary data. Imagine: All other communities are still at the stage of "we feel productivity". We have "our data shows productivity". That puts us at a completely different level --- light-years above the crowd. Haskell --- because we put the "engineering" back into "software engineering".

On Mon, 2007-10-08 at 20:54 +1000, Thomas Conway wrote:

I just had a conversation today that seems relevant to this thread. I was chatting with a friend who is working in the academic sector, and I was observing that Melbourne Uni (my old school), is switching in the new year from teaching Haskell as a first language, to teaching Python. I was dismayed, but not surprised.

Anyway, I was talking about this with my friend said that he understood the main reason for the change was that students were not being "switched on" or excited learning Haskell as they used to be learning C. He put it down to the fact that in C, you are more obviously "making the computer do stuff", and that Haskell is sufficiently high level and abstract that beginner programmers don't get that thrill of feeling like you're making the computer work for you.

I must say, I get that! but at the same time, of course, the high level abstraction is exactly what *we* love about Haskell.

Then they should teach assembly not Python. In fact, I'd recommend assembly anyway.

Yep, I totally agree. At our school, we're teaching the students assembly language, starting with 8-bit 6502 assembly :-) -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Henning Thielemann Sent: Tuesday, October 09, 2007 10:06 AM To: Derek Elkins Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] New slogan for haskell.org On Mon, 8 Oct 2007, Derek Elkins wrote:

On Mon, 2007-10-08 at 20:54 +1000, Thomas Conway wrote:

...

I must say, I get that! but at the same time, of course, the high level abstraction is exactly what *we* love about Haskell.

Then they should teach assembly not Python. In fact, I'd recommend assembly anyway.

Me too. Assembly language is very nice, minimalistic (ok, for today processor not really, even not for RISC processors) and help you understand, what really happens in the machine. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, 10 Oct 2007, Andrew Coppin wrote:

(I'm less sold on whether you really need to learn a particular dialect well enough to *program* in it...)

If you don't then you won't be able to see how complicated things actually get done. It's also an important exercise in abstracting things and keeping something understandable when the system you're building is fighting back against it. -- flippa@flippac.org "My religion says so" explains your beliefs. But it doesn't explain why I should hold them as well, let alone be restricted by them.

What we really need is a sort of stress-strain curve for each of the major languages. Since Haskell is a typed language, we can have one curve for types and one for values: VARIABLE TYPE VALUE ------------------------------------------------------------------- stress | effort to learn language | coding effort/time required -----------|---------------------------|---------------------------- strain | ability to solve problems | marginal rate that problem | | is being solved -----------|---------------------------|---------------------------- yield | knowledge needed to write | boilerplate code needed strength | "Hello World" program | -----------|---------------------------|---------------------------- modulus of | semantic power of | productivity once boring elasticity | language syntax | stuff has been written -----------|---------------------------|---------------------------- ultimate | expressive power | NONE strain | of the language | -----------|---------------------------|---------------------------- ultimate | NONE | point at which code strength | | is getting beyond you -----------|---------------------------|---------------------------- failure | NONE | point at which code is point | | broken and indecipherable -------------------------------------------------------------------- Each language will be strong in one part of the curve. Haskell is superior in those parts of the curve where it matters most in real tasks, at the high strain end of the graph, both in type (there's always something more to learn, so no programmer burn-out) and in value (one person can manage more complexity with less effort). The PR problem is that newcomers to Haskell are being asked either to: 1) Trust me (but President Bush has strained that argument past failure) 2) Sample the curve at the low end (benchmarks, toy problems) and extrapolate the higher end, giving a very false impression The only answer is to provide a positive marginal interest at each point in the language acquisition process to entice the learner to keep sampling as (s)he progresses individually up the curve. This is the real benefit (and most noble purpose) of haskell-cafe. And of course the justification for this strained material science metaphor! :) Dan Weston Philippa Cowderoy wrote:

On Wed, 10 Oct 2007, Andrew Coppin wrote:

...

(I'm less sold on whether you really need to learn a particular dialect well enough to *program* in it...)

If you don't then you won't be able to see how complicated things actually get done. It's also an important exercise in abstracting things and keeping something understandable when the system you're building is fighting back against it.

On Mon, 26 Nov 2007, Thomas Davie wrote:

On 26 Nov 2007, at 15:15, Henning Thielemann wrote:

...

On Thu, 4 Oct 2007, Don Stewart wrote:

...

The Haskell website has the rather strange motivational text:

Haskell is a general purpose, purely functional programming language featuring static typing, higher order functions, polymorphism, type classes, and monadic effects. Haskell compilers are freely available for almost any computer.

To continue an old thread: What about turning the strange words like 'monadic effects' into links to glossary articles?

Btw. where is 'lazy' ?

I believe the point of this discussion was that anyone reading the Haskell webpage will currently get about as far as "featuring static typing", and go "this is all very nice, but what exactly does this language do for me? Why should I use it?". Take for example what the python website says:

I didn't want to repeat the discussion. I think the discussion ended with: Anything more helpful would be too long for the title line at haskell.org, and a more detailed explanation (but not a generic advertisement like that from Python) should be reachable easily. Now my idea was, that making links to glossary articles leaves the slogan as short as it is, and allows people to find out quickly about the words they still don't know. An explanation why Haskell's features are useful for programmers is still required.

apfelmus wrote:

But we'd probably need the glossary articles first before linking to them :)

+12 I added added alpha, beta and eta conversion a while back. (And then some kind soul corrected it because half of what I wrote was actually *wrong*...) Anybody want to take a stab at all 15 kinds of morphisms? :-}

On 26 Nov 2007, at 15:50, Henning Thielemann wrote:

On Mon, 26 Nov 2007, Thomas Davie wrote:

...

On 26 Nov 2007, at 15:15, Henning Thielemann wrote:

...

On Thu, 4 Oct 2007, Don Stewart wrote:

...

The Haskell website has the rather strange motivational text:

Haskell is a general purpose, purely functional programming language featuring static typing, higher order functions, polymorphism, type classes, and monadic effects. Haskell compilers are freely available for almost any computer.

To continue an old thread: What about turning the strange words like 'monadic effects' into links to glossary articles?

Btw. where is 'lazy' ?

I believe the point of this discussion was that anyone reading the Haskell webpage will currently get about as far as "featuring static typing", and go "this is all very nice, but what exactly does this language do for me? Why should I use it?". Take for example what the python website says:

I didn't want to repeat the discussion. I think the discussion ended with: Anything more helpful would be too long for the title line at haskell.org, and a more detailed explanation (but not a generic advertisement like that from Python) should be reachable easily. Now my idea was, that making links to glossary articles leaves the slogan as short as it is, and allows people to find out quickly about the words they still don't know. An explanation why Haskell's features are useful for programmers is still required.

But the point is that this section of the site is the bit that's meant to be an advertisement -- we're trying to encourage people to read more, and quite frankly, making it a fist full of links would make at least me think "Well bugger this if I have to read 10 pages before I even have a clue what it is". Bob

On Nov 26, 2007 1:44 PM, Thomas Davie wrote:

But the point is that this section of the site is the bit that's meant to be an advertisement -- we're trying to encourage people to read more,

Are we? I thought Haskell.org was intended to describe what Haskell *is*. There are plenty of articles and blog posts and wiki pages out there that advocate Haskell. I don't see why the main web page needs to be polluted with marketing. -- Dave Menendez http://www.eyrie.org/~zednenem/

On Tue, 27 Nov 2007, Thomas Davie wrote:

On 27 Nov 2007, at 14:44, David Menendez wrote:

...

On Nov 26, 2007 1:44 PM, Thomas Davie wrote:

But the point is that this section of the site is the bit that's meant to be an advertisement -- we're trying to encourage people to read more,

Are we? I thought Haskell.org was intended to describe what Haskell *is*. There are plenty of articles and blog posts and wiki pages out there that advocate Haskell. I don't see why the main web page needs to be polluted with marketing.

Because someone's first contact with Haskell is likely to be someone saying "I use this really cool language called Haskell", or a lecturer teaching it to them. In either case, if a tiny amount of interest is sparked, their likely second contact is likely to be haskell.org (through guessing or googling).

I think this is true, but for me it means, that we do not need another advertisement at Haskell.org, but facts. I also expect that people visiting the site already know about static typing and have categorized themselves into static typing lovers or haters. They will also have heard about polymorphism (just like object-orientation :-). So they only need to find out about the words, they do not know.

Quite frankly, there's nothing going to put me off a language more than a paragraph full of unknown buzz words that I have to look up on the front page.

There's plenty of places on Haskell.org where we can describe what haskell *is*, but the front page should be used for grabbing peoples attention and telling them why it's useful.

Haskell.org is not only for new users. I like it as front page, because of the news and the entry points to the Wiki.

On Tue, 2007-11-27 at 08:34 -0800, David Fox wrote:

On Nov 27, 2007 8:14 AM, Henning Thielemann wrote:

On Tue, 27 Nov 2007, Thomas Davie wrote:

> On 27 Nov 2007, at 14:44, David Menendez wrote: > > > On Nov 26, 2007 1:44 PM, Thomas Davie wrote: > > > > But the point is that this section of the site is the bit that's meant > > to be an advertisement -- we're trying to encourage people to read > > more, > > > > Are we? I thought Haskell.org was intended to describe what Haskell > > *is*. There are plenty of articles and blog posts and wiki pages out > > there that advocate Haskell. I don't see why the main web page needs > > to be polluted with marketing. > > Because someone's first contact with Haskell is likely to be someone > saying "I use this really cool language called Haskell", or a lecturer > teaching it to them. In either case, if a tiny amount of interest is > sparked, their likely second contact is likely to be haskell.org > (through guessing or googling).

I think this is true, but for me it means, that we do not need another advertisement at Haskell.org, but facts. I also expect that people visiting the site already know about static typing and have categorized themselves into static typing lovers or haters. They will also have heard about polymorphism (just like object-orientation :-). So they only need to find out about the words, they do not know.

> Quite frankly, there's nothing going to put me off a language more than > a paragraph full of unknown buzz words that I have to look up on the > front page. > > There's plenty of places on Haskell.org where we can describe what > haskell *is*, but the front page should be used for grabbing peoples > attention and telling them why it's useful.

Haskell.org is not only for new users. I like it as front page, because of the news and the entry points to the Wiki.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

In that case we need to identify all the groups that the front page is serving and create separate areas for each, all "above the fold" as it were:

1. A "sales pitch" for new users. I see how much this disturbs some people, but maybe it is better to think of it as a quick introduction with a focus on benefits and comparisons to things which are already familiar. This is what one needs when one is in the stage of deciding whether to pursue something.

2. After you have decided whether to pursue Haskell, you probably want to decide *how* to pursue it. In this section would be much of what is there now - links to the definition, documentation, and important tutorials, mailing lists, and so on.

3. Finally, you want a section for people who are already deeply involved. This would be a news section, probably an RSS feed, links to newsletters, and so on.

This thread should focus on part 1 above. I think it would be a huge mistake to deliberately omit this material because "we do not need another advertisement at Haskell.org, but facts." Its all facts! Haskell.org needs to serve everyone who arrives there.

I agree. I know that all those things belong on the front page, but we have to start somewhere. In order to keep the thread productive I decided to post a concrete draft to work with rather than a general approach. I do not want to remove any other parts of the page, except for the slogan. We could re-arrange things a little, though. For example, putting the "Getting Started" part in the middle rather than at the side is a good idea, IMO. Also, the headlines are a little out of date, so maybe we should push them down a little. So here's the current state, incorporating various suggestions and improvements. I'd like to keep the "research" keyword (but tied closely with "practical"), since this is one rather distinguishing aspect of Haskell. " Haskell is a modern, general-purpose, pure functional programming language that combines many powerful results from research into a practical programming language. Its features include: * Static typing increases robustness as the compiler will catch many common errors automatically. * Type inference deduces types automatically freeing the programmer from writing superfluous type signatures. * Higher-order functions, polymorphism, and laziness enable higher levels of abstraction, more compositional, thus more reusable code. * '''Purity''' helps to keep your code maintainable, enables automatic, randomized testing and eases concurrent programming significantly. Haskell comes with many libraries, freely available compilers for almost any computer, debuggers, profilers, code coverage and testing tools. [Maybe: * Monads, Arrows are powerful abstraction mechanisms that can be used to capture domain-specific abstractions, while retaining the safety of static typing. ] == Learn More == links to tutorials, books, wiki-pages (this could just be pointers to the side bar) == Get Involved == links to feeds, mailing lists, hackage, ... == Events == as before == Headlines == as before == News == as before. Or maybe in a side bar? using a 3-column layout? "

On Tue, 2007-11-27 at 23:11 -0500, Sterling Clover wrote:

On Nov 27, 2007, at 11:34 AM, David Fox wrote:

...

In that case we need to identify all the groups that the front page is serving and create separate areas for each, all "above the fold" as it were:

1. A "sales pitch" for new users. I see how much this disturbs some people, but maybe it is better to think of it as a quick introduction with a focus on benefits and comparisons to things which are already familiar. This is what one needs when one is in the stage of deciding whether to pursue something.

There should also be a bit of discussion on *who* folks want the pitch to attract. As I see it, there are a number of categories here as well, and maybe even links to "breakout pages" for different demographics could be in order.

I expect any number of us have had the experience where we want to use Haskell on a project, and need to convince our project manager / other form of immediate supervisor / boss / whatever that this is a good idea -- so there needs to be a pitch geared to benefits that they'll latch on to -- reliability, clarity, maintainability, provability, speed, momentum and staying power, library support, etc.

Then there should be a different sort of pitch for casual new users that want to get their feet wet in different sorts of programming concepts.

Finally, there should be a pitch for people that really know what's up, so to speak, are looking for a place to expend some of their significant talent, and are going to be attracted by some of the mathematically cooler/geekier/blow-your-mind aspects of Haskell, the power of its type system, etc. Mindshare among these folks is key for more people that want to hack on getting Cabal to "just work," adopt the maintenance of libraries and come up with new and useful proposals therein, get involved with compiler development (or at least generate really useful test-cases and bug reports), and all that.

Sorry, but are you talking of *one* homepage? This can all go into own wiki pages that are aimed at certain audiences, but this really can't all fit on the front page. Go ahead, write them! I'm all for it, but at the moment I'm looking for concrete improvements of my suggested phrasing. Any ideas how we could succinctly address those demographics in that short paragraph?

On 28 Nov 2007, at 13:41, Ian Lynagh wrote:

On Wed, Nov 28, 2007 at 09:27:39AM +0100, Thomas Schilling wrote:

...

Sorry, but are you talking of *one* homepage? This can all go into own wiki pages that are aimed at certain audiences, but this really can't all fit on the front page.

I'm reminded of http://www.shiregames.com/shiregames/

We could do something similar, with a column for When you hear "programming", if you immediately think of C or perl, then please read the following: and maybe ML or lisp for the other column.

I don't know if it's a good idea or not, just something to think about.

That's an excellent idea as far as I'm concerned. We get the advertising pitch to the uninitiated, and the old hands keep their navigation routes to the important documentation. Bob

On Tue, 2007-11-27 at 09:44 -0500, David Menendez wrote:

On Nov 26, 2007 1:44 PM, Thomas Davie wrote:

But the point is that this section of the site is the bit that's meant to be an advertisement -- we're trying to encourage people to read more,

Are we? I thought Haskell.org was intended to describe what Haskell *is*. There are plenty of articles and blog posts and wiki pages out there that advocate Haskell. I don't see why the main web page needs to be polluted with marketing.

If someone hears/reads someone talk about Haskell they're probably not going to browse through all the blog posts to find out bits and pieces. They go to the first hit that comes up whan typing "Haskell" into Google, which is www.haskell.org. The very basics of web-usability include that users have to find what they're looking for very, very quickly or they're going somewhere else or simply lose interest. That is why the contents of the home page are very important. Let's not miss this opportunity. / Thomas

On Tue, 27 Nov 2007, apfelmus wrote:

More specifically, "fact" means something that you can easily check yourself. "Robust"/"maintainable"/"testable" code are things you _can't_ easily check yourself without already learning the language.

+1

But "shorter code" is a fact you can easily check, for instance with quicksort as example. In fact, "short code" is the reason why I picked up Haskell. Back then, I was given the task to calculate some sequence of numbers which I did in one page of C code. So far so good, but when I asked the task assigner about his solution, he responded: "Ah, this problem, that's 1 line in Haskell. Well, 2 lines if the terminal is too small."

Ah, a Haskell code contribution to the Encyclopedia of Integer Sequences?

apfelmus wrote:

Henning Thielemann wrote:

...

apfelmus wrote:

...

Back then, I was given the task to calculate some sequence of numbers which I did in one page of C code. So far so good, but when I asked the task assigner about his solution, he responded: "Ah, this problem, that's 1 line in Haskell. Well, 2 lines if the terminal is too small."

Ah, a Haskell code contribution to the Encyclopedia of Integer Sequences?

The task was just for fun, but it's sequence A050000.

import Data.Set xs = let f x m = x: let y = x `div` 2 in f (if member y m then 3*x else y) (insert x m) in f 1 (singleton 0)

As said, it's two lines if the terminal is too small :)

I can't see how it could be one page of C unless the page is 10 lines long ;-) The following code is the direct translation of your Haskell code (except that it prints the result instead of building a list). a+, ld. #include #include void f(int x, intset s) { printf("%d, ", x); f (intset_elem(s, x/2) ? 3*x : x/2, intset_put(s, x)); } int main(void) { f (1, intset_put(intset_new(), 0)); }

Laurent Deniau wrote:

apfelmus wrote:

Back then, I was given the task to calculate some sequence of numbers which I did in one page of C code.

import Data.Set

xs = let f x m = x: let y = x `div` 2 in f (if member y m then 3*x else y) (insert x m) in f 1 (singleton 0)

...

As said, it's two lines if the terminal is too small :)

I can't see how it could be one page of C unless the page is 10 lines long ;-) The following code is the direct translation of your Haskell code (except that it prints the result instead of building a list).

a+, ld.

#include #include

void f(int x, intset s) { printf("%d, ", x); f (intset_elem(s, x/2) ? 3*x : x/2, intset_put(s, x)); }

int main(void) { f (1, intset_put(intset_new(), 0)); }

Well, I only remember that it took _me_ a page of C code :D Basically due to a hand-coded intset and user interaction (no REPL for C, after all). Regards, apfelmus

On Thu, Nov 29, 2007 at 09:48:22AM +0100, apfelmus wrote:

Well, I only remember that it took _me_ a page of C code :D Basically due to a hand-coded intset and user interaction (no REPL for C, after all).

In my C programming, I've taken to using gdb as a REPL: stefan@stefans:/tmp$ vi foo.c stefan@stefans:/tmp$ cat foo.c int foo(int x) { return x * x; } int main(){} stefan@stefans:/tmp$ gcc foo.c stefan@stefans:/tmp$ gdb -q ./a.out Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". (gdb) b main Breakpoint 1 at 0x804835e (gdb) run Starting program: /tmp/a.out Failed to read a valid object file image from memory. Breakpoint 1, 0x0804835e in main () (gdb) p foo(2) $1 = 4 (gdb) p foo(10) $2 = 100 (gdb) p foo(-1) $3 = 1 (gdb) p foo(0) $4 = 0 (gdb) p foo(2)+foo(4) $5 = 20 (gdb) quit The program is running. Exit anyway? (y or n) y stefan@stefans:/tmp$ Makes most debugging tasks much easier. Stefan

The following code is the direct translation of your Haskell code

void f(int x, intset s) { printf("%d, ", x); f (intset_elem(s, x/2) ? 3*x : x/2, intset_put(s, x)); }

No, not that easy. The Haskell code works with arbitrary precision Integer, the C code with a fixed size int. On a 32 bit machine, try to calculate a_{1805133}, which equals to 19591041024. Or a_{8392780} = 26665583616. Or a_{8500000} = 10804333. These values are calculated with the Haskell program in 370s and ~1GB memory usage. Fair enough, on the same machine a C program (*two* pages long) was able to calculate a_{23448481} = 594261577728 and a_{25000000} = 192365946 in 50s and ~1GB memory usage. /BR, Mirko Rahn

...

The Haskell code works with arbitrary precision Integer, the C code with a fixed size int.

This is also a work for a library (BTW like Haskell does), you can use gmp or mpfr. This will just add one line to store x/2 in y and avoid its recomputation. You will also have to switch from intset to set. And there one can start to see the difference. The code refactoring will be longer since C doesn't support parametric polymorphism nor operator overloading.

Yes, Haskell is just great, so many things are hard-wired. Even if you use arbitrary precision Integer and appropriate set implementations, there is still no infinite, lazy list that avoids recomputation... I guess your C code either uses some non-standard includes or does not fit on a single page anymore. Just for the record: Using a 64-bit machine (1.5GHz Itanium2) and a well scaling intset (Judy1), (something like) your C code calculates: * within 1GB and in about 25 mins: a_{892163852} = 11314755057 max seen so far: a_{846081651} = 770163004735488 (50 bit) * and within 32GB and in about 22 hours: a_{28515445370} = 165480993670 max seen so far: a_{25880571766} = 32905425960566784 (55 bit) I guess that a Haskell program that verifies these values will depend on an external intset implementation. Or uses another data structure, for example some Set_of_Intervals... /BR, Mirko Rahn

Thomas Davie wrote:

There's no such check list of "good stuff" with the Haskell slogan, instead, we've got a list of buzzwords, as bad as company webpages preaching that they offer "synergised solutions", but not actually telling anyone what they do.

I couldn't disagree more. The words used in the 'Haskell slogan' may be technical jargon; however as such they have a precisely defined meaning and actually characterize the language fine. This is exactly the opposite of 'buzzwords', which usually lack a clear and unambiguous definition (but are loved by marketing people). Cheers Ben

On Nov 26, 2007 11:38 AM, Thomas Schilling wrote:

Haskell is a general-purpose, pure functional programming languages that puts many interesting results from research into a practical programming language. It's features include:

I think it is stronger to say "many powerful results" rather than "many interesting results".

* Static typing, which increases robustness by allowing the compiler to catch many common errors automatically.

* Type inference, which deduces types automatically and frees the programmer from writing superfluous type signatures.

* Higher order functions, polymorphism, and lazy evaluation, which enable higher levels of abstraction and more compositional, thus more reusable code.

"frees the programmer from writing superfluous type signatures" is a weak (and dubious) advantage. I very often write "superfluous" type signatures first (to be sure I know what I'm asking my program to do) and only then let Haskell check it. Then I leave it in as good documentation. Also, if you're going to stress the benefits for the casual or new reader, maybe you should spell them out explicitly: * Static typing - Compiler automatically infers a static type for every expression, completely eliminating any potential for runtime type mismatch errors, and checks any programmer-supplied type annotation for correctness. The absence of silent typecasting also eliminates a whole class of hard-to-find program logic errors. * Higher-order functions and polymorphism - Encourages higher-level abstraction and unshackles algorithm design from implementation details. * Lazy evaluation - Separates the concerns of the called function ("what can I provide?") and the calling function ("how much do I need to know?") and facilitates "borrow-from-the-future" techniques where useful with infinite data structures or recursive algorithms. Thomas Schilling wrote:

On Mon, 2007-11-26 at 20:31 -0800, David Fox wrote:

...

On Nov 26, 2007 11:38 AM, Thomas Schilling wrote:

Haskell is a general-purpose, pure functional programming languages that puts many interesting results from research into a practical programming language. It's features include:

I think it is stronger to say "many powerful results" rather than "many interesting results".

Yes, good!

Also it should be "its" rather than "it's", but I didn't want to reply to my own message since it was meant as a draft to work with.

I'd like to turn this into a refinement of a concrete proposal. I skimmed the original thread and it pretty much diverged into experience reports or meta-level discussions on what or how to advertise Haskell. This has its place, but I think we can get to a description that is good enough for now and addresses Don's issues mentioned in the thread-starting message.

So, I would welcome more concrete adjustments to my proposal.

/ Thomas

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Simon Marlow writes:

Perhaps

Type Inference: deduces types automatically, so you don't have to clutter up your code with type declarations. You can still write type declarations for documentation purposes, and these will be automatically checked by the compiler.

Perhaps it won't harm adding that manual signatures are useful semantically as well, for the disambiguation.

What I'd *really* like to see is a bunch of links on the front page leading to pages that describe the main differences between Haskell and some other language (C, Python, Java, C#, F#, ...).

... and, perhaps, playing not only with the pedagogy by contrast, but also by similarities, to mention Clean. Jerzy Karczmarczuk

On Thu, 29 Nov 2007, Simon Marlow wrote:

What I'd *really* like to see is a bunch of links on the front page leading to pages that describe the main differences between Haskell and some other language (C, Python, Java, C#, F#, ...). The easiest way to grasp what Haskell is all about is by reference to a known baseline, and programmers tend to have different baselines. e.g. the C page might start with "Haskell is a functional language", whereas the Python page might start with "Haskell is statically typed".

Python page could start with: "You like 'map', 'filter', 'for x in ...' and lambda's in Python? Then you will like to learn where Python has borrowed these features."

lemming wrote:

...

Python page could start with: "You like 'map', 'filter', 'for x in ...' and lambda's in Python? Then you will like to learn where Python has

What about "iterators" - lazy lists - and "generators" - lazy function definitions. And list comprehensions, both lazy and strict. And zip. And the "itertools" module - containing analogues for lazy ++, [n..], cycle, dropWhile, groupBy, zipWith, takeWhile, etc. All inspired by Haskell. Jerzy Karczmarczuk wrote:

Henning, Python *may not* start in such a way. Those functionals are being obsoletised by Guido Van Rossum. "for" remains,

All of them are remaining. Guido's effort to deprecate them brought down a storm of protest. Folds, known as "reduce" in Python, are on their way out, though. They scared people (not "Pythonic").

please, don't try to convince anybody that Haskell was the first language with iterators...

Python's "iterators" are not the same as iterators in C and other older languages. They are lazy lists. The reason they named them "iterators" is not to scare people. Haskell was not the first to have lazy lists, but Haskell was an important part of the inspiration for introducing them into Python. Guido was forced to do something - someone had written a new Python interpreter, called "Stackless Python", in which every Python function was a Scheme-like continuation. People found this very, very scary. So Guido stopped it by introducing laziness, which could be made much less scary. -Yitz

I wrote:

...

Python's "iterators" are not the same as iterators in C and other older languages. They are lazy lists. The reason they named them "iterators" is not to scare people.

...

Haskell was not the first to have lazy lists, but Haskell was an important part of the inspiration for introducing them into Python.

Jerzy Karczmarczuk wrote:

Actually, I would *sincerely* like to see some reference proving that.

The Python Library Reference, "itertools" (section 6.5 in Python 2.5): "This module implements a number of iterator building blocks inspired by constructs from the Haskell and SML programming languages. Each has been recast in a form suitable for Python."

I cite Guido V.R., 2005: "About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches." (http://www.artima.com/weblogs/viewpost.jsp?thread=98196)

OK. Haskell also got those from Lisp, ultimately.

Give to Caesar...: It was Amrit Prem; one history page on WP says that no specific mention of any Lisp heritage is mentioned in the release notes at the time, so all speculations are still possible...

OK. (That is a quote from Wikipedia, yes?)

But, in fact, Python iterators - in general - are neither lazy nor lists. No linking!

True, they are not implemented as linked lists, like in Lisp-family languages. They have semantics similar to a thunk, and the syntax of the language encourages their use for iteration over a sequence; so in practical use, they provide a "feel" very similar to one of the most common uses of lazy lists in Haskell: they allow you to iterate over a sequence without specifying whether or not it has already been computed. (Alright, I should have said "non-strict".)

They are syntactic shortcuts to *objects* possessing the method 'next'. So, there is no call by need, no updated thunks, etc. Calling them lazy is an abuse of the language, although quite intuitive. I don't want to raise a war about that...

Agreed, they are not *really* thunks, they just intuitively feel very like them. The "next method" trick is a perversely cute way of achieving that in a strongly imperative call-by-(value/reference) language. The use of "iterable" in "for x in iterable:" is effectively call by need. itertools.tee() gives you updating thunks.

The laziness, meant as deferred procedure calls *CAN* be used in Python, also in iterator context, through generators, that's true. But still there are no update'able automatically thunks, no lazy data! If generators remind me of something, it is co-routines.

Yes, they are becoming co-routines, you can now send data back into them. If I can put a lazy list comprehension in place of a strict one, why is that not lazy data? Look, I am not arguing that this pseudo-laziness is a central feature of Python, or that Python is close to being a functional language. I don't think Henning meant to say that, either. But there are some features like that, and they are very nicely done, people like them. Even before I knew about Haskell, those were the features of Python that made me really enjoy the language. So I agree with others who wrote that pointing out beautiful Haskell-inspired or Haskell-like features in a person's current favorite language might be a good way to encourage that person to have a look at Haskell.

BTW. The BDFL Van Rossum never said anything about "scaring". He said plainly that folds are things he *hates* most.

He hates them because there is another way to do them in Python. The other way is "simpler" - easier to learn by the uninitiated - and more "Pythonic" - fits in better with an overall consistent and intuitive way of thinking when you write Python programs that makes it easy to think of the right thing to do. People in this thread are using the word "scary" to mean the opposite of those things, so I am also using the word in that way.

...

Guido was forced to do something - someone had written a new Python interpreter, called "Stackless Python", in which every Python function was a Scheme-like continuation. People found this very, very scary. So Guido stopped it by introducing laziness, which could be made much less scary.

Give to Caesar... Someone, was Christian Tismer:

http://www.python.org/workshops/2000-01/proceedings/papers/tismers/spcpaper. htm

Very good, yes, thank you!

and I am doubtful about the statement that people found it very, very scary. Simply they - usually - felt no *need* for another complication to learn, you know, *some* people are lazy... But Stackless still exists, GVR stopped nothing, and the Grant Olson's tutorial

http://members.verizon.net/olsongt/stackless/why_stackless.html

is really interesting

Indeed, thanks. But the efforts of Christian and others to push Stackless into the mainstream of Python were not successful.

From the "Acknowledgements" page of www.stackless.com: "I would like to thank... (many people) ...and Guido van Rossum for still not sending the Spanish Inquisition."

Regards, Yitz

Jerzy Karczmarczuk wrote:

...don't forget that itertools have been introduced in the version 2.3! ...But we were speaking about map and filter, and this is 1994... So, perhaps some concrete references - if given - should be tested against the historical truth.

OK, OK. You want to make me work. In May 1994, there was the following post by Ken Manheimer in which he praises the functional features of Python: http://www.python.org/search/hypermail/python-1994q2/0698.html That invoked the famous response by Guido in which he regrets having introduced some of those features: http://www.python.org/search/hypermail/python-1994q2/0705.html Here are some excerpts: "Really, I don't understand all the fuzz about lambda, and I don't see why its introduction made functions any more first class than they already were in Python... Also notice that Python's map, filter and reduce are quite powerless compared to the same functions in the average functional programming system -- they don't work when applied to infinite sequences since they use eager evaluation." Can we guess which "average functional programming system" he was thinking of? Hint: it uses lazy evaluation. Guido is clearly not rejecting functional influences on Python, he is supporting them. But he feels that these specific instances do not fit in. The thread then continues with a wide-ranging discussion of functional versus imperative programming, including CPS style (intertwined with the original topic, which was Python's layout vs. C-style blocks, where Haskell is also mentioned). This discussion makes it clear that all those who worked on Python at that time were well-aware of what was happening in the functional world, and that this was an important influence on their thinking about Python. Haskell is mentioned by name in the following post by Steven D. Majewski: http://www.python.org/search/hypermail/python-1994q2/0718.html where Haskell is portrayed as taking one paradigm to the extreme, as opposed to Python in which all can be represented. Implying that, in particular, Python must include features from the Haskell paradigm as well. (At that time, I was busy programming in Perl, C++ and other languages, having never heard of either Python or Haskell.) Towards the end of the decade, there were more discussions about adding Haskell features into Python. Several were implemented starting in 2000: "PEP 201 - Lockstep Iteration... Created: 13-Jul-2000... This PEP proposes a standard way of performing such iterations by introducing a new builtin function called `zip'... The function's name... the BDFL strongly prefers zip() due to its Haskell[2] heritage." http://www.python.org/dev/peps/pep-0201/ "What's New in Python 2.0... released on October 16, 2000... The idea of list comprehensions originally comes from the functional programming language Haskell... discussed for a seemingly endless time on the python-dev mailing list." http://www.python.org/download/releases/2.0/new-python.htm Note that after the introduction of list comprehensions - explicitly from Haskell - Guido's argument against lambdas, maps, and folds changed a bit. In the blog post you referenced, his argument is that one should use list comprehensions instead. So that is not exactly a rejection of Haskell influence. Iterators, generators, and itertools we have discussed. Recent additions to Python include partial function application (of sorts), type inference (of sorts), and a "numeric prelude" (of sorts), described in PEPs 309, 3124, and 3141 respectively, all mentioning Haskell by name. Regards, Yitz

On Fri, 30 Nov 2007, Yitzchak Gale wrote:

Jerzy Karczmarczuk wrote:

...

The laziness, meant as deferred procedure calls *CAN* be used in Python, also in iterator context, through generators, that's true. But still there are no update'able automatically thunks, no lazy data! If generators remind me of something, it is co-routines.

Yes, they are becoming co-routines, you can now send data back into them.

If I can put a lazy list comprehension in place of a strict one, why is that not lazy data?

Look, I am not arguing that this pseudo-laziness is a central feature of Python, or that Python is close to being a functional language. I don't think Henning meant to say that, either. But there are some features like that, and they are very nicely done, people like them. Even before I knew about Haskell, those were the features of Python that made me really enjoy the language. So I agree with others who wrote that pointing out beautiful Haskell-inspired or Haskell-like features in a person's current favorite language might be a good way to encourage that person to have a look at Haskell.

That was my point, yes.

On Thu, Nov 29, 2007 at 12:40:00PM +0000, Simon Marlow wrote:

What I'd *really* like to see is a bunch of links on the front page leading to pages that describe the main differences between Haskell and some other language (C, Python, Java, C#, F#, ...). The easiest way to grasp what Haskell is all about is by reference to a known baseline, and programmers tend to have different baselines. e.g. the C page might start with "Haskell is a functional language", whereas the Python page might start with "Haskell is statically typed". I guess this is similar to Ian's suggestion.

+1 Stefan

Combinators get my code done, tralalalala, laughing out loud! Quickcheck locates all of my bugs, tralalalala, laughing out loud! Fusion laws make my code run fast, tralala, lalala, lololol! Folks, I'm so done, Merry Christmas, tralalalala, laughing out loud!

Andrew Coppin writes:

Dan Weston wrote:

...

[...] and facilitates "borrow-from-the-future" techniques where useful with infinite data structures or recursive algorithms.

And this, gentlemen, is just one of the reasons why Haskell gets labelled as "scary".

It's very hard to explain what this enigmatic riddle-like statement actually *means* without a very long exposition. (Heck, *I* haven't worked out how to "borrow from the future" yet...)

Scary - schmary... If you want to be afraid of, say, Santa Claus, that's OK, you are a free man. But, perhaps before saying that you haven't worked out something, *try* to work it out. Read something about Richard Bird's circular programs. A nice Web article (Lloyd Allison) is here: http://www.csse.monash.edu.au/~lloyd/tildeFP/1989SPE/ A really complicated application by Janis Voigtländer http://wwwtcs.inf.tu-dresden.de/~voigt/HOSC.pdf will probably kill you, so don't. But The Web is full of articles. You can even read one or two of my own productions. I - sorry for shameless auto-ad - cited this paper *twice*, once it was after *your* similar statement... http://users.info.unicaen.fr/~karczma/arpap/lazypi.pdf It is called "The Most Unreliable Technique in the World to Compute PI", and it has been written explicitly for fun and instruction. That's a possible answer to your dilemma. Another one shows something even worse than borrowing from the future, namely "going backwards in time", applied to the Automatic Differentiation in Reverse Mode. http://users.info.unicaen.fr/~karczma/arpap/revpearl.pdf And, please, avoid saying that something is scary or difficult, unless you are really sure. Jerzy Karczmarczuk

Andrew Coppin wrote:

Dan Weston wrote:

...

[...] and facilitates "borrow-from-the-future" techniques where useful with infinite data structures or recursive algorithms.

And this, gentlemen, is just one of the reasons why Haskell gets labelled as "scary".

It's very hard to explain what this enigmatic riddle-like statement actually *means* without a very long exposition. (Heck, *I* haven't worked out how to "borrow from the future" yet...)

Birds don't fly because it looks impressive, they just get tired of walking! Scary is refusing to fly because you are an expert walker and don't want to look foolish as a beginning flier. Some people find dialogs less scary that buzzwords (hey, it worked for Socrates!) Let me rephrase some Haskell benefits in less scary language, now that the word count is not at a premium: 1) Mind your own business Son: I need some new clothes. Gimme some money. Strict Dad: How many money do you need (pulls out wad of bills...) Son: Mind your own business! Your job is to pay, not to control my spending! Lazy Mom: Here's a credit card. Just charge what you need. 2) Steal from yourself and others Student: I need a list of prime numbers Teacher: Easy. I'll give you the first one: 2. Now test each odd integer starting at 3 and try dividing by every prime up to its square root. Student: But I need to already know the primes in order to divide them into my candidates, don't I? Teacher: [Lying] No problem, I have an infinite list of them! I'll make you a deal. I'll feed you these divisor primes as you need them, and you tell me whether your numerator ended up being prime. Student: Ok, 3 is the next prime number Teacher: [Surreptitiously writes this down on his list] Student: Hey, you're cheating! I'm the one doing all the work here! I'm generating primes faster than I need them, so really I'm stealing from myself. What's the use pretending I'm getting them from you? Teacher: No, I'm just doodling, I really do know all the primes. Your code is much simpler with me handing you the divisor primes anyway. What do you care where I get them from? It's no extra work for you! 3) Running in circles Athlete: I run on an infinitely long track. I can go forever in a straight line without coming to the end. Trainer: Dummy, you're running on a treadmill. Look around, the walls aren't even moving. Athlete: I can't, the lights are off. The only thing I can see is the lighted path at my feet. Trainer: Moron! Don't you see that number "2" painted on the treadmill that keeps repeating every couple meters? Athlete: Of course, funny how someone had the patience to keep painting the number 2 over and over. Only God could have done such a wondrous thing. Trainer: Has it occurred to you that that is the same number "2" going by each time? Athlete: Prove it! Trainer: Easy, I'll just write a "3" next to it. See, the "2" is gone, now it's "23". Athlete: Now who's the dummy. You know this ground is immutable, chalk won't stick to it. You must have transported me to a completely different track where the number "23" is written over and over. That God must be powerful to have made so many tracks like this. Trainer: Your logic is too lazy for me. You can't tell the difference between an infinite list and a cyclic one. Athlete: What do I care? I still get all the exercise I need! Now that wasn't so scary, was it? All in fun... Dan

On Wed, 2007-11-28 at 21:02 +0000, Sebastian Sylvan wrote:

On Nov 28, 2007 8:54 PM, Thomas Schilling wrote:

...

I put up a draft page. Feel free to adjust it.

http://haskell.org/haskellwiki/FrontpageDraft

Perhaps slightly OT, but while we're discussing the front page. Is there any way of getting rid of the numbering on the front page? It annoys me!

You can turn it off in your preferences under "Misc". I guess someone with admin privileges could change the global defaults.

Thomas Schilling wrote:

I put up a draft page. Feel free to adjust it.

http://haskell.org/haskellwiki/FrontpageDraft

I like the current version better. It is /very/ difficult to pack in such a short paragraph a list of the most important concepts /and/ advertising about how useful all this is. Rather than an advertising front page paragraph, I'd like to have a good introductory page. It should mention all the distinguishing features of Haskell, give a short explanation of the concepts with pointers (links) to more detailed texts (preferably on the wiki), and then go on to give the reader some idea about how and why this is all practically useful, maybe using one or two examples. Some material from the english wikipedia entry for Haskell_(programming_language) could be used as a starting point. However writing such a thing is /difficult/, as it requires deep knowledge as well as good communication skills, and even granted both is still a lot of work to get right. The current introduction page (prominently reachable from the front page) is /not/ a good advertisement for Haskell. To paraphrase C.J.Cherryh, enthusiasm is not a good substitute for a (seasoned) expert. Cheers Ben

Henning Thielemann wrote:

When I want to judge a programming language I like to see a "gallery", a collection of beautiful programs. This shows me 1. what are the problems, the language developers want to tackle (does "general purpose" for the developers mean "web, XML and data base processing" or "computationally intensive numerical stuff") 2. how do they solve them, i.e. what are the special features of the language and how do they help solving the problem, what style of programming does the language support.

Well-said that man... Now, the question becomes "what examples demonstrate the things that Haskell is good at?"