[Haskell-cafe] A functional programming solution for Mr and Mrs Hollingberry
d.turner at tracsis.com
Fri May 25 18:16:57 CEST 2012
On 24/05/2012 18:56, Andreas Pauley wrote:
>> I've used quite a few OO languages. I like to think that I *am*
>> an OO programmer. But this exercise struck me from the beginning
>> as something where classes would add nothing but bulk. As a fan
>> of Smalltalk, I have to say that the Smalltalk version confirmed
>> this for me; a Smalltalk solution for this exercise could be a lot
>> smaller than that one if it _didn't_ introduce new classes.
> Maybe this is an example of where we as an industry has been somewhat
> For many programmers it is difficult to envision coding pretty much
> anything without classes.
> Do you know of an exercise where classes would add value? Something
> fairly small, roughly similar in size to this exercise.
I don't. I think the trouble is that classes don't add value in
exercises of this size. Nor do any similarly heavyweight Haskell
engineering features like polymorphism or typeclasses. Just write the
program and have done with it. Hard-code everything and you'd end up in
C# with something not much different from the Haskell solutions on
Github (except for the usual heavy syntactic overhead of C#). I'd say
many of the programmers in my heavily OO-centric organisation would do
just this: experience shows us that simple == flexible more often than not.
However, it becomes more interesting if the requirements are thought
likely to change in the future. More product lines? More suppliers? More
or fewer troublesome or premium ones? More rules affecting pricing?
Based on what other fields? How much is configurable at runtime and how
much requires programmer time and recompilation? Are you likely to try
and re-sell a similar system to another client and, if so, do you want
to share code across clients to cut your support and maintenance
overheads? More input formats? More output formats? Summary reporting?
Interfaces with other systems?
This is where classes start to become worthwhile, as (with the right
architecture) they let you add to the behaviour of the system without
changing existing working code. Of course, you can get a similar level
of flexibility in a functional setting but it looks different. In OO
languages it's easy to add new subtypes but adding a new method to a
base type is a pain (as each subtype has to be changed). Conversely in
functional languages it's a pain to add new constructors to a datatype
(as all your pattern matching and case expressions need alteration) but
easy to add new functions operating on your datatypes. So this pushes me
in different architectural directions in the two settings - I try and
make expected new requirements involve adding classes in an OO language,
but they should involve adding new functions in my Haskell programs.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4922 bytes
Desc: S/MIME Cryptographic Signature
More information about the Haskell-Cafe