Via @jonathoda on Twitter, here's F# designer Don Syme articulating his reluctance to adding type classes to #F and his critique of some aspects of typing / type theory in general. https://github.com/fsharp/fslang-suggestions/issues/243#issuecomment-916079347

FWIW I am also an opponent of hierarchy. It's one of those organizational concepts that has always sounded good in theory, but has always caused problems in practice. Is there even a single historical example of a hierarchical programming language concept making things better without any "gotchas"?

cough Haskell cough OCaml cough

Adding type-level programming of any kind can lead to communities where the most empowered programmers are those with deep expertise in certain kinds of highly abstract mathematics (e.g. category theory).

Incredible comment. I particularly like the point about IDEs not supporting debugging of this kind of programming.

In Haskell world, typeclasses could be replaced with two pieces of functionality to avoid an explicit hierarchy and the “tweaking” problem: 1. Programmers can add a named property (aka “law”) to a set of functions+data 2. Programmers can make a property “smart” by adding a default implementation for any set of functions if it has some other propert(y/ies) This is easier for IDEs to support than type classes (but doesn’t help the mathiness power dynamics problem)

To be honest, you just need a good implementation of implicit parameters. That's exactly how type classes are implemented: they are a named collection of functions which are implicitly passed into any appropriately tagged function according to certain resolution rules. Making implicit parameters a language feature gets you 90% of the way there. And no inheritance hierarchies are necessary! But this is a digression 🙂

Hierarchies are OK with me - but only emerged or discovered hierarchies, not designed ones. Many successful hierarchies in computing are simply implementations of well-understood mathematical hierarchies, which themselves were discovered rather than designed. What really stood out for me in this comment is debuggability. That's increasingly becoming a main criterion for me in choosing (and, to the small degree I am involved with this, designing) software technology. I am no longer willing to put up with tools and languages that require me to mentally simulate their inner workings.

I'm reminded of the Web 2.0 idea of folksonomies as opposed to taxonomies. Looks like this is the origin of the term: https://vanderwal.net/folksonomy.html

Many successful hierarchies in computing are simply implementations of well-understood mathematical hierarchies

@Konrad Hinsen I'm curious: what would you say are the "successful" hierarchies in computing? N.B. I assume you mean "*ergonomic/usability* success story", not "successfully commercialized/adopted", since we frequently see some poorly-designed hierarchical concepts get adopted. See HTML/XML, whose hierarchy is so obviously inappropriate for interactive or animated content that people have developed elaborate frameworks to circumvent it.

@Nick Smith I am indeed thinking of usability success, not popularity. Most examples would be domain-specific. The least specific is probably the number hierarchy from integers to reals, though it's surprisingly rarely implemented correctly (in the sense of following mathematics).

It's nice that this design decision is also motivated by keeping onboard "less expert" programmers:

Programmers uninterested in this kind of thing are disempowered. I don't want F# to be the kind of language where the most empowered person in the discord chat is the category theorist.