3 ms·

Can someone clarify if this author's methods are actually inline with the core principles of functional programming? I've been doing OOPs from very early in my

Can someone clarify if this author's methods are actually inline with the core principles of functional programming? I've been doing OOPs from very early in my career (I run into FP from time to time but never as a core of my own work), and much of the example he's implementing here seems like make-work simply to enforce a specific paradigm. Am I missing something? For example, at first his concepts seem brilliant, until you get to the refactoring steps, which feel painful. Is this the end result of high-level extreme veteran coders use of FP? With OOPs, simple inheritance & factories seems like it would solve all the dependency issues he's addressing.

dwohnitmok 8y ago
Most of what the author is talking about in the refactoring section has little to do with trying to address dependencies per se. Therefore from the perspective of strictly trying to address the problem of "I have dependencies that I want to be interchangeable" that section is mostly irrelevant. In the refactoring section he's mainly dealing with things like trying to minimize exceptions with `Result` instead and maintaining syntactically linear control flow. So essentially yes that section is make-work if all you care about is dependency injection. It's not if you care about other things beyond dependency injection. That work is not necessary for dependency injection with FP.
bunderbunder 8y ago
I've always found ScottW to be pretty pragmatic. If Martin Odersky favors multiparadigm programming that nonetheless leans toward object-oriented methods, Scott Wlaschin favors leaning toward functional methods as a default. As far as whether he's in line with "core principles of functional programming", that's maybe a phrase that's well-designed to start a fight. Even more so than in object-oriented languages, different ways of doing things tend to cluster around different functional languages. In broad strokes, what he's doing seems fine coming from a F# developer. I think it would translate well enough to Haskell, though I'm nowhere near as experienced in that language. In Clojure, on the other hand, I'm guessing you'd want to do something completely different.

dwohnitmok 8y ago

Most of what the author is talking about in the refactoring section has little to do with trying to address dependencies per se. Therefore from the perspective of strictly trying to address the problem of "I have dependencies that I want to be interchangeable" that section is mostly irrelevant. In the refactoring section he's mainly dealing with things like trying to minimize exceptions with `Result` instead and maintaining syntactically linear control flow. So essentially yes that section is make-work if all you care about is dependency injection. It's not if you care about other things beyond dependency injection. That work is not necessary for dependency injection with FP.

bunderbunder 8y ago

I've always found ScottW to be pretty pragmatic. If Martin Odersky favors multiparadigm programming that nonetheless leans toward object-oriented methods, Scott Wlaschin favors leaning toward functional methods as a default. As far as whether he's in line with "core principles of functional programming", that's maybe a phrase that's well-designed to start a fight. Even more so than in object-oriented languages, different ways of doing things tend to cluster around different functional languages. In broad strokes, what he's doing seems fine coming from a F# developer. I think it would translate well enough to Haskell, though I'm nowhere near as experienced in that language. In Clojure, on the other hand, I'm guessing you'd want to do something completely different.