Lambda the Ultimate

I've yet to see circle/ellipse inheritance modeled correctly in an object oriented language, so I fail to see how this should absolutely disqualify a begginners book from getting a positive review.

Well, this of course depends on what I happen to find correct. Inheritance is supposed to model an isA relation, and as a circle is an ellipse (and not otherwise), a circle should be a subtype of an ellipse. This, however, breaks the Liskov substitution principle (at least if you also introduce mutability, which is quite common in OO languages). So, you either have to keep the two types unrelated, or you have to break intuition and common sense, and let ellipse inherit from circle. But both of these alternatives breaks the isA motivation behind modelling with OO lanuages, and thus are no more correct than the one that broke the LSP.

It seems to me that in order to introduce a correct example, you have to give up at least one of:

mutability - This seems to be enough in the circle/ellipse example, but I'm not convinced it really solves the issue at hand.

the notion that inheritance is useful for modelling isA relations - This would really solve the problem, but it is also the same as giving up.

type == class - Then you could also have method-dispatch on types instead of classes. An ellipse could be said to be of type circle whenever it was circular (checked dynamically). This would solve the problem, but would also make method calls ridiculously inefficient.

LSP - But that would give us unmaintainable and/or incorrect programs. So the LSP is something we want to keep, if not for modelling, at least for creating maintainable, correct programs.

Me myself, I prefer to give up. I choose to accept that most OO programming languages is not particulary suitable for modelling complex relationships between different types of objects. If you want to do that, use a (modelling) language specifically created for that purpose (not a programming language)!

But back to the issue at hand, how is a discussion such as this at all useful for a beginning programmer? Deitel's books are obviously not aimed at people already knowing about the LSP (those would already know how to program, and would not be attracted by the title). Beginning programmers need to see examples of something working, and create simple working themselves. They do not need theoretical discussions. Once they've grasped the basics, then you can teach them about the LSP.

And while it is true that you can learn calculus by starting with set-theory, constructing the integers and the real numbers, all the way relying on as few definitions as possible, and prove every step all the way back to ZF's axioms, only using intuitonistic logic, it is not what most people do! Most people learn calculus by memorizing formulas, learning some weird trics of operator calculus without really understanding why (and when) those tricks are legal, and looking at examples and doing exercises themselves. Once they've learned the basics of that, then you can teach them about real analysis.

The way I see it the LSP is crucial if you want to understand subtype polymorphism. This is why it is essential to explain it to beginners. You don't have to use the the words Liskov, substitution or principle - but the learner must realize the importance of the issue, and why determining something is an Is-A relationship is not always trivial.

A true story. A student was taking my course as well as a Java course using the Deitel book. I talk about the circle/ellipse dillema to explain the problems that can arise (because the LSP breaking) during program maintenance. A student comes and says, you are obviosly wrong. This is a good inheritance hierarchy. Why? Not because of any good reason, simply because "the book says so."

Now this is not what I call learning.

A decent book would either not use this example at all (which is not too hard, there are plenty examples that are more interesting), or explain how you reason in order to decide on the best inheritance hierarchy.

I fail to see why this can not be done, when teaching beginners. This is exactly what must be done, IMO.

On the other hand, it is also important that text-books should be useful as references later, and therefore it is important that when it teaches you something wrong (for whatever reasons), that it informs you of this fact, so you can look the subject up in more advanced texts yourself later. I believe this is what is upsetting you, and I must agree that this is a pretty good reason, but I just don't think one error is enough to diss the entire book.

It would be really hard to find a text-book of around 1000 pages or more, that doesn't do some screw-ups like this. Now, if you could find an error at, say, every other page (such as certain books by Herbert Schilt), then it would start being important.

I've never actually sat down and read a Deitel/Deitel book, but from what I've seen of them, they don't really look that bad. They have too many pages (but beginners might like that), they use colors in ugly ways (but beginners might like that), they are not very advanced (beginners definitely like that), and they seem to focus on teaching a good blend of sound programming advice, basic programming techniques, and language/environment-specific details.

So because I like the basic approach of Deitel/Deitels books, I am willing to swallow a few camels (sorry about that, we are still talking Python here). Yes, that's a pragmatic choice, but the rest of us can't afford to await perfection in programming books (remember Knuth is still only at volume 3). Now, if the average quality of basic programming books was much higher, it would be a different issue, but sadly, most beginning programming books seems to be of much worse quality than Deitel/Deitels.

