Hacker News Reader

Comment by dkarapetyan | Hacker News Reader

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.

View on HN

Lenses aren't really designed for providing OOP, they just happen to be able to do that too.

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.

OOP is an attempt to manage global state and the mutation of it, lenses are essentially a convenient way of transforming values (without mutation) and are only superficially similar. Side effects are inherently non-compositional, so it's no surprise that they are not easy to model, but Monads are gradually teaching us the best way to handle them. The current state of the art appears to be a single monad parameterized with an effect algebra (supporting composition for some effect types). You are of course free to be a skeptic, but in doing so you are rejecting a large part of modern computer science.

Cam you recommend some easy* literature to understand the things you're referring to? I'm interested in particular in things more flexible and easier to understand than the monad. *as in not written by and for mathematicians

PureScript comes to mind. It takes a hybrid approach to handling side effects (such as console IO, AJAX requests, random number generation, etc.).

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.

[0] http://www.purescript.org/learn/eff/

[1] http://www.purescript.org/learn/

Have a source for that paraphrasing of Felleisen and Sussman?

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.

Yes and yes. Felleisen: https://www.youtube.com/watch?v=JBmIQIZPaHY, Sussman: http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...

Maths will never be obsolete. It's the safest bet if you value your time.

I agree. Sussman is a mathematician and Felleisen is a programming language researcher which is close enough of a field to be considered math.

Types are irrelevant to this discussion (the fact that Haskell is typed is a historical accident; the important factor is that it is lazy), and almost everything is useless when it comes to reasoning about large and complex dynamic systems. Except breaking them into smaller, simpler systems.

I'm curious about your comment about Types. Types are an important part of Haskell and Haskell was largely based on Miranda. What makes you believe they were an accident? There are more research papers about type system implementations and extensions regarding Haskell, than there are about laziness.

Don't get me wrong, types are an important part of Haskell. They're probably a significant chunk of the reason Haskell exists, since that is what separates the ML family from Lisps (again, more-or-less).

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.

> Nowhere is the categorical view more visible than in Haskell

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.

[+] https://en.wikipedia.org/wiki/Universal_property

>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.

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.

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.

Monad transformers are not the only way of combining effects.

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

Here's one proposal for an alternative to monad transformers for Haskell: http://okmij.org/ftp/Haskell/extensible/

Yes, they deal with Kleisli composition (which I intuitively think of as taking regular composition and "twisting" it with a monad) but that is different from what I meant. You can't take two different Kleisli arrows twisted with two different monads and combine them in an obvious way the same way you can compose/combine regular arrows. That is why all the tricks with transformers exist. You somehow have to get everything to be a monad again because Kleisli arrows can't cross monad boundaries.

Reply on news.ycombinator.com