On Wed, Jan 27, 2010 at 3:27 PM, Henk-Jan van Tuyl
<hjgtuyl@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@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@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?
--