[Haskell-beginners] single responsibility principle vs functional programming

[Sriram Durbha]

You might find this http://haskell.org/haskellwiki/OOP_vs_type_classes also
useful.
Cheers
Ram

On Wed, Jan 27, 2010 at 3:27 PM, Henk-Jan van Tuyl <hjgtuyl at chello.nl>wrote:

>
> 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<http://www.cs.chalmers.se/%7Erjmh/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?
>>>>
>>>>
>>>
>>
>>
>>
>
> --
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20100127/6045fd76/attachment-0001.html