Keyword Spelling Consistency

[LCMark]

@FourthWorld:

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.

This is why I never use the phrase 'natural language', and always emphasise the 'like' in 'English-like'. We are not aiming to produce a natural language system. What we are aiming to produce is a system where you can tailor syntax to problem domains so that you don't have to use forms that are convenient for a computer but not for us.

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.

Well, most languages are designed to be general and do nothing until you write libraries and such to access functionality. They provide a (minimal) generalised syntax which means you can easily add such functionality, but you cannot influence the syntax to help express the functionality's use. Indeed, where we are moving towards is actually a more traditional model in this regard - the core of the engine will do nothing that has any outward effect - it will be the arbiter of the modules that can actually do something. Of course the key difference here is that each of those modules will be able to define their language environment - i.e. describe how the functionality they provide should be accessed in a much richer way then function/dot type notation.

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.

Right - this is precisely an example of what I said above: the reason xTalks are good at GUI manipulation is because the syntax for manipulating the GUI object model is tailored precisely to that purpose. (The actual GUI object model that LiveCode has isn't all that dissimilar from any other GUI framework - you just get to 'talk' to it more naturally).

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.

It's easy to get lost in specific syntax discussions as you say and miss the wider picture. However, I guess my point in the ramblings above is this: what the problem domain is doesn't matter (whether it be statistics, GUIs, industrial process control etc.), the key is the ability to be able to tailor the syntax of the language to fit the domain you are working within; otherwise, you could have an amazing object model, but it would still be difficult to use because the channel of communication we have to it (as programmers) has to be funnelled through language that serves the computer, not the human.

[FourthWorld]

It's easy to get lost in specific syntax discussions as you say and miss the wider picture. However, I guess my point in the ramblings above is this: what the problem domain is doesn't matter (whether it be statistics, GUIs, industrial process control etc.), the key is the ability to be able to tailor the syntax of the language to fit the domain you are working within; otherwise, you could have an amazing object model, but it would still be difficult to use because the channel of communication we have to it (as programmers) has to be funnelled through language that serves the computer, not the human.

Well said.

So well said, in fact, that it makes me miss having the opportunity to spend any social time with you.

We simply must find a way to get you out here to CA again, to enjoy another campfire conversation. Can we pull you away from the compiler long enough to present at MacTech in November? Their CFP just went out.

The prospect of domain-specific languages is very exciting for me. Ken and I have played around with a variety of pre-processed 5GLs based in LC, but it would be ever so nice to be able to design language elements more smoothly, efficiently. At long last, the one language feature I longed for with REBOL will finally arrive in the language I use.

[mwieder]

Well, most languages are designed to be general and do nothing until you write libraries and such to access functionality.

<g> My working definition of programming is "making a language do things it wasn't already designed to do".

[DarScott]

My habit is to avoid abbreviations and weird spellings, except for char. Maybe avoiding is the wrong notion, I'm a touch typist (as qualified by developing arthritis) and typing fld takes longer than typing field.

I sometimes adapt to the style of those around me, but on the use-list I tend to spell out. Except for char. (My code snippets are cryptic enough without some readability help.)

I sometimes stumble over reading abbreviations, except for char.

[LCMark]

I sometimes stumble over reading abbreviations, except for char.

Ahhh! Another abbreviation which I use universally (like 'rect'). In fact, I don't even think of 'char' as meaning 'character' - it is, well, a 'char' (which I guess is true of 'rect' for me, also).

I guess I could propose that we've potentially identified two categories of abbreviations in the language: those that are truncated words to the first syllable (rect, char), and those which are a selection of letters from words (fld, grp, wd etc.)

[FourthWorld]

My habit is to avoid abbreviations and weird spellings, except for char.

Mine is to avoid abbrev. except for char, cd, btn, fld, and abbrev.

[mwieder]

OK - I use both "rect" and "char". They should be actual words, not abbreviations.
An abbreviation is something that doesn't have vowels.

[LCMark]

So... Maybe truncations should stay, but abbreviations should be banished? *ducks again*

[bn]

How about loc and lockLoc?

Kind regards
Bernd

[LCMark]

Perhaps another way to look at this is what do you say (in your head) when reading code to yourself?

When I read 'char', 'loc', 'rect' - I say (in my head) 'char', 'loc' and 'rect', it's how I think of those concepts. However, when I read 'fld', 'cd', 'btn' I don't say 'f-l-d', 'c-d', or 'b-t-n', I say 'field', 'card' and 'button'.

[DarScott]

I like the idea of some rational as to what stays and what doesn't.

I rarely use loc or location, but with upcoming changes, I might. So, either way will work for me.

I actually spell out rectangle. To me, that communicates well.

I imagine that, for many, abbreviations are an important part of the 'talk they love and know. My heart goes out to them. Until I am able to put myself into their shoes, I'm hesitant to have a strong opinion on this. I hope to get over that soon.

[mwieder]

How about loc and lockLoc?

@Bernd- those have vowels, so they're real words.

[DarScott]

How does one pronounce loc? The same as lock? Or actually say "location" when folks are looking over the shoulders?

[mwieder]

@Dar- I treat "lock" as a command, not as a property.
So I use "lock screen" rather than "set the lockScreen to true" or "set the lock of...", while I do say "set the loc of..."

...and yes, I pronounce "loc" the same as "lock". What about it?

[jacque]

I say "loak", not "lock". And I say "kair", not "char" like burning coals, because they're short forms, not replacements.