Mark
You are a big Tease.
Lagi
On 24 May 2017 at 13:13, Mark Waddingham via use-livecode <
use-livecode@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 ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
