It's always possible to write the non-generic version of a generic method and still get it right. I mean, there are mistakes that the formality will help you avoid (e.g. if you violate associativity, even in a seemingly trivial way, it will always come to bite you at the worst possible time), but it's possible to just not make those mistakes. The advantages of the generic formalism over reimplementing it specifically every time are, just like for any other use of generics, saving code and being able to reuse existing library methods (e.g. traverse, mfix, the various recursion-schemes traversal operators).
There are disadvantages too. Most often performance and not in a small way.
Compare general comparison sorts with counting sorts for a simple example. The latter require additional properties on the value making them much less general, but you gain major performance benefits.
Additionally you assume that you can skip the specific proof given the general one. That is not the case a lot of the time.
You have to verify all required properties anyway or you end up in a similar place.
Generic does not mean general, but programming languages do not have an easy way to verify properties so you end up with general.
> Compare general comparison sorts with counting sorts for a simple example. The latter require additional properties on the value making them much less general, but you gain major performance benefits.
In theory sure, but I've never seen anyone use a counting sort in production code.
> You have to verify all required properties anyway or you end up in a similar place.
You go from n * m to n + m though, and since the properties are often simple and standard they might be done for you in the standard library already.
> Generic does not mean general, but programming languages do not have an easy way to verify properties so you end up with general.
Typeclasses give a reasonable representation; newer languages let you require their properties to be verified if you really want.
