On 2007.12.12 03:29:13 +0100, Wolfgang Jeltsch scribbled 1.6K characters:

Am Mittwoch, 12. Dezember 2007 03:12 schrieb gwern0@gmail.com:

...

FWIW to the discussion about changing the main page, I was reading the CUFP paper and I saw some germane comments (and the writer is apparently one Noel Welsh, whose name I don't see in the thread); the context is a discussion (pg 17) of various members or potential members of the Haskell community and how supported they are:

"What are the needs of the potential programmer? People program to solve prob- lems; so there had better be a clear statement of what kinds of problem the language is good for. The Python community does a good job of this on python.org: "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."

Compare this with the equivalent from haskell.org: "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." If you understand all that, you don't need to be here: you're already a Haskell programmer."

Note however that also the Python slogan isn’t so much about solving problems. And it also contains technical terms: “dynamic object-oriented programming language” instead of “static typing, higher-order functions, polymorphism, type classes, and monadic effects”.

Best wishes, Wolfgang

The Haskell one is dominated by the technical terms, while the Python one is by more generic features. Let's break them down:

Python is a dynamic object-oriented programming language It 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."

It uses two technical terms, one of which is extremely common and understood (or at least, they think they understand it) by the vast majority of programmers, and another which even if you don't know anything about static/dynamic, still sounds neat. Dynamic! Neato! *power* *bop* Leaping librarians Batman! Of the rest of the description, it is all touchy-feely: it reassures you that it'll be able to do what you ask it to do; it'll play nice with your stuff; it's quick and easy to learn; and you won't have to mess around with installing stuff, it's brain-dead simple and 'all there'. Now let's look at the Haskell one.

"Haskell is a general purpose,

OK, that's good; it's not as emphatic or clear as "It can be used for many kinds of software development", but it does mean more or less the same thing.

purely functional programming language

Oh dear. It's 'functional', and I've heard that means scary weird mathematical stuff (first technical term). But I wanted to learn something new, so let's look at something else. But Wait, what's this 'purely' business? If it's purely functional, doesn't that mean I won't be able to my usual stuff, which is presumably impure? (Technical term the second; parity achieved with Python description).

...

featuring:

Equivalent to "It offers"

...

static typing

Technical term the third. Mention of static typing is probably on balance bad: If you are the kind of sort of cutting-edge programmer, then you are more familiar with dynamic languages like Python and Ruby which liberated you from the horrors of languages like Java and C. And these Haskell guys are daring to suggest you might want to go *back*? If you aren't familiar, then static just sounds bad - inert, unbending, rigid and unpleasant. 'I stopped watching that show - its plot was just too static.' It's probably too late now, but I think a better name would've been 'securely typed'. :)

...

higher-order functions,

Term the fourth. Even more obscure. Lispers might appreciate this entry though.

...

polymorphism,

Fifth term. This one is good: polymorphism is used elsewhere, and sounds friendly.

...

type classes,

Sixth. OK, seriously, what group besides those who already understand Haskell would actually know what type classes are or care? If they have to be mentioned, might as well say something more useful (I dunno what, maybe something such as 'they are like multiple inheritance or interfaces, but more powerful').

...

and monadic effects.

This actually sounds even more obscure and scary than just monads would be, and I've seen it oft remarked that monads should just be called soft fluffy things... Seventh.

...

Haskell compilers are freely available for almost any computer."

If the reader is still interested and still takes Haskell seriously after puzzling over the foregoing, this would either be pointless or off-putting. Well, *of course* there are compilers for most computers. You aren't a serious general-purpose language in this day and age if there aren't compilers free for most computers. Such a line either tells the reader what they assume to be true, or strikes them as 'the lady doth protest too much, methinks'... So, the Haskell one uses more than twice as many technical terms, uses more off-putting ones, offers less information, does not reassure as Python's does that switching costs are not high, and so on. It needs to change. Now, the Main Page on haskell.org is not protected, so I could just edit in one of the better descriptions proposed, but as in my Wikipedia editing, I like to have consensus especially for such visible changes. How do you think the description could be improved? -- gwern

i did just read the haskell description from galois [1]. i like 1) "...enabling much higher coding efficiency, in addition to formalisms that greatly ease verification." 2) "All programming languages suffer from a semantic gap:..." maybe we could compose sth similar to 1) to introduce static typed functional programming, and to 2) to introduce some strange new buzzwords coming with haskell. i'm sure, there will be no problem in using scary words, iff we introduce them as easy-to-handle master solutions to all incurable programming diseases. ;) ...imho the present slogan [2] is not that bad, too. - marc [1] http://www.galois.com/methods.php [2] http://haskell.org/haskellwiki/?title=Haskell&oldid=17367

