Dependence on Programming Experts

[Ken Ray]

On 7/15/06 1:28 AM, "Judy Perry" <jperryl at ecs.fullerton.edu> wrote:

Hey Judy,

I agree with both you and Scott. (How? You might say?) You're both right
(IMHO) so long as there are qualifiers:

> (1)  Multiple ways of doing things confuse newcomers.

I agree with you, so long as the multiple ways are *equally promoted*; which
luckily for us, this is not the case. There is always one version of a token
that is predominantly promoted in the Transcript dictionary, with other
variations taking a back seat. Sometimes over time one overtakes the other
and becomes the one that is promoted, but usually it has to do with what
might be considered a natural migration of the language.

Consider "the directory" and "the defaultFolder". I've been around long
enough with both MC and Rev (9 years or so) to have seen the original token
"directory" replaced with "defaultFolder". Why? Because originally MetaCard
came from Unix, then to Windows, and ultimately to Mac. In Unix-land, the
term "directory" was the common term to attribute to that structure; later,
as Windows 95 and the Macintosh UI continued to call them "folders", it made
sense to add "defaultFolder" as a synonym to "directory". And in doing so,
what used to be promoted as the primary term ("directory") eventually was
replaced with "defaultFolder" as the promoted term.

If both terms had been equally promoted it certainly would cause confusion
for newcomers. 

Certain tokens also have a (IMHO) "goofy" syntax, such as using
"playLoudness" instead of what would be more understandable as
"audioVolume". If "audioVolume" were added as an alternative, I'm sure it
would swap places with "playLoudness" and be promoted as the primary term
because it is more understandable.

Adding an alternative token (or set of tokens) does not in and of itself
make things confusing to newcomers (IMHO), so long as only one of the tokens
is used consistently in Rev documentation and is promoted as the token that
*should* be used. 

> (2)  Especially with respect to the history of Lingo, "multiple" ways of
> doing things, when they include more "concise" (read: obtuse) ways of
> doing, virtually guarantee that pretty much every single reference on the
> subject will reference FIRST the obtuse way (if not ONLY the obtuse way).

In the case of Lingo, you're right (so long as you consider xTalk syntax
less "obtuse" than dot syntax); but this was Macromedia's decision - they
felt that it was more important to migrate the language towards a
Javascript-like DOM, and so they promoted what they considered to be the
"better" version of the terms (dot syntax) which people coming from a
Javascript environment would be comfortable with. They apparently considered
the verbosity of xTalk to be not as attractive as dot syntax.

But that was *their* decision. And whether or not you or I agree with it, as
long as RunRev sticks with the "verbose" approach as the primary promoted
approach, I don't think that have alternative implementations will have them
end up the way Lingo did.

> It's not that I am a completely retarded idiot and cannot understand x =
> 5, but I have read the multiple writings on the wall with respect to
> "options" that ultimately aren't and overtake the "standard"/verbose ways
> of doing things.

And if RunRev added stuff that was more "concise" (like x=5) and decided
that this was the preferred method instead of the verbose one, you (and many
of us) would have every right to whack 'em on the nose with a newspaper. :-)

> If I wanted to learn C, I just would.  But I don't.

Believe me, I don't want to learn C either, but adding an option of "x=5"
instead of "put 5 into x" doesn't turn Rev into C... but of course you
already know that. ;-)

In any event, as I mentioned before, this discussion is moot as RunRev
doesn't monitor the list for suggestions, so if there's an enhancement
request for this in Bugzilla, we should all feel free to post our opinions
there so that when and if RunRev *does* choose to look at this, they will
know how we all feel.


Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com