6 ms·
But just using the definitions is cargo cult and using abstractions for the sake of using abstractions is not necessarily good mathematics. Currently it looks l
by qcoh 11y ago
But just using the definitions is cargo cult and using abstractions for the sake of using abstractions is not necessarily good mathematics. Currently it looks like "use this design pattern because mathematics".
- spooningtamarin 11y agocategory theory is excellent mathematics useful in various areas of physics (if you're looking for proof of application) why wouldn't it be useful in programming?
- deleted 11y ago[deleted]
- qcoh 11y agoIt's useful because it's a generic design pattern not because of the mathematics behind it (of which virtually nothing is actually used, at least in everyday programming).
- spooningtamarin 11y agoYeah, generic design pattern which is minimal, compact and simple. Yeah, why would I use mathematics in programming.
- qcoh 11y ago> Yeah, generic design pattern which is minimal, compact and simple. A good argument for monads. Much better than the dishonest appeal to mathematics.
- tome 11y agoI think you're reading more into spooningtamarin's posts than was actually there.
- spooningtamarin 11y agoReally? Yes, I definitely mentioned mathematicians, because they were the ones who showed us the problem solving methods, the modeling/design method. I'm definitely agreeing that one uses practically none of the category theory in programming. But let's say that we can be influenced by the design of category theory, and get some theorems for free because of it.
- calhoun137 11y ago+1 for "just using the definitions is cargo cult", that seems like a common problem! I would add "just using a word from math is cargo cult". I just wish someone had told that to the 7 people who decided to use the word "static" for 7 different things ...
- skore 11y ago> Currently it looks like "use this design pattern because mathematics". I've only recently gotten into FP, but to be honest, I prefer that to "use this design pattern, because design patterns", which is how things usually go, particularly in OOP. A lot of the "theory" in imperative programming seems four steps removed from the underlying theory (to the point where you can't really trace patterns to their underlying theoretical reasoning). Sure, that often makes is easier to understand and utilize. To me, however, after 8 years of that, it's pretty sobering to start realizing just how much of your repertoire is cargo culting. I would also argue that there is a huge difference in how the two worlds use, or even understand, design patterns. FP often puts you through the trouble of going back to basics (yes, sometimes even mathematical basics) and that can take enormous amounts of and effort. That's a level of discomfort and slowness I have come to appreciate.