From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,83242c369c5dc9b0 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: Book REview Date: 1996/05/07 Message-ID: <4mmfsu$b30@goanna.cs.rmit.EDU.AU> X-Deja-AN: 153418713 references: <4mk0vc$opp@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia keywords: textbook, cs1, review newsgroups: comp.lang.ada nntp-posting-user: ok Date: 1996-05-07T00:00:00+00:00 List-Id: 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.