🚀 go-pugleaf

In article <114700003@uxa.cso.uiuc.edu> gsg0384@uxa.cso.uiuc.edu writes:
>
>Hi,
>
>Which language do you think will fit more purposes?
>From the present perspectives, it seems that
>
>FORTRAN 8x for numerical computation
>C++        for system and object-oriented programming
>Modula 2   for general purpose and eduation
>
>are going to serve ninties and the first decade of the 21th century.
>
>1) Is C++ not appropriate for general purpose?  Why?

I see no reason why it shouldn't. C++ basically contains everything that Modula
does, and MUCH more. Its major drawback is what is inherited from C, which
makes it very easy to write terrible code. But then, bad code can be written in
ANY language. C++ lacks the strict checks of module dependencies that are
performed by (most) Modula compilers. However, in a UNIX environment (with
make) the C/C++ approach works equally well (and is much more flexible).

>2) What are the deficiencies of Modula 2 as a system programming language?

In my eyes, first of all the lack of conditional compilation. Look at C code
that is portable across widlely differing hardware and operating systems. GNU
emacs, for example, comes in one distribution for all supported systems. To
configure it for a particular hardware/operating system, one only changes a few
lines (usually 1 to 3) in the configuration file and types "make". I don't see
how that could reasonably be done in Modula.

Second are address computations. Their definition in Modula is WRONG! If you
add one to a pointer in Modula, that's one storage unit (you don't even know
whether it's one byte or one word). In C/C++, adding one to a pointer to char
increments the address by one byte, incrementing a pointer to int increments
the address by sizeof(int). That's the way it should be.

Allocation of space for records (particularily alignment) is unclear in Modula.
Operating system calls frequently return pointers to records with some
operating system defined layout. Mapping these on Modula records is, due to
alignment, compiler dependent.

Further missing are bit manipulation operators. BITSETs provide most (or all)
that is needed, but using the BITSET operators on INTEGERs or CARDINALs
requires many type casts, making these manipulations both messy and unsafe.

Many further deficiencies of Modula will (hopefully) be fixed in the upcoming
international standard.

>What I particularly want to know is:
>3) Which of the two languages, Modula 2 and C++, is better suited for numerical
>computation?

Both have serious deficiencies here. The most serious one is probably the
impossibility to pass multi dimensional arrays of vaying size to subprograms.
Linearizing your matrices to be able to pass them to subprograms is a step back
towards assembler code.

Also very annoying for numerical computations is the lack of a real FOR
statement in C/C++. (Wirth, while always complaining about C, took the same
road in Oberon.)

Both languages lack an exponentiation operator. C supplies a standard library
function for that, Modula doesn't. Modula does not provide information on the
numeric properties of the hardware (like the machine epsilon). C has standard
library functions for that. Modula provides no means to switch between single
and double precision depending on the hardware (e.g. using single precision on
>= 48 bit hardware, double precision otherwise). C makes that easy using
#define.

C has a standard math library that is more extensive than what FORTRAN-77
provides. Modula has virtually nothing, the quasi-standard MathLib0 is totally
insufficient. The upcoming standard may rectify that, though according to what
I've seen so far there is not much hope.

If we look at current (pre-ISO Modula-2, AT&T C++, FORTRAN-77), rather than
future languages (i.e. ISO Modula-2, FORTRAN-8x) the disadvantages of FORTRAN
far outweigh its advantages even for numerics. Currently my language of choice
would be C++ in all three fields. Whether FORTRAN-8x is really better for
numerics I cannot say until I used it for a while.

>Thanks in advance.
>                       Hugh      gsg0384@uxa.cso.uiuc.edu


-- 
Gernot Heiser                   Phone:       +41 1/256 23 48
Integrated Systems Laboratory   CSNET/ARPA:  heiser%iis.ethz.ch@relay.cs.net
ETH Zuerich                     UUCP (new):  heiser@iis.uucp
CH-8092 Zuerich, Switzerland    UUCP (old):  {uunet,mcvax,...}!iis!heiser