Path: utzoo!attcan!uunet!mcvax!enea!naggum!isncr!m2cs!frode
From: frode@m2cs.naggum.se (Frode Odegard)
Newsgroups: comp.lang.modula2
Subject: C++ vs. Modula-2
Keywords: Modula-2 C C++
Message-ID: <122@m2cs.naggum.se>
Date: 16 Jan 89 18:50:45 GMT
Organization: Modula-2 CASE Systems A.S, Oslo, Norway
Lines: 171

This posting is a reaction to some of the statements made in the on-going
C++ vs. Modula-2 debate here in comp.lang.modula2. The quotes are from several
postings.

****..VAR FLAME: BOOLEAN; BEGIN FLAME := TRUE; *****

>> Is C++ not appropriate for general purpose? Why?

>I see no reason why it shouldn't [be]. C++ basically contrains everything that
>Modula does, and MUCH more.

C++ has a notion of scoping that makes me s**k. Modula-2 has better scoping.
The beauty of a language is not found in its size. C++ is too complex.

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

The point is, people won't write purely o-o in C++, because they'll use lots
of exisiting C libraries which are not exactly o-o.

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

Bull! First of all, I would never use a programming language (for a project over
1000 lines) which doesn't support separate compilation of module/class definitions
and implementations. Second, how can the use of a static Makefile give you more
flexibility???  At least Modula make's will find out the module dependencies
by checking .sym and .o files. What's the point of using an o-o language (which
C++ claims to be) if you have to update Makefiles every time class dependencies
change??? Bah! So much for the Smalltalk inheritence, right? :-)

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

>In my eyes, the lack of conditional compilation. Look at C code that is portable
>across widely 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, oone 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.

Have you actually _programmed_ in Modula? Preprocessors and other utilties are
not magically built into a computer language (except maybe Lisp and Smalltalk,
where there's no border between language and environment). Make can be used
for Modula-2, too. I don't use it because I have better tools than the make
that comes with SunOS. I could have used cpp on Modula-2 code, but because I
wish to keep my source code clean of non-standard syntax, I don't. There is
a Modula-2 preprocessor available for very little money which has all the cpp
facilities but demands that commands for it are placed in comment brackets
to avoid the introduction of non-standard syntax. Why should I use old UNIX
tools when I have better tools which make use of Modula-specific facilities?

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

Just like ++ and -- are in C mainly because of the PDP-11 instruction set :-),
Modula-2 has traditionally had the type WORD in SYSTEM. As Modula-2 was ported
to micros, compiler writers added SYSTEM.BYTE. There was some confusion about
ARRAY OF SYSTEM.WORD vs. ARRAY OF SYSTEM.BYTE, and to resolve this, ISO Modula-2
will have something called SYSTEM.SAU. SAU stands for Smallest Addressable Unit,
and thus the old BYTE <-> WORD confusion has been removed. Compiler implementors
are also required to define BYTE and WORD in terms of SAU in SYSTEM. The type
ADDRESS is defined as POINTER TO SAU.

The reason why Modula doesn't have +,-,DIV,REM,* defined for ADDRESS values is
that it is considered machine-specific. There are lots of weird machines out
there, you know. Compiler implementors are free to put as much low-level,
machine-specific features in SYSTEM as they want.

Modula-2 hackers know that modules which import from SYSTEM are machine/os/
compiler-specific anyway.

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

It's not a big problem, really. When you do Modula-2 interfaces to OS calls,
you're operating on a low level of abstraction anyway. The data structures will
not be portable to another OS. They will however, with some usage of subrange
types (another good Modula-2 feature which C/C++ don't have) be portable from
compiler A to compiler B. We've written a very complete interface to the SunOS
system calls, and it was not difficult at all.


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

>Both have serious deficiences 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.

What's the problem? Since Wirth released the paper "revisions and amendments
to Modula-2" quite some time ago, multiple-dimension open arrays has been
_in_ the language. It is also in ISO Modula-2 [which is now only a few months
away]. If C++ has so many fantastic things, why doesn't it have this feature
(BTW, I thought it _had_, honestly)?  Wirth consentrates on the essential
features when designing languages, that's why his languages are rather small
and clean.

> <goes on and on about library issues>
The library issue is being fixed once and for all in the upcoming ISO standard.
This hasn't been a huge problem for big Modula-2 projects (at least that's my
experience) because "real Modula hackers write their own libraries anyway".
Standard libraries: great for text-books and classes, but some of the big
Modula projects have done everything from the compiler up to the 3,000,000-line
application in-house. What's a 3,000-line library, then? A couple of weeks of
hacking? C's standard library is rather UNIX-oriented. The 4-5 library styles
used in different Modula implementations also lean towards different operating
systems (Medos for example).

>Personally, I despise all procedureal languages for being such. They are
>semantically obfuscative, period.
Not true. ISO Modula-2 is defined in VDM. It works!

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

Heretic! :-)  I quite disagree. The safety of Modula-2 (Modula-3 goes even further I
believe) has saved a lot of money for its users. Modula-2 users spent much less
time that C users digging on a low level trying to find a bug that wasn't seen
by the compiler.

Working on programming environment research, I believe that the trend of the future
is towards more intelligent environments. I don't believe in the C culture that says
"leave my hacks alone, I only run lint on Christmas Eve".

C++ is not as good as Modula-2 for large projects, I expect, because it doesn't
support separation (by compilation, by rule, defined in the language etc.) of class
definitions and implementations.

>In the Modula-2 context, I am sure that the machine-specific vector extensions
>to the CDC Pascal/Modula-2 compiler (for the Cyber 205 & ETA-10) are not
>syntactically valid on other machines.

If someone does non-standard Modula-2 implementations, I don't think Modula-2
can be blamed. Compiler/machine-specific extensions to the language should be
put in SYSTEM.

>Including .h files is not the same as importing modules, no matter what a C
>hacker tells you.

Right!! :-)  This cannot be repeated too often. One must tell people that
.h files are textually included and expand to "extern func_name;" declarations,
which the same old ASM/FORTRAN story. C hasn't got a module concept.

>Conditional compilation is not the same as dead code elimination.

I agree. However, I'm not sure preprocessors repesent a good solution to
portability. I think Modula-2's module concept is vastly under-estimated
when it comes to writing portable Modula-2 software. I certainly dislike
solving the problem by introducing language extensions. I work for a company
which is building a Smalltalk/Interlisp-D inspired programming environment
for large-scale Modula-2 projects (runs on Suns and VAXen). I think we have
solved a lot of problems by creating better Modula-2 tools instead of extending
the language.

*** FLAME := NOT FLAME; END ******

 					- Frode
-- 
| Frode L. Odegard         |"The world is coming to an end! Repent and|
| Modula-2 CASE Systems    |rm /bin/cc"                               |
| NORWAY (EUROPE)     	   |                                          |
| Email: frode@m2cs.uu.no  |                                          |