Don't overlook the advantages of using familiar operators and names: you have some intuition about '+' and 'map', so if you see them, then you'll have some idea what they do (assuming the author is neither stupid nor malicious). However, if you see some operator like '$>+' or some name like 'pp3', then you probably won't have any intuition about it.
Writing good software is about conveying intentions, and part of the way we can do that is relying on what other people already know. Which means using familiar names and operators when it is helpful to do so.
Keep in mind that such intuitions often have a formalization. We have an intuition about what "map" means. When we dig deep and try to write down what that intuition is, the following appears:
map id = id
map (f . g) = map f . map g
Now that we have an operation and laws, it is reasonable to use a typeclass.
To me, typeclasses are at their best when you have a real abstraction to encode. If you are having trouble using a typeclass and need C++-style ad-hoc overloading, it's likely you are trying to encode a "fake" abstraction -- one that has only linguistic, rather than mathematical meaning.
Haskell is not an isolated linguist. Her low tolerance for vagueness strikes again.
Luke
I would
consider any book which is hard
to read because of that badly written. Things are quite similar with the code.
I consider the current state of affairs quite poor: namely, abuse of type classes and alternate names and operators that aren't very suggestive, but were chosen purely to avoid conflicts.
Programming language should be easy to reason about for both computers
and humans. Compiler should therefore disallow programming style that is
inaccessible for potential readers. Want to overload something? Well,
use typeclasses to be explicit about it.
Type classes were not designed for name overloading. They're designed to factor out common patterns in programming. You shouldn't use a type class just because you want to use a name or operator.
And as I said before, if you want to "disallow programming style that is inaccessible for potential readers," then you should disallow the current state of affairs.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net | 877-376-2724 x 101
_______________________________________________