Make LC less verbos

[YogiYang]

Hello,

While developing in LC I feel that it is very Verbos like for example:

Code: Select all

set the text of field "DisplayMessage" to the text of field "EnterMessage"

Instead of this can we write something like this:

Code: Select all

set the field "DisplayMessage".Text to field "EnterMessage".Text

This will really reduce my typing.

TIA

[Klaus]

Hi Yogi,

there have been a LOT of discussion about DOT notation in the past, but this will not happen very soon, if at all, in Livecode!
But you can do this, which is even shorter

Code: Select all

put fld "DisplayMessage" into fld "EnterMessage"

And use abbreviations wherever possible:
cd = card
btn = button
fld = field
sb = scrollbar
grp = group
grc = graphic


Best

Klaus

[shaosean]

You can do a nifty hack to get dot-notation, but it requires you to build a huge backScript to pull it mostly off.. You also lose some of the built-in debugging, as it uses the same feature to allow your backScript to figure out what it's supposed to do.. I lost my code for this, but could probably figure it out again..

[[-hh]]

put fld "D" into fld "E"
(Sorry Klaus)

[Thierry]

put fld 1 into fld 2
(Sorry Hermann)

@YogiYang: avoid this in a complex app; hellish to debug

[Klaus]

Hi friends,

the fields are named "DisplayMessage" and "EnterMessage", which was not my idea, and have the layers 4 and 9, sorry guys!


Best

Klaus

[dunbarx]

I find that typing "conversationally" is faster than "translating" my intentions into any form of shorthand. Of course, this derives from three decades of doing it that way. Abbreviations, like "cd", are already built in to my being, but that is not as important as the "natural" flow of language. It is nice, of course, that LC abbreviations reduce keystrokes.

I have never understood, beyond the fact that certain users have migrated from other languages where such notation is, to them, "natural", why this keeps popping up. And I get that one person's "natural" may not be like another's. But if one embraces LC at all, one must also embrace the local, er, nature.

Craig Newman

[dunbarx]

@YogiYang

The above silliness aside, on a different note, do you understand why Thierry's warning about using numbers as control references might be hellish?

Craig

[YogiYang]

Hi Yogi,

there have been a LOT of discussion about DOT notation in the past, but this will not happen very soon, if at all, in Livecode!
But you can do this, which is even shorter

Code: Select all

put fld "DisplayMessage" into fld "EnterMessage"

And use abbreviations wherever possible:
cd = card
btn = button
fld = field
sb = scrollbar
grp = group
grc = graphic


Best

Klaus

I am not saying that current syntax should be removed. In fact there should be two way to writing code in LC:
1. The current one which is very Verbos
2. The DOT notation one which is definitely less Verbos

Let the developers choose as to what they want to use.

TIA

[Klaus]

I do not decide this, the mothership from Scotland does.

I am only telling you my experiences from my last 18 years with LC,
Revolution and Metacard (the latter are the ancestors of Livecode).

But the developers did not want DOT notation so far...

[FourthWorld]

I had a long discussion about dot notation with LiveCode's CTO, Mark Waddingham. The result was an appreciation I've gained for his earnest stewardship of the LiveCode language. He feels dot notation is not a good fit for the unique flavor of LiveCode, which would not only break from a leaning toward more natural-language expressions where practical, but also dot notation establishes expectations of OOP conventions not supported in the language.

So yes, it means using "of" instead of ".", but over the course of a code base allows for readable code that's almost self-commenting.

In the example you provided above, the difference in typing is 10 characters. Since the long form is 74 characters, the shorter example saves about 13.5%. That might seem like a lot when extrapolated across a code base, but it's limited to statements that set properties so in practice it would likely result in a keystroke savings of maybe in the range of 3-8%, depending on the nature of the code.

When assessing verbosity, it's helpful to consider the code base as a whole, rather than a single statement. While many LiveCode statements are longer than their counterparts in other languages, in many (most?) cases you'll find yourself typing far fewer statements for an equivalent task.

