from Hacker News

Why category theory matters in programming

by kailuowang on 9/13/17, 8:48 PM with 45 comments

  • by ebola1717 on 9/13/17, 11:31 PM

    Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: )

    Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't help you do anything with it though. And Future technically doesn't even truly obey the Monad laws, because of exceptions.

    It's useful that a couple of container classes in scala use implement this trait:

        trait ChainableContainer[A] {
          def map(fn: A => B): ChainableContainer[B]
          def flatten(nested: ChainableContainer[ChainableContainer[A]]):ChainableContainer
        }
    
    But beyond making it a little easier to guess what's going on, the underlying math isn't useful in actual programming.
  • by keithnz on 9/13/17, 10:24 PM

    Functional Programming and Category Theroy are great, there's a strong level of robustness in the whole approach to programming.

    The author slams imperative programming, it isn't backboned on a robust compositional system, as is often done by FPers

    BUT :)

    there's lots of good programs in both styles....to me, this implies that there are more important things that matter to programming, the design to achieve a purpose. It's nice to express your designs in a robust system ( and be influenced by it), but what matters most is the design choices you make. When I look at well programmed things it's always the design choices that impress me.

  • by LolWolf on 9/13/17, 11:18 PM

    Category theory is fine, I guess, but there's no need to invoke a sledge-hammer when talking about 99% of most work here.

    It's a little like saying, yes, fine we can reference the hyperreals to derive infinitesimal calculus in a beautiful way, but it's mostly abstract and highly involved, even to just understand the foundational aspects (which one may argue is the case for normal calculus, but the notion of local linearity I believe is much more obvious than an extension to the reals). Though it's a nice academic exercise, which may even yield some insights, it's rather obscure and unintuitive for almost all purposes.

    This is the way I view category theory and functional programming; though I'd love to be corrected if I'm wrong. There's no need to invoke almost all of it, since most things can be expressed quite clearly in the language of set theory need there be rigour.

  • by purescript on 9/14/17, 2:31 AM

    Category theory matters to programming because, among other things, it teaches us how to abstract over programming languages. What better definition of abstract programs than "things with types which compose"?

    Now consider categories with various types of constructions (products, limits, exponentials, etc.) and you'll notice they correspond to requiring certain features in your language.

  • by kafkaesq on 9/14/17, 2:29 AM

    That's nice, but form a hard-nosed engineering perspective, not just sometimes, but in general 19 lines of yucky procedural code that pretty much anyone can understand (and debug) are usually way, way better than 9 lines of "elegant" functional code comparatively far fewer people can (really) understand - and which can be comparatively far more sinister and nefarious to debug.

    Given that, after all, it's just posting likes we're talking about. You'd think that with such a bold proposition as "Why category theory matters -- no really, it does!" this would be about hot-synching whole data centers, or getting drones to deliver medicine in Africa, or something like that. You know, something perhaps unthinkable (or maybe just far less tractable) with procedural (or just less sophistical functional) code.

    But no, in this case apparently it's about... updating your FB likes.

  • by d--b on 9/14/17, 5:51 AM

    Er... I think that people tend to use the if then else approach, because it is actually more flexible, in the sense that you may actually want to do something else than return false when something wrong happens in one of the functions in the composition chain...
  • by hprotagonist on 9/13/17, 9:48 PM

      category*
  • by Veedrac on 9/14/17, 3:44 AM

    > So, is there a simple and universal way to compose these functions?

    proceeds to add layers of complexity

    Why not just write a function to compose them? Argue against the competition, not strawmen.

  • by thomastjeffery on 9/14/17, 7:23 AM

    What language are these coffee examples written in?

    The article doesn't give me a reference for what syntax I'm trying to parse, and while most of it is easy to guess, it would be helpful to have an explicit reference.

  • by Twisell on 9/14/17, 3:36 AM

    This kind of contribution always make me hesitate betweeen two reactions:

    1.Man I must be dumb I can't even begin to understand what matter

    2.Can't we achieve/explain the same goal by keeping it simple stupid