5 ms·

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 con

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.

PeCaN 11y ago
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.
rntz 11y ago
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.
- dkarapetyan 11y ago
  Yes and yes. Felleisen: https://www.youtube.com/watch?v=JBmIQIZPaHY https://www.youtube.com/watch?v=JBmIQIZPaHY, Sussman: http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...
  - willtim 11y ago
    Maths will never be obsolete. It's the safest bet if you value your time.
    - dkarapetyan 11y ago
      I agree. Sussman is a mathematician and Felleisen is a programming language researcher which is close enough of a field to be considered math.
d4rkph1b3r 11y ago
>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 11y ago
  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 11y ago
    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 11y ago
      Monad transformers are not the only way of combining effects.
      - smadge 11y ago
        Can you elaborate? I don't follow the subject very closely anymore.
willtim 11y ago
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.
- paxcoder 11y ago
  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
  - qubitcoder 11y ago
    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/ http://www.purescript.org/learn/eff/ [1] http://www.purescript.org/learn/ http://www.purescript.org/learn/
mcguire 11y ago
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.
- willtim 11y ago
  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.
  - mcguire 11y ago
    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.
deleted 11y ago
[deleted]
auvrw 11y ago
> 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 https://en.wikipedia.org/wiki/Universal_property

PeCaN 11y ago

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.

rntz 11y ago

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.

dkarapetyan 11y ago
Yes and yes. Felleisen: https://www.youtube.com/watch?v=JBmIQIZPaHY https://www.youtube.com/watch?v=JBmIQIZPaHY, Sussman: http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...
- willtim 11y ago
  Maths will never be obsolete. It's the safest bet if you value your time.
  - dkarapetyan 11y ago
    I agree. Sussman is a mathematician and Felleisen is a programming language researcher which is close enough of a field to be considered math.

d4rkph1b3r 11y ago

>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 11y ago
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 11y ago
  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 11y ago
    Monad transformers are not the only way of combining effects.
    - smadge 11y ago
      Can you elaborate? I don't follow the subject very closely anymore.

willtim 11y ago

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.

paxcoder 11y ago
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
- qubitcoder 11y ago
  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/ http://www.purescript.org/learn/eff/ [1] http://www.purescript.org/learn/ http://www.purescript.org/learn/

mcguire 11y ago

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.

willtim 11y ago
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.
- mcguire 11y ago
  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.

deleted 11y ago

[deleted]

auvrw 11y ago

> 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 https://en.wikipedia.org/wiki/Universal_property