Re: The disturbing myth of Eiffel portability

[pcg@aber.ac.uk (Piercarlo Grandi)]

>>> "jmiller" == Jeff Miller <jmiller@probe.net> writes:

jmiller> The Rt Rev'd Colin James III, KOTM 1/96 wrote:

cjames3> Eoin Woods is deluded in the article quoted below.

Ah well, perhaps you should phrase this in a less personal way :-).

cjames3> Almost all banks still do most of their processing in COBOL.

Well, indeed, if one is considering back-office processing; but their
front-office applications are nowadays indeed mostly done, in the more
progressive banks, in:

cjames3> All new development in US banks with European branches is in
cjames3> C++ back end and many front ends

In many cases these front-ends are C++ based too...

cjames3> (none in Eiffel that I know of).  This is partly due to C with
cjames3> its silly pointers not scaling well and mostly due to floating
cjames3> point problems at run time in C.

I don't think that the definite advantage that C++ has as to the ability
to define ``intelligent'' pointers is much relevant to why banks use C++
instead of C for front-office developments, so I would not consider it
even a partial cause ("partly due");

IMNHO the major cause is perhaps the fashionability of C++.

As to technical reasons I can agree that perhaps the strongest ("mostly
due") one is indeed the ease and efficiency of adding a multiple
precision numeric type to C++, which obviates the variable precision
properties of floating point arithmetic in C.

jmiller> Could you elaborate on the way pointers in C restrict
jmiller> scalability?

Well, there is not much need to: there is an ample literature (just use
some WWW index to search for either "intelligent pointer" or "pointer
swizzling" for many references to the two concepts) on the possibility
to define ``intelligent'' pointer datatypes in C++, in a way that is
impossible in C, and then uasing those to implement the ability to do
pointer ``swizzling'' and other techniques (mostly inspired by
Smalltalk-80's LOOM and other similar technologies in Lisp Machines)
that allow a program to manipulate a set of objects potentially much
larger than that which can be contained in the address space visible to
a program (depending on how large the latter is).