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.
From design patterns to category theory
71–78 of 78 posts
Re: From design patterns to category theory
#72I 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…
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
#73Earlier 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…
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
#74Earlier 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…
Huh? List is very much a monad.
Re: From design patterns to category theory
#75Earlier 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.
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
#76Earlier 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)
> [1,-2,3] >>= (\x -> replicate (abs x) x)
[1,-2,-2,3,3,3]Re: From design patterns to category theory
#77Better 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 :)
Re: From design patterns to category theory
#78Earlier 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)