On 11/11/2010, at 4:02 PM, Sebastian Fischer wrote:
Why blame languages instead of writers?
We _find fault_ with programming languages and we _blame_ their designers. A programming language is a tool. A saucepan whose handle keeps falling off is defective, and if someone who didn't realise the dangers gets a pan of boiling water over their feet, we find fault with the saucepan and blame its designer. A programming language can help in the production of working software in several ways: - making it easier to do the right thing - making it easier to find mistakes - making it harder to make mistakes - making it easier to read the result. For some tasks, C makes it very easy to do the right thing. It also makes it horribly easy to make mistakes and hard to find them. The amount of time spent maintaining a program is much higher than the amount of time spent creating it initially. That means that if you have a tradeoff between ease of writing and the other virtues of a language, ease of writing *matters* less. Consider the vexed question of repeating all or part of the record name in the field name. Yes, this *is* a burden on the person writing it. But it is a **help** to the person reading it. The same applies to using module prefixes (possibly abbreviated ones). If I see 'length' in a Haskell program, I am for sure going to think it is the one from the prelude. If I see 'B.length', I know that I need to remember what B is (probably some kind of ByteString, these days). When people enthuse about how the compiler can figure it all out, I shudder. How am *I* going to figure it all out without heavy machine assistance? If length, map, and so on had always been part of a Sequence typeclass, people would not now be talking about
a lot of value in locally saying 'this particular invocation should be ad-hoc overloaded' for common functions like 'length', 'map', 'lookup', etc.
I expected more use of type classes in the Prelude for Haskell'.