The insanely great:
- Like Haskell, but simpler. Haskell is primarily a research language. Monads, monad transformers, lifts, arrows, templates, bang patterns, etc. etc. get added to GHC on a regular basis. If you want to use Haskell, you'll have to constantly deal with unproven technology in FPL design, like monads and monad transformers. Clean is simpler. If you know Haskell (even if you don't fully grok monad trasformers), you can learn all there is to Clean in a few hours. For better or for worse, the features are pretty stable and simple, which brings us to my second point:
- No monads necessary. That's right, a lazy functional language that can perform mutation and IO safely without monads. Imagine that! Clean uses uniqueness types in its otherwise Haskell-like type system. This choice turns out to be both easier on the brains and on the optimizer...
- As fast as C (the compiler is very fast too), and it ain't no bullshit either! You may have heard from Haskell advocates that Haskell is as fast as C. Well, it's really a half-truth. Sometimes, there is simply no substitute for a good old-fashioned array and mutation of it. It's the only data structure known to man that gives you O(1) read, write with a small constant factor to boot. Haskell can give you that, but your choices are: (1) state and other monads (that don't compose too well) with mutable arrays in GHC (that can cause insane GC slow-downs), defeating the purpose of using them or (2) malloc'ed array hacking. If you look at the Shootout entries, Haskell entries are ugly unsafePerformIO and malloc-using hacks with everything stuck into IO monad, where Clean is idiomatic and simple, and still faster!
- 1980s called, they want... If your Clean program encounters a runtime error, like off-by-1 access, it will print a message naming the error and quit. This may have been good enough in the 80s, but these days I expect more finesse. Haskell allows you to handle these situations in a customized way.
- No FFI. WTF?
- Have someone who speaks English natively proof-read your books, manuals, etc. I won't go into detail here. I too suck at writing.
- License. For a long time, Clean was closed-source, offering only commercial licenses. A few years ago, Clean was released as open source under LGPL. Can you now write and distribute your closed-source commercial code using Clean? I'm not a lawyer, so I couldn't give you a definitive answer, but in doing so, you would be incorporating part of Clean in your generated binary (statically linked runtime). This might not sit well with LGPL and the Free Software Foundation that may demand that you make your code open-source for doing that.
- Development model. Clean may be open-source, but it's basically developed in-house. I do believe that programmers should be paid for their time and expertise developing software, especially programmers and brilliant as the authors of Clean must be, but the reality is that programming languages are different from most other software: As a consumer of a programming language, your investment both learning and writing code in it is tremendous. You want to be assured that your language will continue to exist in the future and won't cost an arm and a leg later. You simply won't use a language for anything important, unless you get these assurances. That's why, unless your vendor is a predictable monster like MS, for a programming language to be viable it has to either have open standards and multiple vendors, or have a fully open and distributed development and place no restrictions on the runtime (generated binaries) whatsoever. I want to ask Clean authors: is it better to have 5 users of whom 0 or 1 are paying customers or to have thousands of non-paying users, who however might make you famous and buy your books?
If you are developing performance-demanding code and love FP, Clean may be a very good choice for you, assuming that you don't shy away from LGPL and can live with some eccentricities like missing FFI and 80's style error messages.
Posts
