Daniel Carrera wrote:
Hi all,
Anyone here familiar with the Clean programming language?
It looks /very/ similar to Haskell, both in functionality and syntax.
I would be grateful for any sort of comparison. I'm trying to decide which language I should try to learn.
I sent something to this newsgroup more than two years ago, suggesting that such a topic SHOULD be in the FAQs... More or less: 0. They *ARE* very similar, both being lazy, pure functional languages, and the possible application domains are strongly overlapping. I strongly suggest to everybody who wants to specialize in the FP that he/she learn both. YES! It won't harm you, it will give you a bit larger perspective. 1. There is a visible difference in general philosophy. - Haskell started as an exploration language, undergoes frequent (even if small) modifications, its "maintenance" is distributed, there are at least 3 (OK, 4 if you wish) major implementations, and the documentation (even if driven by one super-mind) is the result of a community consensus. - Clean - in its actual instance - was thought as an industrial-strength programming platform, stable, and changing only in the case of necessity. (I mean - when the authors feel really unhappy about the status quo, and they have nothing else to do, which is rather rare...) There is a cross-breeeding between them, but on quite different levels. While the authors of Clean profit from time to time from Haskell formal constructions (notably the superficial appearance of the class system), some Haskell-oriented people have been fascinated by the powerful and coherent (even if difficult) Clean interfacing library. Haskell produces/inspires from time to time some offsprings (and - with my full sincere respect - some bastards): generic Haskell, Polyp, Cayenne, etc., some really wonderful headache generators, strongly recommended for all free and ambitious minds. Clean is more application-oriented, and has a good reputation for being really fast. We could have read here and elsewhere some critical voices: that it would be better to concentrate the human effort on one language, instead of producing two << faux jumeaux >>, if you know what I mean... I disagree violently with this, and I think that the co-existence, and the competition between them is good, inspiring, and offering better support for those who think already on new languages. 2. Thus, there are some design differences. Haskell had since the beginning the arbitrary-precision Integers, and numeric computations were for too long considered as something of less importance. This resulted in somewhat unsatisfactory status of numerically-oriented parts of the standard library, but it is improving. Clean in these contexts is more brutal, and seems to optimize better some programs which in Haskell need some attention of the user (such as avoiding to use Integers, where Ints suffice; Clean has only "standard" Ints). Also - for the current implementations - the manipulation of arrays is more efficient in Clean. (But I haven't done any benchmarking with the last GHC version...) Clean has quite efficient head-strict, unboxed, but spine-lazy lists, which is *very good* for signal processing, especially together with an aggressive strictness analysis. Haskell is more difficult to optimize here. The type inference is a bit different, and in general the type systems *are* different. Haskell system is easier to learn. The status, the relation between classes and types is a nice, baroque construction. Clean class system is - apparently - more "plain", the relation between classes and overloaded functions is more straightforward, but if you look at some details, it is substantially more complicated, and sometimes disturbing. In Haskell a function which takes two arguments and produces a result of type c has the type a -> b -> c. In Clean you may write it as a b -> c which *will* disturb a Haskeller, since it might be understood as a one- argument function with a being some constructor. Clean shortcuts produce the effect that the types of f x y = z x y and f x = \y -> z x y are different, while in Haskell it is the same. Some missing or "redundant" parentheses in the type specification in Clean are far from being inocuous, *never* try to write the above as (a b) -> c ... Clean type categoriess are quite rich. Uniqueness, strictness, type dependence [a=>b] etc. - all this must be studied for many hours in order to be able to understand some compiler messages and/or to code in the most efficient way.. 3. Some people say "Haskell uses Monads", Clean - uniqueness types for IO and elsewhere. Uniqueness type for a variable means that that this variable can be accessed only in one place within the program. So, if there a new object is produced from the transformation of the original, and if this object is also "unique", the program can update in place the original, yielding the new instance. This cannot be done directly in Haskell. In fact, there are people who use Monads in Clean as well. The update- in-place-; single-thread data processing chains are simply implemented in Clean at a lower level, while IO Monad in Haskell is primitive. So, Clean is more universal, permitting to implement more "imperative" things by the user, while Haskell is "cleaner"... Clean programs possessing imperative flavour could be quite messy, but Clean disposes of a syntactic contraption, a kind of sequential "let" with specific scope rules, permitting to REUSE names: # (aFile,aFileSystem) = openItInside aFileSystem # aFile = WriteToItOrDoSomethingElseWith aFile # aFile = continueToProcess aFile ... where you don't need to write aNewFile = process aFile, etc. A file is still unique, because of these sequential scoping rules. Haskell on the other hand has the "do" block, permitting to write monadic chains in an imperative style do var <- doSomething ... encore <- doSomethingElseWith var printSomewhere encore ... return (whatYou want et encore) 4. A general observation about the use of both languages by a beginner who wants to learn on examples: Haskell disposes of two decent interactive interpreters: Hugs and GHCI permitting to test directly small expression, to ask about their types, etc. which is often useful for debugging, and for grasping the essentials on small exercises. Clean is a compiler which processes the whole program. It has a very decent interactive interface with make/project options, and plenty of information produced on the screen by the compiler, but - as in my case - the class usage is a bit less appropriate. (There are other views as well, I am not trying to depreciate Clean). It must be admitted though that neither is really an *interactive* language like Scheme or Python. In a pure, strongly typed programming framework the compiler performs a lot of global analysis, which makes the incremental programming difficult. (In Clean: impossible; in Hugs: awkward - you can input expressions, but not definitions; in GHCI: possible: let foo = someThing useThisFoo foo ... but this is a monadic construction in disguise... 5. So, a personal touch. When I worked on the definition of abstract vectors and tensors in Hilbert space, in order to implement *quantum structures*, I used Haskell. When I simulated musical instruments using some numeric dataflow circuits, I used Clean. I am satisfied, and I love both. =================== Now, for the people who asked those questions. Choose whatever you wish, if your philosophy is "I have no time to learn two languages, only one, so tell me which one is better", then I have some VERY STRONG statements: * Whoever says to you "H is *better* that C" (or vice-versa) is LYING. * If you want to learn FP, you should have a good view on the principal paradigms, not on particular syntactic constructs. Then, some knowledge of two different languages is more than helpful. * Learning of languages is a big adventure and pleasure. * Here and elsewhere both H and C communities are helpful, people who know, answer all questions without pretensions nor suggestions that they are respectful gurus bothered by beginners (which happens too often on other "language-oriented" newgroups I visit from time to time...). Jerzy Karczmarczuk Caen, France