Keyword Spelling Consistency

[LCMark]

I also prefer fewer options. I believe having too many options can actually make it more difficult to learn a language, since it raises expectations for some tokens that can't be met by others. Learn one, use it, move on.

After 25 years of habits, if you take my abbreviations away I'll scream.

Slight case of cognitive dissonance there @FourthWorld?

I remember suggesting many years ago the prospect of removing abbreviations (such as btn etc.) on the improve-list (as it was then) - it was a contentious suggestion then, and I suspect still will be today amongst our existing user-base.

And if you can quantify the speed difference for disallowing my well worn habits my screaming will be that much shorter.

The reason for removing abbreviations would not be to do with speed, just language cleanliness... Indeed, I can pretty much guarantee that had they never been there in the first place, no-one would have suggested adding them.

There's no real issue with supporting abbreviations in the new parser, it's more a case of whether they are something which should be phased out.

If the main purpose of abbreviations is to accelerate script input then a better solution would perhaps be a configurable set of auto-expansions at the script editor level.

Anyway, I was mainly just throwing the suggestion out there again to see what the reaction would be - I must confess I'd probably find it somewhat jarring to not be able to type 'the rect of tControl' anymore (although I'd no doubt get used to it); and we can't really justify removing some abbreviations and not others - I think it would have to be either all or nothing.

[FourthWorld]

I also prefer fewer options. I believe having too many options can actually make it more difficult to learn a language, since it raises expectations for some tokens that can't be met by others. Learn one, use it, move on.

After 25 years of habits, if you take my abbreviations away I'll scream.

Slight case of cognitive dissonance there @FourthWorld?

If you think humans aren't complex you've been spending too much time with machines.

I didn't say I recommend abbreviations, only that it's become my habit to use them.

If the main purpose of abbreviations is to accelerate script input then a better solution would perhaps be a configurable set of auto-expansions at the script editor level.

Agreed.

Since we're talking about streamlining for consistency, do you have an opinion about allowing "the" to be used for some function calls but not others?

[LCMark]

If you think humans aren't complex you've been spending too much time with machines.

Hehe - it just made me smile. I can't really comment too much - I'm completely consistent with everything, except when I'm not

I didn't say I recommend abbreviations, only that it's become my habit to use them.

I suspect that's true of everyone who uses them - thus if we can provide a more configurable solution (at a more appropriate level) that serves the same purpose, I don't think we'd get many (if any) complaints.

Since we're talking about streamlining for consistency, do you have an opinion about allowing "the" to be used for some function calls but not others?

I thought you'd have realized by now that I have an opinion about most things (LiveCode-related at least).

At the moment the engine implements some things as properties (parsed in the MCProperty class) - this is true of most global properties. It also implements some things as functions (anything deriving from MCFunction). If a function takes no arguments, or only a single argument it can also be written in property form.

My intention is that with 'clean syntax' there will be only one way to write any particular piece of syntax - and I expect the majority of functions to disappear there, being replaced by more natural English-like syntax.

The main reason the engine has so many functions, rather than nice English-like phrases, is because they are easy to add and don't cause ambiguity problems in the current ad-hoc parser. Given that the new parser is much much more flexible there seems no reason not to try and clean this up as much as possible.

A good example is the recent uuid() addition. I'd quite like to experiment with syntax like:

Code: Select all

  put a random uuid into tUuid
  put the md5 uuid for tName in tNamespace into tUuid

Another example is controlAtLoc() which was added recently. Ideally this would be something like:

Code: Select all

  put the control at tPoint into tControl

An older example is within(). This should really be an operator:

Code: Select all

  if tPoint is within control 3 then answer "yay!"

[mwieder]

Doh! I'd completely forgotten that "rect" was an abbreviation.
Guess I'll have to rethink things now.

[jacque]

If you remove abbreviations I'll kill myself and make you pay for the funeral. I haven't typed whole object names in 25 years.

All my stacks will break. <sob>

[monte]

lol... the idea is that the scripts would be automatically elongated both when you upgrade a stack to the new parser for the first time and when you are typing abbreviations... but hey if Jacque will kill herself then I'm out.... who would eat my sandwiches?

[monte]

Don't forget the abbreviations in commands...

Code: Select all

lock screen for visual effect in rect theRect

[FourthWorld]

Doh! I'd completely forgotten that "rect" was an abbreviation.
Guess I'll have to rethink things now.

Me too. My hands simply won't type "rectangle". If the IDE did it for me it might help, but on further consideration there's value in going back to a script and reading it as you typed it, rather than as the IDE may have rewritten it.

If there was a compelling performance boost I'd say let's do it, but in the absence of that I'm inclined to favor my own habits. Sure, I recognize that it's both selfish of me and only furthers my own "cognitive dissonance" <g>, but hey, at least I'm being honest here. I'm willing to admit that addiction to abbrev. is a shortcoming, but also that it's a shortcoming I don't mind having.

