5 ms·

I think it does. Of course, I think this as somebody who has just begun learning about it, so I certainly don't speak from any experience :P. Particularly, cat

by tikhonj 14y ago

I think it does. Of course, I think this as somebody who has just begun learning about it, so I certainly don't speak from any experience :P. Particularly, category theory seems to center around abstraction. I think abstraction is essentially the core of CS (but maybe that's just because of SICP) and exceptionally important in everyday programming. Learning this sort of math (along with some related fields like abstract algebra) essentially allows you to unlock a higher level of abstraction. This can help in two ways. For one, it allows you to write more general code and create extremely useful libraries. The Haskell standard library, naturally, is a great example of this. Additionally, it helps with thinking about conceptually difficult concepts in programming. For example, even just the basic ideas of category theory really helped me to understand and work with non-deterministic programming. Thinking about composing non-deterministic functions, and how these functions behave much like normal functions, made life much easier. Category theory is one of the more abstract branches of math, so it's no surprise that it lends itself to great programming abstractions. Understanding and using such abstractions in a uniform and systematic way is extremely useful, so I think it's definitely an area that would be beneficial for programmers to study. It's also fun, but that's another story entirely :).

sznurek 14y ago
I was learning Haskell for last six months (part of my undergraduate studies). It was (and is!) fun and challenging but I had hard time seeing any measurable profits from learning what are and how to use functors, monads etc. Until recently when I was writing asynchronous communication framework in Python and I was searching for simple solution to sequence actions in this heavily callback-based environment. Now everything looks so simple... (I am looking at you, monads!) The bad part is that many people do not know what I am talking about when I try to describe them the design ;)
- runT1ME 14y ago
  I had the exact same experience! A light went off when I figured out how to elegantly sequence asynchronous calls in Scala, and it was then that I realized I was using Monads to do so. However, I am curious if python's solution looks ugly (since they don't seem to have a 'do' or 'for' expression that Haskell and Scala have respectively)?
  - wonderzombie 14y ago
    I'm guessing you can't really do a 1:1, although maybe the OP can clarify. They do stuff like this in jQuery, so I can't imagine it's all that difficult in Python. My initial thought would be to write something analogous to Maybe. You can't pattern match in Python, which is a shame, but you could make it so that foo.bar().baz().quux() will return MaybeResult, which everything involved in the transaction inherits from. MaybeResult might have a "success" variable on it indicating whether it ought to be treated as Nothing. Otherwise, check "result." This is naive but it gets you a little bit closer to fault-tolerant chaining of interdependent methods. Not as nice as Haskell, obvs. :)
    - sznurek 14y ago
      I wrote 'monad-inspired' structure because of lack of syntactic sugar (do notation). So it basically looks like that: login_action = Write('PASS') >> \ Read('pass') >> \ Guard(lambda v: v['pass'] == 'mysecret') >> \ Write('WELCOME') register(socket, login_action, on_success=func1, on_error=func2) Of course you can develop this idea futher: cat = Read('line') >> Write(lambda v: v['line']) cat.append_action(cat) register(socket, cat, on_error=handle_error_cb)
      - edwkar 14y ago
        Nice!!
  - samstokes 14y ago
    I did the same thing in Ruby [1], but it does indeed look uglier than the equivalent Haskell/Scala because of the lack of language support for monadic syntax. The benefit of realising the monadic behaviour of asynchronous sequencing (which I call "Deferrable#bind!") was that if you had a bunch of nested callbacks, the monad associativity law [2] meant you could replace them with a simple linear sequence of chained bind! calls: fetch().bind! do |a| process(a) end.bind! do |b| process(b) end.bind! do |c| # ... end instead of fetch().callback do |a| process(a).callback do |b| process(b).callback do |c| # ... end end end I find the former a lot more readable, partly because the "end" keywords don't all pile up at the end, and especially if you try and do error handling (in the nested case the error handling ends up in reverse order!). [1] https://github.com/samstokes/deferrable_gratification#bind-for-when-one-thing-leads-to-another https://github.com/samstokes/deferrable_gratification#bind-f... [2] http://www.haskell.org/haskellwiki/Monad_Laws http://www.haskell.org/haskellwiki/Monad_Laws
- jerf 14y ago
  Go check out gevent. It removes the need for heavily call-back dependent code.
