I think it is important to remember the following quote:
"There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors."
At the end of the day syntax largely comes down to naming things - it is
really not an easy task at all.
On 2016-03-17 17:51, Richard Gaskin wrote:
In a language that has "playLoudness" to mean "soundVolume", a
"destroyStack" property that doesn't destroy the stack, and "this me",
adopting the world's most common way to express non-equivalence would
seem a shoe-in.
Well "this me" was mine and I make no apologies for it. It is a
relatively 'advanced' feature, and one for which no-one could come up
with a better *implementable* piece of syntax for. I believe at the end
point of the discussion about that particularly piece of syntax was -
this is really really needed by those using chained behaviors in
advanced ways, pretty much all of the potentially 'better' pieces of
syntax were exceptionally hard to shoe-horn into the parser and when we
have Open Language we can look at it again.
The "playLoudness" - I have no idea why that is that - it is a piece of
history we are 'stuck' with for now; just like 'hilite'.
To be fair "destroyStack" should probably be "deleteStack" as the very
used to destroy objects in LiveCode is "delete". I've never been
entirely convinced by the 'purge' argument (as purge generally has a
slightly different sense in computing); but nor have I ever entirely
convinced about the not 'purge' argument. My general feeling has always
been that the documentation just has to be better, and there are some
important concepts which perhaps need to be 'bedded in' more than they
are at the moment (i.e. the strict distinction between stacks and
stackfiles; or things which are in-memory, and those which are on-disk).
Esp. given that "<>" is supported but almost unique to our language,
and "≠" has been suggested by a member of the core dev team to be
elevated from an undocumented convenience for HyperCard ports to a
native token:
<http://lists.runrev.com/pipermail/use-livecode/2016-March/224664.html>
"<>" is certainly not unique to our language. Indeed see here:
https://en.wikipedia.org/wiki/Relational_operator
The use of <> is predominant in Pascal-like and BASIC-like languages.
In regards to Peter's post, he did say "there's no immediately obvious
reason for this" - the key point here is "immediately obvious". There
are good reasons why it does not work on platforms other Mac, and
equally good reasons why we have never tried to make it.
How does one even type "≠" in any keyboard other than a Mac?
Exactly - one of the reasons why it didn't seem worth making it work
cross-platform even when scripts became unicode enabled.
If we were talking about "==" I could understand. The difference
between "=" and "==" in languages that support both accounts for
millions of lost hours for developers and end-users due to accidental
bugs every year.
But "!="? I just don't see the harm. Sometimes accommodating the
rest of the world isn't a bad thing.
Isn't that thoroughly inconsistent though? Why is "!=" special?
If your only experience had been C-like languages, you might also try to
use "==" for equality, and find it doesn't work. At that point you have
to go and review the operators in the docs to see what the LiveCode
language expects.
Also, it is important to remember that *some* operators exist in
LiveCode which have the same names as those in C - for example "," and
"&". Both of these operators do *very* different things in LiveCode. So,
at the end of the day it comes down to the fact that if you are learning
a language then learning its operators is also something you need to do.
At a time when I hope we're all keenly sensitive to the need for
increased adoption, this seems more of a focus on "We're different"
than "We help you get the job done more efficiently".
I'm not sure I see how adding "!=" is going to suddenly open the
flood-gates and see proportionally more users.
At the end of the day it is important that programming languages are
consistent, well defined and well documented. LiveCode does reasonably
well on the first two (indeed it now does a great deal better than it
did from 7+ on the 'well-defined' aspect); it perhaps does not do so
well on the documentation aspect and I do think that the arguments for
adopting operators from other languages (for 'personal taste' reasons -
i.e. yes to "!=" but not "==") are weak in comparison to just ensuring
that the documentation of this important area of all programming
languages is up to scratch.
Indeed, the general discussion internally ended up with the idea that a
Script Editor feature which did an element of 'auto-correct' would be a
far far better way to go. i.e. If you type "==" or "!=" in a place where
"is" or "is not" would work the script editor would tell you - that way
you actively *learn* what the operators are in a natural way; and in a
way which doesn't have some of the problems outlined above.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
