From design patterns to category theory
21–30 of 78 posts
Re: From design patterns to category theory
#22The 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 killer.
P.S. I love what dg for python has done - http://pyos.github.io/dg/
>Annoy advocates of the category theory!
>With Haskell's syntax but none of its type system, dg is the best way to make fans of static typing shut up already
Re: From design patterns to category theory
#23The 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.
Re: From design patterns to category theory
#24The 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…
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 ).
Re: From design patterns to category theory
#25The 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…
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 success of tools like React or RxJava in Android makes me think that the tools define the paradigm and not the other way around... no matter how much we want it to be.
Re: From design patterns to category theory
#26The 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 tagless final and/or free monads. There are _a lot of_ concepts that don't have any equivalent in "the real world". The gang of four design patters are a child's toy in comparison.
Re: From design patterns to category theory
#27The 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.
Brainfuck has even simpler syntax and is even more inaccessible. There's way more to languages than syntax.
Re: From design patterns to category theory
#28The 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.
It's better to have 50 keywords than 1000 nested brackets.
Re: From design patterns to category theory
#29I'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.