Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Category Theory for Programmers (2014) [pdf]

github.com

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Category Theory for Programmers (2014) [pdf]

#81

Post by patrec »

visarga wrote: post #79
crimsonalucard wrote: post #71

Earlier quoted context omitted.

Apologies. I was on the phone typing the above. Still, remarks like "What?" that provide no information or context are against the rules on HN. Just FYI. The OP said that there's no point in labeling an arbitrary type as a functor or monadic value. I'm going to use an example to illustrate how there is a benefit in being aware of this concept. I will be using a "String Monad" in my example. Imagine you have some type…

I would simply do: original_dict = {1:2 ,3:4, 5:6, 7:8} array = sum(map(list, original_dict.items()), []) And it would have been simpler if items returned lists instead of tuples. In my benchmarks it runs 10x faster.

Still needlessly complex and slow.

    [x for kv in d.items() for x in kv]

Re: Category Theory for Programmers (2014) [pdf]

#82

Post by feanaro »

knzhou wrote: post #60
westoncb wrote: post #58

Earlier quoted context omitted.

I think you may be missing something here. > The "theorems" they then prove do not provide any new insight Knowing that you can model reaction networks using categorical concepts may not provide new insights IF you have no deep familiarity with those concepts—but if you do, then knowing there is a "symmetric monoidal functor from the category Petri to the category Dynam" is a richly useful piece of information. It's…

> Knowing that you can model reaction networks using categorical concepts may not provide new insights IF you have no deep familiarity with those concepts—but if you do, then knowing there is a "symmetric monoidal functor from the category Petri to the category Dynam" is a richly useful piece of information. Look, I completely agree with the general point. I love new ways of thinking about things. But blindly applyin…

> What is happening here is like taking a 2-line program that adds together two numbers and dressing it up into thousands of lines of OOP, until you have AdditionObjectFactoryGetterSetter objects being created by AdditionObjectFactoryGetterSetterFactory objects. Then you can bring in powerful OOP tools, but the only things they help you with are understanding the excess complication you added in. Maybe the sheer scale of that structure is beautiful to someone, but we're discussing whether scientists should bother learning it.

In my opinion, this severely misrepresents what's happening. Your example is simply adding extrinsic, incidental complexity and this is not what the categorical treatment of this is doing, in my opinion. The additional complexity introduced by the CT machinery is not a lot and most of the complexity is intrinsic to the problem.

Re: Category Theory for Programmers (2014) [pdf]

#83

Post by runeks »

philzook wrote: post #52
CTmystery wrote: post #43

Can someone please explain to me the excitement for category theory in this forum? I've gone through the first 10 chapters + exercises of this book, and truth be told the content is interesting but the ROI is low for programming (FWIW I started this book as part of a study group in a large unicorn co, and after approximately one month I was the only person left grinding through the exercises, hoping for some payoff).…

I think I've got the category bug. I very much was intrigued by Milewski's course and found that it made things happening in Haskell make more sense to me. There are a couple of things that really excited me. Conal Elliott's compiling to categories. Categories make a great intermediate representation for DSLs. They are very easy to manipulate/optimize in a simple algebraic manner without issues related to named varia…

Great example!

Here’s a video where Conal demonstrates interpreting a Haskell program (actual Haskell, not a DSL) into a) an image of a graph-like structure (visualizing the algorithm), b) Verilog (for compiling to hardware), and c) GLSL (for being rendered by a GPU in the browser).

https://youtu.be/vzLK_xE9Zy8

Re: Category Theory for Programmers (2014) [pdf]

#84

Post by patrec »

crimsonalucard wrote: post #71
edflsafoiewq wrote: post #59

Earlier quoted context omitted.

What?

Apologies. I was on the phone typing the above. Still, remarks like "What?" that provide no information or context are against the rules on HN. Just FYI. The OP said that there's no point in labeling an arbitrary type as a functor or monadic value. I'm going to use an example to illustrate how there is a benefit in being aware of this concept. I will be using a "String Monad" in my example. Imagine you have some type…

So congratulations, category theory allowed you to come up with a solution which would make you immediately fail any reasonable job interview! Compared to the obvious answer your proposed approach is more code to write, orders of magnitude slower and has security as well as potential data corruption/robustness issues. Your gloss reveals further substantial misapprehensions about python basics (there are no regexps here, no it's not faster to do it that way, no it's not any more order preserving then iteration).

Assuming your problem is purely lack of experience, here's a word of advice: stay the hell away from abstractions for a year or two. Instead try to form some basic mental model of a) how a computer and b) your main tools (such as python) work (have a very simplified model of how the CPU, memory network and SSD work, with numbers correct to 1 or 2 orders of magnitude; read a bit about the python implementation). Try to predict how much time/memory/etc something should take before you implement it. Then implement it in the most straightforward and direct way.

Re: Category Theory for Programmers (2014) [pdf]

#86

Post by atq2119 »

BeetleB wrote: post #56
davidxc wrote: post #18

Earlier quoted context omitted.

