Category Theory and Declarative Programming
bartoszmilewski.com
bartoszmilewski.com
The author should consider making that online book into a leanpub book - it would be nice to get it in ePub or Kindle format.
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.
Have you ever wanted to return a copy of an array with an element changed? Like (JS) var new_a = a.concat(b) gives you a new array, don't you sometimes wish there was e.g. new_a = a.update(3, x)? I sure have. That's what lenses do, and they do that more efficiently and for way more than just arrays.
I don't know about Sussman, but I'd be surprised to hear Felleisen say that. My extremely loose characterization of Felleisen's view would be that the most important types are the ones in your head, which is not quite the same thing.
You don't know what this means. Monads are precisely about composition.
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.
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.
I'd recommend checking out Phil Freeman's article, which provides a nice overview along with many concrete examples [0]. Unless you've had prior exposure to Haskell, I wouldn't get too hung up on the syntax--but if you're curious, the PureScript learning resources are fantastic; I wish such resources existed when I was trying to learn Haskell! And frankly, these concepts require repeated exposure, practice, and some time to marinate in your brain before their usefulness/power become clear.
Types are, however, irrelevant to Haskell's relationship to category theory, which is more-or-less the topic under discussion. Haskell needs monads in order to do stateful things like IO, that are necessary for a programming language but a thorn in the side of lazy languages which don't have an easily defined execution order.
Category theory's importance to Haskell and vice-versa have nothing to do with Haskell's type system and much more to do with the fact that it is a lazy functional programming language. In fact, one of the weaknesses of Haskell's type system is that it can't enforce the "monad laws" when you give an implementation of the monad typeclass.
and the author's point when he writes In ... Haskell ... types ... are built in, rather than being defined by universal constructions [+] is indeed that current programming languages don't entirely capture what category theory is about in practice.