Bayley, Alistair wrote:

...

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Derek Elkins

...

(Not directed at gwern in particular)

I have a better idea. Let's decide to do nothing. The benefits of this approach are: 1) it takes zero effort to implement, 2) the number of people who immediately give up on Haskell from reading that is, I suspect, neglible (actually I suspect it is zero; I think the number of people who actually read that at all is probably negligible), and 3) it accomplishes the same end as debating endlessly while creating much less list traffic.

Should we set up a haskell-marketing mailing list for people who still have some passion (or merely stamina) for the discussion? Or is there a lighter-weight way to take the discussion off-list/to another list?

Alistair

This is a great idea! Other languages have advocacy mailing lists and/or newsgroups. I think Haskell should have one too. I know if there was one I'd be the first person not to subscribe ;-) Mike, bored of these endless debates

...

...

...

...

gwern0 writes:

> If the reader is still interested and still takes Haskell > seriously after puzzling over the foregoing, this would either > be pointless or off-putting. Well, *of course* there are > compilers for most computers. You aren't a serious > general-purpose language in this day and age if there aren't > compilers free for most computers. Such a line either tells the > reader what they assume to be true, or strikes them as 'the lady > doth protest too much, methinks'... > So, the Haskell one uses more than twice as many technical > terms, uses more off-putting ones, offers less information, does > not reassure as Python's does that switching costs are not high, > and so on. > It needs to change. > Now, the Main Page on haskell.org is not protected, so I could > just edit in one of the better descriptions proposed, but as in > my Wikipedia editing, I like to have consensus especially for > such visible changes. > How do you think the description could be improved? Why don't you let Haskell speak for itself? Instead of putting such buzzwords nobody really understands (and cares), put random problem descriptions and one-line solutions in Haskell. Well known problems like Fibonacci, Quicksort, etc. may be good candidates, even "add 1 to all elements of an Integer list" may be. First impressions of a language usually not by a slogan, I don't tell my friends about Haskell saying "it's a statically typed, functional, blah blah blah" language. Instead "the thing that you write with a loop in C, I write in Haskell like this --oh, and it also has infinite lists..." I think Haskell code impresses me much more that those words. Emre

Emre Sahin wrote:

Why don't you let Haskell speak for itself?

Instead of putting such buzzwords nobody really understands (and cares), put random problem descriptions and one-line solutions in Haskell. Well known problems like Fibonacci, Quicksort, etc. may be good candidates, even "add 1 to all elements of an Integer list" may be.

...and normal programmers care about the Fibonacci numbers because...? Seriously, there are many, many programmers who don't even know what Fibonacci numbers *are*. And even I can't think of a useful purpose for them. (Unless you count Fibonacci codes?) Quicksort is a well-used example, but several closely related sorting algorithms turn out to be fairly wordy in Haskell. It just so happens that [a very simple] quicksort is quite short. I guess the question we've got to ask [hmm, we are repeating aren't we?] is who we're trying to attract. Yeah, we should probably set up a seperate list for this stuff...

On Wed, 2007-12-12 at 11:19 +0000, Andrew Coppin wrote: . . .

...and normal programmers care about the Fibonacci numbers because...?

Seriously, there are many, many programmers who don't even know what Fibonacci numbers *are*. And even I can't think of a useful purpose for them. (Unless you count Fibonacci codes?)

Knuth[1] pp. 417-419 discusses Fibonacci trees and Fibonacci search. According to Knuth (and who am I to argue with him) Fibonacci search has better average case running time than binary search, although worst case can be slightly slower. Cormen et. al.[2] devotes chapter 20 to Fibonacci heaps, which they say are of primarily theoretical interest. [1] Donald E. Knuth, The Art of Computer Programming, vol. 3, second edition, Addison Wesley Longman (1998). [2] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest and Clifford Stein, Introduction to Algorithms, second edition, The MIT Press (2001). -- Bill Wood

Hello Andrew, Thursday, December 13, 2007, 12:40:59 AM, you wrote:

...

Knuth[1] pp. 417-419 discusses Fibonacci trees and Fibonacci search. According to Knuth (and who am I to argue with him) Fibonacci search has better average case running time than binary search, although worst case can be slightly slower.

afair, it's only because binary shift operation is rather slow on MIX machine while Fib. search use just subtraction to compute next index to try -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Thu, 2007-12-13 at 09:55 -0500, Denis Bueno wrote: . . .

More importantly for this discussion, however: Fibonacci heaps have nothing to do with calculating the fibonacci numbers, and you don't even need to know what the fibonacci sequence is to use fibonacci heaps. (You discover what it is, if you didn't know, when you do a complexity analysis of fibonacci heaps, but, that's only useful for proving how efficient the heaps can be.) Therefore, I don't think one can successfully argue that fibonacci numbers are important because a heap has "Fibonacci" the name in its name.

