Book REview

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

Last Friday I received several textbooks for review.
One of them was

	Ada 95 Problem Solving and Program Design
    by	Michael B. Feldman
   and	Elliot B. Koffman
  ISBN	0-201-87009-6
  pub.  Addison-Wesley
  date  1996

Now, regular readers of comp.lang.ada will need no introduction to
Dr Feldman.  He's just about at the top of the list that people like
Rev. <deleted to avoid lawsuits" are at the bottom of.  From his
postings and from another of his books, I had the very hightest
expectations for this book.

Well, there's good news and there's bad news.

The book is intended to be used as a CS 1 text.  All of the examples
(some 200) are available over the net.  There is an _excellent_ range
of topics, and much good advice.


Now for the bad news.
I should make it clear that I started by reading chapter 14 (picked
haphazardly; that's where the book fell open), and then sampled
chapter 8 to confirm my findings.  I have not studied the whole book
in detail.

The book is apparently being sold in an international market (I'm posting
from Australia), but it appears to have been _written_ for the US market.
For example,
	SUBTYPE Uppercase IS Character range 'A' .. 'Z';
	...
	IF Ch IN Uppercase THEN ...
The preface says the programs are intended to be __entirely__ portable;
their emphasis.  Too bad about EBCDIC, ISO Latin 1, DOS CP 437, or any
of the IBM, HP, Apple, or other character sets where the capital letters
are not a contiguous range.  This method of checking for an upper case
letter simply cannot be used in any character set but ASCII.  Now Ada83
was ASCII-only, but Ada95 is not.

For a more blatant example, how about reaing and writing dates?
The US convention of month, day, year is allowed to dictate the order of
fields in a record (without any comment), and to dictate the form of IO.
You can't please everyone, but that example would have been a _splendid_
opportunity to point out that cultural conventions for things like dates
differ, and that an important reason for having packages like SimpleDates
is so that you have a _single_ place to change when adapting to a different
locale instead of having local conventions replicated in hundreds of places.
("Adapt the implementation of SimpleDates to read and write dates in
  Spanish form, which is ...".  would have made a _great_ exercise.)

Another cultural matter:  what the heck is a GPA?  It's assumed without
explanation (or at any rate without _nearby_ explanation).  I know what
a CPA and a GPF and a GAP are, but a GPA?

The index is incomplete.  For example, chapter 14 introduces subunits
and separate compilation, and neither "subunit" nor "separate" appears
in the index.  In fact, they don't appear table 14.1 either.

This probably reflects the sloppy proofreading I have found everywhere
I looked.  A couple of examples:
	on p653, one occurrence of the assignment symbol is spelled ": ="
	while all the others are spelled ":".

	in chapter 8, is the package called (a) Dates, (b) SimpleDates, or
	(c) Simple_Dates?  The text can't make up its mind between (a), (b),
	and (c), and the _code_ can't decide betwee (a) and (b) either.
	
	does the record type introduced in example 8.1 have five fields
	(as in the code and some of the text) or six (as in figure 8.1
	and the rest of the text)?

	The identifier "NonNegFloat" on p385 should almost certainly be
	HoursRange.

	The examples in self-check exercise 1 for section 14.1 on p660
	use a field called "Link", but the field is actually called "Next"
	in the declaration on p654

There are some questionable technical points.
Chapter 8 repeatedly insists on the formula sqrt(x**y + y**2), which
is great mathematics but poor computing.  

The definition of "memory cells" had me cringing, and the _uses_ that are
made of that concept disappointed me.  Page 371, for example, says
	"Because arithmetic and logical operations--except for equality
	and inequality--can be performed on only[sic] individual memory
	cells, record variables cannot be used as the operands of
	predefined arithmetic and relation operators."
(a) In this book, "memory cells" means _bytes_ (it is taken for granted
    in another example that each Character occupies precisely one "cell").
(b) The machine I'm posting from (a SPARC) cannot do arithmetic or logical
    operations on bytes; it can _only_ perform these operations on groups
    of 4 or 8 bytes.
(c) And the SPARC, like many modern machines, doesn't do arithmetic or
    logical operations on memory cells at all; it operates on the _values_
    which are held in registers.
(d) Of course machines like CRAYS, Alliants, (SPARC V9 with VIS instructions?,)
    B6700s, and many others are quite happy to operate on whole arrays.
(e) Whatever the _hardware_ can do, APL programmers would be surprised to
    hear that aggregates can't be operated on, and of course COBOL has had
    ADD CORRESPONDING, which operates on records, for quite a long time.
(f) Come to that, Ada _has_ got logical operations defined on arrays.

The _right_ explanation here would be
	"Ada's predefined arithmetic and logical operators are not defined
	 for records.  There are many reasons for this (see Rationale section
	 N if you care).  If you have a record type on which arithmetic
	 and/or relational operators would make sense, you can define them
	 yourself; we shall see how in Chapter 10."

Self-check exercise 1 for section 8.2 says

    1.	What does the program segment below do?
	Provide the declarations for variables Exam1 and Exam2.	

	    PrintStat (Exam1);
	    Exam1 := Exam2;
	    Exam2.High := Exam2.High - 5.0;
	    PrintStat (Exam2);
	
The answer to this is

	It is impossible to tell what it does.
	I can't find "Exam" or "PrintStat" in the index.  For all I
	can tell, PrintStat could do ANYTHING.  Any declaration like

	type Exam_Type is record
	    High: Float;
	end record;

	Exam1, Exam2: Exam_Type;

	would do for declaration, but I cannot tell what the type name
	_should_ be or what other fields, if any there should be.

Programming exercise 1 for section 8.5 on p389 uses a construction which
is not explained until p404.

The procedure "Post" on page 400 contains
	LOOP
	  -- invariant:
	  -- no prior value of NextCommand  is Sentinel
	  ...
	END LOOP;
but that statement is _not_ an invariant of the loop (when the loop terminates
it is false) and in any case the invariant that _matters_ in this loop is
	"for each category C, Budget(C) is the sum of the expenses
         in category C read so far".

Programming project 6  for chapter 9 on p477 says
	"The data string for each employee takes up 42 positions:
	 1--10		Employee's last name
	11--20		Employee's first name"
One of the lessons that seems to be hard to get across to students here is
that "fixed sizes are almost always wrong".  This is an excellent example.
I just checked our student name list, and find that there are 108 distinct
first or last names which will not fit in 10 characters, including
	Giannoulopoulos,
	Steigenberger,
	Townley-O'Neill,
	Goldsworthy,
and	Christopher,
the longest such name having 20 characters.  This would have been a good
place for a "what's wrong with this design" question; instead it serves
as a bad example which will be imitated rather than avoided.

The description of big-O notation on p419 is cursory and rather poor.
One must understand that teaching big-oh notation is not a goal of the
book.  Even so, I think it might have been better to leave it out
entirely than to include the present text on the matter.

And so it goes.

The pity of it all is that my _overall impression_ is that this is a
really good book.  If this were a _draft_ I had been sent for review,
I would be saying "wonderful, let's use it next year".  Thanks to the
sloppy proof-reading, I'm actually saying "I _wish_ we could use this
book but we cannot in good conscience recommend it to students without
an errata booklet."

I am *really* sorry to say that.  I am aware from Dr Feldman's postings
in this group and his data structures book that he is deeply committed
to excellence in computer science education, and secondarily to Ada as
a superb tool for that job.  I am less acquainted with Dr Koffman's
work, but evidently he too enjoys an earned high reputation; a staff
member here who does know some of Koffman's books speaks highly of them.
The topics, presentation, review material, examples, explanations, and
all that are, wherever I have examined them, of a high or very high
standard; following this course material would improve our first year
teaching substantially.  BUT if only one of the seven formal reviewers,
two other helpful commentators, seven member production team, or any of
the other people thanked on pxi had done a thorough proofreading job!


-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.