Book REview

Book REview

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

Re: Book REview

[Robert Dewar]

Richard O'Keefe said about Mike Feldman's book:

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

This is very confused on Richard's part. The Type Character is always
Latin-1, in which 'A'..'Z' is definitely contiguous. The quoted code
is correct Ada. 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.

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!) I particularly think that the
discussion of generics and abstract data types is well done.

No doubt one can find minor typos, but they have not proved a problem
for us using the book, and the examples on diskette (whcih are really
the only form in which students look at the programs closely) are
accurate.

Re: Book REview

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

Re: Book REview

[Michael Feldman]

In article <4mmfsu$b30@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>
>Is there anyone besides Robert Dewar who has seen the book
>and would honestly disagree with those points?

Well, I've seen the book (I wrote it) and certainly there is much
homework for me to do regarding the substance of your messages.
Many of your complaints are valid; some are a matter of taste.

There is some validity to your complaint about a US bias in the
text; it is odd, though, that the first edition of this book was
published nearly 5 years ago, and has been used by courses and
individuals around the world (including Australia), but nobody has 
mentioned the US bias.

That said, 

(1) I think the tone of your review is a bit harsh;

(2) I don't think I'd ever write a review as critical as yours without
    at least sending a cc to the author; that would just be courteous. 

I don't read CLA every day (the signal/noise ratio is getting too low
and I've been very busy), and so I was caught quite by surprise when
a CLA acquaintance pointed me to your review. You are, of course,    
entitled to your opinion, and I am thick-skinned enough to handle
a bad review. On the other hand, there's no need to blindside the
author by not even sending him a copy to respond to. Generally you're
a polite CLA reader/writer; I'm quite surprised at your discourtesy.

Indeed, had you been courteous enough to ask me for an errata list,
I would have been happy to send it to you. Not all your reports are
there (yet), but many are.

'Nuff said.

Mike Feldman

Re: Book REview

