Re: [Caml-list] productivity improvement

[Alessandro Baretta <alex@baretta.com>]

John Max Skaller wrote:
> Alessandro Baretta wrote:
> 
>>
>> Yes, but RTTI is a hack. 
> 
> 
> 
> Matches on ocaml unions _also_ use run time checks.

Sure. Pattern matching is not a problem when it's idiomatic 
and safe. You can say that pattern matching is the most 
basic construct in O'Caml--even let x = 1 is a pattern 
matching. C++, on the other hand, has *no* pattern matching 
construct. RTTI is a kludge, retrofitted on a badly flawed 
language, because there were situations where OO 
polymorphism could not be used.

>> Nobody would seriously "plan" to use RTTI during the design stage of a 
>> software system. 
> 
> Sure they do.

Some people even go bungee jumping o sky diving. You just 
wouldn't beleive how crazy people can get.

>> You just "happen" to need RTTI when most of the code is already there 
>> and you realize there is a bug in the specification which would 
>> require to redesign the inheritance hieararchy. In such cases you go 
>> with RTTI. Otherwise, you'd stick to simple OO polymorphism, which is 
>> the "Right Way(TM)" to use 
> 
> No. (class based) object orientation is utterly flawed as a paradigm, as 
> can be seen
> by posing the trivial problem of representing any type with a binary 
> operator.
> It just can't be done, the problem is called 'covariance problem'.

I searched Google for a covariance problem related to 
unimplementable interfaces but with no luck. Could you point 
me to some literature?

>    struct X { virtual bool binop(X const&)const=0; };

Tell me if I got this straight: OO polymorphism requires 
that inheriting classes wishing to override methods of 
parents must use covariant return types and contravariant 
parameter types, so as to guarantee that inheritance implies 
subtyping. In this case, it would be meaning less to 
implement interface X because, applying the contravariance 
principle to the formal parameter of binop, you'd end up 
with a class whose binop will accept as rhs parameters any 
instance of any subtype of X. Therefore a class Integer will 
have a greater_than_binop accepting instances of class 
Rational, Real, Complex, Quaternion ... This is meaningless, 
of course, so we conclude that establishing an identity 
between inheritance and subtyping relations is paradoxical. 
Correct?

> In commerical applications, almost ALL data is relational,
> and so cannot be abstracted. The OO paradigm is not just
> useless here, but downright destructive.

Slow... What? I don't follow you here.

> Example:
> 
>    class Transaction { ..
>    class Invoice { ...
> 
> Well, suppose you wanted more than one kind of transaction,
> and more than one kind of invoice .. some ignorant designer
> would think polymorpism would work here.
> 
> I doesn't though. You you end up using RTTI hacks,
> NOT because of a design error .. but because the very paradigm
> is faulty.

I can't say. All the literature I read on OO languages 
(_Teach_yourself_C++_in_21_days_/_Java_for_Dummies_ :-) ) 
seems to indicate that RTTI is "intracardiac adrenaline" of 
fibrillating software systems. You try RTTI, then, if it 
dies all the same, you type "rpm --install 
ocaml-3.04.<your_arch>.rpm" and start a new life.

> Not I'm not saying objects/classes etc are useless. I'm saying
> they're just a tool with some limited uses: they perform well
> when restricted to those uses. If no covariant methods are needed,
> abstraction works. For example: device drivers typically have
> methods with invariant arguments.

That's why Linux is coded in C as opposed to C++. I wonder 
about the possibility of writing a functional kernel...

Anyway, it is now appropriate to conclude with: Long live 
the Caml!

Alex



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners