[Haskell-beginners] single responsibility principle vs functional programming

[Henk-Jan van Tuyl]

I have the experience that you better start from scratch when learning a  
new programming paradigm, do not try to write object oriented programs in  
Haskell. A great description of how to use the functional programming  
paradigm can be found in "Why Functional Programming Matters" [1]. Maybe  
also interesting is "The Monad.Reader/Issue3/Functional Programming vs  
Object Oriented Programming" [2].

[1] http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
[2]  
http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue3/Functional_Programming_vs_Object_Oriented_Programming

Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--


On Wed, 27 Jan 2010 23:43:27 +0100, Joe Van Dyk <joe at fixieconsulting.com>  
wrote:

> Thanks, I'm starting to get it.
>
> Perhaps what I need to do is take a small standard OOP system and try
> converting it to FP.
>
> Or perhaps there's already examples of such a thing I could look at?
>
> Joe
>
> On Wed, Jan 27, 2010 at 11:43 AM, Stephen Blackheath [to
> Haskell-Beginners] <mutilating.cauliflowers.stephen at blacksapphire.com>
> wrote:
>> Joe,
>>
>> IMHO:
>>
>> Classes in OOP have several purposes, one of which is to manage the  
>> mutation
>> of state so as to put a lid on the complexity that could result.  The  
>> inside
>> of an OOP class is usually a C program, and the outside is (ideally) a
>> semi-functional program with interfaces that are simple at the level of
>> abstraction where they operate.  The single responsibility principle  
>> exists
>> to stop the C programs getting big and messy, and to help the  
>> programmer to
>> build neat layers of abstraction on top of each other by having more
>> abstract classes constructed out of less abstract ones.
>>
>> Functional programming essentially takes the C part away and makes the  
>> whole
>> program into a layering of abstractions, even at the lowest level.
>>
>> An FP function more-or-less maps to an OOP class, and the reason why it  
>> can
>> be a much lighter-weight structure is because the need to manage  
>> mutation
>> has been removed.  I think the same principle applies, though - an FP
>> function should have only one responsibility.
>>
>> Perhaps in FP the need for this principle to be explicitly stated and
>> carefully observed is not so great, though.  If an FP function does two
>> things and can be split up, it's not such a big deal, because  
>> re-factoring
>> is easy in an FP language.  By comparison in OOP, splitting a big messy
>> class up is a lot of work with a great risk of breakage. This amplifies  
>> the
>> importance of applying the single responsibility principle before you  
>> start
>> writing the class.
>>
>>
>> Steve
>>
>> Joe Van Dyk wrote:
>>>
>>> So I'm still pretty new to functional programming.
>>>
>>> In OOP, you have the concept of each class having a
>>> single-responsibility (or reason for changing).  See
>>> http://en.wikipedia.org/wiki/Single_responsibility_principle
>>>
>>> I'm having problems seeing how that concept maps to functional
>>> programming.  Perhaps it doesn't?
>>>
>>
>
>
>


--