[Richard A. O'Keefe]

mfeldman@seas.gwu.edu (Michael Feldman) writes:

>There is some validity to your complaint about a US bias in the
>text; it is odd, though, that the first edition of this book was
>published nearly 5 years ago, and has been used by courses and
>individuals around the world (including Australia), but nobody has 
>mentioned the US bias.

In Australia there is something called "The cultural cringe".
There is a widespread attitude that if things are different overseas
they must be better, so it's our fault.

>That said, 

>(1) I think the tone of your review is a bit harsh;

On the same day I received four books for review.
One was "The Little Schemer".  I haven't looked very far into that one
yet.  "The Little Lisper" was a *great* book except for its "all the
world is America and there are no Jews or Muslims" attitude.
That's an MIT Press example.

The other three all came from Addison-Wesley.
Two of them were C textbooks by the same pair of authors.
They had some good topics, and good or very good presentation, but 
in one 25-line example I found 8 outright errors, and a large chunk
of one chapter is devoted to explaining a technique which has never
been legal in ANSI C, and is likely to cause trouble in segmented
architectures.  I am talking _really_ bad.  Frankly, I was outraged.

So, I turned to your book.  Imagine a poet turning from looking at
a disgusting monster, to look in relief at a beautiful woman, and
then he sees lice wandering over her face.

I was angry:
 * for myself: it was such a disappointment
 * for our students: this _could_ have been such a big help to them
 * for you: there are no really fundamental problems that I can see
            with the book, the proof-reading and formal review process
            let you down.

This may not _excuse_ the tone of the posting, but perhaps it _explains_ it.

Let me publicly apologise for the tone.



>(2) I don't think I'd ever write a review as critical as yours without
>    at least sending a cc to the author; that would just be courteous. 

>I don't read CLA every day (the signal/noise ratio is getting too low
>and I've been very busy), and so I was caught quite by surprise when
>a CLA acquaintance pointed me to your review.

I see that I must apologise again.  I had thought of you as a regular
CLA reader, so I was (without, it turns out, adequate reason) quite
sure that you would see it.  It was certainly my _intent_ that you would
see it.

>You are, of course, entitled to your opinion, and I am thick-skinned
>enough to handle a bad review.

The thing that still has me angry is that at one level it _isn't_ (or
isn't meant as) a bad review of the "World 3" book.  It's really an
angry review of the _proofreading_ and _review_ processes.  How come
such a well planned book by such great authors ended up with a flawed
result?  (By the way, talk to Addison-Wesley about the binding.  I
have had my copy for less than a week; I have handled it gently; but
the back cover now resembles a capital C.)

I am upset because I want to use the book you wanted to publish.

>On the other hand, there's no need to blindside the
>author by not even sending him a copy to respond to.

As I have explained, I did not mean to blindside you.
(I don't actually know what that means, but I think it means something
like "do something behind your back".)
I thought of posting to CLA as, amongst other things, an efficient way
to get you a copy.

I apologise again for being stupid about that.

>Indeed, had you been courteous enough to ask me for an errata list,
>I would have been happy to send it to you.

To be honest, it appears I have been stupid again.
It never occurred to me that a newly published book would _have_ an
errata list, or that Addison-Wesley would have withheld it from a
reviewer if it had.

In my own defence, I can only say that I *did* visit
	http://www.aw,com/cseng/authors/feldman/cs1-ada2e/cs1-ada2e.sup.html
and found the only supplements to be the source files in .tar.Z format for
UNIX and .zip format for Dos,Windows,OS/2.  There was no hint of the present
or likely future existence of an errata sheet there, so I supposed there
was none.

I failed to download the sources "Transaction timeout".
I've had a lot of trouble trying to download such sources from aw.com.

>'Nuff said.

Let me drag this out by pointing out one more example.

I mentioned the "in Character range 'A' .. 'Z'" method of testing whether
something is an upper case letter, and pointed out the flaw.  I was
considerably startled when the book fell open at page 466 just now, and
I saw "FOR c IN UpperCase LOOP".  Honest, the book did fall open at that
page without any prompting.  I then discovered that the example I quoted
before wasn't an isolated slip.

	p463

	Problem Specification
	---------------------
	Write a program which draws a histogram for the frequency
	of occurrence of the letters of the alphabet.   Uppercase
	and lowercase letters are to be counted separately;
	nonletter characters can be ignored.

	p785

	PACKAGE Ada.Characters.Handling IS
	...
	  FUNCTION Is_Lower (Item: IN Character) RETURN Boolean;
	  FUNCTION Is_Upper (Item: IN Character) RETURN Boolean;

This seems like the perfect opportunity to point out that "the alphabet"
in Ada 95 is ISO Latin 1 and that it contains a lot of letters and that
there are some standard functions for handling them, and that a good way
to handle this problem is

	type Character_Count_Table is array (Character) of Natural;

	Uppers: Character_Count_Table := (others => 0);
	Lowers: Character_Count_Table := (others => 0);
	Ch    : Character;

	...

	while not Ada.Text_IO.End_Of_File loop
	    while not Ada.Text_IO.End_Of_Line loop
		Ada.Text_IO.Get(Ch);
		if Ada.Characters.Handling.Is_Upper(Ch) then
		    Uppers(Ch) := Uppers(Ch) + 1;
		end if;
		if Ada.Characters.Handling.Is_Lower(Ch) then
		    Lowers(Ch) := Lowers(Ch) + 1;
		end if;
	    end loop;
	    Ada.Text_IO.Skip_Line;
	end loop;	    

	...

	for C in Character loop
	    if Ada.Characters.Handling.Is_Lower(C) then
		Draw_Bar(Lowers(C));
	    end if;
	end loop;
	Draw_Bar(0);
	for C in Character loop
	    if Ada.Characters.Handling.Is_Upper(C) then
		Draw_Bar(Uppers(C));
	    end	if;
	end for;
	...
	for C in Character loop
	    if Ada.Characters.Handling.Is_Lower(C) then
		Ada.Text_IO.Put(C);
	    end if;
	end loop;
	Ada.Text_IO.Put(' ');
	for C in Character loop
	    if Ada.Characters.Handling.Is_Upper(C) then
		Ada.Text_IO.Put(C);
	    end	if;
	end for;
	...

Instead, the text goes out of its way to hammer home the unintended lesson
that the 52 unaccented letters are the only letters in Ada and that all
the upper case letters are contiguous and all the lower case letters are
contiguous.

    - Uppers and Lowers in the book have non-overlapping index ranges,
      which won't work in Ada 95 if you try to handle _all_ letters.
    - the input loop in the book uses a CASE statement, and while an
      IF statement could have been adapted to Ada 95 letters, the CASE
      statement cannot.
    - the letters at the bottom of the display are in a string literal
      instead of being computed as above.	
	
Taken literally, in the context of Ada 95, the program of Figure 9.4
does not meet its specification.

Do we call this a cultural matter (there are only 52 letters in the world)
or a technical matter (there are only 52 letters in Ada)?  Well, my father's
name and my sister-in-law's name cannot be represented in ASCII, and they
are both of British descent, and their names are genuine (not made up) names.
Perhaps it is a cultural matter.  On the other hand, in Ada 95 there are
114 letters, not 52, so perhaps it is a technical matter.  Certainly, there
are coding techniques that used to work in ASCII that no longer work, and
one of the good things about Ada 95 is that it gives us the tools to do the
job properly.


Now, for this example, the histogram will only work if you have 120
columns on your screen, because 114 columns + a bit is more than will
fit on an 80-column screen.  Is it a good idea to restrict attention to
the American letters so that the display will fit on the screen?  Or is
that another easy hack that breaks when you try to handle the full
Ada 95 character set?  I honestly don't know, and I'm glad it wasn't my
decision.  (Actually, my decision would have been to map upper case letters
to lower case.  I can now see that that would have been the wrong decision,
because it merely delays the problem; my kluge won't adapt to Wide_Character.)

Am I being paranoid about a minor point?

Well, I have two 2nd-year C tutorials on Thursdays.
I asked them

	"What can you tell me about this method of
	 checking for an upper case letter in C?

		if ('A' <= x && x <= 'Z') ..."

The only suggestion I got was "it needs more parentheses" (which of course
it doesn't).  I explained that the system they are using (a SPARC running
Solaris, with X11) is configured to use an 8-bit character set, which has
a lot more capital letters than 26, and that the PC systems some of them
use at home has a _different_ 8-bit character set, which also has more
upper case letters than 26.  Next I asked

	"Can you suggest a way to test for _any_ upper case letter?"

Some of them had K&R2 with them.  It took some _very_ heavy hinting to
get them to look in the index.  Finally they understood that

		#include <ctype.h>
		...
		    if (isupper(x)) ...

would do the job.  Next question:

	"Will you use this?"

The answer:  "The book doesn't; why should we?"  (The book not= K&R2)

The lesson for Ada text-book authors?  "The book doesn't; why should we?"

I checked the index of the Ada95 book.  I could not find "letter",
"Is_Upper", "Is_Lower", "case, alphabetic", "lower case" in the index,
and the sole reference to "upper" was "uppercase and lower case, use of".

Is it reasonable to tell the whole truth in a CS 1 textbook?
No, it is not reasonable; it is not possible.

Is it reasonable to omit any mention of the fact that the character set
used by the language includes more letters than the American 26?
Well, a _lot_ of CS1 books include a chart of the ASCII characters,
and a chart listing all of the members of Character in Ada 95 would
require only a one page appendix.  In fact there _is_ an appendix
"The Ada Character Set..." which says "a number of additional characters
to provide for the additional letters used in non-English languages" but
doesn't say what they _are_.

A very small change to the book would eliminate most of my objections
about letters and ranges thereof.
(1) Change the third sentence in appendix A to say
	"This character set includes the usual upper case (A-Z) and
	 lower case (a-z) letters.  It also includes many other letters
	 useful in some European languages, including English.  For
	 example ....
	 Ada 95 identifiers should not use any of these extra letters.
	 The examples in this book just use the letters found on
	 US keyboards; if you want to use the other letters, you will
	 have to find out locally how to get them on your computer or
	 keyboard, AND YOU WILL HAVE TO CHANGE THE PROGRAMS."

(2) Somewhere about here in appendix A, say
	"Ada 95 programs can tell what kind of character they have been
	 given by using the functions in Ada.Characters.Handling whose
	 names begin with 'Is_'; see appendix G."

(3) At the end or appendix A, add a chart with all the ISO Latin 1
    characters.  I've seen it printed legibly on half a page.

(4) Whenever the current text says or implies that A-Z a-z are the
    only letters, add a footnote
	"* Strictly speaking, there are 114 letters. See Appendix A."
    or something of the kind.

(5) Put "letter", "letter, upper case", "letter, lower case" in the
    index, pointing to appendix A _and_ to all the examples in the
    main text that talk about letters.

While I was looking for "letter" in the index, I found 

	CASE STUDY: FINDING THE ALPHABETICALLY FIRST LETTER

on p141.  Now, the book is elsewhere quite clear that only the 52
character A-Z, a-z count as letters.  I am rather sensitive to this
issue because last year when I tutored the CS 1 class, an assignment
required students to read "letters", and there was massive confusion.
It turned out that, as here, the author meant by "letter" "any
character whatsoever, whether it is a letter or not".

The Ada code in program 4.2
 - reads arbitrary characters, not letters.
 - does not check that they are letters.
 - does not compare the characters "alphabetically", but according
   to their codes in ISO Latin 1.  This matters, because
	'a' < 'F'
   _alphabetically_, because A precedes F in the (English) alphabet
   -- there is historic precedent for considering & to be part of the
   English alphabetic, for what it's worth --
   but it's 'tother way around in ISO Latin 1.

   The alphabetically first _letter_ amongst "Ma!" is "a".
   The program will report '!'.
   The alphabetically first letter amongst "Max" is "a".
   The program will report 'M'.
   Surely a does come before m in the alphabet?

Rename the case study to
	Finding the character with the smallest code
replace "letter" by "character", "alphabet" by "character set",
and the objection vanishes because the confusion vanishes.

I am _not_ going to quarrel with the decision to use two IF statements
instead of just

	AlphaFirst := Character'Max(Character'Max(Ch1, Ch2), Ch3);

because it's a perfectly good educational decision to postpone details
like <scalar_type>'Max to CS2.

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

Re: Book REview

[Michael Feldman]

In article <dewar.831408874@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>
>This is very confused on Richard's part. The Type Character is always
>Latin-1, in which 'A'..'Z' is definitely contiguous. The quoted code
>is correct Ada. 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.

Thanks for this correction, Robert.
>
>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!) I particularly think that the
>discussion of generics and abstract data types is well done.