What would be a simple inheritence example that didn't have advanced problems?

Two things I like to talk about:

Inheritance used for classification (Vehicle, Car, Truck; Animal, Fish, Reptile).

Interface inheritance for ADTs (abstract stack, concrete stack).

Previously, I reviewed the "Java How to Program" book and found it to be a terrible waste, sure to take all the fun and creativity out of programming, and lead the readers down a path leading only to a pit of talentless drones. So when I saw this book on the shelf, I flipped through it, hoping that the free-wheeling nature of Python might have lead the Deitels towards a more enlightened approach to instruction. I quickly found that this book has many lessons to teach (although precious few that I would agree with). For example:

* Python programmers are NOT having more fun than Java (or other) programmers; all languages are equally stultifying.

* Learning a language is a tedious task, centered around learning features of the syntax in a prescribed order. (This is like learning to cook by trying ingredients one at a time in alphabetical order, without ever trying to put together something tasty.)

* The practice of programming has no underlying principles, only an endless series of questionable tips presented in overly-garish multicolor pages. (You'd be better off with a single chapter of "Structure and Interpretation of Computer Programs" than with anything in this book.)

* Programming is inherently boring, involving endless repetitive typing; it is better for the programmer to do a lot of work than to expect the computer to. For example, consider this masterpiece of brevity from chapter 4 (Fig 4.7):

===================================

import random

frequency1 = 0 frequency2 = 0 frequency3 = 0 frequency4 = 0 frequency5 = 0 frequency6 = 0

for roll in range( 1, 6001 ): # 6000 die rolls ___face = random.randrange( 1, 7 )

___if face == 1: # frequency counted ______frequency1 += 1 ___elif face == 2: ______frequency2 += 1 ___elif face == 3: ______frequency3 += 1 ___elif face == 4: ______frequency4 += 1 ___elif face == 5: ______frequency5 += 1 ___elif face == 6: ______frequency6 += 1 ___else: # simple error handling ______print "should never get here!"

print "Face %13s" % "Frequency" print " 1 %13d" % frequency1 print " 2 %13d" % frequency2 print " 3 %13d" % frequency3 print " 4 %13d" % frequency4 print " 5 %13d" % frequency5 print " 6 %13d" % frequency6

===================================

(_ used for space to make sure it indents right.) This is 36 lines (52 if you count the copyright notice) for something that a grade-schooler could tell you (I know -- I've asked) is better done with 7 lines:

import random

def roll(sides=6, n=6000): ____freq = [0] * sides ____for roll in range(n): ________freq[random.randrange(sides)] += 1 ____return freq

I find it a case of unconscionable student-abuse to suggest that it is permissible to write a function such as Deitel et al. present, but I suppose they had their reasons: perhaps they hadn't introduced lists (or functions) yet. Perhaps lists (or functions) didn't fit readily into their idea of the right order to learn concepts in BASIC (which must therefore be the best order to learn concepts in every other language).

If you want to learn Python, or learn to Program with Python as your first language, try another book such as "Learning Python" or "Programming Python".

If you want to ensure that you won't appreciate why Python is the way it is and why it is interesting; if you want to make sure that you'll be a drone of a programmer with no chance of doing anything creative at a good company or school, by all means stick to this book.

Those who were raised on SICP may have a different story; mine is that there is no one source, still less any one book, from which I learned to program. In practice, I think I started with a piecemeal understanding of how to make my ZX Spectrum do certain amusing things, and gradually layered things like variables, looping constructs, subroutines, variables with local scope, functions, data structures, abstract data types, objects, polymorphism, higher order functions, multi-parameter type classes and so forth on top of that, changing computer, operating system and language repeatedly along the way. If I'd read certain things earlier, it might have saved me a fair amount of time and confusion. The order I learned things in was weird: I read (part of) a Forth book very early on, for instance...

If there is a "learning style" that the Deitel books are suited to, it evidently isn't mine. But I do wonder if they don't fill a niche. A lot of the stuff I started out on was pretty dreadful too - magazine listings of BASIC programs for the Sharp MZ80K - but it got me doing programming, and discovering the problems and (best case scenario) how to tackle them as I started writing larger and more complex programs.

I thought Bird-Ostrich was the cannoical bad example for inheritence.