Of course, type classes still offer a couple of extra niceties, e.g. that type class instances can be inferred whilst extra arguments generally can't, and that instances are globally consistent (this is important for `Set`, which the article also mentions is a counterexample to `Functor`). Still, type classes seem to appear less and less elegant as time goes on (e.g. compare their use in dependently typed languages).
I'm optimistic though, as that indicates that we're asking questions and setting expectations of our systems above and beyond what was common 20 years ago.
I do think typeclass programming could do with having the same functionality as ordinary programming available. Here in Scala typeclasses are ordinary values (resolved via an implicit mechanism), which enables a lot - though the cost of abandoning global coherence is high.
Ultimately, syntax and conciseness does matter. I don't think anything as verbose as that link has a chance of getting off the ground.
Not really. There's no way to enforce that each Order has a singleton type which is what you'd need to resolve that.
I think part of the problem is that type classes are so easy to abuse. When you have a problem like e.g. monad transformers, where a) you have a lot of boilerplate code which would be irksome if written out by hand, b) you have laws to make sure the generated code is sensible, and c) your types have exactly one such sensible instance, then classes are very nice. Abuses of type classes exist where any of the three above conditions fail to hold IMO, and a scrap-your-typeclasses approach can be very valuable then.
This is a good reason to implement traverse in terms of Applicative rather than Monad - foldMap then becomes just a special case of traverse.