
Category Theory and Declarative Programming - CarolineW
http://bartoszmilewski.com/2015/04/15/category-theory-and-declarative-programming/
======
mark_l_watson
Great writing!

The author should consider making that online book into a leanpub book - it
would be nice to get it in ePub or Kindle format.

~~~
gh02t
I've been following this book since Dr. Milewski started writing it. His
presentation really hits a chord with me and it's taught me a ton. I hope he
is planning on at least compiling it into an ebook, but I'm holding out hoping
for an ink-and-paper bound volume too. I feel like the pictures that accompany
all the chapters would look especially impressive in print and I'd love to
have a physical copy to pore over.

------
dkarapetyan
I'm not convinced. Nowhere is the categorical view more visible than in
Haskell and yet some of their most advanced libraries are designed for
providing OOP constructs, e.g. lenses. Another thing is The dreaded monad.
Even though it provides denotational semantics in the categorical setting for
various side-effecting constructs the thing is inherently non-compositional.

Like all things in programming the truth is a little more subtle than just
saying category theory is the right approach for structuring programs. I'm
with Felleisen and Sussman when it comes to these things: Types are stupid and
most of these things are useless when it comes to reasoning about large and
complex dynamic systems.

~~~
d4rkph1b3r
>Even though it provides denotational semantics in the categorical setting for
various side-effecting constructs the thing is inherently non-compositional.

You don't know what this means. Monads are precisely about composition.

~~~
rntz
Monads themselves don't compose nicely. There's no guarantee that the
composition of two monads is itself a monad, for example. That's why Haskell
has monad transformers. But monad transformers are quite hard to reason about
(they're not even commutative).

It's true that in a certain sense monads are "about composition", but that
doesn't mean they aren't without issues, and I certainly think it's
appropriate to call monads non-declarative. In fact, I think "being in a
monad" is more or less the essence of what it is to be imperative - which is
why they're useful! Quite often we _want_ to be imperative.

The word "compositional" is quite vague. I wish people would stop tossing it
around so lightly without explaining what they meant by it.

~~~
smadge
To add on:

For example, monads don't "compose" as nicely as applicatives. You can
automatically compose two applicatives and have a guarantee the the result
obeys the applicative laws. Like you say, for monads you would have to write
your own monad transformer, and hopefully verify it is still a law abiding
monad. You don't have to write a transformer for applicatives.

~~~
willtim
Monad transformers are not the only way of combining effects.

~~~
smadge
Can you elaborate? I don't follow the subject very closely anymore.

~~~
willtim
Here's one proposal for an alternative to monad transformers for Haskell:
[http://okmij.org/ftp/Haskell/extensible/](http://okmij.org/ftp/Haskell/extensible/)

------
mcguire
There's another version of this duality: small step versus big step
operational semantics.

