He's forgetting one important thing. Compared to other functional languages Clean has virtually no community. That said, the things they (the language developers) can build are pretty impressive. Their iTasks workflow system (unfortunately there is only a very old web page online, but I've seen a recent demo at a conference) is very cool.
Many, if not all, languages are defined in large part by their communities. Java is for the unwashed masses, Ruby is undisciplined, monkey-patching lunatics, Haskell is friendly, brilliant, and (for the most part) ignored. It almost seems like languages are just touchstones around which to build a community (by writing libraries, frameworks, etc.). The differences between the actual languages seem much less important that the idioms within the languages.
(For the record: I know Python, MATLAB, Lisp, and Java.)
Look, what is so innately wrong with monkey-patching? You mention it in a distinctly perjorative tone, but why? Yes it can be used badly, but it can also be bloody brilliant.
Bad monkey-patching: touching any method defined in core.
Good monkey-patching:
class Array
def to_sentence
return "I contain #{self[0..-2].map {|x| x.to_s + ', '}}and #{self[-1]}."
end
end
Seriously, being able to do throw that kind of thing into the beginning of your program, extend the core classes just like that, is frickin' awesome.
People abuse it, yes, like people abuse any power they're given. Just last week I wasted several hours trying to fix some strange ActiveRecord errors which turned out to be the morons in Rails Core monkeypatching Hash#to_json; my solution ended up being monkeypatching it straight back. Great. Obviously, I wish I didn't have to do that kind of thing.
However - don't blame the technique, blame the people who misuse it. Used properly, it can be a dream come true. Always wish that Time could print to string including milliseconds? Baby, I've got Time#to_s_usecs for you in three lines of code.
Monkeypatching is a sharp knife - you can cut your bread or you can cut yourself. Either way, it's not the knife's fault. And either way, I'd rather have a knife than not have one : )
The problem is that you throw this in your module, and then someone else defines another Array#to_sentence (say in some Natural Language module you require) and all of a sudden you've got hell on earth.
This is fine if this will be only used by you. Now what if you started distributing this, say in a gem? The person using your software may already have a to_sentence monkey-patch in place, and your gem they are using interferes with that.
Also, what if someone monkey-patches a core method of Array? Any one else consuming this script has a broken build they need to deal with it. Most of the time, these collisions do not occur, but sometimes they do and and often in subtly and hard-to-detect ways.
Overriding core methods is a definite no-no. And if you were actually going to distribute something, you'd probably have a new class descending from Array and add your methods to that.
But for private code - you've got a bunch of Arrays, you want them to output something interesting - what's wrong with that?
Now now, I know you're joking, but the non-rails community is perhaps larger than you think. They just tend to be less noisy. Particularly in Japan, there is a huge number of people who use Ruby primarily for scripting - as in, traditional scripting, automating system tasks and the like. I personally know at least half a dozen or so "pure rubyists" like this.
The number of people who use Ruby who have never even touched Rails is probably quite low - who wouldn't want to try out the hot new thing? - but heaps of Ruby users are not primarily there to use Rails.
Funny thing is, I generally prefer Rails users' code. Rails enforces such a strong MVC structure that one can't help but write decently organised code, IMO, and the habit sticks. People who came at Ruby from scripting tend to just write "whatever works" and you know how that turns out.
"languages are defined in large part by their communities"
For the longest time, Clean wasn't open sourced. These days, the chances of a non open source language gathering a strong community around it is hard (except maybe for Microsoft languages), and even when a community forms, it is likely to remain small. I for one, would never put my time in to a community around a closed source language.
"I for one, would never put my time in to a community around a closed source language."
I for two. With open source, one knows one's contribution is going to help others, will be another small push of momentum, and generally just all-round contribute to the virtuous cycle of this language is good because lots of people help becuase the language is good, etc.
Closed source? You've got to be kidding. Whatever it is, they can do it themselves.
I don't think that Microsoft is an exception to that, actually. C# didn't really start gaining popularity until AFTER ECMA ratified it as an open standard (same for the .NET platform and the CLR).
I don't think you can build a community by just writing libraries, frameworks, etc. ;) The crucial (and hard) part is getting people from the outside involved, so that you _don't_ have to write everything yourself, but it will turn into a 'community effort'.
The team working on Clean is pretty small. Currently there are some efforts to make it more friendly and welcoming for other people to join.
