The great "that's why" is as follows: when you have an abstraction,
then it is sufficient to hold the abstraction in mind instead of the
whole concrete implementation. That's the whole purpose of
abstraction, after all, be it maths or programming.
Let me illustrate this.
Suppose you are developing a library that, for instance, has a notion
of "settings" and is able to combine two "settings" with several
strategies for resolving conflicts between settings with duplicate
keys: take the first setting, the second, none, or make a setting with
multiple values. For example, an alternative GetOpt.
Suppose you don't know what a monoid is and don't even know that such
an abstraction exists.
Now, when you're reasoning about the library, you have to think "If I
combine 3 settings, should the order of combination matter? Hmm, would
be nice if it didn't. Also, what should I return if someone queries
for a non-existent key in the settings? Should I return an empty list,
or a Nothing, or throw an error, or what? Do empty settings make
sense?" etc. If you're smart and lucky, you will most probably get
most things right and inconsciously create a settings monoid.
Now, if you know what a monoid is, you immediately recognize that your
settings should be a monoid by nature, and now you have absolutely no
doubt that you should make the combining operation associative and
provide a unit; and you use this monoid abstraction all the time you
are designing this library. Now, you don't think about whether you
should throw an error or return a Nothing for an empty key; but
instead you think about which result would behave like a unit for the
monoid, being motivated by mathematical principles rather than pure
intuition.
You end up designing a mathematically sound library whose principles
make sence and has no design flaws, at least in the mathematically
sound part, even if you never actually use the word "monoid" in the
documentation.
Also, read this post by sigfpe that motivated me to learn abstract
algebra in depth (I am yet in the beginning, however), and, overall,
this is a breathtaking post:
http://sigfpe.blogspot.com/2008/11/approach-to-algorithm-parallelisation.html
- this is where I started to appreciate the power of mathematical
abstractions even more.
2009/1/17 david48 <dav.vire+haskell at gmail.com>:
> All of this is still lacking the great why : why/how an abstraction so
> generic can be useful.
> I'm starting to believe that the only reason to make a datatype an
> instance of Monoid is... why not ! since it's not hard to find an
> associative operation and a neutral element.
>
--
Eugene Kirpichov