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

Re: [Caml-list] when OO is wrong

[Ed Keith]

--- On Mon, 3/30/09, Raoul Duke <raould@gmail.com> 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?
>
> it is worth seeing http://www.info.ucl.ac.be/~pvr/book.html

I'm still learning Ocaml, coming from a C++ background. 

I love Concepts, Techniques, and Models of Computer Programming. It is one of the best computer books I've ever read. One of it's messages is that there is no one right paradigm. This is what I like about C++ and Ocaml. I am not forced to fit a square peg into a round hole. I can use procedural, functional or o-o techniques, depending on which is a better fit for the problem. 

I do wish I had better tools for visualizing FP designs. I use Nassi-Schneiderman diagram for procedural designs and UML of OO designs.

   -EdK

Ed Keith
e_d_k@yahoo.com

Blog: edkeith.blogspot.com

Re: [Caml-list] when OO is wrong

[Jon Harrop]

On Monday 30 March 2009 23:38:45 Ed Keith wrote:
> I do wish I had better tools for visualizing FP designs. I use
> Nassi-Schneiderman diagram for procedural designs and UML of OO designs.

That's an interesting idea. Someone must have worked on this?

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

Re: [Caml-list] when OO is wrong

[Oliver Bandel]

Quoting "Jon Harrop" <jon@ffconsultancy.com>:

> On Monday 30 March 2009 23:38:45 Ed Keith wrote:
>> I do wish I had better tools for visualizing FP designs. I use
>> Nassi-Schneiderman diagram for procedural designs and UML of OO designs.
>
> That's an interesting idea. Someone must have worked on this?
[...]

In the book "Haskell: The Craft of Functional Programming"
at some pages are graphical notations, at least explanatory,
for some things.


A paper which you also might find interesting:

"To Dissect a Mockingbird:
A Graphical Notation for the Lambda Calculus with Animated Reduction"

   http://users.bigpond.net.au/d.keenan/Lambda/index.htm


Ciao,
    Oliver

Re: [Caml-list] when OO is wrong

[Ed Keith]

--- On Tue, 3/31/09, Oliver Bandel <oliver@first.in-berlin.de> wrote:
> Quoting "Jon Harrop" <jon@ffconsultancy.com>:

> > On Monday 30 March 2009 23:38:45 Ed Keith wrote:
> >> I do wish I had better tools for visualizing FP designs. I use
> >> Nassi-Schneiderman diagram for procedural designs and UML of OO designs.
> > 
> > That's an interesting idea. Someone must have worked on this?
[...]


> A paper which you also might find interesting:
>
> "To Dissect a Mockingbird:
> A Graphical Notation for the Lambda Calculus with Animated Reduction"
> 
>  http://users.bigpond.net.au/d.keenan/Lambda/index.htm

The notation is very useful for teaching, but I can not imagine using it to design a complex system.

   -EdK

Ed Keith
e_d_k@yahoo.com

Blog: edkeith.blogspot.com