when OO is wrong

when OO is wrong

[Alexy Khrabrov]

I liked the part of Yaron's Caml Trading talk where he says that OO is  
not always the right way to model things.  I wonder about other  
situations where OO is wrong and functional approach simplifies  
modeling?  And then, since UML is so OO-motivated, should we get a new  
UML, or all that OO Analysis/Design/Development is a heritage of non- 
programming bureaucracy?

I've done some Fortran coding recently for high-performance, numeric  
OpenMP app, and also noticed that just about everything fits into an  
array -- just like almost anything in FP fits into a list.  That's  
another case where a flat structure clears the mind.  I've found a  
graph library in Fortran 77 which, with its compact representation,  
was directly applicable to a rather complex social network modeling  
problem of today!  There's something similar to the "everything is  
array" simplification in FP, but it's hard to pin it down exactly.

What is it about FP which makes modeling simpler than OO, conceptually  
and technically?  How can folks summarize their "enlightenment"  
experiences in this regard?

Cheers,
Alexy

Re: [Caml-list] when OO is wrong

[Raoul Duke]

> What is it about FP which makes modeling simpler than OO, conceptually and
> technically?  How can folks summarize their "enlightenment" experiences in
> this regard?

it is worth seeing http://www.info.ucl.ac.be/~pvr/book.html

Re: [Caml-list] when OO is wrong

[Martin Jambon]

Alexy Khrabrov wrote:
> What is it about FP which makes modeling simpler than OO, conceptually
> and technically?  How can folks summarize their "enlightenment"
> experiences in this regard?

OO is not dirty. Wait until you feel it's the right time and do it safely ;-)


Objects and classes tend to be more appropriate than modules and records in
the following cases:

- self-centric data that can be considered as a "resource", typically for IO
operations.
- frequent need to define and use interfaces before implementations.
- keeping familiar names for functions/methods without requiring
disambiguation prefixes ("input", "output", "print", "flush", "read", "send",
etc.)



Martin

-- 
http://mjambon.com/

Re: [Caml-list] when OO is wrong

[Jon Harrop]

On Tuesday 31 March 2009 04:02:43 Martin Jambon wrote:
> Alexy Khrabrov wrote:
> > What is it about FP which makes modeling simpler than OO, conceptually
> > and technically?  How can folks summarize their "enlightenment"
> > experiences in this regard?
>
> ...
> Objects and classes tend to be more appropriate than modules and records in
> the following cases:
>
> - self-centric data that can be considered as a "resource", typically for
> IO operations.
> - frequent need to define and use interfaces before implementations.
> - keeping familiar names for functions/methods without requiring
> disambiguation prefixes ("input", "output", "print", "flush", "read",
> "send", etc.)

I'd also add that OCaml's object system is great when you're developing code 
and don't want to have to keep type definitions up to date as the code 
evolves. For example, I used objects to represent LLVM's state in HLVM.

I also used an object to avoid introducing a huge mutual recursion in Smoke.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] when OO is wrong

[Raoul Duke]

also, check out

http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora151.html