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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
