I wish people could let go of historic terminology

[KillyMXI]

Currently reading https://paullouth.com/higher-kinds-in-c-with-language-ext-part-2/
Decided to write a comment at the following paragraph:

Those of you that have been paying attention will notice that Mappable is, of course, a Functor! Yes, I realize this was hardly the reveal of the century, but for those of you who are relatively new to functional programming, terms like Functor might be a bit too much to take in whilst learning about a new technique for higher kinds! Now when you hear "Functor" just think "Mappable".

While I'm excited about functional programming, not all of established names speak to me.
Some just leave my ADHD brain without a mark. I still have an idea of a computational flow, but I have no word to refer to it.

I wish people could let go of the self-reproducing loop of terminology, and for the worst offending terms, switch to something more descriptive for average minds. So the whole functional programming could be made friendlier...

While part of audience can appreciate parallels with Haskell, other part could probably better appreciate parallels with more pragmatic naming of standard C# functions. Albeit I can imagine their existence might be the reason to avoid collisions...

I don't expect to convince any change, but I need the discussion to exist.
At the very least, it may motivate better documentation. Be conscious about the difference between what is familiar and what is sensible/descriptive.

[louthy]

Whilst I understand where you're coming from, there are deeper meanings to most of the terminology that can become blurred when you start inventing new 'pragmatic' names. A functor, for example, is a structure preserving morphism between two categories in category theory. Now, you don't need to care about that right now whilst learning that "functors have a Map function", but as you become more skilled in functional programming and understand more of the theory behind it, you'll realise that calling functors Mappable just won't cut it and isn't enough when trying to talk precisely about the more general concepts.

So, a term that changes depending on your skill-level is, I would argue, worse. It's better to learn them upfront in my humble opinion. As a fellow ADHD sufferer I've not found it particularly problematic, it's just a case of getting used to a different paradigm's lexicon.

It's not like OO doesn't have a similar problem with terminology: polymorphism, instance, inheritance, object, class, method. You may think that - other than 'polymorphism' - they're easy to understand, because they're words from 'real life'; but they are all misleading terms that cause massive problems due to their apparent ease-of-use. They're imprecise and often outright lies! But because they're common terms we think it "makes more sense". But, what happens with OO is you learn the terms quickly and then spend a lifetime dealing with the fallout of their imprecision.

For example, "object", in the real world objects don't mutate in-place, they have a history, time exists, and causality holds. That isn't true for OO objects. Objects in the real world don't have behaviours attached to them. They are pure state. Yet we attach behaviour to our state in OO-land. This problem exists for most OO terms and I think it causes some pain points, especially dogmatic pain points.

FP has its own lexicon, which is (on the whole) more precise - mostly because the terms are from mathematics. However, because the terms aren't used day-to-day they can initially seem impenetrable. But, once learned there isn't the same long-tail of misunderstanding as there is in OO-land.

[KillyMXI]

But at the end of the day using that terminology allows us to draw intuition/connections from millions of other projects/people that use that terminology.

For me it looks like some kind of technical terminological debt. It keeps us going, but requires more and more effort to do so.

My exact issue in the title. I think humans need to "refactor" these things from time to time.

English is a pretty shitty language but it'd be dumb to rewrite all our docs in Esperanto or something.

I don't think this is a good analogy.
(But I would also love to see some language reforms to make them less shitty...)

[louthy]

Changing the terms, because you're not willing to learn them, seems a little harsh on those that have, no? They now have to go and learn a whole new set of terms for things they already have an intuition for and understanding of. All papers written on the subject become meaningless, all code written using those terms need refactoring... just because you don't like "functor" -- seems a lot of work to me!

There's a satirical take on the history of programming languages, which is hilarious, but is also the origin of the famous "a monad is a monoid in the category of endofunctors, what's the problem?" trope.

1990 - A committee formed by Simon Peyton-Jones, Paul Hudak, Philip Wadler, Ashton Kutcher, and People for the Ethical Treatment of Animals creates Haskell, a pure, non-strict, functional language. Haskell gets some resistance due to the complexity of using monads to control side effects. Wadler tries to appease critics by explaining that "a monad is a monoid in the category of endofunctors, what's the problem?"

