[Haskell-cafe] A functional programming solution for Mr and Mrs Hollingberry

[David Turner]

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

Cheers,

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4922 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120525/e152c5ea/attachment.bin>