Verbosity and Lines of code

[Richard Gaskin]

Lagi Pittas wrote:

 > I Can't understand this fixation with how many characters typed.

This is part of a statement: It's
This is part of a statement: not
This is part of a statement: so
This is part of a statement: much
This is part of a statement: about
This is part of a statement: the
This is part of a statement: typing
This is part of a statement: as
This is part of a statement: it
This is part of a statement: is
This is part of a statement: about
This is part of a statement: clarity

There is content, and then there is syntactic sugar.  Whether that sugar 
is sweet or merely noise may be subjective, but I believe it's useful 
(and apparently entertaining for some of us here <g>) to at least 
discuss it where it may pertain to new contexts.

The with-the-grain method for passing name-value pairs as a param in 
LiveCode is to use an array, and arrays often need to be loaded with 
blocks of code in which each line assigns one value to one key.

The example above is an English-like way to communicate with humans 
using a similar pattern.  What we have is ultimately a single 
expression, but when we load each meaningful part of the expression in a 
separate statement filled with repetitive sugar the extra typing is less 
cumbersome over time than the extra reading.

For small things it matters little.  And as I wrote before, the robust 
performance of arrays makes them quite suitable for me in cases where I 
need named args; the absence of a more concise method of expressing 
those has never stopped me from shipping anything.

But it's not like the languages which have adopted name-value pairs are 
all made by dummies. There's probably a reason so many languages support 
them. Seems worthwhile at least exploring what those reasons might be.

Even if a language pattern isn't appropriate for LiveCode (and let me 
please reiterate that AFAIK Mark Waddingham has already made it clear he 
doesn't feel named params are worth pursuing in the engine for the 
foreseeable future), such discussions may help inspire useful scripted 
solutions, or perhaps lead to other things that may indeed be worth 
pursuing in the engine.


One of the best LiveCode conference sessions I ever attended had nothing 
to do with LiveCode - it was about everything else, about things NOT in 
LiveCode.

At the RevLive conference in Vegas a few yeas back, Robert Cailliau's
opening keynote covered some of the most adventurous feature requests
I've ever heard anyone suggest for xTalks.

Here's one example (I'd love it if he could post his slide deck from 
that talk; there were many great gems in it): named control structures.

This would allow us to exit a specific loop when loops are nested.

I can't recall the specifics of his proposed syntax, but I remember
being impressed by how natural it seemed. Maybe it was along the lines of:

   repeat with i = 1 to tSomething named "MySomethingLoop"
     repeat with j = 1 to tSomethingElse named "MyOtherLoop"
       DoSomethingWith i,j
       exit "MySomethingLoop"
     end repeat
   end repeat



While there's very little functional similarity between any programming 
language and any natural language, the good examples of each have one 
thing in common:  they continually evolve to meet changing needs.

The working vocabulary of 15th century England would be no more 
satisfying for modern humans to express themselves than for today's 
LiveCoders to limit their language to HyerTalk.

If we stayed true to the roots of the mother tongue, we wouldn't have:
- Arrays
- Binary file I/O
- Sockets
- Bitwise operators
- BinaryConvert
- BaseConvert
- StdIn/StdOut
- Encryption
- Hashing
- Scrollbars
- Anything related to mobile
...and a whole lot more.

Many of those would have been far too geeky for an authoring system 
delivered in 1987.

But for a professional programming environment in 2017 they're essential.

Arrays are a particularly good example in this discussion because not 
only were they completely absent from all versions of HyperCard, 
SuperCard, and OMO, but their syntax is notably not at all English-like 
(who talks in brackets?), following patterns already in common use 
throughout much of the programming world.

In The xTalk Way, we might use:

    put "SomeVal" into bucket "SomeLabel" of array tArray

...rather than the more concise form we enjoy today:

    put "SomeVal" into tArray["SomeLabel"]

Again, the few extra characters doesn't matter much when typing as much 
as it matters for reading.

Sometimes setting aside at least some of the syntactic sugar now and 
then to let the distinguishing content become more readily self-evident 
can be a good trade-off.

Not always, of course.

And that's why we have discussions like this one.

Not every feature of every language is worth implementing.  But most are 
probably worth learning from.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com