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

51–60 of 78 posts

Re: From design patterns to category theory

#51

Post by BoiledCabbage »

sandGorgon wrote: post #25
lolive wrote: post #24

Earlier quoted context omitted.

I have learnt monads via the absolutely MARVELOUS book by Brian Lonsdorf. cf https://github.com/MostlyAdequate/mostly-adequate-guide I agree that Haskell is built around those concepts. But the point of learning category theory is to change your mindset when programming. And even in Javascript, it is super useful. (basically because, while trying to learn category theory, you become fluent in functional programming )…

pretty cool. Especially this. > Part 3 will start to dance the fine line between practical programming and academic absurdity. We'll look at comonads, f-algebras, free monads, yoneda, and other categorical constructs. I myself like this - https://github.com/valentjedi/ddd-dynamic - but I'm beginning to think maybe all of this is not the right paradigm for programming in languages like javascript or python. The succes…

I'm not certain, but isn't RxJava just a specific inplementation of a monadic pattern with IObservables?

I thought the original Rx was a Haskeller saying "Hey a 'dsl' built on a monad would be really powerful here in C#" and implemented it. Then it spread to other langs from there.

Re: From design patterns to category theory

#53

Post by crimsonalucard »

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…

Functional programming is just imperative programming with heavy heavy restrictions. So yes this can be done, as long as you fully understand what functional programming really is...

A functional program is simply a program that is made up of a single mathematical expression. Complexity is achieved in functional programming by composing smaller expressions into a single big expression. It should be possible to write your entire functional program as a single expression or statement (not saying you should do it, but it should be possible). That's it. That means all your python functions should be a single expression only (use lambda always instead of def; or if you must use def make sure all your variables remain immuted)

If you want to apply like category theory to it, then just make sure your python functions always stick to specific types. Don't let a function take in either a string or an int and return a list or a iterator or any bullshit like that. Keep the typing consistent... If you define all your functions to behave mathematically like only taking in a string and only returning an int, not an int or a None... then you are following category theory.

So nothing like this:

  def someFunc(value):
     if value == "hello"
        return 1
     elif value == 123:
        return [1,"world"]
or this:

  blah = lambda a: "hello" if a is None else 304
If you wanted automated type checking at run time you can use a decorator to check the types of variables going into the function and coming out.

If you try this style at work, people will complain haha, I don't recommend it

Re: From design patterns to category theory

#54

Post by marcosdumay »

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…

On the other hand, as soon as you know how to apply the concepts of CT, learning Haskell mostly is a matter of syntax. So, why not?

Besides, I don't think you would gain anything by using CT concepts in a language that won't resolve type polymorphism for you. It will lead to a mess of a code, where you'll have to make everything explicit.

By the way, great language. an await command in a where scope is just phenomenal. Between seamless lambdas, interdependent functional declarations, and forced async I don't think it missed any language at its trolling.

Re: From design patterns to category theory

#55

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 ?

Oh and nothing was translated. A monad is a general concept applicable to almost any language. Deep understanding of a monad is to understand it outside of the haskell ecosystem.

Re: From design patterns to category theory

#57

Post by aaimnr »

Mark Seemann, TFA's autor wrote a highly praised book Dependency Injection in.NET and then slowly gravitated towards F# and Haskell. He presents lot of perspectives on FP often in the context of OO alternatives making it easier to appreciate FP advantages not just in theory, but in the context of practical application problems.

I've found his Pluralsight course on Functional Architecture pretty interesting.

Re: From design patterns to category theory

#58

Post by kazinator »

empthought wrote: post #30
201709User wrote: post #28

Earlier quoted context omitted.

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

Personally I don't see the advantage of )}]]})} over ))))))).

It's more time consuming to close )}]]})}. With ))) we just repeatedly type ))) until the cursor jumps to the target opening paren we are trying to close. With a mixture of different parens we have to interrupt what we are doing and determine the correct parens which will continue the closing sequence.

Re: From design patterns to category theory

#60

Post by AstralStorm »

closed wrote: post #36
AstralStorm wrote: post #18

Earlier quoted context omitted.

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?).

Unless you somehow teach people to actually run math proofs on the fly, it won't do any good either way if they start using mathematical descriptions since they will still "fake out" the math.

It is like trying to teach calculus by showing baked approaches at solving integral equations.

Just because you call a thing a Monoid does not mean it is one. Similar in how people use the design patterns in real life, except these do not demand clarity and of you partly misnamed it people are not confused.

Post reply on HN