[net.lang] C++ and Modula2

bs@alice.UucP (Bjarne Stroustrup) (10/30/85)

> From: rmarti@sun.uucp (Bob Marti)

> Subject: Re: C++ available (C++ and Modula-2)

> Posted: Mon Oct 28 20:07:01 1985

> Organization: Sun Microsystems, Inc.


> Now some remarks to the points you raised:


>(1) Thank you very much for telling me so much about type checking I did not

>    know!  Seriously, though, I don't see what passing a pointer to a vector

>    of functions or a zero-terminated list of pointer arguments has to do with

>    type checking.  If you want to say that Modula-2 does not support the

>    varargs stuff, you are right, it doesn't.  You can pass an array or a

>    pointer to an array of procedure variables, however, and you can also pass

>    zero-terminated arrays whose elements are of type ADDRESS, and coerce them

>    into their appropriate types inside that procedure (just like in C).  If

>    C++ does more than that, that is just fine!

Given the diverse readership of net.lang it is easy to get misunderstood and/or
state the obvious. Sorry. Yes, I do think that some form of varargs is important,
so C++ has it. The list of pointers example is a common C use of that.

>(2) Modula-2 does have facilities to define abstract data types, and an

>    object-oriented programming style is also supported to some degree:

>    Data abstraction is achieved by the textual separation of type and

>    procedure declarations from their representations/implementations.

>    (The representation of a data type can be hidden by declaring an "opaque

>    type" in a definition module).  An object-oriented programming style in

>    Modula-2 typically involves the use of procedure variables as the fields

>    of the representation of an opaque type.

Here, I think, is the heart of the matter. Consider the terms
	data-hiding,	data-abstraction,	object-oriented.
I doubt we will get a general agreement on their meaning this decade, but I'll
try to define them to give you an idea of why I think that Modula2 does not
support data abstraction or object-oriented programming. If someone wants to
re-start the debate about the proper definition of DA and OOP, please invent
a new title for the discussion.

data-hiding:
	A language supports data hiding if it can guarantee that some variables
	are only manipulated by a specific set of functions.

	Modula2 supports this directly.
	C supports this through the use of files in separate compilation.
	In both languages the hiding relies on name hiding and can (at least
	in most implementations) be circumvented by the use of address arithmetic.

data-abstraction:
	A language supports data abstraction if it allows the user to define
	new types for which variables can be declared so that the representation
	of a variable is hidden (that is so that the data in a variable can only
	be manipulated by a specific set of functions).

	C++ and Ada support this directly; C and Modula2 do not.
	A C or Modula2 module is an object, not a type, so no variables can be
	declared, operations like assignment are meaningless, etc.
	You can of course ``fake'' user-defined data types by defining a module
	that maintains a set of objects managed by the module and accessed only
	through the functions provided by the module for that purpose. However,
	such ``fake'' variables, must always be accessed through pointers (or
	some similar indirection mechanism), do not obey usual scope rules,
	and none of the usual mechanisms and notational conveniences for
	dealing with variables are available. This is equally true for C and
	Modula2. (Ada's model for data abstraction differs from C++'s but that
	is yet another story).

object-oriented:
	A language supports object-oriented programming if it provides a
	mechanism for determining the type of some objects at run time in
	contexts where that type cannot be determined by static type checking.
	Naturally the language must provide a mechanism for defining several
	types that can be manipulated in a uniform manner taking advantage
	of a dynamically determined type. (In other, words I think that an
	inheritance mechanism is essential for supporting object-oriented
	programming).

	C++, Simula67, and Smalltalk support this; C, Modula2, and Ada do not.
	Again, you can ``fake'' it in any sensible language; in its simplest
	form you simply need pointers to functions.

Clearly a style of programming is possible in most sensible languages even if
a language does not support it. For example, C does not support the notion of
type checking of arguments, but I may write my programs so that they do not
violate the type rules. However, in the absence of a program that checks
specific rules I'm likely (1) to have slightly different rules from what you
expect, and (2) break the rules deliberately and/or accidentally. That is one
reason why C++ and Modula2 check their arguments, and why (some) C programmers
use lint. Furthermore, since the C compiler does not know the rules I'm trying
to follow it can give me no conveniences based on the knowledge that I'm following
them. For example, there can be no implicit type conversion.

In the same sense, you can do data abstraction and object-oriented programming
in C and Modula2. It is about as easy and convenient as writing "strongly typed"
programs in C. C++, however, supports specific models of data abstraction and
object-oriented programming.

>(3) I don't know why you think Modula-2 would have been a much more

>    interesting language if it had appeared in 1978 as Pascal-2 (!), but

>    I can assure you that Modula-2 *did* appear in late 1978 (see N. Wirth:

>    "Modula-2." Swiss Federal Institute of Technology Zurich, Instut fuer

>    Informatik, Report Nr.27, 1978).  As far as I recall, even a compiler

>    generating PDP-11 code was publicly available at that time.

``The first implementation of Modula-2 became operational on the PDP-11 computer
in 1979, and the language's definition was published as a Technical Report in
March 1980. ... the compiler was released for outside users in March 1981.''
	- N. Wirth: Programming in MODULA-2 (second corrected edition).
However, each year dozens of languages and dialects spring up, and many see
intensive use (How do you like BNR Pascal?). Had Modula2 in 1978 had clear
support as a/the new Pascal standard (i.e. been Pascal2) and had there been
widely available implementations of good quality together with program development
tools, documentation and introductory material, C would have had real competition.
However, in 1978, C had those things and Modula2 did not have a compiler.
Modula2 MAY have those thing NOW, in which case it is about 7 years late.


>(4) As far as the quality of Modula-2 books, especially Wirth's book, versus

>    the quality of K&R is concerned, I think this is largely a matter of taste.

>    But even if you rate K&R considerably higher than Wirth's Modula-2 book,

>    it still is a very lame excuse for not looking into Modula-2.

I didn't make it. I just found Wirth's book a strange cross between a reference
manual and a tutorial. Maybe some of the latest crop of Modula2 books are better
(or, should I say, more to my taste).
 
>(5) Class-concept, inheritance, data hiding, operator overloading, etc. sounds

>    just fine to me.  I will certainly have a thorough look into your book on

>    C++.  It'll probably quite a while until I'll get a chance to use C++,

>    though.  I agree that at least inheritance and operator overloading are

>    a considerable step beyond the facilities of either C or Modula-2, and

>    I also realize that the design and implementation of these facilities

>    are non-trivial, to say the least.

Thanks. The implementation is not really that complicated once you figure out
how to do it. Good luck. C++ is in use on Suns, so it might not be so hard for
you to get to try it.

> --Bob Marti, {decvax, ucbvax, seismo}!sun!rmarti


	- Bjarne Stroustrup (AT&T Bell Labs, Murray Hill)