Just a nit, but I thought it worth mentioning. =]

That's fair, and Cormen et. al. said pretty much the same thing in Chap. 20. I think the argument is that the Fibonacci sequence is important to *understanding* the Fibonacci heap. Still your point is well taken. -- Bill Wood

On Fri, 14 Dec 2007, Henning Thielemann wrote:

Worst case analysis of AVL trees also leads to Fibonacci numbers, as far as I remember.

The number of possibilities to arrange bricks of a certain width is also Fibonacci number. In general I think that Fibonacci numbers serve as simple non-trivial example for difference equations. | | || -- || -- ||| |-- --| ||| |-- --| ...

gwern wrote:

Now, the Main Page on haskell.org is not protected, so I could just edit in one of the better descriptions proposed, but as in my Wikipedia editing, I like to have consensus especially for such visible changes.

Hey, why has the front-page already been changed then? I don't like neither this nor the new slogan. Concerning what slogan should be on the front page, I prefer technical terms to buzzwords. myReadText = filter (not . buzzword) In any case: it's not our task to convince others by means of an enterprisey formulation, people are free to choose. If they don't want it, so be it. We provide data points ("I have written a big but robust program, it's called <insert name here>", "We have a FFI and its use is explained here", "look, this quicksort function is so beautiful") but judgment is what everybody has to do for himself. Regards, apfelmus

Henning Thielemann wrote:

apfelmus wrote:

...

gwern wrote:

...

Now, the Main Page on haskell.org is not protected, so I could just edit in one of the better descriptions proposed, but as in my Wikipedia editing, I like to have consensus especially for such visible changes.

Hey, why has the front-page already been changed then? I don't like neither this nor the new slogan.

Edit war!!!!!

Yarr, bring up the guns! Y-rifle, fire! http://ellemose.dina.kvl.dk/cgi-bin/sestoft/lamreduce?action=normalize&expression=%5Clamb.%28%5Cx.%5Cf.f%28x+x+f%29%29+%28%5Cx.%5Cf.f%28x+x+f%29%29+%28%5Cf.%5Cda.f%29&evalorder=normal+order Goodstein gun, fire! import Data.Tree type Number = Forest Integer zero = []; one = [Node 1 zero]; two = [Node 1 one] -- (shortened) hereditary three = one++two; four = [Node 1 two] -- base 2 representation subtractOne p (Node 1 []:xs) = xs subtractOne p (Node a []:xs) = Node (a-1) []:xs subtractOne p (Node 1 k :xs) = let k' = subtractOne p k in subtractOne p [Node 1 k'] ++ Node (p-1) k':xs subtractOne p (Node a k :xs) = subtractOne p [Node 1 k ] ++ Node (a-1) k :xs goodstein !p n = if null n then [] else n:goodstein (p+1) (subtractOne (p+1) n) goodsteingun n = concat $ "lamb":map (const "da") (goodstein 2 n)

goodsteingun three "lambdadadadadada" goodsteingun four "lambdadadadadadadadadadadadadadadadadadadadadada[...]

Will it ever cease? Regards, apfelmus

On Dec 11, 2007, at 22:47 , Steve Lihn wrote:

1. can be used for many kinds of software development. (some may argue yes, but different kinds from what python is good for.)

This question is somewhat tied to (3), but really the answer is "it can be, but you may have to think differently about the problem to formulate a good program". (See below.)

* Domain Specific Language (who needs it? other than academics and Wall Streeter?)

DSELs can be thought of as a programming methodology; as such, it has wide applicability, but most programmers don't think that way. Tcl was originally positioned as a "DSEL enabler" (write composable functions in C, tie them together in Tcl), but most programmers "don't get it" and so don't tend to use it as such. More recently, Lua seems to be using a similar philosophy with a little more success --- but mainly by limiting it to something which most programmers can deal with. Also compare how Perl and Python monoliths have replaced the original Unix philosophy in which the shell is a DSEL enabler (composing single-function programs like "cat" and "sort"). When it comes down to it, Haskell's strengths are only realizeable if you approach programming problems in a different way from most common languages. It's a fairly big leap, and arguably Haskell won't compete well in the mainstream until more programmers have made that leap. -- 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

Hello Steve, Wednesday, December 12, 2007, 6:47:36 AM, you wrote:

* clear distinction between functional and imperative (is this really an advantage? almost everything I deal with is IO, network, and db related, what is left for purely functional?)

if your program has simple computations and mainly toss data in&out, this is drawback. if you have complex algorithms which compute output data from input ones, this is an advantage because Haskell allows to write more complex algorithms easier and have better performance -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com