So if the seeming brevity of dot notation might save us as much as 8% across the code base, LiveCode's conveniences like GUI controls as inherent language elements, automatic type coercion and memory management, and others may likely result in a savings well in excess of 20-40%, depending on what the code does and what it's being compared to.

In C++ or Java it's common to see code blocks that are much longer, given the necessity of declaring variable types, manually managing memory, etc. Even in popular scripting languages like Python and JavaScript, being core languages only with no inherent facilities for GUI objects, they need to work with external subsystems to provide an interface (wxWidgets or the browser DOM, respectively), and the code to use those GUI objects is not always (or even often) sparse.

In short, yes, when we isolate single statements LC can appear verbose for some operations.

But when we look at keystrokes-per-application, LiveCode's not bad at all, and often compares favorably.

Moreover, there's the nature of the each programming language itself. Python is white-space-sensitive, which Python programmers enjoy but drives some newcomers crazy. Bash is sparse to an almost insane degree, with a unique way of working quite unlike any other lanugage. JavaScript is typed, but not strictly, and OOP, but not purely. And LiveCode favors readability where practical.

Every language has its own unique strengths and weaknesses. The reason our world has so many is so everyone can enjoy the one that best fits their own set of priorities, and indeed new ones are invented every year for that reason.

If brevity were the only priority we'd all be using bash. Or Perl, famously referred to as the "write-only language.

[shaosean]

If you really really want dot notation, fork the code base and add it in..

[mrcoollion]

I do agree with Mark Waddingham that the code must be easy to learn and understand therefore simulating a normal language with less as possible special characters and structures one needs to memorize.

I would rather see the editor evolve in such a way that for example when I start to type in 'put' it suggests a list of possibilities during typing i can select from and after I type in or select 'fld ' (or field ) it suggest a list of possible field-names on that card I can select from and so on.
That would save me a lot of time and prevents many type errors as well as creating a much shorter learning curve for newbies (like me).

Just my penny worth thoughts.

[bogs]

I would disagree with the need for dot notation myself. Some above have already pointed out that you can easily use abbreviations to shorten the keywords (Klaus), use shorter command formatting (Klaus), or likewise edit the IDE if you really want the dots (shaosean).

Heck, although I am (pretty) sure your names for the fields were examples only, even naming convention would shorten your code further, and I am not talking about the DRASTICALLY shortened examples of "1" and "2" <shuddering at that code reviewing nightmare>, but lets say using "DsplyMsg"(8 char.) over "DisplayMessage"(14 char.), or "EntMsg"(6 char.) over "EnterMessage"(12 char.) almost halves your typing while leaving the names easily decipherable.

My own thinking tends to follow the other comments here, as well, but I would add that you don't need 'dot notation' as much as 'time using the language' to learn to save typing. I think that the language is only as verbose as you want it to be. Even using full names for the different objects instead of the abbreviations, which is a style I use (field instead of fld), I tend to use so many less lines that the typing is reduced from that alone.

Take some more time in learning to use the language, I think you'll find that it is plenty brief.

I would rather see the editor evolve in such a way that for example when I start to type in 'put' it suggests a list of possibilities during typing i can select from and after I type in or select 'fld ' (or field ) it suggest a list of possible field-names on that card I can select from and so on.
That would save me a lot of time and prevents many type errors as well as creating a much shorter learning curve for newbies (like me).

If there is one thing I tend to miss from other languages I've used, this would be it I'm not sure it would create a shorter learning curve, since you would most likely as a new person use it more like a crutch instead of going to find what you need to know, but it sure would save time depending on implementation (seen both good and bad on that one, for instance preferred Delphi 5,6 to VB 5,6 auto-complete). I would guess (although I haven't tried to work it out) that you could write a script that would collect the type and name of objects added into an array, and then insert a drop index of possible values into the editor, but at the point I am now it is above my pay grade

This post required 2741 characters and was very verbose !


** The above ramblings were unsolicited, and as such should be taken with the attention span of a gnat. No warranties or claims expressed or validated. Your mileage may vary. The time is now 5:25 am. If a train is leaving Chicago at 2 pm...

[Klaus]

...The time is now 5:25 am. If a train is leaving Chicago at 2 pm...

How old is the engine driver? 47!