This is a nice plug, but for a different book. Richard is referring
to Feldman/Koffman, "Ada 95 Problem Solving and Program Design", the
CS1-level book that appeared in February. It is this book that will
be bundled with the forthcoming Intermetrics/Thomson "Academic
AdaMagic" compiler on CDROM. I believe the CD is due in August.

The book you're using in your class is my CS2 book, Feldman, "Software 
Construction and Data Structures in Ada 95", which is at the printer's 
and will be in stock at the beginning of next month (June).
>
>No doubt one can find minor typos, but they have not proved a problem
>for us using the book, and the examples on diskette (whcih are really
>the only form in which students look at the programs closely) are
>accurate.

The same is true of the CS1 programs. One minor correction: Addison
Wesley has gotten out of the diskette business and instead has set
up a web/ftp site for code distribution. I'm not so sure I like this
abandonment of the diskette, but it's a sign of the times.

One more plug, this time for my list of Ada 95 texts (mine and all
the others) at http://www.seas.gwu.edu/faculty/mfeldman/ada95books.html
and all the various www mirrors. There's a nice selection of books, 
with reviews written by a number of reviewers. Also there are pointers
to the web sites for the individual books, where these exist.

Enough hype for now.:-)

Cheers -

Mike Feldman

Re: Book REview

[Michael Feldman]

In article <4mk0vc$opp@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:

[snip]

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

That was the intention; glad it succeeded in that regard.

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

Well, from the list below [snipped to save bandwidth], you've caught
a helluva lot of typos and a few "cultural errors" that seem to imposed
an American bias on some of the discussion.

These typos, and other reported ones, will be fixed at reprint time.
Whether the "cultural bias" stuff can be repaired remains to be seen.
It is true that this stuff escaped both the reviewers (all profs like
yourself) and the proofreaders. I am creating an errata sheet and
will put it online in a short while.

I take full credit for the errors as well as the good stuff. I've gotten
into the habit of paying students $1.00 for the first report of each 
error. Be sure that I will scour your list carefully; where do I send
the check?:-)

[snip]

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

US bias. Grade Point Average.:-)
>
>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.

[details snipped]

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

I agree with you on this one.
>
>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."

When do you need that errata booklet?

[details snipped]

Don't blame Koffman - I take full credit and blame.:-)

Mike Feldman

Re: Book REview

