At 11:56 PM +0100 1/13/03, you wrote:
I have been always thinking that, real mistakes and omissions apart, it was
a precise Macromedia policy mantaining the Help Documents just so as they are.
I may be wrong of course.
& you are ("I may be wrong")
- there are almost always many small Help changes in every release.

It's just that the focus during the release is always on new features and these must get included before the features are truly finalized, and so it's always an uphill battle toward correctness.

What would probably be best is if the time could be allocated each last release's features to be re-examined & cleaned up sometime during each next release.

But this doesn't happen unless someone really pushes.

For instance, the new sound Lingo that was introduced in d8 got a pretty significant re-exam & rewrite during d8.5. It got a LOT better and I still see improvements that could be made.

But, in my opinion, it may have happened because
they were afraid to scare young people, beginners or people coming from
other programming environments with true manuals rich of rules, details,
exceptions and, what's worst, the harvest of examples that would be
necessary to illustrate them.
The amount of detail include for each entry is a different issue.

Optimally, it would be nice to be able to determine a right amount, but this is quite difficult - Lingo serves a variety of skill levels and some entries don't lend them selves to simple descriptions & some don't lend themselves to rich ones. More importantly, many are quite difficult to describe in isolation.

The first impression when opening a paper or electronic document should be
that you're dealing with something easy, immediate and friendly. In a sense,
something well fitting the multimedia world, which people perceives as fun,
entertainment and exercise of free creativity.
As a unique example, and in addition to the specific subject in question,
let me quote how the Help Documents tackle the subject of the objects side,
of OOP (as opposed to the behaviors side). A sea constrained into a drop of
water. They could offer a glass at least, if the sea seems too much.

I for one think that Lingo, which is a true programming language, suffers
greatly for this situation. And I think also that it was a unhappy circumstance
having them refused your offer. But, according to my opinion expressed so far,
we could have been at the risk of having a pair of true manuals:)
What it sounds like you are asking for is a 'Using Lingo' manual. The current package doesn't include this.

It includes 'Using Director', which is necessarily shallow in detail and the Lingo Dictionary, which is light on thematic progression.

Third party books often do a better job for the 'Using Lingo' side of things.

Your example of OOP is one of those topics that could be a book unto itself.
In fact, Irv Kalb has begun a pretty good one: http://www.furrypants.com/loope

hth
-Buzz


Franco

IFC Programming Consultant
http://www.chnexus.com/athroon~/index.htm
mailto:[EMAIL PROTECTED] | [EMAIL PROTECTED]
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi  To post messages to the list, email [EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo.  Thanks!]


Reply via email to