[ebola1717]

Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: )

Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't help you do anything with it though. And Future technically doesn't even truly obey the Monad laws, because of exceptions.

It's useful that a couple of container classes in scala use implement this trait:

    trait ChainableContainer[A] {
      def map(fn: A => B): ChainableContainer[B]
      def flatten(nested: ChainableContainer[ChainableContainer[A]]):ChainableContainer
    }

But beyond making it a little easier to guess what's going on, the underlying math isn't useful in actual programming.

[tel]

That has a little to do with Scala just being a pretty bad place to implement most of these things. E.g., Monad transformers work just great in Haskell but are terrible in Scala due to the sort of terrible ways type parameters and inference work together.

Future also doesn't obey the monad laws for not being RT and that causes a lotttt of complexity.

[throwawayjava]

OK, I'm another data point for "studied category theory; program in an ML dialect; think it's silly".

Most all the theorist/logician/algebraist-turned-programmer folks I know all feel more-or-less the same way.

Just explain the pattern in english. Might as well call it a FooDeBar. Giving axioms and such is usually a waste of The Man's money and my time.

That said, I think it's extremely valuable to see this sort of thing in an academic or side project/enrichment activity setting. The mindset and mental model are fantastically helpful. See dshnkao's post, for example.

[Myrmornis]

Just to be clear, you're advocating:

1. Don't use terminology from academic category theory / abstract algebra in computer programming

2. But if you haven't studied these things, and you are a programmer, it might be very enlightening to do so.

Is that right?

[throwawayjava]

> category theory / abstract algebra

Woah there!

But otherwise, yes.

Most working mathematicians have seen category theory and borrow bits and pieces of notation and such. But most of their work is done in far more concrete settings.

Working programmers should adopt the same arrangement.

It's a subtle position, but not an inconsistent one. I promise :-)

[hota_mazi]

It's not just monad transformers, monads themselves are pretty awkward to use in any language that's not Haskell. And actually, a lot of FP languages simply don't even have monads at all (OCaml, F#).

Monads should never have escaped Haskell.

[tome]

> Monads should never have escaped Haskell.

They should have put them in a monad.

[s4vi0r]

Isn't a Monad just the fancy name for a type/structure that implements map and flatMap in a lawful manner?

[hota_mazi]

Close: the required operations are `flatMap` and bind/pure/point/lift/return/whatever-you-want-to-call-it.

You can derive `map` from these two other functions so it doesn't need to be part of the interface.

[ebola1717]

Bind is flatMap (>>=)

Confusingly, map in scala is fmap in Haskell

[hota_mazi]

Oops you're right of course. And I can't edit my post.

[Retra]

I was reading very famous paper[1] today, and I stopped at the following:

    "To get an adequate definition of g [<] f we must therefore consider all possible algorithms for computing f."

You see, I was reading this paper because I'm currently looking into various ways of that the symmetries of Turing machines are modeled (I.e., the fact that a TM can emulate any other TM would seem to imply that the concept of an 'algorithm' must have fundamental features that are preserved across this kind of virtualization. Closely related to the concepts of an Oracle, a Non-deterministic TM, and recursion.)

Now, this passage stood out to me because it seemed to be a set-theoretic, indirect phrasing of the exact symmetry I'm talking about. We have to consider all algorithms for computing f in order to recover the features that must be true for all f, and thus give identity to the notion of a general algorithm for f. Which in turn is used to establish theorems about such a general algorithm notion; (critically, its "relative complexity".)

My point being that I would not have expressed this notion in set theoretic language because my intuition wants it expressed in algebraic language. Things are identified by their symmetries, and building theories around symmetries directly is more efficient and insightful than building theories around how those symmetries are embedded in set theory. And when I sit around thinking about how to design a good API or an efficient program, I want to do it by stating what must always be true about the problems I'm solving, in a high-level, abstract way. (I'm not so good at it in practice.)

Set theory may be a simple model of many things, but it is only really intuitive for things that can be easily described in terms of unions and intersections. It is often just extra work elsewhere, at least if you have a frame of mind to see other ways.

[1] https://www.cs.toronto.edu/~sacook/homepage/rabin_thesis.pdf

[tome]

http://h2.jaguarpaw.co.uk/posts/greenspun/

[dshnkao]

as someone who also works in scala, MonadTransformer is so much better than gigantic nested flatMaps and pattern matchings