[Haskell-beginners] single responsibility principle vs functional programming

[Joe Van Dyk]

I'm not saying to directly translate a OOP project to Haskell using
the same design, but rather to take the business requirements of the
OOP project and write them in Haskell.

(So, both versions do the same thing, but the design of them will be
completely different)

Joe

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
> [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?
>>>>
>>>
>>
>>
>>
>
>
> --
>



-- 
Joe Van Dyk
http://fixieconsulting.com