Live data from Hacker News

Category Theory for Programmers (2014) [pdf]

github.com

101–110 of 136 posts

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

#101

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…

> This technique utilizes category theory. No, it doesn't. Category theory is not intrinsic to the development, use or explanation of this technique. Category theory is merely one possible framework for explaining why the technique works the way it does. That's an important distinction, and likewise it's not the most practical framework for understanding this technique by a long shot. In particular, understanding why…

[deleted]

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

#102

Question to all CS majors, that invested in learning Category Theory: Did you have any concrete take aways from learning it? ( I have a math background, and struggle to find something concrete. Maybe I am just blind. )

The chain goes like this: Everyone's favorite programming language (Python, JS, ...) gets (much of) their concepts from Haskell and Haskell gets its concepts from category theory. Thus, by studying CT you enable yourself to see these concepts in the programming languages you use at work. This can make it easier for you to read, write and reason about programs, since you are provided with new (previously unknown) ways to think about it.

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

#103
post #82
post #60

Earlier quoted context omitted.

> 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 scal…

Argh, I wrote this in an editor and accidentally posted only a partial response. I cannot edit anymore so I'm responding with the full comment:

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

What this does is to add rigor to something that you (or a chemist) may understand intuitively. To a person with a working, intuitive knowledge about a subject, that may seem a bit pointless, but it is nevertheless useful since an intuitive understanding might overlook reasoning holes or edge cases. Building upon this result may yield further useful insights.

Granted, this really may not be useful to a working chemist. The cost/benefit ratio of a chemist doing chemistry is more favourable than investing a lot of time in CT, hoping for a large breakthrough.

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

#104

Is there any point in learning category theory without first learning the things that it generalizes? I didn't see any value in learning about geometric algebra until I had learned enough about complex analysis to appreciate what it would mean to connect it with vector calculus.

I think category theory generalizes pretty much everything, so that may be tough.

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

#105
post #88

Earlier quoted context omitted.

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

Yes, thanks for this. It appears that maybe the entire university's website has changed location? So maybe a more official link will come back up soon

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

#106
Here's a really great introduction to CT for the non-mathematically inclined:

Lawvere and Schanuel. "Conceptual mathematics: a first introduction to categories." Cambridge University Press, 2009.

The authors are two of the "founders" of the subject, so don't be fooled by the elementary appearance of this book.

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

#107

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

> the content is interesting but the ROI is low ...

Even mathematicians themselves have had this view, for a long time. The attitude appears to be "hey I'm doing my good calculations here, why should I be messing around with arrows?" Theoretical physicists are now getting involved in this debate aswell. So it's a much bigger complaint than "how is this going to give me better programs?"

I've thought so much about this, I don't really know where to start. The functional programming stuff is nice, but it is only one manifestation of CT ideas. Probably, if you are any good at programming you are already "doing" CT. Anytime you have a class invariant, you are "doing" category theory. The methods are preserving some kind of structure (the class invariant.) And that is the key idea behind OOP. That is what it means to have an object and not just a bucket of data. FP does this too but in a strict way; nothing is mutable.

The revelation of CT is how deep (or wide?) these ideas are, but maybe the only thing you get from this is the satori.

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

#108

Earlier quoted context omitted.

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 progr…

> What do you think? Should we use different words?

Maybe it's because I was up until midnight debugging a production problem on Christmas eve, but I can't make myself care much either way. My kneejerk reaction is to say no, because I hesitate to introduce categories without being quite certain of their operational reality.

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

#109
post #84

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…

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 he…

First off, I don't like your sarcastic attitude. It's against the rules on HN to do that. Don't violate rules to be rude.

Second off, my example is just an example. It's not production level code. The intention of the example is to show "lifting" from from one type into another "category." The efficiency is less relevant here... in some contexts it can be faster in other contexts it could be slower or not even possible.

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

You sentence here reveals a failure in reading comprehension. I never mentioned what did was a regexp. I said you Could use a regexp to make it faster. A regexp if you know basic computer science is the one of the fastest possible string parsing operations. Take a course on Automata at a top university, this would be helpful in educating you, but you need to qualify first.

If there is a bottleneck it's in the casting functors str() and eval(). I didn't benchmark it and I very much doubt you did either. I suspect it is faster as the interpreter needs to "interpret" the data structure anyway regardless of whether or not it has string quotation marks around it so the parsing bottleneck is already there regardless of whether or not you have quotation marks. This is just a guess, and I'm pretty sure both of us are too lazy to generate actual specs to prove it either way. Stop throwing hard conclusions at things you have ZERO evidence for. If you do have evidence, show it, don't talk out of your ass... I'm willing to concede given evidence but without evidence you don't know what you're talking about.

The string does hold order preserving properties. You are absolutely wrong about this:

"{1:2, 3:,4}" during string manipulation can be made into "[1,2,3,4]" without sorting because the string itself is a List of ordered characters. Unserialized, the dictionary has no order. Again what's going on here is you misreading and not understanding my explanation.

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

This is flagrantly offensive. Let me give you a word of advice. Keep your attitude in check, this kind of attitude can ruin your whole career after you get your ass fired. Any hiring manager would prefer a less technical person (which you have not demonstrated any dramatic ability in) over someone with a bad overly domineering attitude, and that is a fact.

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

How does this have anything to do with the topic at hand. You are invoking OS and CPU architectural level concepts which are so far away from python it has basically nothing to do with it. An SSD? Are you serious? All of these low level operations are light years in distance away from python. If you want time and space analysis of both algorithms, at the python level/category theory level you just follow the standard model of Big Oh complexity. You want to get nitty gritty? get the bench marks or switch to something like C++ or Rust. Nowhere does anyone have a detailed enough mental model to map out how the python code will execute at the assembly instruction level.

Category theory is a top down approach to programming while computer architecture is more of a bottom up approach. Experts in both fields are unlikely to collide.

FWIW I double majored in Electrical/Computer Engineering and Computer Science 10 years ago from a top university. Not only do I have a general model of computing from semiconductor physics (this is below logic gates and non linear circuits and computer architecture, all said to patronize you.) all the way up to python, but I hate throwing down credentials for no reason... SO why did I do it here? because you decided to assume that I lack experience.

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

#110
post #84

Earlier quoted context omitted.

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 he…

Author mentioned elsehwere that he used that trick in postgresql , not in python, where it allowed him to skip SQL acrobatics and sped up query.

Thank you for this. This is indeed where I actually used the technique. You do get dramatic speed up if you do it in SQL this is provable.

I chose to use python as an example here mainly because the SQL example would get very convoluted and be much less concise.

The main point was the general technique of moving back and forth between isomorphic types, but people are getting too involved with implementation details of python. Yeah it might(keyword) be slower, yeah it's more convoluted than a traditional list comprehension in python, but that is not the point.

Lesson learned: don't use arbitrary examples to prove a point. Use an example where all metrics are dramatically better.

Post reply on HN