3 ms·
> Not to mention that the standard OO cult of unit test / mock everything and make everything "reusable" leads to such shitty designs that almost fall out natur
by edgyswingset 10y ago
> Not to mention that the standard OO cult of unit test / mock everything and make everything "reusable" leads to such shitty designs that almost fall out naturally from the language/paradigm.
Not sure I'd call it a cult. From an F# perspective I do it this way:
* REPL-driven work to get it up and running
* Unit tests to protect what needs to be correct against change
* Mock the service boundaries
* Expose object-oriented layer to C#/VB consumers
Unit tests, mocking, and reusability are good things. Overuse (e.g., mocking to make sure that X calls Y in some business logic engine) is just what it is - overuse. Users of functional languages have their own problems, like suffering from code golf and over-using partial application. I wouldn't call one any worse than the other, it's just the functional crowd is smaller so you see it less.
- rubber_duck 10y agoThere are a bunch of "preachers" who advocate "best practices" which are rarely presented as "we had A and B problems and X worked out better than Y", instead it's "X gives you 1/2/3/4 over Y and therefore X is better", and the community follows along - cult like. Limited nature of language helps promote these "patterns" and "best practices" because it's often hard to find a better solution and much simpler to just apply them indiscriminately, and you end up with verbose and crazy code that the C# ecosystem is full of. I agree that both have their own issues but I do think one is better than the other, F# is more succinct (without turning in to code golf) and (actually) being multi paradigm avoids cases where OO just doesn't fit well. With micro services, actors, distributed computing, etc. those cases are expanding.