You have done a good job with the explanation. I think the bigger picture is that the SOLID principles are a specific application of computer science principles to OO. For example, Separation of Concerns and polymorphism are not specific to OO. And SOLID simply directs some of those more general concepts at OO.
I do not think the SOLID principles apply to FP, but instead the more general CS concepts apply. I am being slightly disagreeable here for a practical reason. When I was a new functional programmer, I tried to apply OO principles to learning FP. And it made learning FP difficult. In fact I gave up the first attempt. I find that the best way to approach learning FP is to treat it as structured programming with a few new rules such as: immutability, deterministic functions, and using expressions instead of statements.
For a more humorous take on this topic, check out this great presentation by Scott Wlaschin.
Which has this hilarious slide that saw some circulation.
I am a self-taught developer from Argentina currently living in Spain. I am passionate about improving my technical skills and helping others do the same.
Hey Kasey, thanks for writing this. I heard that about learning functional programming many times, unfortunately for me I still haven't found a way of letting go of everything related to oop, probably with time the functional side will get better. Right now I am in that case you describe. I already watched that talk from Scott is super good though I haven't got into F# yet.
Thanks for the comment. You can retain all your OO knowedge while learning FP, but maybe just put it in a box to the side. :) It is helpful to look at it as going back to basics. You just have data structures and functions, maybe like Go. That is a good starting place for the journey. I wrote an introductory article here. It is for F#, but the principles should apply to OCaml, Haskell, or Reason.
From my experience, really the only way in is learning-by-doing, and best using a language that simply doesn't allow you (or makes it uncomfortable for you) to fall back into OOP thinking. For me that language was Clojure, for some it is Haskell or F#. I never used or looked at F#, but I heard good about it, too. I think learning one of these three and applying them in a real-world scenario will just ease you into FP as a "byproduct".
I am a self-taught developer from Argentina currently living in Spain. I am passionate about improving my technical skills and helping others do the same.
Thanks for the comments, I agree with everything you said. I also like the approach of learning with a language that doesn't let you fall back. I am also learning with Clojure. I tried Haskell but it was too much for me. So far Clojure has been a very pleasant experience but I still have a long way to go. I am still with the basics. I am using a book called "Functional programming for the object oriented programmer" by Brian Marick, is quite good
You have done a good job with the explanation. I think the bigger picture is that the SOLID principles are a specific application of computer science principles to OO. For example, Separation of Concerns and polymorphism are not specific to OO. And SOLID simply directs some of those more general concepts at OO.
I do not think the SOLID principles apply to FP, but instead the more general CS concepts apply. I am being slightly disagreeable here for a practical reason. When I was a new functional programmer, I tried to apply OO principles to learning FP. And it made learning FP difficult. In fact I gave up the first attempt. I find that the best way to approach learning FP is to treat it as structured programming with a few new rules such as: immutability, deterministic functions, and using expressions instead of statements.
For a more humorous take on this topic, check out this great presentation by Scott Wlaschin.
Which has this hilarious slide that saw some circulation.
Hey Kasey, thanks for writing this. I heard that about learning functional programming many times, unfortunately for me I still haven't found a way of letting go of everything related to oop, probably with time the functional side will get better. Right now I am in that case you describe. I already watched that talk from Scott is super good though I haven't got into F# yet.
Thanks for the comment. You can retain all your OO knowedge while learning FP, but maybe just put it in a box to the side. :) It is helpful to look at it as going back to basics. You just have data structures and functions, maybe like Go. That is a good starting place for the journey. I wrote an introductory article here. It is for F#, but the principles should apply to OCaml, Haskell, or Reason.
From my experience, really the only way in is learning-by-doing, and best using a language that simply doesn't allow you (or makes it uncomfortable for you) to fall back into OOP thinking. For me that language was Clojure, for some it is Haskell or F#. I never used or looked at F#, but I heard good about it, too. I think learning one of these three and applying them in a real-world scenario will just ease you into FP as a "byproduct".
Thanks for the comments, I agree with everything you said. I also like the approach of learning with a language that doesn't let you fall back. I am also learning with Clojure. I tried Haskell but it was too much for me. So far Clojure has been a very pleasant experience but I still have a long way to go. I am still with the basics. I am using a book called "Functional programming for the object oriented programmer" by Brian Marick, is quite good
put very diplomatically!