Xref: utzoo comp.object:3275 comp.lang.misc:7557
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!andante!alice!bs
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.object,comp.lang.misc
Subject: Re: Readability of Ada
Summary: another example
Message-ID: <20245@alice.att.com>
Date: 20 Apr 91 17:29:49 GMT
References: <3878@ssc-bee.ssc-vax.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 118



I think that it is interesting to note that the example used in this
debate about the readability of Ada/C/C++ is in the domain where the
solutions are essentially equivalent. Hence the diversion (?) of the
debate into namin and commenting conventions. I do not think that there
are any significant differences between the languages at this level
so that the debate necessarily gets diverted into matters of taste,
management, and sociology. Those discussions have their place, but
I think that there is a significant issue in the readability of code
where a language supports or fail to support a programming paradigm.

So, how about comparing the languages on the example originally used
to introduce the technique we now commonly refer to as object-oriented
programming in the Simula textbook SIMULA BEGIN? The problem is to
write a little program that define a set of shapes and manipulates
them (I'll rotate a list of shapes). Then we add another shape and
see what effort that takes and whether the original code manipulates
shapes still works. There are other `tests' for object orientation
(both harder and easier on the expressiveness of programming languages),
but this one has the property of demonstrating a realistic problem
of program organization in a small problem and has been around for
about 20 years.

Naturally, I'll give my version in C++ and in a programmer's rather
than a software engineer's style of C++. The comments are used
primarily to explain C++ features to a non-C++ programmer and only
secondarily to document the program. If someone feel the urge they
can complete the example (it is for example missing suitable constructors)
and elaborate it suitably with comments and organizational details:

// first we define the Shape type as an abstract class:

	class Shape {	// representation details common to all shapes:
		point center;
		color col;
		// ...
	public:		// user interface:
		point where() { return center; }
		void move(point to) { center = to; draw(); }

		virtual void draw() = 0;
		virtual void rotate(int angle) = 0;
		// ...
	};

// `virtual' means that dynamic binding will be used in a call of a virtual
// function, `= 0' means that any class derived from this class must provide
// an implementation of the function.

// To define a particular shape, we must say that it is a shape
// and specify its particular properties (including the virtual functions).

	class Circle : public Shape {
		int radius;
	public:
		void draw();
		void rotate(int) {}    // yes, the null function

		// ...
	};

	void Circle::draw()
	{
		// ...
	}

// we can now write a piece of ``user core'' manipulating Shapes:

	void rotate_all(Vector<Shape*>& v, int angle)
		// rotate all members of array `v' `angle' degrees
	{
		for (int i = 0, i<v.size(); i++) v[i].rotate(angle);
	}

// I used a Vector template rather than a plain C array as the argument type
// Vector<Shape*>& means `reference to Vector of pointers to Shapes.'
// If that is considered `cheating' I can either go back to the C style
// or provide the Vector definition; it is about 20 lines of C++

// adding new Shape doesn't interfere with older Shapes
// or with older code manipulating Shapes:


	class Rectangle : public Shape {
		Point nw, se;
	public:
		void draw();
		void rotate(int angle);
		// ...
	};

	void Rectangle::draw()
	{
		// ...
	}

	void Rectangle::rotate(int angle)
	{
		// ...
	}

Please note that I'm not claiming that all programs require the
mechanisms used here (many do and many don't) nor that C++ is the
only language that can express this example easily (it is not, I
deliberately chose one of the oldest and most easily expressed examples
of object-oriented programming techniques).

Reeasonable questions in this context is to which extent abbreviations
such as + for `plus' & for `reference to' and { for `start scope' affect
readability and more generally how the issue of terseness vs verboseness
affects readability for novices and experts.

Another interesting issue is once a program has been expressed in a language
what guarantees does the language provide? This relates to the issues of
direct support vs programming techniques and to the thorny issue of run-time
versus compile-time checking.