Version française
Home     About     Download     Resources     Contact us    
Browse thread
RE: [Caml-list] Some Clarifications
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David Thomas <david_hd@y...>
Subject: Re: [Caml-list] Some Clarifications
I notice that there are two things that people have
been commonly confusing with the notion of Object
Oriented programming.  The first of these is the
notion of modularity.  While this is generally
provided by OO design, it can (and should!) certainly
be applied in virtually any methodology.

The second is the notion of OO design, and the
language features provided to make it easier.  Any
time you write a program that focuses on the
components as "data and operations on that data," you
have written an OO program.  This can be done in any
language.  It doesn't matter what the components are
called, they can be classes, structures, records,
modules, or libraries. It also does not require the
use of polymorphism or inheritence,  although these
quite often make implementing and extending such
designs significantly easier.  I've seen many designs
in OCaml (most of the core libraries, to start with)
that have this focus, and much (though not all) of
what I've written does as well, regardless of whether
we've used those language features set aside as
designed to facilitate OO implementations.  I would
guess that you have, too.

** digression **
The Java practice of forcing you to represent the
entire program as a class does nothing to encourage OO
design.  The focus is not on the data, it is still on
the operation to be performed.  This limitation on a
"pure OO" language is admittedly imposed from outside.
 I've yet to see an OS that provides support for truly
OO design.  The GUI notion of associating a default
action with a file type comes close, but I've not seen
this used in a shell, which would be rather
interesting, though I've no clue how usefull.

--- Jon Harrop <jon@ffconsultancy.com> wrote:

> On Wednesday 27 July 2005 10:38, Don Syme wrote:
> > For what it's worth, I found your posts genuinely
> interesting.
> 
> I think there is something of interest worth
> discussing but most of it would 
> be more appropriate on c.l.functional than here. I'd
> be happy to discuss this 
> there.
> 
> Just replying to the OPs OCaml-related comments: I
> don't think that most 
> programmers use OO because it is the right tool for
> the job. I think they use 
> it either because it is forced upon them (Java) or
> because the language fails 
> to provide alternatives (C++).
> 
> OCaml is a useful case study here because it
> provides many alternatives. 
> You're not going to implement a closure via an
> object (as you would in C++) 
> or a 3D vector via an object (as you would in Java),
> for example. So it is 
> instructive to look at uses of OO in OCaml code.
> 
> Of the OCaml code which I have studied, the OCaml
> compilers make scarce use of 
> objects, the stdlib makes no use (IIRC), the third
> party data structures and 
> algorithms that I use also make no use of OO but
> lablgtk uses OO and I have 
> one friend who has tried using OO in his own OCaml
> work.
> 
> In my code, I have used an object once, in order to
> circumvent a typing 
> problem. I have never successfully used OO in OCaml.
> 
> From my point of view, it is interesting to compare
> graphics and GUI code 
> which I have written in a classical FP style to a
> friend's who chose the OO 
> approach because GUI code is a pedagogical example
> of OO design. Although it 
> is early days, I see no evidence that OO is any
> better than the classical FP 
> approach at this task.
> 
> > Part of what I think accounts for the popularity
> of OO in the real world is
> > that it allows you to program in a very sloppy way
> in the early stages of
> > development without blowing your ability to muck
> with the way things
> > interact,  and alter their behavior later in the
> development process.
> > Ideally,  it allows you to build big,  sloppy, 
> poorly planned systems that
> > are nevertheless manageable to maintain. 
> 
> My experience is exactly the opposite. I worked on a
> project for several years 
> which was written in C++ and which used OO
> extensively. Ultimately, we 
> ditched both C++ and OO in favour of OCaml and FP
> precisely because we wanted 
> to make a few fundamental changes and those changes
> were simply too difficult 
> for us to make successfully. In contrast, we have
> made many similarly 
> complicated fundamental changes to the OCaml code
> with no problems.
> 
> So, despite reasonable understanding and planning
> beforehand, OO completely 
> failed to allow us to maintain and develop the
> program.
> 
> > I find that the facilities of a language like
> OCaml are so inadequate to
> > represent this domain,  that using OCaml can be a
> distinct impediment.
> 
> If you would like to discuss OCaml-related stuff
> then I'd like to hear more: 
> specifically what it is you're working on, what you
> have tried and failed to 
> do in OCaml and why you think OCaml is "so
> inadequate"?
> 
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> Objective CAML for Scientists
>
http://www.ffconsultancy.com/products/ocaml_for_scientists
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
>
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs