Customer Reviews

Lingo Sorcery: The Magic of Lists, Objects and Intelligent Agents

5 star:		(4)
4 star:		(2)
3 star:		(2)
2 star:		(2)
1 star:		(5)

 

 

Well this book is useless for any practicing or aspiring lingo programmer, the obscure approach to coding OO lingo has absolutelty no realworld use value. The book offers %95 blabber on the virtues of OOP without one bit of useful code. The author may be a good cheerleader for something he heard on TV, but how he was allowed to publish this book is a complete mystery to me.(Well, thats not exactly true: the title was good, the timing was right, and the economy was booming) This book was written by a fan for fans. So if you need a motivational speaker to convince you that OOP is a good thing, buy this book, read it, recycle it and then buy Bruce Epstein excellent "Lingo in a Nutshell" and write some nice ojects in Director.

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.

This Book is virtually a gem. The Ideas in this book have completely changed my way of thinking OOP wise.Also it opened my mind to totally new paths regarding the use of Lingo.

However, I could have saved a lot of time reading and understanding that book ,if the author had paid more attention to the way he presented his Ideas to the readers. It took me more patience than intelligence to keep up with the authors trail of thoughts. He many times switched from an Idea to another without any prior warning then jump back to the original Idea the same way he left off. Also it took me hours to fill up the gaps the author had left in his illustrative projects including codes,sprites or castmembers that I had to figure out on my awn. So I ask the author kindly to eliminate these major sorts of distractions to make his readers more focused on the Ideas of the book ,rather than what went wrong or what is missing , if he is planning on writing any other books on lingo.

But regardless of all the above, in the meantime, this book is one of a kind comparing to other books on lingo and I can confidently say that it's a must for every lingo enthusiast.

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.

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.

Peter's terms in this book are nonstandard for a reason.

His intent is to get a point across without simultaneously boxing the reader's perspective into one angle, one paradigm, one image about how OO coding works, how it's supposed to happen, who's supposed to do it, who's supposed to know about it and so on.

There are certain types of programmer who will object to this approach. However that does not invalidate the approach, and it does not make the book bad.

I made that mistake, and wasted my money. Be aware. This book does not cover AI or Intelligent Agents in the traditional sense.

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.

This book has some useful information but it is presented in a long winded manner. It should have had a CD with the full source code and working programs of the examples in the book. Instead there are only partial chunks of code given as examples. Fortunately I only paid a couple of bucks for it. It is definately not worth full retail.

This book is not an academic approach to Object Oriented. It teaches you how to use Director in a very different (and better) way. You stop viewing a Director movie as "frames in the Score Window" and start using it as an "object-maker". It opens up your mind for new possibilities. I'm not a programmer, but after reading this book I've started making good projects with Director.