Browse thread
RE: [Caml-list] Some Clarifications
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | james woodyatt <jhw@w...> |
| Subject: | Re: [Caml-list] Some Clarifications |
On 27 Jul 2005, at 03:58, Jon Harrop wrote: > > 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 the first pass through at my functioanl reactive I/O [Iom] library in OCaml NAE, I managed to get a lot done without using any objects. In general, this produced tighter code, but it was less adaptable than I wanted it to be, and I found it hard to reuse parts of reactors. Sure, reactors themselves were highly reuseable, but I found myself wanting to make a framework of very similar reactors all built out of some common functions. A reactor was typically written as a huge bundle of mutually recursive monad functions, and it was a major pain to separate the reusable functions from the rest of the bundle. In my recently announced refactoring of the [Iom] library, I found I could get more adaptability by using the object system. In the new code, reactors can be written as classes (even pure functional classes) and the monad functions implemented as methods. It makes the challenge of designing a general purpose reactive I/O framework a lot easier. The problem of separating the reusable functions from the rest of the bundle is resolved by implementing a class with virtual methods. I doubt this hybrid approach, combining both FP and OO, could be used in any other language I know about. From my perspective, FP and OO are orthogonal and not mutually exclusive techniques. Once you decide to use OO for what it really does, and which FP doesn't, I think you find that what it has to say about large-scale software development is a lot less than what most practitioners think. This is because you're right: most programmers don't use OO because it's the right tool for the job; most use it because it's inappropriately forced on them by a language that doesn't provide reasonable alternatives for things that don't need OO to enable. -- j h woodyatt <jhw@wetware.com> markets are only free to the people who own them.