[Richard A. O'Keefe]

mfeldman@seas.gwu.edu (Michael Feldman) writes:
in reply to my review of new Feldman/Koffman book.

Thank God you took it so well.  After Robert Dewar's posting,
I was thinking "oh no, have I made a faux pas? have I offended
all the people I admire in comp.lang.ada?".  WHEW!

>Well, from the list below [snipped to save bandwidth], you've caught
>a helluva lot of typos and a few "cultural errors" that seem to imposed
>an American bias on some of the discussion.

>These typos, and other reported ones, will be fixed at reprint time.

Great!  I had a face-to-face discussion recently with someone about C
textbooks (see my posting "Textbooks!" in comp.lang.c.moderated for
the context) and their comment was "Even K&R make mistakes, but they
_admit_ them and _fix_ them." and that is all one can reasonably expect.

>Whether the "cultural bias" stuff can be repaired remains to be seen.

If you think I'm picky about that, try a Frenchman!

>It is true that this stuff escaped both the reviewers (all profs like
>yourself) and the proofreaders.

As I think I may have mentioned, I am teaching a software engineering
subject, as well as some computer science subjects.  So these days I find
myself thinking,
    what is there about the (book production) PROCESS
    which
	- caused these defects
	- let them through into the product.

Cultural bias.

    A teacher, located in a particular culture, teaching students
    who are immersed in that culture, will naturally try to pick
    examples that involve concepts his students already understand.
    [I was once trying to explain Montague Grammar to a class, and
    said "slash categories are just like the types in typed lambda
    calculus", only to find that they didn't even know what the
    untyped lambda calculus was.  A _good_ teacher doesn't do that!]

    I _suspect_ that the problem is that when course materials that
    have worked well in such a context are turned into a book that
    is to be sold in an international market, "internationalisation"
    is given a low priority compared with topics, presentation, and
    accuracy.

    Perhaps it should be.  However, an Addison-Wesley book I recently
    was sent listed 11 publisher's people by role and name at the top
    of the first page, from "Aquisitions Editor" to "Cover Illustration".
    It is the _publisher_ that has the experience with international
    markets; perhaps amongst all these people, room could be found for
    an "Internationalisation Proofreader".

    Topics to watch out for include
	- references to currency
	- references to political figures (who are Kennet and Brumby?)
	- references to political institutions (what is the ATSIC?)
	- references to the educational system (which is the honours year?)
	- presentation of dates and times (why not follow ISO 8601?)
	- traffic directions and signs (there is an international standard
	  for traffic signs, I believe; some countries still haven't switched)
	  (I never knew why US people talked about "yellow"; our traffic
	  lights are red, ORANGE, and green, plus red and white T signs for
	  the trams)
	- references to local history (what was the Eureka stockade?)
	- references to national sports (what is AFL? how does it differ
	  from VFL? who are the Bombers? how do you play two-up?)
	- it is fair to use national spelling and punctuation in the running
	  text, but examples should not depend on things that differ.
	  (E.g. US punctuation alternates ` ' with `` '', while UK
	  punctuation alternates `` '' with ` '.  No text processing example
	  should rely on either.)
    and there are many others, such as use of colour, iconic symbols, and
    so on.  

    I do not think it is fair to expect every author to be aware of all the
    internationalisation issues.  I have left out some that I do know about,
    and there must be many more that I don't.  I _do_ think that it is fair
    to expect an international publisher selling educational textbooks into
    an international market to have a "Guide for Authors" that mentions
    such issues, and for their proofreaders and copy editors to keep an eye
    out for them.

    Could you perhaps find out whether Addison-Wesley would be interested
    in having something about this in their Guide for Authors?  I would be
    interested in contributing to it.

Incomplete revision

    The book is a large book, (page numbers run up to 814), worked on by
    two authors, who were presumably under pressure to get it out in
    time for the second half of the current academic year.  (See previous
    section...)

    Even Homer nods.  These things happen.  But...

    Is there no hope of having automatic tools to catch some of them?
    Take the Simple_Dates -vs- SimpleDates -vs- Dates issue.
    Simply checking each identifier that appears in the text against
    the index would have caught at least one of these:  Dates and
    Simple_Dates appear in the index, but SimpleDates doesn't.
    It should be possible to automatic this check.

    I would go further.  I would have liked to see packages, procedures,
    and concepts in _separate_ indices, rather like Common Lisp, the
    Language, 2nd edition.

    It should be possible to devise "semantic markup" conventions and
    tools to catch many errors of this type.  For example, if this
    book were in SGML, it would be possible using our SIM system to
    pose queries that take into account the structure of the text,
    "List the names of packages defined in chapter 8"
    "Find all package names used in a chunk preceding the chunk where
    they are defined."
    And so on.

    Even then, the bottom line is the proof reading done by the authors
    and by the publishers.  Now, it took me about 3 hours per chapter,
    and I didn't quite finish chapter 8.  Chapter 14 was 42 pages, so
    that's about 14 pages per hour.  Call it 15.  810/15 = (30*27)/(30*0.5)
    = 54 hours to proof-read the lot, round it up and say 60 hours.
    That's a lot of time, and clearly the authors cannot fully proof-read
    the book after each change.  The retail price isn't quite legible on
    the forms I was sent, but it seems to be around AUD 50.  My time is
    worth (according to the prices the department is actually paid when
    I do consulting) AUD 100 per hour and up.  So the price for a good
    proof-reader to check the book with reasonable care is around the
    AUD 6000 mark, which corresponds to the retail price of 120 copies.
    We have more than that many students in our CS1 class, in fact
    roughly twice that many, and they _won't_ be buying that book until
    the reprint because it _wasn't_ proofread to this level.

    Let's be frank about this:  I _mind_ about the cultural issues, but
    we wouldn't let that stop us buying the book.  The problem is that
    having found a certain number of errors, we don't _know_ whether the
    other errors are serious or not without spending AUD 6000 worth of
    my time.

    This is a book that, if thoroughly proof-read, deserves to sell
    a great many copies.  I think Addison-Wesley should have spent the
    money on first-rate proof-reading.  (Which, by the way, means
    proof-reading by someone reasonably knowledgeable about Ada.  Or,
    if the book is about C, HPF Fortran, or Visual Basic, about C,
    HPF Fortran, or Visual Basic.)  They would have made it back in
    sales at a single site.

Another issue that I didn't really address before.

    CS 1 students, by definition, do not have a wide computing background.
    They do not know what is true of computers in general.
    They only know what they were told in secondary education (*sigh*; I
    wish the high schools would either *stop* teaching computing or
    start doing it right; what I really really long for is students who can
    spell and add; we can teach them the rest) and what they are told in
    their CS1 class.  We should not teach them as universal truths things
    that are truths about a specific language.  This doesn't mean going
    into a lot of detail.  It just means that instead of "You can't do X"
    or "A computer can't do X" one says "You can't express X directly _in
    Ada_."

    If they are told that arrays cannot grow because that is in the nature
    of arrays, they don't know that it isn't true in Burroughs Algol,
    Algol 68, Common Lisp (array-push-extend), Dijkstra's notation (which
    I implemented in Pop; it's _easy_), or a raft of other languages.

    If they are told that records cannot be added because the computer
    can't do it, they don't know that COBOL programmers have been doing
    it for years.

    If they are told that a computer can only operate on single numbers,
    they don't know about complex numbers in Fortran, Pascal, Algol 68,
    or C++, nor does the book mention Ada.Numerics.Complex_Types (which
    it shouldn't, but the message _is_ false about Ada).

    If they are told that "memory cell" = smallest addressible unit = byte
    (yes, yes, I know we're told a memory cell is a _group_ of bytes, but
    the same page tells us that 1 megabyte = 1 million cells) and that
    "a memory cell can contain a program instruction", they probably don't
    know that a SPARC instruction _can't_ fit in a "memory cell" so defined.

    If they are told (on p95) that
	Pi: constant Float := 3.14159;
    many students these days have a sufficiently weak grasp of mathematics
    to believe that Pi = 3.14159.  I wish I were joking.  If Robert Dewar
    is right and students only look at the diskette copies of things, they
    will never notice the definition of p782.  What a pity they weren't
    advised to do

	Pi: constant Float := Ada.Numerics.Pi;

    After all, Float _could_ be more than 32 bits...

>I am creating an errata sheet and will put it online in a short while.

This is excellent news.  Could you please set it up as a form so that
people can easily contribute new problem reports?

>I take full credit for the errors as well as the good stuff. I've gotten
>into the habit of paying students $1.00 for the first report of each 
>error. Be sure that I will scour your list carefully; where do I send
>the check?:-)

I prefer Knuth's offer of $2.56 (:-).
If my comments prove of any use, just tell Addison-Wesley they
want me to review more of their books _before_ they fill the warehouses.

>>Another cultural matter:  what the heck is a GPA?

>US bias. Grade Point Average.:-)

I'm sorry, but that isn't an explanation.  I _have_ received an explanation,
and what a curiosity the thing is.  How come the Statistics department in
every US university hasn't threatened to walk out in a body until something
a little less quirky is adopted?  The explanation belongs in the book.

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

>When do you need that errata booklet?

Academic years and civil years coincide in Australia and New Zealand.
We'll be making our decisions about CS1 textbooks in about 4--6 months.

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

Re: Book REview

[Dave Jones]

Richard A. O'Keefe wrote:
> 
> 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
><cut> 
> 
> 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.<cut -- lots of complaints about American stuff>

Personally, I think that it is wise to make a textbook culturally specific.  The 
use of culturally specific examples helps to hold student attention and makes for 
a superior textbook.  Perhaps, Mr. O'Keefe should contact Addison-Wesley about 
creating an Australian edition.  For that matter, I would think that the 
Australians are perfectly capable of writing their own textbook.

Mr. O'Keefe also needs to realize the economics of the situation.  Australia has 
a tiny population (about 18 million) and a trivial GDP (about US$340 billion).  
It would be very very unwise for Addison-Wesley to risk a position in the US 
market in order to increase their position in the Australian market.  I would not 
expect there to be any changes in the book until people in larger countries start 
complaining.  

-- Dave Jones
davedave@io.com

Re: Book REview

[sxc]

In article <3190CEC1.5799@io.com>, Dave Jones  <davedave@io.com> wrote:
>Personally, I think that it is wise to make a textbook culturally specific.  
>The use of culturally specific examples helps to hold student attention and 
>makes for a superior textbook.  

That is a matter of opinion ... 

Outside of the USA, I'd expect culturally non-specific examples to be
marginally more interesting to CS1 students ... and substantially less
grating!  

If I had been an American undergraduate, I might be irritated by the
suggestion that my attention span was so short that I needed to be
pandered to with culturally specific examples.  As an Australian
undergraduate, I certainly would have been!

>Perhaps, Mr. O'Keefe should contact 
>Addison-Wesley about creating an Australian edition.  For that matter, I 
>would think that the Australians are perfectly capable of writing their 
>own textbook.

Richard is not stupid.  He knows that it would be a waste of time.
And you should realise this too ... given your next paragraph.

>Mr. O'Keefe also needs to realize the economics of the situation.  Australia 
>has a tiny population (about 18 million) and a trivial GDP (about US$340 
>billion).

Gee thanks ... it's >>so<< nice to have a non-Australian imply that my 
country is trivial!
 
>It would be very very unwise for Addison-Wesley to risk a position in the US 
>market in order to increase their position in the Australian market.  I 
>would not expect there to be any changes in the book until people in larger 
>countries start complaining.

While the market for Australianised Ada books is obviously tiny, the
market for Internationalised Ada books is huge.  Australia, Canada,
India, New Zealand, South Africa, UK, much of continental Europe,
South East Asia, Africa, etc.

BTW: I think Richard should keep quiet about teaching Australian
students to write internationalised software.  How is the Australian
software industry going to maintain it's edge if we broadcast our
trade secrets?

:-) :-)

-- Steve

Re: Book REview

[dave]

sxc@itd.dsto.gov.au wrote:
> 
> In article <3190CEC1.5799@io.com>, Dave Jones  <davedave@io.com> wrote:
> >Personally, I think that it is wise to make a textbook culturally specific.
> >The use of culturally specific examples helps to hold student attention and
> >makes for a superior textbook.
> 
> That is a matter of opinion ...
> 
> Outside of the USA, I'd expect culturally non-specific examples to be
> marginally more interesting to CS1 students ... and substantially less
> grating!
> 
> If I had been an American undergraduate, I might be irritated by the
> suggestion that my attention span was so short that I needed to be
> pandered to with culturally specific examples.  As an Australian
> undergraduate, I certainly would have been!

I suspect that your Australian students are a little bit more disciplined than
our American students.  Sadly, the short attention span of the typical
American student is something that teachers here must deal with.  I am very
pleased to say that I no longer teach at the college level.  

> 
> >Perhaps, Mr. O'Keefe should contact
> >Addison-Wesley about creating an Australian edition.  For that matter, I
> >would think that the Australians are perfectly capable of writing their
> >own textbook.
> 
> Richard is not stupid.  He knows that it would be a waste of time.
> And you should realise this too ... given your next paragraph.

Actually, it probably would not be a waste of time:  A-W would not risk any
sales in the American market by creating a special "Australian edition" --
or a special "International edition".  Also, I have seen several good 
programming textbooks come out of Australia, so I would certainly encourage 
any Australians who want to write an introduction to Ada book.  (Incidentally, 
any "Australianisms" in the book would probably help to hold the students' 
attentions here in the U.S..  For some reason, we Americans are fascinated 
by Australia.).

> 
> >Mr. O'Keefe also needs to realize the economics of the situation.  Australia
> >has a tiny population (about 18 million) and a trivial GDP (about US$340
> >billion).
> 
> Gee thanks ... it's >>so<< nice to have a non-Australian imply that my
> country is trivial!

If it makes you feel better:  I think that Australia's GDP per capita is higher
than ours.

> 
> >It would be very very unwise for Addison-Wesley to risk a position in the US
> >market in order to increase their position in the Australian market.  I
> >would not expect there to be any changes in the book until people in larger
> >countries start complaining.
> 
> While the market for Australianised Ada books is obviously tiny, the
> market for Internationalised Ada books is huge.  Australia, Canada,
> India, New Zealand, South Africa, UK, much of continental Europe,
> South East Asia, Africa, etc.

Agreed, but like Feldman said in one of his posts, the first edition
has been out for several years, and no-one has complained until now.  It would
seem that his Americanisms do not bother most people.  

Nevertheless, I do partially agree with you and Richard:  Either Addison-Wesley 
should publish special non-American editions or Feldman should add some
footnotes for the international editions explaining the Americanisms.  However, 
I do *not* think that he should alter the editions being sold in the U.S. (except,
of course, the errors should be corrected).
  
-- Dave Jones
davedave@io.com

Re: Book REview

[dave]

I hate to reply to my own post, but I just realized that there is an
ambiguous sentence in it.

dave@gte.net wrote:
> 
> 
> >
> > >Perhaps, Mr. O'Keefe should contact
> > >Addison-Wesley about creating an Australian edition.  For that matter, I
> > >would think that the Australians are perfectly capable of writing their
> > >own textbook.
> >
> > Richard is not stupid.  He knows that it would be a waste of time.
> > And you should realise this too ... given your next paragraph.
> 
> Actually, it probably would not be a waste of time:  A-W would not risk any
> sales in the American market by creating a special "Australian edition" --
> or a special "International edition".  

That last sentence will be less ambiguous if it is rewritten as follows:
A-W would not be risking any sales in the American market if they created
a special "Australian edition" -- or a special "International edition".

> Also, I have seen several good
> programming textbooks come out of Australia, so I would certainly encourage
> any Australians who want to write an introduction to Ada book.  (Incidentally,
> any "Australianisms" in the book would probably help to hold the students'
> attentions here in the U.S..  For some reason, we Americans are fascinated
> by Australia.).
> 

> -- Dave Jones
> davedave@io.com

Re: Book REview