- tikhonj 14y ago
  I actually had a very similar revelation in JavaScript. Using Haskell-style arrows to abstract over things like events and CPS functions is really great for that sort of code. The real beauty of these concepts is that they are not tied to just one logical thing. They're applicable to callbacks and networking, but then they translate effortlessly to handling errors or early termination or non-determinism.
lmkg 14y ago
I think all programmers should learn one of the more abstract maths, like abstract algebra or real analysis. Like you say, it helps train in abstraction. However, I'm less than convinced that Category Theory is a good choice compared to other branches of math. This may be a mathematician's bias, but Category Theory is somewhat underwhelming because you can't really do anything with it. It's actually too abstract--you can model basically every branch of mathematics with Categories, but you can't actually prove very much about them from this perspective. All you get is a different vocabulary to talk about results that you already knew. It's also less approachable because its objects of study are other branches of mathematics, whereas most other branches have number, vectors, and functions as standard objects. Abstract Algebra, Real Analysis, and Set Theory will provide you with very similar experience with heavy abstraction, while also teaching some specific tools that are more practical. Abstract Algebra is the beating heart of Fourier Transforms and crypto algorithms, as well as a similar experience with data transformations that you would get from Category; Real Analysis gives a lot of numerical algorithms, stability, and a good handle on dealing with unbounded scaling; Set Theory is relational databases, data representation, and again with the data transformations. Category Theory gives you Monads... which are actually pretty cool, but I honestly found Category Theory more of a hindrance than help in figuring how they work. tl;dr Every programmer should learn math for the abstraction. Category Theory is pretty good for this, but other maths might be better because Category Theorists are the Architecture Astronauts of the math world.
- s_baby 14y ago
  >This may be a mathematician's bias, but Category Theory is somewhat underwhelming because you can't really do anything with it. It's actually too abstract It seems Category Theory might one day be useful in ordering "Upper Level Ontologies". Since it's logically impossible to have one consistent ontology( Incompleteness Theorem ) the next best thing is to find morphisms across knowledge domains, no?
  - jkbyc 14y ago
    What exactly would be the benefit of using category theory? What would you gain in comparison to doing just normal homomorphisms? And that's even assuming you would be able to find a homomorphism at all; it may well be prevented by the ontologies being mutually inconsistent, right?
Dn_Ab 14y ago
I am hard pressed to find any practical use for Category theory. No that is not quite true. Knowing concepts like the fusion law, natural polymorphisms, initial and final algebras, ana/cata/hylo morphisms make many fuzzy patterns concrete. And motivate many algorithms. But I have never found a use where a theorem was useful in deriving some part of a program. I feel it helps my programming the way some people say Lisp helps their Java. But I have flipped through Bird's Algebra of Programming a very few times to solve some problems. the above is paraphrasing a recent post.

by tikhonj 14y ago

sznurek 14y ago

I was learning Haskell for last six months (part of my undergraduate studies). It was (and is!) fun and challenging but I had hard time seeing any measurable profits from learning what are and how to use functors, monads etc. Until recently when I was writing asynchronous communication framework in Python and I was searching for simple solution to sequence actions in this heavily callback-based environment. Now everything looks so simple... (I am looking at you, monads!) The bad part is that many people do not know what I am talking about when I try to describe them the design ;)

runT1ME 14y ago
I had the exact same experience! A light went off when I figured out how to elegantly sequence asynchronous calls in Scala, and it was then that I realized I was using Monads to do so. However, I am curious if python's solution looks ugly (since they don't seem to have a 'do' or 'for' expression that Haskell and Scala have respectively)?
- wonderzombie 14y ago
  I'm guessing you can't really do a 1:1, although maybe the OP can clarify. They do stuff like this in jQuery, so I can't imagine it's all that difficult in Python. My initial thought would be to write something analogous to Maybe. You can't pattern match in Python, which is a shame, but you could make it so that foo.bar().baz().quux() will return MaybeResult, which everything involved in the transaction inherits from. MaybeResult might have a "success" variable on it indicating whether it ought to be treated as Nothing. Otherwise, check "result." This is naive but it gets you a little bit closer to fault-tolerant chaining of interdependent methods. Not as nice as Haskell, obvs. :)
  - sznurek 14y ago
    I wrote 'monad-inspired' structure because of lack of syntactic sugar (do notation). So it basically looks like that: login_action = Write('PASS') >> \ Read('pass') >> \ Guard(lambda v: v['pass'] == 'mysecret') >> \ Write('WELCOME') register(socket, login_action, on_success=func1, on_error=func2) Of course you can develop this idea futher: cat = Read('line') >> Write(lambda v: v['line']) cat.append_action(cat) register(socket, cat, on_error=handle_error_cb)
    - edwkar 14y ago
      Nice!!
