Re: Book REview

[ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)]

dewar@cs.nyu.edu (Robert Dewar) writes:

>Richard O'Keefe said about Mike Feldman's book:
>"        SUBTYPE Uppercase IS Character range 'A' .. 'Z';

>This is very confused on Richard's part. The Type Character is always
>Latin-1, in which 'A'..'Z' is definitely contiguous.

I'm not the one that is confused.
*YES*, A..Z are contiguous in ISO Latin 1.
**NO**, those are not the only uppercase letters in ISO Latin 1.

>The quoted code is correct Ada.

It is _legal_ Ada with a well defined effect,
but that effect is _not_ to recognise upper case letters.

>Sure you could have a type EBCDIC which had other
>characteristics, but Standard.Character itself is definitely ISO Latin-1.
>I can't imagine exactly what gave Richard a contrary impression.

Nothing did.  I pointed out that Ada83 had been ASCII only.
When I said that Ada95 was not, I meant (but did not say) that
it handles ISO Latin 1 (Character) and ISO 10646 (Wide_Character).
Indeed, I thought about mentioning that there was an Ada Interpretation
or something of the sort saying that Ada83 compilers could use Latin-1
too.

I'm afraid that Dewar has mistaken some of my points.
There are at least two separable things conveyed by any one example:

	- this is something you can do in Ada

	- this is a general technique to be tried in any language

In this particular example, the problem is
	"recognise all and only upper case letters".
Problem 1:
    The Ada code, while legal, simply fails to work in Ada 95,
    because there are additional upper case letters that were not
    present in Ada 83 (roughly 30 of them).

Problem 2:
    While _Ada_ is defined to use ISO Latin-1, other languages are not.
    That was the relevance of EBCDIC.  If a student learns "the way to
    test for an upper case letter [*] is to test whether it is in the
    range 'A' to 'Z' inclusive", then that student has learned something
    wrong.  If you insert [in ASCII only, or in older Ada 83 systems]
    in place of the [*], it's true, but without that restriction, it's
    false.  First year students aren't aware of the restriction and
    here at any rate learn the wrong lesson.


