6 ms·
> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But
by cannabis_sam 6y ago
> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.
Do you have a code example? It would be interesting to see what this kind of code looks like.
Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. It’s a pretty straightforward implementation detail that have very little to do with your business logic.
And business logic is far, far easier to model using ADTs (it’s literally just AND and OR, applied to data structures) than confounding object inheritance hierarchies.
In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with.
- scarmig 6y agoWell, we're used to the AbstractBeanHandlerFactoryFactories already. A slight discomfort of learning something new can seem much bigger when you're already acclimated to abuse.
- strbean 6y agoPosting to name-drop SimpleBeanFactoryAwareAspectInstanceFactory
- robocat 6y agoFor details of the interfaces that the class inherits from, see: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactoryAware.html https://docs.spring.io/spring-framework/docs/current/javadoc... https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/aspectj/AspectInstanceFactory.html https://docs.spring.io/spring-framework/docs/current/javadoc...
- raegis 6y agoThe guy next to me on the bus is asking why I'm laughing so hard. I'm not sure how to respond. "These class names are really funny!"
- dllthomas 6y agoInternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
- hinkley 6y agoThey're talking about Existential Crises in another post today. I think I still have a copy of the book that Johnson wrote to accompany the creation of Spring (which someone wants $300 bucks for on Amazon, I didn't know it was a collector's item). The last time I used Spring, I had the distinct thought that I should go through his book as if it were a bingo card, comparing it with the latest version. It seems like it has reacquired all of the bits of J2EE that it set out to avoid. If, outside of Spring, there is anything in the Java world that more perfectly embodies Nietzsche's warning about fighting with monsters, I don't know what it is.
- philosopher1234 6y agoI'm glad we got the Simple one
- IncRnd 6y agoSometimes, though, you can only get the desired effect with SimpleBeanFactoryAwareAspectInstanceFactory_EX.
- cannabis_sam 6y agoThank you! I’m deeply familiar with the phenomenon!
- HelloNurse 6y agoI'd prefer readability to suffer because the fold over a monad needs something clever that requires a bit of reasoning to understand than because vast amounts of "readable" boilerplate (for example, trivial getters and setters) hide a needle in a haystack.
- qppo 6y agofolding over a monad (or any other combinator) doesn't require extra reasoning or anything clever, that's the point.
- 1tCKV3QfIo 6y agoIt shouldn't, but it does to people who get discouraged because they aren't having instant success. It's like anything that results in short-term regression convices them it's too complex for them to learn.
- JadeNB 6y agoI think HelloNurse's point was less that a fold is inherently clever or subtle (as you say, it isn't), and more that, if there is something clever or subtle involved, the lesser verbosity of the fold makes it easier to see than would a more familiar, boilerplate-heavy approach in which the clever or subtle point could be lost.
- chrischen 6y agoIt does if you are unfamiliar to the pattern. It probably has more to do with experience with the patterns used rather than readability.
- mattmanser 6y agoMaybe in the 00s, but these days most languages have collapsed boiler plate down massively. This comes across as an old fashioned view (bordering on extremely old-fashioned).
- munk-a 6y ago
- treetide 6y agoI just wrote about some possible pitfalls down the ADT route: https://treetide.com/posts/domain-model-pitfalls-oop-fp.html https://treetide.com/posts/domain-model-pitfalls-oop-fp.html > As more operations are demanded, it is more likely that the existing partitioning of the world into the nice distinct cases won’t suit that operation anymore. Then, as a fix, we can introduce more specific cases, or make existing ones more general - leading to ambiguity, bloat and mental load for the existing operations. Just an aspect.
- cannabis_sam 6y agoI like it! It’s the kind of reasonable discussion that I crave in this field.
- cuddlybacon 6y agoI think many of the responses to your parent post are focusing too much on `fold` and not the custom monad that is implied to just be a re-implementation of list.
- misja111 6y ago> Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. This was just an example of a behaviour that, if taken too far, could eventually lead to those 'hundreds of lines of abstract code'. Of course a single fold in itself is nothing to be concerned about. But an API that accepts a type 'm a' instead of '[Order]' has lost some of its connection with the business domain already. Again, this might not be bad, it can even be good, but the problem is that many FP enthusiasts overdo it. > In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with. Yes, this is the same problem which pops up in the OOP world as well. I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it.
- cannabis_sam 6y ago> 'hundreds of lines of abstract code'. Yeah, I’ve spent way to much time digging into “hundreds of thousands” of lines of abstract OOP code. And it’s sadly, largely ceremonial, mostly due to limitations in the language. The less fanatic about OOP the language is, the more useful it is, is a good rule. But it’s absolutely not exclusive to either paradigm. > But an API that accepts a type 'm a' instead of '[Order]' has lost some of its connection with the business domain already. I completely agree, but I’m also curious how any API interface like that would pass code review. Since it’s so obviously too general. But I guess the perceived upside is that the equivalent oop-construction would not get caught in code review. > Yes, this is the same problem which pops up in the OOP world as well. I know. I’ve spent more time working within oop than without. The type based FP-world just have orders of magnitude better tools. > I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it. This is kind of a sad way to dismiss people, as if they’re some kind of ephemeral fireflies... The reality is that trying to force reality into in an inheritance-based, tree-structured taxonomy, is not only stupid, it also creates endless maintenance headaches. Some problems fit that model better sure, but most things fit a much simpler ADT-based model since it’s much closer to how we think logically. (In terms of logical primitives and implicit recursion)