Rating: 
Summary: Review the contents
Review: A lot of pages, some little triks. Not a deal.
Rating: 
Summary: slap-dash
Review: He begins the book with a useful approach to lingo, but around page fifteen he starts to abbreviate explanations. He included images from previous version of book inconsistent with what he's talking about, so when you try it it doesn't work. typical slap-dash approach of people trying to make a quick buck, or should i say $50 bucks if you get it from Borders. I thought this would be a really good book, but he should have kept the format of explain step-wise as in the first ten pages of the book. pretty disappointed.
Rating: 
Summary: Excellent for beginners...eh-OK for advanced programmers
Review: I encountered this book by accident after having read what seemed like a million books on Director and Lingo programming. It is by far the most lucidly written text that I've encountered. My only problem with it is that the authors don't do a very good job of explaining OO programming to those who are unfamiliar with it. Aside from a brief section, it's assumed that you're coming to the table with this knowledge. On the other hand, I was able to "wow" some other developers with info that I gleemed from this book. It's a good book to have regardless of your skill set.
Rating:
Summary: Over priced and incomplete.
Review: I have mixed feelings about this book. I purchased it thinking that I was going to be able to greatly increase my programming skills and understanding of OOP. This book contains very good ideas and will increase your understanding of OOP. Many of the scripts just don't work. Maybe this is due to the fact that the book was apparently written for Director 4 and 5. That is all that I see referenced. It would be great if Mr. Small would update the book because it can have great value. His web site contains some dot syntax examples from the book that actually work. If you purchase the book, you will increase your understanding of lingo and you will increase your frustration level trying to make the scripts work. For the price, it should have a companion cd.
Rating:
Summary: This book has nothing to do with AI or IA's
Review: I made that mistake, and wasted my money. Be aware. This book does not cover AI or Intelligent Agents in the traditional sense.
Rating:
Summary: This book has nothing to do with AI or IA's
Review: I made that mistake, and wasted my money. Be aware. This book does not cover AI or Intelligent Agents in the traditional sense.
Rating:
Summary: The worst explanation of OOP I have ever read...
Review: I was introduced to object-oriented programming about 15 years ago, in the LISP and Smalltalk versions. Now that I'm learning Director, I was excited to find a book devoted to OOP in Lingo. What an utter disappointment this book has turned out to be...an utterly confusing waste time.
Rating:
Summary: Feh
Review: I've seen programmers say they didn't like this book, but that it might be good for non-programmers. I've seen non-programmers say they didn't like this book, but that it might be good for programmers. That's a bad sign. Specifically, I've seen a review of this book that says "My only problem with [this book] is that the authors [sic] don't do a very good job of explaining OO programming to those who are unfamiliar with it." Well, I /am/ familiar with OOP, and I found the explanations startlingly bad. I'll pare it down to two points: Point one: Chapter 1 starts out: "What's an object? The simple definition of an object is that it is anything you want it to be. In the context of the Lingo programming environment [!], the definition could [!] be: anything you want to put into the computer's memory. In the OOPS [!] sense an object might [!] be described as an entity which can persist in time [as opposed to persisting in... space?] and can monitor and respond to complex conditions and events. These seemingly vague and indefinite descriptions of an objects are very hard to visualize and can make object-oriented programming seem to be an infuriatingly elusive concept for newcomers to wrap their minds around. The program, however, is not that it is too difficult to understand; rather the reverse, it is so ridiculously obvious and intuitive that people try to look for something more subtle and complicated in order to explain it." Well, you don't have to be a lexicographer to see that these are not helpful definitions, and the discombomulation that follows doesn't get any better. An "object", I say, is a structure of data with which the programmer has associated certain bits of code ("methods", "routines", "handlers", whatever you call them), so that you can invoke those bits of code as actions performed on the data structure you've got at hand. An object can be a data structure representing (and corresponding to) a circle drawn on the screen; you can associate with it a bit of code that flashes any such objects. Then you can say "perform the action Flash on object This_Circle" (which may look like "Flash This_Circle", "This_Circle.Flash", or "This_Circle->Flash", depending on the language in question), and it'll do it. Tadaaa, object-oriented programming REVEALED! And I didn't even charge you $50 for that explanation. So why all the smoke and mirrors, and the scaretalk about it being too hard to be simple, and so on? Now, go back to that paragraph, and replace "object" with "variable", or "function". It's basically all still true, and just as unhelpful, but obviously noone would /dare/ write an intro-to-programming text that started out that way? Feh! Now, to point two: There are basically two kinds of OOP systems around: 1) Classy OOP systems -- the kind where you have classses; every object belongs to a class; and the class is where you keep all the methods/routines that you want your objects to be capable of. 2) Classless OOP systems -- the kind of OOP system where there are NO CLASSES; you get generally get new objects by "cloning" other objects (possibly prototype objects provided for just that purpose); and methods are associated with individual objects, and are inherited by their clones/children. Now, classy OOP systems are so well known that most programmers think that's /all there is/; and even people who are aware of the existence of classless OOP systems probably can't name more than three computer languages that do it that way, much less name anyone who uses any of these languages for anything. Well, guess what, Lingo is a classless OOP system. That's odd, and unfamiliar, and this book should have treated this unfamiliarity with care. But: If you, the reader, happen to know something about OOP, you've probably never heard of anything but classy systems, so the first thing you do when faced with a new language's OOP framework is "OK, how do I declare the class, put methods in it, and instantiate/construct objects in it?" So you plod thru about two paragraphs of the prose I've quoted above (and there's plenty more where that came from!), you get bored, and then just go and look up "class" in the index. The /one/ entry for "class" in the index points you to /one/ paragraph, which reads: "[...] Some of the literature on object-oriented programming will [?] describe objects as instances of classes. This is because objects birthed from the same parent script will have a common set of characteristics which allow them to be categorized into a single class -- hence each object can be regarded as an intance of its class." At first sight, this makes no sense. And at second sight, it's just plain /wrong/. Classy OOP systems aren't systems where there's similar objects that just happen to be, in some Platonic abstract realm, characteristically in an thing called a "class". Instead, classes are where you get the methods that make, manipulate, and destroy objects. It's /all/ about classes. I'm not harping about some minor technicality here -- this /is/ a book about OOP, and in the /single/ place in the book where an experienced programmer would jump in expected some degree of coherence, there's nothing but a wild misconstrual of basic structure of the only kind of OOP system the reader is likely to be familiar with! That's bad, and it shouldn't be that way. Instead, there should be a section explaining that if you the reader have dealt with OOP systems, you've probably dealt only with (and have heard only of) classy OOP systems, but that there's such a thing as classless OOP, and so on, and so forth. So in a nutshell -- this is a bad book. While reading it, I had to constantly say "now, here's what he's saying -- but is it really some other way, and he's just screwed /this/ up too?" A book that seeks to explain and to teach should do so simply and clearly; the reader should not have to constantly second-guess the explanation, and wonder why it's vague, where it's wrong, and how it's been distorted from reality.
Rating: 
Summary: Yes for sure it's a great book
Review: If you are a beginner; Sometimes Mr Small go fast but it's the good to refine you search for knowledge. If not: Great ! Peter gives a chance to your dreams. Even if you want to learn Java it's probably one of the best starts. I think it's time for Peter to write a novel about programming. It's great to spend my money and feel richer.
Rating: 
Summary: Disappointing
Review: It would have been nice if he had working samples online of the programs to go along with the stuff in the book. While interesting subject, his programming is not the most efficient. Have the time I feel like he is just B.S.ing his way through the book. It is a pain to have to build all your own examples, which means you can't just jump into the chapter you're interested in. Also, the images in the book are blurry, how the heck did the publisher ever let that get by? Haven't they ever seen a clear screen shot.
| 