[Richard A. O'Keefe]

dave@gte.net writes:

>> Actually, it probably would not be a waste of time:  A-W would not risk any
>> sales in the American market by creating a special "Australian edition" --
>> or a special "International edition".  

>That last sentence will be less ambiguous if it is rewritten as follows:
>A-W would not be risking any sales in the American market if they created
>a special "Australian edition" -- or a special "International edition".

There can be no question of an "Australian" edition,
because such a thing would be no use.
An edition full of Australianisms would cause offence in the UK and NZ.

The issue is "US" -vs- "English-speaking other than US" editions.

Splitting the market _has_ to mean higher prices for _both_ editions,
which has to mean fewer sales or less profits in the US.

And the whole basis for such a split is the unsupported belief that
the accidental Americanisms in the book offer some advantage to US students.


Let me give an example from another book.
This one's "The Little Schemer".  on p13 we find

	=> Now go make yourself a peanut butter and jelly sandwich. <=

		+-------------------------------+
		|				|
		|   This space reserved for	|
		|				|
		|   JELLY STAINS!		|
		|				|
		+-------------------------------+

What's to cavil at here?
(a) There's something that seems to be a peculiarity of American English,
    the serial verb "go make" instead of the conjunctive "go AND make".
    I suppose that can't be helped.

(b) Peanut butter and jelly is an American cultural item.
    Much of the rest of the world finds the idea disgusting.
    (Rightly or wrongly.)

(c) The commonest food allergy in this country is to peanuts, followed
    by milk.  If my wife had a peanut butter and jelly sandwich, it
    would probably kill her.  A _lot_ of people are allergic to peanuts.

(d) The biggest words on the page (jelly stains) are an unjustified
    insult to the readers.

(e) Many non-US readers find this kind of thing, even were the food item
    familiar and innocuous, nauseatingly patronising.  Not all, of the
    book wouldn't have any non-US sales, but enough to matter.

On p147 we find

	----------------------------------------------------
	Whew! Is your brain twisted up now?
		Go eat a pretzel; don't forget the mustard.
	----------------------------------------------------
What's here?
(a) Another insult:  the reader is in effect told "you are too stupid
    to understand this without strain."

(b) Another American food item.  The things I know as pretzels are
    never eaten with mustard.

(c) I can't stand the smell of mustard, and actually eating more than
    a tiny amount makes me vomit.  Surely I cannot be alone in this.

(d) Still nauseatingly patronising.


Do a patronising tone, gratuitous insults, and instructions to prepare
and eat an assortment of American cultural items really help students
to learn Scheme?  Do they help _all_ students in America?  Would a
book with a less patronising tone, fewer insults, and references to
something more neutral really do worse with _any_ students?

Actually, it strikes me that "The Little Schemer" is a small enough
book that it might be feasible to conduct a serious educational
experiment by preparing a couple of alternative versions and trying
them out.

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

Re: Book REview

[Richard A. O'Keefe]

dave@gte.net writes:
>Agreed, but like Feldman said in one of his posts, the first edition
>has been out for several years, and no-one has complained until now.  It would
>seem that his Americanisms do not bother most people.  

Take 500 lines:
	Absence of evidence is not evidence of absence.

(a) How do you know that "no-one has complained until now"?
    For all you or I know to the contrary, _every_ Asian student might
    have complained to his or her lecturer.  All you know is that no-one
    has told _you_ about any complaints.

(b) Nobody *at RMIT* has complained up till now because nobody here has
    used the first edition of the book, or Koffman's Turbo Pascal book
    from which it derives.  Some people don't complain, they just refrain
    from buying the book.

(c) With all of my complaints about Feldman's book, it is head and shoulders
    above *every* C textbook I have seen, and I've seen a lot of them.
    That I spent time raving on about Americanisms instead of gross errors
    in the code and radical misunderstandings about Ada is *good*; in NONE
    of the roughly a score of C textbooks I have looked at did I ever get as
    far as complaining about the index or about cultural bias!

    If lecturers have been using Feldman's books, and not passing on
    such student complaints about cultural bias as they may perhaps have
    had, it could just be an overwhelming relief at being able to use a
    book written by somebody who actually knows what he is talking about
    and can get his basic facts straight that makes them feel it would be
    ungrateful to pass the complaints on.

    Let me quote the October 1992 issue of Scientific American,
    quoting William J. Bennetta, editor of "The Textbook Letter":

	with the exception of some books for advanced placement
	courses, most [US school] textbooks are "wretched junk"
	written by "clowns who know nothing about the subject matter".

    In my view, this opinion could be applied with equal force to most
    of the programming language textbooks I've seen.  (The record is
    held by a small Prolog textbook I once saw in a university bookshop,
    which had an example on nearly every page, and EVERY SINGLE one was
    syntactically illegal.)  For some reason, Ada books seem to be the
    pick of the bunch.

(d) The US has a "culture of dissent"; shared by New Zealand, Australia,
    Canada, and the UK, and some European countries.  In the educational
    context, it seems to be strongest in the US.  The students who are
    worst affected by cultural bias are the very same students raised
    in "cultures of conformity" where it would be *extremely* rude for
    a student to question a teacher or a textbook.  The more affected a
    student is by the issue, the *less* likely he or she is to raise it.

    For example, it is not without signifance that I belong to a church
    which refuses to have an official creed (so I share the "culture of
    dissent") and once memorised the words to "Deck the Halls with
    Boston Charlie" and was planning to use "Rackey Coon Chile" as the
    nickname of my new daughter if she had been a son (so I am pretty
    much Americanised) and had a _great_ time working in California.

    (1) I know which things in the book are "American" and which are
	"Western".  My students don't.  One reason why overseas students
	in Australia might not care to complain is that they don't know
	which things are "host country" matters they would look stupid
	for not knowing, and which things are "foreign" to the host
	country.

    (2) The points which I identified as puzzling are points which
	puzzle someone *friendly towards* US culture and exposed to it
	from childhood up.  If E. D. Hirsch is right, I probably
	understand more of the entries in "Cultural Literacy" than most
	US high school students.  This means that what I have found
	is probably just the tip of the iceberg.  (For what it's worth,
	"GPA" and "sophomore" are not in "Cultural Literacy".)

    (3) I am willing to challenge authority.  I can believe at one and the
	same time the ideas "Feldman is a vastly better teacher than me
	and knows a lot more than I do" and "on a particular point, I can
	be right and Feldman wrong".

    I gave a concrete example of what the "culture of conformity" can do
    to a student when I mentioned an Asian student who was having great
    difficulty with an assignment because he didn't know what the word
    "descendants" meant, and didn't dare to ask his lecturer face to face
    or to raise the issue in the "public" newsgroup for that subject.
    (The lecturer in question is one of the most approachable people in
    the department who has shown great willingness to explain and clarify
    this very assignment.)  Because I had the label "tutor" for this
    subject, because he and I were alone, and *because I asked* him why
    his code had a particular form, he reluctantly explained the problem.


>Nevertheless, I do partially agree with you and Richard:  Either Addison-Wesley 
>should publish special non-American editions or Feldman should add some
>footnotes for the international editions explaining the Americanisms.  However, 
>I do *not* think that he should alter the editions being sold in the U.S. (except,
>of course, the errors should be corrected).

There are two separable issues here.

 -  What ought to be done for Feldman's book in the short term?
    In the short term, reprinting with corrections that don't affect
    pagination is economically feasible; revision is not.

 -  What ought to be done about CS textbooks in general?

    With all due respect, the idea of having separate US/international
    editions is less sensible than it might at first appear.  What are
    just some of the major problems with the idea?

    *  Just because a class is geographically located in the US does not
       mean that the students in it would not benefit from an international
       edition.  I am told that US classes often include a high
       proportion of overseas students or comparatively recent immigrants.

       Don't forget the US citizens raised in Spanish-speaking families.

    *  Having two versions of a book puts up production costs.  Book
       prices in Australia are already high, except for the ones that
       are very high.  The last thing we need is any practice that will
       put the prices up higher.  It's no use having the perfect book
       if the students can't afford it.

    *  Having two versions of a book puts up MAINTENANCE costs.  There
       are two versions to revise for the next edition.  This has got
       to increase the cost, or the likelihood of letting proofreading
       errors slip through, or more likely both.

    *  Nobody has yet presented _evidence_ that the _accidental_
       Americanisms in this book provide any advantage to anyone.
       Will someone have the goodness to explain to me precisely how
       leaving Konrad Zuse and Alan Turing out of a history of milestones
       in computing does anything to help US students?

       Let's face it, if the Americanisms in this particular book were
       deliberate, surely the colour name translation example (program
       3.5) would translate between English and _Spanish_ colour names,
       not English and French.  (By the way, my French teachers would
       have had a fit at the idea that "yellow" and "jaune" could be
       identified.)
	

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

Re: Book REview

[Theodore E. Dennison]

sxc@itd.dsto.gov.au wrote:
> 
> If I had been an American undergraduate, I might be irritated by the
> suggestion that my attention span was so short that I needed to be
> pandered to with culturally specific examples.  As an Australian

He he! That's a good one.

What makes you think your average American has any clue that she
has just read something "culturally specific"? I certainly never
noticed such a thing (unless you count "queues" in data structures;
"queue" isn't really a word in this country).

I suspect most undergrads won't notice, as long as it is specific to
THEIR culture. Unless they are accomplished travelers, how could 
they?

I'm not saying this is a GOOD thing. I just found that statement
humorous.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Book REview

[Richard A. O'Keefe]

This is no longer about Mike Feldman's book.
It is about textbooks in general.

Richard A. O'Keefe wrote:
> Last Friday I received several textbooks for review.
> 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.

Dave Jones <davedave@io.com> writes:

>Personally, I think that it is wise to make a textbook culturally specific.

Perhaps so, but
(a) there is a big difference between INTENTIONALLY localising a book
    and UNINTENTIONALLY localising it.
(b) if a textbook is deliberately made culturally specific, then
    why sell it to other cultures?>

>The use of culturally specific examples helps to hold student attention
>and makes for a superior textbook.

This may be so.  Can you point me to any studies which provide
_evidence_ for this claim?  Certainly in the specific case at issue
*none* of the cultural specificity is of the kind that would grab
the attention of a US student.  They are things that a US student,
just like a US author, simply takes for granted.  I find it difficult
to imagine a US student being excited by "GPA" or "Sophomore" or the
assumption that there are only 26 letters.  Or, to take another example,
look at the history of computing on p5.  It's not really surprising that
there is no mention of the CSIR Mk 1, which was the first electronic
stored program computer in Australia, and was among the first five
_anywhere_ in the world, running its first program during 1949.  But
it was rather a shock to find no mention of Zuse or Turing.
Does this focus on US contributions to computing "hold student
attention"?  Like fun it does, they don't _KNOW_ the bias is there.
Does it "make for a superior textbook"?  I really don't see how leaving
Algol out of Ada's history makes the textbook any better.
If you are concerned with women in history, how does including Christine
Anderson but excluding the first programmer, the Countess of Lovelace,
"hold student attention" or "make for a superior textbook"?
(This is _not_ an argument for omitting Christine Anderson; but I think
Grace Hopper has more claim to be included in a table of Milestones.)


>Perhaps, Mr. O'Keefe should contact Addison-Wesley about 
>creating an Australian edition.  For that matter, I would think that the 
>Australians are perfectly capable of writing their own textbook.

>Mr. O'Keefe also needs to realize the economics of the situation.
>Australia has a tiny population (about 18 million) and a trivial GDP
>(about US$340 billion).

Mr Jones needs to read what he just wrote.  If Australia has a tiny
population (and it's about 6 times the population of my own country)
and a trivial GDP, then why would Addison-Wesley be interested in
creating an Australian edition?

In any case, Dr O'Keefe is not an Australian, so would not be able to
produce an Australian edition, and as about half of the students he
is worried about aren't Australians either, he wouldn't _want_ an
Australian edition.  About half of our first year students are not
native speakers of English.

>It would be very very unwise for Addison-Wesley to risk a position in the US 
>market in order to increase their position in the Australian market.  I
>would not expect there to be any changes in the book until people in
>larger countries start complaining.

Perhaps Mr Jones should think a little bit more about the politico-economic
situation himself.  Of the countries in the Asia-Pacific region, Australia
is the *most* Americanised.  Australia and New Zealand (which is where I
come from) _do_ have a tradition of free speech and dissent; many of the
more populous cultures of the region have a tradition of teacher authority
and student submission; if the Big Teacher dishes something out, the
student dutifully memorises it, whether it makes sense or not.  Don't
think of

And in the case of the Feldman/Koffman book, internationalising it would
pose absolutely no risk to its position in the US market.  *None* of the
issues I have identified is central to its educational aims or methods.
For example, the continuing project which is one of many excellent features
of the book, the "spider graphics" stuff, is about as culture-neutral as
one could reasonably hope for.

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

Re: Book REview

[Richard A. O'Keefe]

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

>Don't
>think of

Which should have read
	Don't think of me as a lone madman, think of me as a miner's canary.

Coincidentally, after posting that message, I received the results of a
local survey of *post-graduate* students.

- "more than 50% were migrants
   or permanent residents who had not been in Australia very long"

-  about 50% of the students have worked overseas or had been asked by
   their employers to work overseas during the course (roughly split as
	50% Asian countries, 25% Anglophone countries, 25% European counties).

-  most students saw internationalisation of the post-graduate program
   "as having been achieved"

-  "the majority of the students could not find any subjects where the
   subject matter is Australian-centered" except that
     * some case studies (including one relating to Telecom Australia)
       were Australian-related, which was something of a problem
     * some students commented that 'most of the material' is US-oriented
       and that was a problem
     * some data base materials were identified as "very 'Western'";
       this is a code word for 'American'.

-  most students wanted an "internationalised" course
   if it wouldn't cost them any more or impair their job prospects

-  about a quarter of the students commented that they wanted our
   program to have more overseas content.


Now, this was a survey of POST-graduate students, not CS 1 students, but
"more than 50% migrants or recent permanent residents" describes our CS1
students pretty well too.  They come from a variety of Asian and European
backgrounds.  So an "Australian" edition of a textbook would switch off
half our students.  Not a good idea.

The bottom line for textbook authors and reviewers here is that
"Americanisation" _is_ an issue for Asian students; they _are_ aware of
the cultural biases in the text-books and it _does_ bother them.

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

Re: Book REview

[Dave Jones]

Richard A. O'Keefe wrote:
<lots of stuff about "Americanization"  (?"Americanisation"?)
in textbooks>

Richard O'Keefe has argued his position very well.

I now concede that I was mostly wrong, and Richard was
largely correct.

-- Dave Jones
davedave@io.com

Re: Book REview

[Todd Coniam]

In article <3190CEC1.5799@io.com>, davedave@io.com says...

>Personally, I think that it is wise to make a textbook culturally specific.
>  The 
>use of culturally specific examples helps to hold student attention and mak
>es for 
>a superior textbook.  Perhaps, Mr. O'Keefe should contact Addison-Wesley ab
>out 
>creating an Australian edition.  For that matter, I would think that the 
>Australians are perfectly capable of writing their own textbook.
>
>Mr. O'Keefe also needs to realize the economics of the situation.  Australi
>a has 
>a tiny population (about 18 million) and a trivial GDP (about US$340 billio
>n).  
>It would be very very unwise for Addison-Wesley to risk a position in the U
>S 
>market in order to increase their position in the Australian market.  I wou
>ld not 
>expect there to be any changes in the book until people in larger countries
> start 
>complaining.  
>
>-- Dave Jones
>davedave@io.com

-- 
Personally I would like to appologize to Richard and my other 
planetary occupants for the unnecessary arrogant remarks made 
by Mr. Jones.  I would like to assure everyone that not all
Americans feel that the rest of the world is insignificant 
and not worth the trouble.  I wish internationalization was easy,
but Richard has pointed out just how difficult it can be.

As a side note, Americans in general are not widely traveled or
exposed to other cultures (except at restaurants, I mean eating 
establishments, seems restaurant is an Americanism too... ;-)
which does explain, though not forgive, their ignorance...

-------------------------------------------------------------------------
Todd Coniam       | Member: Team Ada
tconiam@ionet.net | Ada 95 - The international standard in OO languages
-------------------------------------------------------------------------
Check: http://lglwww.epfl.ch/Ada/     Free compiler: http://www.gnat.com/

Re: Book REview

[Simon Wright]

In article <4n6it0$ldp@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:

> Let me give an example from another book.
> This one's "The Little Schemer".  on p13 we find
> 
> 	=> Now go make yourself a peanut butter and jelly sandwich. <=

And in the UK, the word would be "jam".

-- 
Simon Wright                    Work Email: simon.j.wright@gecm.com
Ferranti Naval Systems                     Voice: +44(0)1705-701778
GEC-Marconi S3I Combat Systems Division      FAX: +44(0)1705-701800

Re: Book REview

[sxc]

In article <SIMON.96May14070756@pogner.demon.co.uk>,
Simon Wright <simon@pogner.demon.co.uk> wrote:
>In article <4n6it0$ldp@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:
>
>> Let me give an example from another book.
>> This one's "The Little Schemer".  on p13 we find
>> 
>> 	=> Now go make yourself a peanut butter and jelly sandwich. <=
>
>And in the UK, the word would be "jam".
>

No self respecting Englishman would mix peanut butter and jam / jelly
in the same sandwich.  It's barbaric :-)

-- Steve

Re: Book REview

[John McCormick]

>The thing that still has me angry is that at one level it _isn't_ (or
>isn't meant as) a bad review of the "World 3" book.  It's really an
>angry review of the _proofreading_ and _review_ processes.  How come
>such a well planned book by such great authors ended up with a flawed
>result?

In defense of Mike (but NOT of Addison-Wesley) I'd like to say that many
errors are out of the control of the author, editors, and reviewers.

I supplied my publisher with disks containing all the final text and
programs for my CS2 book: _Ada Plus Data Structures: An Object-Based
Approach_, 1996.  The typesetter was unable to read one of my chapter files.
Rather than request another copy from me, they decided to key in the chapter
from the hardcopy.  Needless to say I spent weeks combing the page proofs
correcting all of the errors introduced.  Thank goodness that I was able to
use the page proofs for this chapter in my class so I had many more pairs of
eyes helping with the checking.

It is bad enough to make one think about giving up textbook authoring.

John



===========================================================================
=                                                                         =
=  Moving this summer to the University of Northern Iowa                  =
=                                                                         =
=  John W. McCormick, Professor        Phone   (518) 564-2785             =
=  Computer Science Department         FAX     (518) 564-3333             =
=  State University of New York      mccormjw@splava.cc.plattsburgh.edu   =
=  Plattsburgh, NY  12901            mccormjw@snyplava.bitnet             =
=      USA                                                                =
=                           SUNY Plattsburgh                              =
=                                where                                    =
=       Computers + Model Railroading = Digitally Controlled Trains       =
=                                                                         =
=                        *      *     *                                   =
=                                          *                              =
=                                             *                           =
=          ##                           ##    T                           =
=        ######_########_########_#####_#########-                        =
=         o  o   o    o   o    o   o o  oo OOOO oo\                       =
===========================================================================

Re: Book REview

[Dave]

This letter is best read in a monospaced font.

On Sat, 11 May 1996, Todd Coniam wrote:
> Personally I would like to appologize to Richard and my other 
> planetary occupants for the unnecessary arrogant remarks made 
> by Mr. Jones.                           ^^^^^^^^

I began my letter by stating a resonable opinion.  I followed that with 
two suggestions -- one of which was complimentary to Richard and the 
other of which was complimentary to Australians in general.  I then 
stated two facts.  Based on those facts, I stated another reasonable opinion.
Then I closed my letter.  Where is the arrogance?

Personally, I think that someone around here *is* being arrogant, but I 
won't name names.

> I would like to assure everyone that not all
> Americans feel that the rest of the world is insignificant 
> and not worth the trouble.  

I did *not* say that Australia was insignificant.  I did *not* say that 
Australia was not worth the trouble.  If you had taken the time to read 
my letter you would know that I was making the following point:

Because the Australian market is small, it would be very unwise to risk a
position in the U.S. market in order to capture a position in the
Australian market.  (For the benefit of persons such as yourself, perhaps
I should not have left the following point implied:  By removing the
"Americanisms"  from the book, they might make it less attractive to the
U.S. market.)

In any case, the fact that I suggested a special Australian edition should
make it perfectly clear to anyone with a brain larger than a pea that I
*do* consider Australia to be significant.  (For those who live in
countries where there are not peas:  A pea is a small (about five
millimeter diameter), round vegetable.)

> 
> As a side note, Americans in general are not widely traveled or
> exposed to other cultures (except at restaurants, I mean eating 
> establishments, seems restaurant is an Americanism too... ;-)
> which does explain, though not forgive, their ignorance...
>            ^^^^^^^             ^^^^^^^        ^^^^^^^^^

Most of the Americans that I know are widely traveled and are exposed 
to other cultures on a regular basis.  Since I cannot *explain* Todd's 
*ignorance*, I guess that I will just *forgive* him for it.

-- Dave Jones
davedave@io.com

Re: Book REview

[Theodore E. Dennison]

Dave wrote:
> *do* consider Australia to be significant.  (For those who live in
> countries where there are not peas:  A pea is a small (about five
> millimeter diameter), round vegetable.)

This explanation will be lost on those who live in non-metric using 
countries witout peas. Plus there are probably a lot of Innuit reading
right now who are wondering just what a "vegetable" is.

:-)

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Book REview

[Tucker Taft]

Dave (davedave@io.com) wrote:

: Because the Australian market is small, it would be very unwise to risk a
: position in the U.S. market in order to capture a position in the
: Australian market.  (For the benefit of persons such as yourself, perhaps
: I should not have left the following point implied:  By removing the
: "Americanisms"  from the book, they might make it less attractive to the
: U.S. market.)

I don't think anyone is being arrogant ;-).

However, I humbly disagree with the notion that removing "Americanisms"
might hurt the book in the U.S. Market.  If anything, an attention
to international concerns is essential for all of us, especially those
interested in being successful in the software market.  If a text
book helps to raise awareness of issues relating to internationalization
and localization, it would be doing students a great favor.

And as far as being interesting, I suspect many students will find
it more interesting to see examples talking about Rubles or Swiss Francs
or Pesos than always seeing the typical dollars-and-cents examples.

I also don't fault Mike for missing some of these issues, given the
effort involved in creating a text book in the first place.  But
the suggestions relating to removing Americanisms, some of which are
probably unintentional (such as "GPA"), seem worth considering for
future revisions of the text, and would probably enhance the appeal of 
the text, even in the U.S. market.

Just another opinion...

: -- Dave Jones
: davedave@io.com

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA