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_Progra... 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 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] 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?

--

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 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_Progra...

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 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] 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