English Like?

[Mike Kerner]

One of the other things that the xtalk languages have that makes them more
appealing is synonyms (and similarly, abbreviations), which makes it a much
more personalized experience as a writer with fewer mental gymnastics.  I
tend to prefer the longer, more verbose forms when writing.  I will open
file/read from file/write to file/close file even though I could just use
the URL-file form.  I think it reads better, later, when I'm trying to
figure out what I did.  Some people prefer "cd", and I prefer "card".
Think about the different ways to reference a group, or to write a comment.

To Mark's comment on addressing arrays differently, the xTalk way would be
to just add a different way, not change the existing way.  Most of the code
that most of us write will be managed and maintained by one person.  It is
therefore more important to give us more ways to say the same thing so that
we can help our future self understand what we were thinking when we wrote
the original.

On Wed, May 24, 2017 at 8:13 AM, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 2017-05-17 22:41, William Prothero via use-livecode wrote:
>
>> Folks:
>> It can be difficult for long term users of an application to
>> appreciate the “exceptions” to the philosophy of a dev app. I think
>> the livecode community is affected by “familiarity” over clarity
>> sometimes. For years (when Director was a viable dev platform), I had
>> a negative feeling about Hypercard type syntax. I had done some pretty
>> extensive programming in Hypercard and Supercard too. I liked the way
>> Director worked. I liked that it did not insult my intelligence by
>> requiring “put 3 into x” instead of the universal "x=3” syntax that
>> all algebra students lewarn in gradeschool, When Director died, I
>> looked around, held my nose, and jumped to livecode, and now I’m glad
>> I jumped that initial negative barrier. But, I take exception to the
>> many claims that livecode is “english-like” (in spite of the many
>> “english-like” commands), especially if you want to do the advanced
>> work that most of the users do.
>>
>
> Finally getting around to responding to this, as it is something which
> interests me... Specifically, we often hear about how LC's syntax
> 'insults intelligence' or is 'babyish' etc. However, I have to say that
> I've
> never understood *why* really.
>
> The only two reasons I really come up with are:
>
>   1) The 'high-priest' argument: programming languages should use somewhat
> arcane and obscure means of expression so that it limits who would want to
> / can use them.
>
>   2) The 'burnt by limited English-like systems in the past' argument: the
> incorrect association between being 'English-like' syntax wise, and not
> being a full, general, programming environment (the point here being the
> limits are in the implementations, not in the concept).
>
> I'd be really quite interested to know what other people think here.
>
> In particular, the use of 'put X into Y' rather than 'X = Y' comes up
> periodically.
>
> <nit-picky-mathematician>
> The mathematician in me has to point out that the argument that 'X = Y' is
> 'better because we learn it in algebra' is technically erroneous. Algebra
> (and mathematics in general) operates on pure substitution - all values are
> singletons and the *only* thing which is equal to any value, is the value
> itself. Put another way, algebra does not have 'variables' in the sense we
> mean it in computing, 'X = 3' really does mean that X *is* 3, not that it
> should have 3 assigned to it, hence in a mathematical expression you can
> replace every occurrence of X *with* 3. (Modelling computer languages in
> the pure world of mathematics requires a bit of mental leap - what we
> consider a procedure is transformed into a function on the set of all
> possible states of the computer it is running on, rather than as sequential
> actions which occur on a single mutable state). Indeed, many languages
> choose ':=' for assignment and not '=' for this reason (it also means you
> don't have to use '==' for equality, and can use '=' which is a much better
> fit with what we do learn in Algebra).
> </nit-picky-mathematician>
>
> Okay, so back to the point, if one wants a language to be readable and
> easily understandable it needs to be consistent. So, in isolation, perhaps
> have 'X := Y' for assignment might seem more economic. However, LiveCode's
> 'put' command is actually a fair bit more flexible. You can do:
>
>   put X into Y
>   put X after Y
>   put X before Y
>
> So if you have code which does:
>
>   put "foo" after X
>   put X into Y
>   put "bar" before Y
>
> You end up with:
>
>   put "foo" after X
>   Y := X
>   put "bar" before Y
>
> Here you end up having to do mental contortions because the sense of the
> 'before' and 'after' forms are opposite to the assignment (copy) form -
> easy readability vanishes. In particular, put flows from left to right, in
> contrast to the right to leftness of ':='.
>
> Certainly one could replace 'put X into Y' with 'X := Y', and even 'put X
> after Y' with 'X &= Y' - but what about before? 'X =& Y'? e.g.
>
>   X &= "foo"
>   Y := X
>   Y =& "bar"
>
> This looks really quite subtle to me, much easier to miss that one is
> 'append' and the other is 'prepend'.
>
> One thing I think LiveCode does do because of its slightly more verbose
> syntax is that it encourages readability (and as a result perhaps more
> maintainability) in code - something which other languages do not
> directly... Indeed, writing C programs which are readable and maintainable
> can take a great deal of time to learn *how* to do well - the language in
> and of itself doesn't really help you much at all. (That isn't to say it
> isn't possible to write unreadable code in LiveCode, because it clearly is
> - muddy abstractions can cause that as much as the syntax itself, but I'd
> like to think that LiveCode lends itself to more readable code by
> default... As subjective as that might be!)
>
> Of course, LiveCode syntax isn't perfect - it has [] for array access for
> example - it might be nice to be
> able to do:
>
>    put index 3 of tNumericArray into tFoo
>    put the foo of tAssocArray into tBar
>
> Which is perhaps the way I'd suggest the language should go - replacing
> what we currently use symbols (operators) for with 'English-like' forms.
>
> It should be noted in all of this that syntax is just sugar (but don't
> take that as meaning that sugar isn't important - if you forget the sugar
> in recipes you often end up with inedible things). A handler such as:
>
>   command Foo
>     put the long id of control "Foo" into tVar
>     put the backColor of tVar into tVarBackColor
>     set the backColor of char 3 to 5 of field 3 to tVarBackColor
>   end Foo
>
> Could be equivalently written (in a more 'traditional' syntax) as:
>
>   void Foo()
>   {
>      tVar := control("Foo")
>      tVarBackColor := tVar.backColor
>      field(3).char(3, 5).backColor := tVarBackColor
>   }
>
> Indeed, it is my feeling that (if there was value in doing so in the
> future) then a more 'traditional' variant syntax for LiveCode would be a
> better way to go than trying to mix 'English-like' syntax more with
> non-'English-like' syntax - that way you keep consistency within both
> 'syntax worlds', but still allow you to view them in either form. In this
> case it would be critically important to maintain direct 1-1 mappings
> between the two different syntaxes - neither would be more expressible than
> the other. That way, it would be a switch in the editor which form you see,
> thus meaning we wouldn't bifurcate the community in terms of what code
> people could and could not understand. (It should be noted that the
> semantics would be identical, a variant syntax might *look like*
> JavaScript, but it wouldn't actually be JavaScript which has quite
> different rules about how values work and flow).
>
> One of the achievements of the refactor we did (resulting in 7.0) was to
> ensure that there was a complete and clear split between the code which
> parses and dispatches LiveCode syntax, and the implementation of the action
> itself (all LiveCode's implementation of the action of syntax is now held
> in a large collection of C++ functions with well defined prototypes; rather
> than embedded in the VM's abstract syntax nodes). This work is one part of
> making this possible and various parts of the work done for LCB make up
> some other parts. It has gone from being something which could be
> considered a fantasy, into something which could be a reality.
>
> Indeed, at some point that might let us go further - allow LiveCode's full
> functionality to be accessed directly from *other* languages in a manner
> natural to them... This is the reverse of the Infinite LiveCode 'FFI'
> project but the abstract principal is the same - e.g. creating natural
> JavaScript bindings around LiveCode's functionality at the 'syntax action'
> level'. However, that is perhaps a story for another day...
>
> Just my two pence :)
>
> Warmest Regards,
>
> Mark.
>
>
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."