🚀 go-pugleaf

quoth  Gernot Heiser <mcvax!cernvax!ethz!iis!heiser@UUNET.UU.NET>:

>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.
>>

Personally, I despise all procedural languages for being such.  They are
semantically obfuscative, period.  As optimization methods for the
compilation of functional languages continue to develop at a furious pace,
I expect that some as yet unrealized LISP/Prolog stew shall be the
principal source of sustenance for the hungry programmers of the late 90's
and beyond.  This is the case particularly in view of the fact that
automagical code-generation is MUCH simpler (and more efficient) in such
languages.

>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.

As was recently observed in the info-pascal mailing list, optimization ->
conditional compilation.  Consider:
      .
      :
      CONST
      .
      :
        OpSys = VMS;
      .
      :
      IF OpSys = VMS THEN
        DoVMSStuff
      ELSE
        DoOtherOSStuff;
      .
      :

All but the most inanely STUPID of compilers will completely eliminate the
unreachable code.

>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.

Call me a heretic, but I often think that the safety-madness of Modula-2
is the result of completely loosing sight of the purpose of programming:
To GET THINGS DONE.  Modula-3 rectifies this to some extent, but if I actually
want to get results in a reasonable time-frame, and LISP is forbidden to me--
often the case in systems-level applications by virtue of the relatively
primitive state of commerically availiable LISP compilers, I'll pick C/C++
over M2 anyday.  On the other hand, big multi-party projects make the laxity
of C prohibitvely expensive.  (Too obvious for words, right?) Hence C++.

>>What I particularly want to know is:
>>3) Which of the two languages, Modula 2 and C++, is better suited for numerica
   l
>>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.)

I don't understand how it is 'impossible' to pass such arrays in C.  I may
not be cognizant of changes made by the ANSI standard in this regard, but
each dimensional component of a C array being merely a pointer, one may
readily pass any array of any structural characteristic, to a 'subprogram'.
It is however, necessary to pass explicit information regarding the run-time
structural characteristics of such a data object, in order to prevent
inappropriate memory accesses.

Nor do I understand what is unreal about
C's 'for'.  It is a powerful generalization (within it's limited domain)
of the BASIC/Pascal/Modula, etc. 'for'.  I'd like to know what objections
you have to the character of the C 'for', please.

>....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.

Again, conditional compilation...

I hope that my comments will be construed constructively and prove sufficiently
non-trivial to provoke some rejoinder.

;;__________________________________________________________
;;Anthony L Kimball : alk @ ux.acss.umn.edu / UMNACVX.bitnet
;;U of Mn ACSS Languages Group.
(use-package 'disclaimer) ;quidquid cognoscitur, cognoscitur
                          ; per modem cognoscentis.