It is obviously aiming at the some of the same issues you're raising. But, if I reword that sentence to use the terms I'm using in the Higher Kinds tutorials then I'd get:

"An chainable is an addable in the bag of self-mappables, what's the problem?"

Which is now truly meaningless and imprecise: monads are more than just 'chainable'; monoids don't just add; and functors have a deeper meaning than just mapping - the topic of functors is so unbelievably large -- and their impact on mathematics huge -- that calling them 'mappable' almost seems offensive to functors, haha!

With the original statement, even if its terminology is dense, I can completely understand what it means -- it's precise. Which was the point I was trying to arrive at in my first post.

You dismissed the precision argument out of hand in your reply - I understand that it may not seem as important if you're coming from OO where there's very little precision and very little theory. But, whether the names feel awkward or not, is not the point. If the names mean 1 thing only and that 1 thing has an accepted meaning, then everything becomes more precise.

If you go and read about functors on wikipedia then you'll see that not only is there definition of words, but there's a mathematical definition, that definition comes with a proof -- we can prove if our code is correct.

"Mappable" has no such wikipedia entry.

The reason I believe the precision argument is a very strong one is that function-composition is everything -- EVERYTHING in functional programming. And function composition requires precision, otherwise the composition fails:

For example:

a → b   (Func<A, B>)

Composes with:

b → c   (Func<B, C>)

Creating:

a → c   (Func<A, C>)

If your components are pure and total then the composition is pure and total. This is the superpower of functional programming. It's all there in the examples above. Composition doesn't work in OO, which is why its hitting complexity limits now, because it's hitting the grey-matter limits of the humans writing the OO code. However, pure functional composition can keep going forever -- turtles all the way down.

The problems with the composition above comes with more complex types (higher-kinded types):

a → List<b>

How do I compose that with:

b → c

I use a functor, it gets me:

a → List<c>

What if the thing I am composing with also produces a higher-kind?

a → List<b>

Composed with:

b → List<c>

If I use functors I get:

a → List<List<c>>

Instead, I use 'monad', it gets me:

a → List<c>

You can think of these terms as less like "object", "inheritance", etc. and more like the 'Gang of Four' Design Patterns -- which all OO devs end up having to learn the names of eventually. Monoid, functor, monad, applicative, etc. are all just 'design patterns', or more precisely, a set of mathematical rules that define the shape of function composition.

When everything is function composition, I think it's much more important to have precise definitions.

In my mind a tutorial should use whatever terminology and whatever analogy it needs to help the student to learn. But, it shouldn't stop short and not give the student the academic definition. I use the terms 'Mappable', 'Addable', etc. on my site to help ease the novice reader to get in to the subject. But, I think it would be dishonest to leave them thinking those were the terms that the FP paradigm uses. Or, that the narrative I use on the site is the end of the story.

I have a particular issue where this has been done elsewhere -- 'Railway Oriented Programming' is an attempt to take the route you advocate -- in this case as an alternative terminology for monads. Unfortunately, the analogy only works for the simplest monadic types and breaks down with the more advanced methods, leaving the student without the tools to get to the deeper meaning. This, I believe is the problem with being imprecise.

[KillyMXI]

because you're not willing to learn them

This is incorrect. I simply can't. It might be my neurodiversity. But the tragedy of it is that we can't fathom how each other is handicapped even while we know how we ourselves are handicapped.
Things I pick up on - are more important for me to function than other people can accept. But I believe they may also make the world more accessible for everyone.

"An chainable is an addable in the bag of self-mappables, what's the problem?"

I love it. You've only proven that it can be more accessible if you leave out the snobism.

All papers written on the subject become meaningless

I disagree. The language itself is evolving, albeit slowly.
This becomes a concern for those looking back. I would say, while submerged in certain context, it should be possible keep awareness of evolving terminology.
But for the rest of us it would allow to move forward faster.

If we bring up anecdotes:

The story goes that during an interview, Brendan Eich was asked about a bug in the language, and he reportedly responded with something along the lines of "Are you kidding? We can't fix that bug; there are tens of thousands of websites that depend on it!"

