[Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results

[karczma]

Fergus Henderson comments the comment of Andre Pang concerning my
nasty comment addressed to Marcin Kowalczyk. 

> On 08-Oct-2004, Andre Pang <ozone at algorithm.com.au> wrote:

>> I believe that Marcin wishes to prove the same point that I want to: 
>> namely, Clean encourages use of strictness by making it easier to use 
>> (via language annotations).  At the risk of sounding ignorant and 
>> arrogant, I think the Haskell community in general does not understand 
>> the importance of syntactic sugar to make such tasks easier.
> 
> I think the Haskell community understands well the importance of syntactic
> sugar; witness the use of syntactic sugar for monads, the `infix` operator
> syntax, the layout rules, etc. 
> 
> I think the Haskell community has just been a bit slower in understanding
> the importance of strictness :)  But that seems to be gradually changing.

What are you, both, or all three of you suggesting?
That the world of programming is evolving, people invent new, wonderful
programming tools, nice and easy, and Haskell remains stagnant, old,
conservative, user-unfriendly, whatever? This is nonsense. 

NOW, I will tell you what is *really* changing!
Haskell which began as an academic language, implementing a certain number
of paradigms, laziness in particular, and a specific vision of controlled
polymorphism, whose ambition was to show the power of computing with
abstractions, finally reaches the layers of computing irremediably polluted
by the 'mainstream' atmosphere. 

You want to convert Haskell into a "super-C" language?? 

OK, I admit that I will never understand these complaints about the
inefficiency of non-strict computations, since what I *require* in most
of my work is laziness. Had I needed strictness for the sake of efficiency,
I would use a different language instead of throwing dirt at Haskell. Why
don't you the same? This mythical Haskell community which "slowly begins to
understand the role of strictness" is simply an *enlarged* community, with
people who want to adapt Haskell to their own, old, conservative, "standard"
needs. 

Those people don't care about the progress in the implementation of types,
and about thingies which go beyond the theory of types, such as mathematical
attributes with their hierarchies and subsumptions. 

Actually, they don't care at all about the cost of modifying an existent,
well defined language. I think that it would be good to invent some new
practical functional languages, which would answer their demands.
Any takers? 

? 

Yes, I thought so. 

On the positive side of such discussions I see the following.
* Despite the dirt thrown at Clean because of their distribution policy,
 you see the importance of another, sibling language, which may be used as
 a comparison gauge. Concerning strickness: Clean has not only those
 ubiquitous !annotations, but has a powerful strickness analyzer,
 which alleviates their use. I have the impression that Haskell strickness
 analyzer is less aggressive, and I would like to know why, or - perhaps -
 to hear that this is not true. 

 Clean compiler produces *automatically and globally* human-readable
 type headers for all the definitions (at least in the main module).
 I would like to see such a compilation option in Haskell as well; it
 should be fairly easy and cheap, since all this information is anyhow
 available. Hm., can hi -ddumping and
 --show-iface etc. be useful here? I never tested that... 

* The user-friendliness seem - because of this enlarged community -
 gaining in importance. We have witnessed the birth of the 'do' syntax,
 continued by the 'proc' stuff of Ross Paterson, but there is a mileage
 to go. GHC rewrite rules are still quite weak. 

* I began to respect more and more all the really new and fascinating
 ideas in computing paradigms, as far from the superficial quarrels
 here, as possible.
 Genericity/polytyping, arrows, co-monads (which don't seem dead yet,
 although not too many people speak about them).
 THIS IS HASKELL. If you want Cobol disguised in Haskell, use simply Cobol. 

Jerzy Karczmarczuk