Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From design patterns to category theory

blog.ploeh.dk

Post reply on HN
Print view View original

41–50 of 78 posts

Re: From design patterns to category theory

#41

Post by terminalcommand »

ambicapter wrote: post #34
terminalcommand wrote: post #10

Earlier quoted context omitted.

Full disclosure: I have not dabbled with data science, nor I'm an experienced programmer. But many of the CS pioneers dealt with the issue of reading input, processing it, and giving a meaningful output. Recently I've stumbled upon Jackson's Principles of Program Design and it has really helped me in writing a parser. IMHO general understanding of structuring a program goes a long way than arbitrary design patterns.…

Its always hard for me to decide how those modules are going to end up communicating though. Should there be a lingua franca to all your modules? Or do they all have specialized APIs?

Programming to interfaces help in this matter. e.g. if I have a data interface, I could use the same type on any format I liked. If it is the same interface, methods are the same too.

For encapsulation and message passing, coroutines work wonders. You could use a generator in Python, or a goroutine in Golang. And then you could treat different modules of your program, as if they were a standalone independent part.

Re: From design patterns to category theory

#43

Post by pizza »

uptownfunk wrote: post #8

Has anyone come across design patterns w.r.t data science (e.g., importing / transforming data / creating a modelling record / doing a grid search / scoring a new data set / outputting results?) I see these things running in scripts generally, but wondering if there are any applications of design patterns to a data science workflow.

There's another mathematical approach: http://www.drmichaelrobinson.net/sheaftutorial/index.html

Re: From design patterns to category theory

#44

Post by tasuki »

sandGorgon wrote: post #40
tasuki wrote: 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…

genuine question - can this be done in python in a production ready manner ? I'm have been trying to answer this question for quite some time. In Haskell, writing monads or applying category theory is part of the idiomatic language. Not so in js or python. for example, if you want to apply haskell like concepts in javascript, the closest thing I know is purescript ( http://www.purescript.org/ ) or Bucklescript. So yo…

Wrt your question about production-ready manner: I don't know.

However, there are many libraries which make functional programming in Python seem viable. See eg: https://pypi.python.org/pypi/PyMonad/

Re: From design patterns to category theory

#45

Post by lmm »

conistonwater wrote: post #2

> It seems to me that some design patterns are essentially ad-hoc, informally specified, specialised instances of basic category theory concepts. There is a flaw in this type of thinking which I think is not addressed here, but should be. (I took the quote from the summary, but I think it's fair.) The usual issue with ad-hoc informally specified things is that the ad-hocness and the informality leaves something out,…

It's always possible to write the non-generic version of a generic method and still get it right. I mean, there are mistakes that the formality will help you avoid (e.g. if you violate associativity, even in a seemingly trivial way, it will always come to bite you at the worst possible time), but it's possible to just not make those mistakes. The advantages of the generic formalism over reimplementing it specifically every time are, just like for any other use of generics, saving code and being able to reuse existing library methods (e.g. traverse, mfix, the various recursion-schemes traversal operators).

Re: From design patterns to category theory

#46

Post by lmm »

sandGorgon wrote: post #40
tasuki wrote: 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…

genuine question - can this be done in python in a production ready manner ? I'm have been trying to answer this question for quite some time. In Haskell, writing monads or applying category theory is part of the idiomatic language. Not so in js or python. for example, if you want to apply haskell like concepts in javascript, the closest thing I know is purescript ( http://www.purescript.org/ ) or Bucklescript. So yo…

> genuine question - can this be done in python in a production ready manner ?

It can, but without a type system you lose most of the benefits. You can put monads in there but if you refactor fearlessly the way you would in Haskell (without tests), you'll get production bugs.

> Compare this to design patterns or OO, or reactive programming (via rxjs or whatever) - which are so accessible that they are now the reason to learn a particular language!

Isn't that the same thing? Monads etc. are the reason to learn Haskell.

Re: From design patterns to category theory

#47

Post by crimsonalucard »

tasuki wrote: post #26
sandGorgon wrote: post #22

The problem with category theory and monads, etc are that they are inaccessible for some of the popular tools. E.g. javascript, python, ruby . It invariably happens that learning these patterns needs you to learn haskell, lisp or erlang. Which is where accessibility breaks down. If there was a conceptual framework that bridges these higher order designs to accessible languages .. even if partially so, that would be k…

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 be a monad. Monads are just burritos where ANY abstraction/design pattern can be the wrapping, it does not need a haskell type system to wrap something. Albeit the type system in haskell does really help you grok the concept.

Weirdly how someone chooses to implement a monadic value and the bind operator suffers from the same problem as what this article writer complains about in OOP design patterns. Both monads and design patterns really depend on previous understanding of a pattern, and a variation on how someone chooses to implement the bind operator or a design pattern can really throw off people.

Here is an example of an alternative variation of the "Maybe" monad in python, for the return values:

  ["Only", 1], None
And a variation on bind:

  bind = lambda a, f: f(a[1]) if a is not None else None

Re: From design patterns to category theory

#48

Post by sandGorgon »

crimsonalucard wrote: post #47
tasuki wrote: 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…

this is a super interesting reply - you kind of translated these monadic concepts to python.

Is there a resource for this ? or good old intuition ?

Re: From design patterns to category theory

#49

Post by loup-vaillant »

AstralStorm wrote: post #18
closed wrote: post #4

Earlier quoted context omitted.

Wow, this really struck home the idea of useful forms of generality for me. Definitely reminded me of an interesting section in Polya's book Induction and Analogy in Mathematics that discusses different forms of generality, and when it's useful (in the context of a problem to figure out).

And then you wake up to the fact that most programmers are really bad at higher abstractions and especially mathematics. They start off way better than general population too... But they can deal with nested smaller abstractions or impure smaller abstractions just fine. It is easier to think of a set of logic properties than essentially equation describing construction of an object with such properties. And that is t…

> most programmers are really bad at […] mathematics.

I wouldn't be so sure. Many of us got into programming to flee what we often call "mathematics". But the stuff we learned in school is quite different from actual mathematics (rote application of recipes, and tedious exercises, mostly).

I'm pretty sure we can teach maths to those traumatised programmers. Just don't utter the "M" word so they don't recoil in horror.

Monoids for instance are a deeply mathematical, yet very simple concept. And useful too: want to do map-reduce? make sure your binary operation is associative (meaning, make sure your stuff is a monoid), or you won't be able to parallelise your reduce step.

Re: From design patterns to category theory

#50

Post by crimsonalucard »

sandGorgon wrote: post #48
crimsonalucard wrote: post #47

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…

this is a super interesting reply - you kind of translated these monadic concepts to python. Is there a resource for this ? or good old intuition ?

Nah no single resource, it took me a lot of time to understand monads, going over many resources.

Just remember Absolutely ANY design pattern / data structure can be a monad as long as you can get an internal value out of that abstraction and define a bind operator to compose monads together.

This rule tells it all:

  (>>=)            :: m a -> (a -> m b) -> m b
m is the abstraction wrapper and a is the internal thing that is wrapped. You can wrap it in a type string, a list. Even like a binary tree can be a monad.

You can define the bind operator to do whatever you want, it just needs to follow the type signature above and be associative.

Post reply on HN