3 ms·

I'm sympathetic to your POV as it makes sense, but the author of OP even calls out FP at the end along with a list of what they seem to imply are not "data firs

I'm sympathetic to your POV as it makes sense, but the author of OP even calls out FP at the end along with a list of what they seem to imply are not "data first" ways of designing systems. I'll go ahead and admit my bias here: rules are overrated, especially ones that propose "X first" at the expense of everything else because there are no one size fits all paradigms. You can find situations where orienting around types makes sense but you can always find situations were it doesn't make sense. I also don't imply it's "50/50" as I really don't know what works or doesn't, it could be data-types first design works in 85% of the cases and so it's good to promote it or think in terms of design that way. I just don't like "X is the right way" talk in general, although it doesn't seem like the author is proposing this be a hard fast rule.

wellpast 7y ago
I agree and I think rules are pointless. Everything is a tool and you pick the right tool for the job and that requires context and thinking. However, having built systems in OO and then in functional, I've come to realize that the OO tools always have a surface of familiarity (`cat.meow()` vs `meow(cat)`) but are highly coupled (inflexible) while the latter, functional composition is not. And if there's any objective measure to complexity it's a measure of degrees of coupling. And OO distinctly loses to functional there.
- mpweiher 7y ago
  Hmm...I would say that cat.meow() has higher cohesion and lower coupling than meow(cat). Which is exactly what you want. Maybe a different example would better illustrate the point?