I believe my real analysis class made me a significantly better programmer and thinker in general, but I don't use anything specific from it (not yet, anyway).

Genuinely curious how real analysis made you a better programmer...? I've taken it and loved it, but my interest was more due to physics/engineering applications. I can't see a connection to programming.

I suspect it could be that real analysis truly makes you challenge your assumptions and forces you to build a habit of thinking through corner cases.

Other maths courses do this as well, but real analysis is particularly vivid for some people because of all the fun counter-examples you get to see in a well-taught course, such as a function that is everywhere continuous but nowhere differentiable.

This habit of thinking through corner cases is something I miss from a lot of (junior) programmers.

Re: Category Theory for Programmers (2014) [pdf]

#87

Post by s_gourichon »

madhadron wrote: post #74
reykjavik wrote: post #24

Watched that guy's lectures and conference talks. While it's quite interesting and educative - I still don't get the "for programmers" part of it. I don't quite get how I would jump from understanding categories, morphisms, monoids etc. to building actually better systems. There are zero practical examples in his talks. Is it because i'm not using functional languages or what am I missing here?

So here's a "folk theorem" that explains why you should care about such abstract structures. Take a 2x2 matrix with real elements (a b)(c d). If I take the space of all such matrices and put a uniform probability distribution over it, what is the probability of getting a matrix that is not invertible? Not invertible is det M = 0, or a c - b d = 0. I can solve for a in terms of b, c, and d, which shows that the non-in…

Thank you. A lot. This is one of the most well-founded, didactic and insightful comment I ever read on HN.

I happen to have a decent background in mathematics. Some people say it's useless for most contexts that a programmer can meet (exceptions being vectors and matrix for 3D and quaternions for some 3D APIs for example), but I disagree. You just illustrated how abstract mathematics can be directly relevant to programming.

Even when the mathematics one knows are not directly applicable, I think having studied mathematics helps shape the brain activity at all tines into thinking things orderly and more efficiently. Having correct intuitions about what will be a productive approach and what will not. Loving and embracing simplicity

That said, perhaps we should use different words for the different activities that look like programming. To be caricatural, one is just piling frameworks and libraries on a language where you don't even master the basics, filling in the blank from examples and snippets from the net. The other activity is writing well thought out programs on top of highly generic patterns like Reactive Programming or even designing your own patterns and frameworks to be used by others.

The first activity does not need much mathematics, the second greatly benefits from it.

What do you think? Should we use different words?

Re: Category Theory for Programmers (2014) [pdf]

#88

Post by feanaro »

crimsonalucard wrote: post #77
philzook wrote: post #50

Earlier quoted context omitted.

Check out Program Design by Calculation and The Algebra of Programming. Category theory and related formalisms do have a strong case to being a formal theory for designing/calculating programs http://www4.di.uminho.pt/~jno/ps/pdbc.pdf https://themattchan.com/docs/algprog.pdf

Super interested in this and thanks for posting. Your first link is dead though. Do you have an alternative?

http://web.archive.org/web/20190519200157/http://www4.di.umi...

Re: Category Theory for Programmers (2014) [pdf]

#89

Post by jolux »

LessDmesg wrote: post #80
curryhoward wrote: post #76

Earlier quoted context omitted.

> by carrying a "world" parameter that represents the state being modified From this, it's clear you've never read and understood Moggi's seminal paper. Monads are functors with some extra monoidal structure. The concept, and even Moggi's use of it in categorical semantics, has nothing to do with "worlds". The important realization is that there are many more monads than just the one hardcoded into one's programming…

Monads are still programmable semi-colons, though. Yes, there are a lot of things you can program into a line-end symbol. Yes, some of those things are general and work for any already modded semi-colon. But it's still just programmable semi-colons: implicit, uncomposable, and frankly better left alone.

>implicit

You'll have to elucidate, I don't follow.

>uncomposable

Demonstrably false, see monad transformers.

>better left alone.

"Yeah, well, that's just, like, your opinion."

Re: Category Theory for Programmers (2014) [pdf]

#90

Post by tome »

rubyn00bie wrote: post #22
playing_colours wrote: post #11

I liked “An Invitation to Applied Category Theory“, pdf is available here: [1] It is written in a more terse, mathematical language, but it is very clear and friendly for non-mathematicians. The authors provide interesting examples of applicability. Hardcover is quite expensive, but the quality is great [2]. [1] http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf [2] https://www.amazon.com/gp/aw/d/1108482295

I've quite literally spent the last month trying to read, digest, and apply the above to a record layer I'm writing for FoundationDB. Dr. Spivak's work has been absolutely beyond helpful and insightful. There's no way I'd even be able to approach the subject with his efforts. I'd also recommend these as they're associated with the 7 Sketches and help fill in some blanks: Functorial Data Migration - https://arxiv.org/…

Since you sound like you're from the category theory community you may already know this, but my database library Opaleye is directly based on David Spivak's ideas.

https://hackage.haskell.org/package/opaleye

Post reply on HN