- samstokes 14y ago
  I did the same thing in Ruby [1], but it does indeed look uglier than the equivalent Haskell/Scala because of the lack of language support for monadic syntax. The benefit of realising the monadic behaviour of asynchronous sequencing (which I call "Deferrable#bind!") was that if you had a bunch of nested callbacks, the monad associativity law [2] meant you could replace them with a simple linear sequence of chained bind! calls: fetch().bind! do |a| process(a) end.bind! do |b| process(b) end.bind! do |c| # ... end instead of fetch().callback do |a| process(a).callback do |b| process(b).callback do |c| # ... end end end I find the former a lot more readable, partly because the "end" keywords don't all pile up at the end, and especially if you try and do error handling (in the nested case the error handling ends up in reverse order!). [1] https://github.com/samstokes/deferrable_gratification#bind-for-when-one-thing-leads-to-another https://github.com/samstokes/deferrable_gratification#bind-f... [2] http://www.haskell.org/haskellwiki/Monad_Laws http://www.haskell.org/haskellwiki/Monad_Laws
jerf 14y ago
Go check out gevent. It removes the need for heavily call-back dependent code.
tikhonj 14y ago
I actually had a very similar revelation in JavaScript. Using Haskell-style arrows to abstract over things like events and CPS functions is really great for that sort of code. The real beauty of these concepts is that they are not tied to just one logical thing. They're applicable to callbacks and networking, but then they translate effortlessly to handling errors or early termination or non-determinism.

lmkg 14y ago

I think all programmers should learn one of the more abstract maths, like abstract algebra or real analysis. Like you say, it helps train in abstraction. However, I'm less than convinced that Category Theory is a good choice compared to other branches of math. This may be a mathematician's bias, but Category Theory is somewhat underwhelming because you can't really do anything with it. It's actually too abstract--you can model basically every branch of mathematics with Categories, but you can't actually prove very much about them from this perspective. All you get is a different vocabulary to talk about results that you already knew. It's also less approachable because its objects of study are other branches of mathematics, whereas most other branches have number, vectors, and functions as standard objects. Abstract Algebra, Real Analysis, and Set Theory will provide you with very similar experience with heavy abstraction, while also teaching some specific tools that are more practical. Abstract Algebra is the beating heart of Fourier Transforms and crypto algorithms, as well as a similar experience with data transformations that you would get from Category; Real Analysis gives a lot of numerical algorithms, stability, and a good handle on dealing with unbounded scaling; Set Theory is relational databases, data representation, and again with the data transformations. Category Theory gives you Monads... which are actually pretty cool, but I honestly found Category Theory more of a hindrance than help in figuring how they work. tl;dr Every programmer should learn math for the abstraction. Category Theory is pretty good for this, but other maths might be better because Category Theorists are the Architecture Astronauts of the math world.

s_baby 14y ago
>This may be a mathematician's bias, but Category Theory is somewhat underwhelming because you can't really do anything with it. It's actually too abstract It seems Category Theory might one day be useful in ordering "Upper Level Ontologies". Since it's logically impossible to have one consistent ontology( Incompleteness Theorem ) the next best thing is to find morphisms across knowledge domains, no?
- jkbyc 14y ago
  What exactly would be the benefit of using category theory? What would you gain in comparison to doing just normal homomorphisms? And that's even assuming you would be able to find a homomorphism at all; it may well be prevented by the ontologies being mutually inconsistent, right?

Dn_Ab 14y ago

I am hard pressed to find any practical use for Category theory. No that is not quite true. Knowing concepts like the fusion law, natural polymorphisms, initial and final algebras, ana/cata/hylo morphisms make many fuzzy patterns concrete. And motivate many algorithms. But I have never found a use where a theorem was useful in deriving some part of a program. I feel it helps my programming the way some people say Lisp helps their Java. But I have flipped through Bird's Algebra of Programming a very few times to solve some problems. the above is paraphrasing a recent post.