As we move forward toward ever more English-like syntax, as much as I like the idea I must admit I also find myself somewhat cautious. With programming, we're dealing with a very specialized form of communication, since rather than talking to the rich intelligence of a human we're merely issuing instructions to a machine too stupid to count past 1. Given the cognitive limitations of computers, we need to be very explicit in how we talk to them, and inevitably wind up with powerful but non-English like expressions like:

Code: Select all

put SomeFunction(tArray[1][2]) into tMyVar

That's pretty crappy as far as English goes, but wonderfully explicit and concise for talking to a computer.

Moving forward with the "English-like" mandate, I believe we may want to remain mindful of the limitations inherent in such a mandate, being careful not to raise expectations that ultimately can't be met without making the language as cumbersome and prone to misunderstandings as English usage among humans.

Sure, programming languages require a learning curve, and perhaps LiveCode will never completely be an exception to that.

But as I've taught xTalk over the years, the thing that really stands out for aiding learnability the most turns out not to be the syntax per se as much as the integration of the language with the GUI object model.

Most languages treat GUI objects as an afterthought, grafting them in after the core language is defined, to arrive at a system in which the core language and making GUI apps with it are conceptually disjointed.

With all xTalks, the most powerful beauty is that GUI elements are deeply integrated with the language at its deepest level. And since the message and property inheritance tends to follow the flow of object layers as they appear visually on screen, it's all just that more powerfully learnable.

So I suppose as I spend more time thinking about this, I would suggest we step back from the syntax-as-text and think instead about the whole context of the language, object model and all. In such a birds-eye-view I think we'll discover the strongest element of LiveCode's learnability, which I believe is a much bigger contribution than just the English-like syntax alone.

[mwieder]

The thing I like about the "angle" part of "rectangle" is that it uses alternate-hand keystrokes on the keyboard. I find that words that do that are easier to type and less error-prone than ones that make me find consecutive keys with the same hand.

That said, I still prefer typing "rect" to "rectangle", even though my left hand ties itself in knots typing the word.

[mwieder]

put SomeFunction(tArray[1][2]) into tMyVar

@Richard- I'm hoping we can arrive at a syntax for arrays something like

Code: Select all

-- given tEmployee["id"]["name"]
put the name of tEmployee tIDNum into tMyVar

instead of

Code: Select all

put tEmployees["id"]["name"] into tMyVar

[jacque]

lol... the idea is that the scripts would be automatically elongated both when you upgrade a stack to the new parser for the first time and when you are typing abbreviations... but hey if Jacque will kill herself then I'm out.... who would eat my sandwiches?

Who would MAKE your sandwiches?

Sudo parse abbreviation.

[mwieder]

Makefile:

Code: Select all

sandwiches:
    call Jacque

[monte]

both make and eat

[monte]

It is kind of amusing that we have this ridiculously verbose language that's sold as english like and in order to use it efficiently we need to shorten our keywords to the point that a statement then becomes just a long illegible phrase unless you know the language... no better than the short illegible phrases from other languages with the disadvantage you need to type more...

Lately I've been trying to force myself to stop using abbreviations to improve readability and maintainability... admittedly I never really thought of rect as one which of course it is...

[LCMark]

It is kind of amusing that we have this ridiculously verbose language that's sold as english like and in order to use it efficiently we need to shorten our keywords to the point that a statement then becomes just a long illegible phrase unless you know the language... no better than the short illegible phrases from other languages with the disadvantage you need to type more...

Well, you can write illegible code in any language - i.e. using one or two letter variables and function names - makes it 'quicker' to type, but impossible to decipher later on.

So I think the main thing here is habit and the fact you *think* you are saving yourself time, not need.

Most people who code a lot type quickly (or over time learn to) thus the number of characters you have to type really isn't an issue, more so with LiveCode because there's very little need to use symbols (which are slower to type than letters and numbers - for English keyboards at least).

In the majority of cases, code is (initially) written once but read and modified many times. Indeed, the cost of code ownership quickly skews towards maintenance after a very short time - thus encouraging people to write more readable code in the first place surely isn't too much of a bad thing, is it?

Of course, the other aspect of this is collaboration. Having variant forms of syntax (and abbreviations) mean that it is harder for someone else to read your code and contribute / take over or whatever.

These issues aren't just limited to LiveCode, of course. It's why coding style/standards in native code projects are so important - in this regard, the perfect project to which multiple people contribute is one where (by looking at the code itself) you couldn't tell who had originally wrote it.

Anyway, we have options at the 'Clean Syntax' point, so it's good to discuss how far we should go with it and what's worth doing. I suspect this kind of discussion will rage on for quite a while