From design patterns to category theory • Hacker News Board

Re: From design patterns to category theory

#31

Post by TuringTest » Thu, Oct 05, 2017, 11:13 AM UTC

westoncb wrote: 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.

I haven't read that book, but it sounds similar to how Peter van Roy deconstructs programming paradigms:

[1] https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf

[2] https://en.wikipedia.org/wiki/File:Programming_paradigms.svg

Re: From design patterns to category theory

#32

Post by hoorayimhelping » Thu, Oct 05, 2017, 11:22 AM UTC

edem wrote: post #23

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…

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

How many stack overflow questions and answers are there for lisp(s)? How many for Java? How many applications on the web are written in a lisp? How many are written in Java (or Python or Ruby or PHP)?

There's a lot more to accessibility than how easy the syntax is to grok. This is just one simple and limited example.

Re: From design patterns to category theory

#33

Post by avodonosov » Thu, Oct 05, 2017, 11:25 AM UTC

through blockchains?

Re: From design patterns to category theory

#34

Post by ambicapter » Thu, Oct 05, 2017, 11:46 AM UTC

terminalcommand wrote: post #10

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.

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?

Re: From design patterns to category theory

#35

Post by mikekchar » Thu, Oct 05, 2017, 11:54 AM UTC

vog wrote: post #17

defined wrote: post #9

> I'll write these articles in an authoritative voice, because a text that constantly moderates and qualifies its assertions easily becomes unreadable. Don't consider the tone an indication that I'm certain that I'm right. Kudos for including this disclaimer. The article can be trim and readable, while the disclaimer acts to dissuade well-meaning reviewers (like - ahem - me), who sometimes value precision and accurac…

In other words: strong opinions, loosely held. Shouldn't this be the default expectation, for every article we read, anyway? Such a disclaimer makes only sense if the article was written by some very famous author who must reasonably fear that their advice is taken too dogmatically. Speaking of that, I've never seen people like Martin Fowler make such a disclaimer.

To be fair, Martin Fowler's entire blog is a "bliki" because he intends to (and does) change his entries often. He's even ripped out entire swathes of his writing when he thinks he's wrong (occasionally frustrating when you think he's wrong about being wrong ;-) ).

I assume he doesn't make such a disclaimer because he thinks everyone already realises it -- but I have to agree that it would be nice if he (and other people as well) did. A lot of times people seem to think that reading something from a well known author is equivalent to permission to turn their brains off :-( Instead of, "Oh, that's amazing! Let's try it", they think, "Oh, that's amazing! We don't have to try it".

Re: From design patterns to category theory

#36

Post by closed » Thu, Oct 05, 2017, 12:02 PM UTC

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…

I don't know if they're bad at higher abstractions, or if the pay-off of a higher abstraction isn't always there (or is unclear).

The original comment did a good job of illustrating this. It's not clear from this post what category theory can do for a person programming with design patterns in mind (in other words, how will it change their behaviors?).

Re: From design patterns to category theory

#37

Post by Udik » Thu, Oct 05, 2017, 12:05 PM UTC

201709User wrote: post #28

edem wrote: 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.

I think there are people who value completeness- they enjoy working on systems with many rules tailored for specific use cases, and like accumulating knowledge about which rule is the correct one to apply in each situation; and there are people who value open-endedness- systems that have few simple rules that can be combined to obtain novel and unexpected results, even if these are not as optimized as they could be in a more complete system.

I picture the difference as that between a role playing game and chess: complex, domain-specific rules on one side, simple and abstract rules on the other.

Re: From design patterns to category theory

#38

Post by heroku » Thu, Oct 05, 2017, 12:13 PM UTC

how long do we wait until the series is complete, a year?

Re: From design patterns to category theory

#39

Post by madhadron » Thu, Oct 05, 2017, 12:30 PM UTC

fmap wrote: post #29

I'm looking forward to reading this series! Based on the overview, I would call it "From design patterns to algebra", though. There's (in most cases) no reason to involve categories in a discussion of monoids/semigroups and isomorphisms.

That would be my choice of title, too. I considered writing exactly such a thing a few years ago, but realized that I am almost certainly the wrong person to do so, since I use the algebras but not the design patterns that approximate them.

Re: From design patterns to category theory

#40

Post by sandGorgon » Thu, Oct 05, 2017, 12:46 PM UTC

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…

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 you need to switch over to a different language to achieve the richness of these concepts.

I'm hardpressed to apply these concepts idiomatically to the mainstream languages. 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!