Live data from Hacker News

From design patterns to category theory

blog.ploeh.dk

71–78 of 78 posts

Re: From design patterns to category theory

#71
post #23

Earlier quoted context omitted.

How can you call lisp an inaccessible language? It has less syntax than anything else. It is as simple as a language gets.

It's better to have 50 keywords than 1000 nested brackets.

Not really. You can't comment on this until you tried a lisp. I know that you haven't tried it because if you had you would have known about paredit and how it solves the paren problem.

Re: From design patterns to category theory

#72
post #7

I found another interesting approach to formalizing design patterns a few years ago: https://dl.acm.org/citation.cfm?id=2207827 —rather than expressing them as particular instances of more general things (as you'd do using category theory), he breaks them into a small set of more fundamental things which can be re-combined into familiar design patterns. I find it pretty interesting that it's possible to do both of th…

> … rather than expressing them as particular instances of more general things (as you'd do using category theory), he breaks them into a small set of more fundamental things which can be re-combined into familiar design patterns.

How do these two approaches differ from each other? As far as I can see, they’re exactly the same thing. From the linked article:

> Smith introduces a foundational layer of patterns terminology: a collection of core patterns that can't be decomposed further.

This is exactly the purpose of category theory. Rather than have group theory, set theory, propositional logic, etc., category theory unites all of these into something that cannot be decomposed further (identity and composition).

Re: From design patterns to category theory

#73
post #26

Earlier quoted context omitted.

Not sure what you mean by "inaccessible", but you can use monads pretty much anywhere. In my opinion the biggest hurdle is the fact that getting to unrestand purely functional programming is pretty difficult. You start with monads, but quickly find out they do not compose. Move on to monad transformers, good for the simple stuff, but then you hit another wall because they don't compose either! Move on (up!) to tagles…

He means that there's no type syntax to assist with monad creation or usage which indicates a sort of incomplete understanding of the concept. As an example, a maybe monad in python can be implemented by having a monadic function return either: ["Just", 1] ["Nothing", None] and the bind operator (>>=) would be: bind = lambda a, f: a if a[0] == "Nothing" else f(a[1]) You should also understand that a list itself can b…

> You should also understand that a list itself can be a monad.

A list is not a monad — it’s just a container of values, ie. a functor. A monad is a data structure defines a computation in a specific context, and allows composing these in a sequential manner. For example, the Haskell IO monad is a computational context in which you can do input/output, and all of these IO operations are represented using a data structure of the type “IO ”.

For example, the function “readLine” has the type “IO String”, and represents a computation that reads a line from standard input and returns it as a string. At runtime, evaluating this value will result in the runtime system asking the user for some input, and at compile-time this is represented as the string (that the user enters at runtime) inside the IO monad.

Re: From design patterns to category theory

#74
post #73

Earlier quoted context omitted.

He means that there's no type syntax to assist with monad creation or usage which indicates a sort of incomplete understanding of the concept. As an example, a maybe monad in python can be implemented by having a monadic function return either: ["Just", 1] ["Nothing", None] and the bind operator (>>=) would be: bind = lambda a, f: a if a[0] == "Nothing" else f(a[1]) You should also understand that a list itself can b…

> You should also understand that a list itself can be a monad. A list is not a monad — it’s just a container of values, ie. a functor. A monad is a data structure defines a computation in a specific context, and allows composing these in a sequential manner. For example, the Haskell IO monad is a computational context in which you can do input/output, and all of these IO operations are represented using a data struc…

> A list is not a monad

Huh? List is very much a monad.

Re: From design patterns to category theory

#75
post #74
post #73

Earlier quoted context omitted.

> You should also understand that a list itself can be a monad. A list is not a monad — it’s just a container of values, ie. a functor. A monad is a data structure defines a computation in a specific context, and allows composing these in a sequential manner. For example, the Haskell IO monad is a computational context in which you can do input/output, and all of these IO operations are represented using a data struc…

> A list is not a monad Huh? List is very much a monad.

You're completely right. I had no idea.

But I can't make sense of the definition of >>= for the list in Haskell, which is:

    xs >>= f = [y | x 
It seems to imply that I get a list in return when I do xs >>= f, but I need to do the following in order for it to work:

    [1,2,3] >>= return . (+1)

Re: From design patterns to category theory

#76
post #75
post #74

Earlier quoted context omitted.

> A list is not a monad Huh? List is very much a monad.

You're completely right. I had no idea. But I can't make sense of the definition of >>= for the list in Haskell, which is: xs >>= f = [y | x It seems to imply that I get a list in return when I do xs >>= f , but I need to do the following in order for it to work: [1,2,3] >>= return . (+1)

Perhaps this might help (or perhaps not!)

    > [1,-2,3] >>= (\x -> replicate (abs x) x)
    [1,-2,-2,3,3,3]

Re: From design patterns to category theory

#77
post #13
post #12

Better to use discovered languages as they say, but also better to learn the actual abstractions of computation itself, which CT does a great job at, instead of arbitrary patterns that are based on human intuition.

Category Theory is also a set of arbitrary patterns based on human intuition. Just with the added property of being formalised and consistent :)

What about the Curry-Howard-Lambek correspondence? This is directly relate to why math works so well on the real world. CT and pure FP languages seem to tap into this fundamental workings of our mind and possibly the universe (CT is used in quantum mechanics). In contrast things like OOP are modeled based on intuitive patterns that solve specific problems, and which are often based on metaphors or abstract analogies, but not a fundamental abstraction of nature. In other words CT seems to capture the patterns of computation itself.

Re: From design patterns to category theory

#78
post #75
post #74

Earlier quoted context omitted.

> A list is not a monad Huh? List is very much a monad.

You're completely right. I had no idea. But I can't make sense of the definition of >>= for the list in Haskell, which is: xs >>= f = [y | x It seems to imply that I get a list in return when I do xs >>= f , but I need to do the following in order for it to work: [1,2,3] >>= return . (+1)

You're probably use to Monads that wrap a single object, like the maybe monad. Monads can wrap multiple objects or anything. This is the case for a list.
Post reply on HN