≠ or not equal

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps