It's not the idea, but the jargon that's offensive.

I get this with higher-kinded types. The concept seems pretty straightforward to me, but go and read any explanation of it and it seems like someone got a bulk discount on asterisks.

Yeah. It's not actually complicated, but I don't know if you could express it more simply. The "kind" of a type of an actual piece of data is represented with an asterisk. Higher kinded types, then, are thought of as (curried) functions from types to types.

So we have:

    Integer :: *
    String :: *

    Set :: * -> *
    Set Integer :: *

    Map :: * -> * -> *
    Map Integer :: * -> *
    Map Integer String :: *

You can say things like "a type function that takes 3 arguments", but that makes it harder to express things like

    StateT :: * -> (* -> *) -> * -> *

Higher kinded types can be thought of as curried functions from types to types, but that's not how i think of them, and that's exactly the kind of explanation that i find unnecessarily offputting. For some people, thinking about functions on types is natural and useful, but for people not already deep in the functional juju, it's not.

My explanation is something like:

"You know generic types, right? They have a type parameter, and when you bind that type parameter to a particular concrete type, you get a concrete type. So, List<E> is generic, and when you bind it to the concrete type String, you get a concrete type List<String>. Well, a higher-kinded type is a generic type where you can bind the type parameter to a generic type instead of a concrete type. So you might have CollectionMaker<T>, and bind that to List<E>, and end up with a CollectionMaker<List<E>>, where the E isn't bound. Then, particular methods on the class can go on and bind that parameter to particular types."

That explanation is probably isomorphic to the one about functions on types. But it's given in terms of constructs a programmer might actually use.

I'm in favor of getting a variety of approaches to explanation out there. My post was attempting to provide context you'd seemed to be missing, not attempting an entirely separate explanation. I'm sorry you found it offputting. Using C++ template style syntax for paramaterized types does seem a reasonable alternative, though they're not exactly known for their clarity. I do think you're going to lose a whole lot of programmers with CollectionMaker (smelling a bit of industrial-Java style overengineering) - a better example should be found.

"But it's given in terms of constructs a programmer might actually use."

A lot of programmers I know actually use StateT - myself included.