>I did not read the rest of Richard's "review" in detail, but I should
>say that I have been using this text in my CS2 course at NYU, and I
>have found if very effective (I don't like the upper case keywords, but
>that's hardly a significant criticism!) 

So the strategy is "seize on one poorly expressed and not central point,
and trash that, in the hope that the criticism will go away."  Sigh.

Since this is the _second edition_ of the book, and since it was only
published this year, I do not find the claim "I have been using this
text and found it very effective" particularly impressive, unless of
course the publication date is a fiction and Dewar's students were
able to purchase the book last year.  If that's so, then the testimony
is valuable, *BUT*

 - you have to remember that Robert Dewar himself knows a heck of a lot
   about Ada, has been involved with it for many years, and understands
   the language and how to use it intimately.  

 - such a highly skilled person, at a university with such a good
   reputation, surely attracts strong students

 - the book is not presented as a >>CS2<< text, but as a >>CS1<< text.
   The preface explicitly states
	"we assume no previous programming experience, in any language".

Now, contrast that with the situation here.

  - we have some very experienced CS1 lecturers who like Ada, but they are
    nowhere near as experienced with Ada as Robert Dewar.  In fact, the
    book may well teach them a few things.  (I would say "us", but I'm not
    doing any CS1 teaching this year.)

  - RMIT's quite good, but there are a couple of even better universities
    in Melbourne, so we don't get the best students from Victoria, and we
    also get quite a lot of overseas students with weak English.

  - Robert Dewar reports that the book is very effective as a >>CS2<< text,
    but we need a good >>CS1<< text, and the book is presented as a CS1
    text, and I have criticised it as a CS1 text.

>I particularly think that the
>discussion of generics and abstract data types is well done.

I was at some pains to stress that I thought the choice of topics and
the overall presentation were excellent.

>No doubt one can find minor typos,

We are talking about *lots* of glitches.  Everywhere I looked I found
such problems.  I only studied two chapters in any detail, and didn't
give you even half of the problems I found in those chapters.
EVERYWHERE I LOOKED I found such problems.
We're not talking about "typos", by which I understand the odd typing
mistake, formatting glitch, &c, we're talking about slips that seem to
be caused by incomplete revision.  In fact I used this as an example in
a software engineering class, to point out the usefulness of tools that
can check for consistency within documents that are not executable code.

>but they have not proved a problem for us using the book, and the
>examples on diskette (which are really the only form in which students
>look at the programs closely) are accurate.

What is not a problem for top teachers in a CS *2* class
may well be a serious problem for average teachers in a CS *1* class.

To be honest, I don't know what form the students look at.
What I _can_ say is that the copy I was sent for review contained
*NO* diskette, and the "Program Library" section of the book makes it
quite plain that no diskette is supplied; if you want an electronic
form of the examples, you have to download them over the net or find a
CD-ROM having them.  This one remark really makes me wonder whether
Robert Dewar and I are talking about the same book.
If he simply meant "normal operation of a course based on this book
will entail the instructor obtaining the examples in electronic form
and making them available to the students in some convenient electronic
form, such as a floppy", then ok, but that's a different matter.
How students are to read a diskette (that doesn't come with the book)
on the train or tram escapes me.  (Trams have been known to scramble
floppies.)  Whether it is really true that students don't read paper
any more, I don't know, but in that case why bother to have the code
in the book at all?

I don't see how having correct code available by international FTP
is any reason not to proof-read the printed code, _whoever_ reads it.

Here's another thing I just spotted when the book fell open at a
page that I hadn't seen before.

p646, quick check exercise 2:
    Which is generally more efficient (in terms of running time
    and space), recursion or iteration?

I am really dismayed that two such experienced teachers are still
trashing recursion like this.  (Let's face it, there isn't the least
chance that they are trashing iteration!)  The only right answer is

    Neither is _generally_ more efficient than the other.
    It depends on the problem, the language, the hardware, and the
    compiler.  Two compilers for the same language implemented on
    the same hardware may have vastly different space strategies for
    recursion (e.g. on a SPARC there are compilers which always use
    register windows with consequent huge stack frames, but there
    are also compilers which use a single window, treating the SPARC
    as a 32-register machine, and they use a _lot_ less stack space).
    With a good compiler and a complex problem, the compiler may be
    better at figuring out which variables need to be preserved and
    restored than the programmer, so recursion may use _less_ space
    than iteration.

Remember, Feldman and Koffman think they are talking about Ada,
but CS *ONE* students think they are being taught about programming
in general; they do not know, unless they are told, which statements
apply generally, which are specific to Ada, and which are specific
to the Ada compilers used by the authors.

Another dip into the book at haphazard.  Not a revision glitch this time;
not a poor exercise, but an "US culture rules the world" assumption.
Example 12.7 (figure 12.5).  What the devil are "Freshman", "Sophomore",
"Junior", and "Senior"?  I have enough Greek to figure out that
"Sophomore" means "Wise fool", but what does it mean in the context of
a US university?  We don't use those words here.  (Thanks for the
explanation of the term "upper-class students" on p583; I wouldn't have
stood a chance of figuring that out otherwise.  In fact, in some of the
countries where I've lived, it would have unambiguously referred to
_social_ class.)


Let me repeat my major points:
 - this book is written by some *very* good people
 - the topics and presentation are *excellent*
 - but the book is marred by consistently sloppy proofreading.
 - to the point where I believe the authors and publisher ought
   to provide a list of errata *pronto*
 - and the authors assume their students have a US cultural background
   when less culture-bound examples would have served equally well.
    

Is there anyone besides Robert Dewar who has seen the book
and would honestly disagree with those points?
-- 
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.