(I can't find at the moment where I read it, so this is just how ChatGPT remembers it, unfortunately.)

The point is, for any refactoring, the time when it is cheapest to introduce is right now. The "sunk cost" just keeps increasing, and so does the negative impact of not doing it.

You dismissed the precision argument out of hand in your reply - I understand that it may not seem as important if you're coming from OO where there's very little precision and very little theory. But, whether the names feel awkward or not, is not the point. If the names mean 1 thing only and that 1 thing has an accepted meaning, then everything becomes more precise.

It's not about OO background. Things wouldn't be any different even if I weren't familiar with it prior. And we can still mean the precise thing and give it a name that requires less explanation.

I may need to clarify: I'm not completely new to functional programming either. I've been learning Haskell quite successfully few years back. I have no use for Haskell itself now, but it affects my programming practice in different languages. My knowledge of related areas of mathematics is quite surface level but not zero at least. I'm happy to incorporate all available functional features in different languages but I have limited capability and interest to focus on it above pragmatic purposes.

"Mappable" has no such wikipedia entry.

The Functor page defines it as:

In mathematics, specifically category theory, a functor is a mapping between categories.

And links to links to https://en.wikipedia.org/wiki/Map_(mathematics)

So why the extra step from very arbitrary name (https://en.wikipedia.org/wiki/Function_word causes the eyebrows raise - how arbitrary this is)?
"Mappable" or "morphable" or "catmap" - I still can't see how it can ruin the precision. If anything, it can add it.

Following examples miss the point, I think. I have no issue about precision. I think naming problem is a separate one.

OO Design Patterns

I understand the parallel. I also think, to the most part, design pattern names are more descriptive of what they do. Less linguistic constraints and less creativity in naming.

In my mind a tutorial should use whatever terminology and whatever analogy it needs to help the student to learn. But, it shouldn't stop short and not give the student the academic definition. I use the terms 'Mappable', 'Addable', etc. on my site to help ease the novice reader to get in to the subject. But, I think it would be dishonest to leave them thinking those were the terms that the FP paradigm uses. Or, that the narrative I use on the site is the end of the story.

I appreciate that. But I think there should be collective transition from "what was introduced as Mappable is actually a Functor" to "Mappable was also known as Functor".
It won't happen in a moment, it won't cause a tragedy of epic proportions.

Railway Oriented Programming

I don't advocate for something like that. I'm aware that all analogies are of very limited use for monads.
I think some things can be renamed based on what is already there, what we know now, with all the hindsight.

[KillyMXI]

Iirc, the graph shown at https://wiki.haskell.org/Typeclassopedia evolves over time itself, and Haskell language has to evolve following our best understanding of the functional building blocks.
That's why they are "trying to avoid popularity by all cost" - to have the room to break things.

I don't think naming can be more sacred than that.
We need to break things from time to time.

[louthy]

"An chainable is an addable in the bag of self-mappables, what's the problem?"

I love it. You've only proven that it can be more accessible if you leave out the snobism.

"snobism" -- I think you just outed yourself there. This isn't snobbishness or elitism, it's actually deferring to accepted norms within the pure functional programming community. The .NET ecosystem has classically been very insular -- initially by being against open-source and now it's more that "only .NET open-source will do". Whereas I am trying to make this library a part of the wider open-source community and a wider push for pure functional programming. I want it to be trivial for people who use Haskell, or PureScript, or Cats in Scala to transfer their skills over to C# and use this library, just as I want it to be trivial for C# devs who have worked with language-ext to transfer their skills to other ecosystems -- that doesn't happen by creating a whole new dialect and cutting ourselves off from everyone else.

But, going back to the sentence "A chainable is an addable in the bag of self-mappables, what's the problem?" and your claim that it's "more accessible". It isn't. It is utterly meaningless. Because it doesn't come with any supporting definitions.

The original: "a monad is a monoid in the category of endofunctors, what's the problem?" has:

• "Monoid" -- which I know is a single object category where all morphisms are from and to that object
• "Functor" -- which I know is a mapping between categories
• "Endofunctor" -- which I know is a functor from a category back to the same category. So it's a functor that points back to itself.

Those terms each have terminology in their definitions:

• Category
  • Contains zero or more Objects
  • Objects can have zero or more morphisms connecting them
    • The morphisms create a 'relationship' between the objects
  • Morphisms compose
  • Morphism composition must be associative
  • All objects have identity -- a morphism from and to itself
  • Categories themselves can be Objects in larger categories - creating a structure that allows mapping between categories aka functors.
• Objects
  • The smallest unit
  • Can represent anything at all
  • You can't "look inside" and see the details of an Object, it just is.
  • Has identity

That's ^^ all of category theory right there btw. Those definitions create laws and structure that mean something when you say "a monad is a monoid in the category of endofunctors". Those definitions don't exist for 'Mappable' or 'Chainable'. You could, of course, clone those rules for Mappable and Chainable -- but then consumers of Mappables and Chainables have to go and find out what they are, which seems like they're gonna have to learn the rules anyway -- you may as well learn its real name at the same time and leverage the many acres of online material talking about them.

I also think, to the most part, design pattern names are more descriptive of what they do. Less linguistic constraints and less creativity in naming.

I went to look at the list from the Design Patterns book when I wrote that and honestly I couldn't remember what more than a few of them did and, with many of the ones I'd forgotten, I couldn't infer what they did. And that's my ADHD, my brain rapidly forgets stuff it hasn't used. The names may appear more approachable, but I don't think the names alone are meaningful in any way, you still have to learn the rules.

"Mappable" has no such wikipedia entry.

The Functor page defines it as:
In mathematics, specifically category theory, a functor is a mapping between categories.
And links to links to https://en.wikipedia.org/wiki/Map_(mathematics)
So why the extra step from very arbitrary name (https://en.wikipedia.org/wiki/Function_word causes the eyebrows raise - how arbitrary this is)?

Because 'Map' on its own is not a functor. For example, a function from A → B could be considered 'Mappable', it maps an A into a B. And in maths 'map' is literally just a function. But a functor has additional laws that make it a functor beyond just having a map function. The image in the wikipedia page you link to shows the problem -- it isn't structure preserving and functors are structure preserving. There is no requirement for Mappable or for any other functions to preserve structure, therefore the terms have less meaning by default. The laws are what make it a functor. When people know it's a functor, they expect it to follow the functor laws - this allows additional insight into these traits and to make inferences that don't require the programmer to go and look at the code behind the curtain (true abstraction).

By the way, you don't get on my good side by comparing this library to the clusterfuck that is JavaScript! This library is nearly 10 years old and, the terminology isn't going to change. I don't consider it to be a mistake to use the names that are directly from mathematical concepts - which automatically have documented meaning. There are some new traits that I have either already changed or am considering changing - but only the ones that aren't backed by a named mathematical concept. Alternative for example is a new trait that I have changed from the Haskell equivalent. It is essentially a lifted monoid and at the moment there's SemiAlternative (lifted semigroup) and Alternative (lifted monoid) -- I don't like these names and I don't think there's a mathematical concept that backs them, so it's on my TODO list to consider before a beta release of v5.

I realise it's not ideal for you, but the one positive I can offer is that none of these terms are needed to leverage the library. If you want to do the super-abstract programming, yeah, learning the terms is useful. But you don't need to know what a functor is to call list.Map(f) or any of the other methods. Another thing to note is that this library is very much planting a flag in the pure functional paradigm, where the terminology is what it is, but there are obviously other approaches to functional programming. The F# community looks less to Haskell and more to the OCaml side of things -- there's less focus on the mathematical abstractions and in some quarters a pushback against it. There may well be other functional libraries in C#-land that have a similar ethos. It just ain't gonna be this one ;-)

[KillyMXI]

I do feel there's often a snobbishness about those of us who are doing functional programming in C#. The arguments are nearly always based around some bullshit academic reasoning, which I don't think adds anything.

from

the irony

We all draw lines somewhere, and similarly displeased to find ourselves on a different side of someone's else line...

[louthy]

Taking arguments out of context isn't adding any value to this discussion. That argument is about the internal implementation of the language -- making a point that Haskell is implemented with an extended lambda calculus adds no value to a discussion about whether hkts in c# are valid. The argument is purely academic, adds nothing, and isn't related to the duality between tuples and applications.

Trolling this forum is not appreciated. I don't spend hours of my life building language-ext to deal with this unnecessary level of time-wasting.