Quantcast

English Like?

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

English Like?

Richmond Mathewson via use-livecode
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.

For example, suppose I want to do the very basic task of coding a conditional that test for the name of a card. What I would intuitively expect is:

put the name of this cd into cdName

What I get for cdName is:  Suppose the name of the cd is theName
card “theName”

Ok, now I only want the name, so I do

if word 2 of the name of this cd is “theName” then
  —do my stuff
end if

Nooooo, I don’t get that. First, I need to do:

put word 2 of cdName into cdName
replace quote with “” in cdName
if word 2 of the name of this cd is “theName” then
  —do my stuff, this works
end if

I don’t call this intuitive.  I just spent more time than I should have sorting this out.

So, how should a company supporting a platform deal with this? Macromedia chose a really nice strategy when they added dot syntax, which its users wanted. What they did was implement a flag named “useLegacyCode”  (or something like that). This way the legacy users could just set that flag and couldn’t complain about their apps breaking, and the new apps could be built on a more refined code base.

This could be a strategy for the LiveCode mothership to implement when it becomes desirable to implement new, improved, and different code syntax that may conflict with legacy syntax. There are other non-intuitive oddities like the example I gave above. If livecode wants to embody “english-like” syntax, there could be numerous improvements to help the newby. Conversely, perhaps another language entirely might compile to the same tokens as the current version, but that’s a job for another huge effort.

Just sayin'…..

Regards,
Bill P,

William A. Prothero
http://earthlearningsolution.org/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
Bill,

The solution to your issue is to use the short name version of name.

Marc

On May 17, 2017, at 1:41 PM, William Prothero via use-livecode <[hidden email]<mailto:[hidden email]>> 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.

For example, suppose I want to do the very basic task of coding a conditional that test for the name of a card. What I would intuitively expect is:

put the name of this cd into cdName

What I get for cdName is:  Suppose the name of the cd is theName
card “theName”

Ok, now I only want the name, so I do

if word 2 of the name of this cd is “theName” then
 —do my stuff
end if

Nooooo, I don’t get that. First, I need to do:

put word 2 of cdName into cdName
replace quote with “” in cdName
if word 2 of the name of this cd is “theName” then
 —do my stuff, this works
end if

I don’t call this intuitive.  I just spent more time than I should have sorting this out.

So, how should a company supporting a platform deal with this? Macromedia chose a really nice strategy when they added dot syntax, which its users wanted. What they did was implement a flag named “useLegacyCode”  (or something like that). This way the legacy users could just set that flag and couldn’t complain about their apps breaking, and the new apps could be built on a more refined code base.

This could be a strategy for the LiveCode mothership to implement when it becomes desirable to implement new, improved, and different code syntax that may conflict with legacy syntax. There are other non-intuitive oddities like the example I gave above. If livecode wants to embody “english-like” syntax, there could be numerous improvements to help the newby. Conversely, perhaps another language entirely might compile to the same tokens as the current version, but that’s a job for another huge effort.

Just sayin'…..

Regards,
Bill P,

William A. Prothero
http://earthlearningsolution.org/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

---------------
Marc Siskin
Manager, Modern Language Resource Center
Carnegie Mellon University
[hidden email]<mailto:[hidden email]>



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Richmond Mathewson via use-livecode
William Prothero wrote:

 > 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.

The team seems to share the same feeling; you'll find most references to
"English-like" are historical.

LiveCode is readable, almost to the point of being self-documenting, and
generally quite learnable,

But no language designed for communicating with a machine benefits much
from from attempting to follow Chomsky rules for natural/accidental
languages we use when communicating with humans; very different
cognitive abilities in the listener, very different usage goals, leading
to very different design patterns.

Your specific question is an interesting one in terms of syntax consistency:

 > For example, suppose I want to do the very basic task of coding a
 > conditional that test for the name of a card. What I would intuitively
 > expect is:
 >
 > put the name of this cd into cdName
 >
 > What I get for cdName is:  Suppose the name of the cd is theName
 > card “theName”
 >
 > Ok, now I only want the name, so I do
 >
 > if word 2 of the name of this cd is “theName” then
 >   —do my stuff
 > end if
 >
 > Nooooo, I don’t get that. First, I need to do:
 >
 > put word 2 of cdName into cdName
 > replace quote with “” in cdName
 > if word 2 of the name of this cd is “theName” then
 >   —do my stuff, this works
 > end if
 >
 > I don’t call this intuitive.  I just spent more time than I should
 > have sorting this out.

I'm afraid you'll have to blame the authors of the mother tongue,
HyperTalk, on that one.

Your expectations a perfectly reasonable:  with most properties we ask
for a value and we get that value, without also getting some other
metadata like object type.

Imagine if:

   put the rect of button 1

...returned:

   rectangle "20,20,120,44"

That would be annoying as hell.  And yet with object names that's pretty
much what happens, where we have to add more (an extra keyword) to get less:

   put the name of button 1

...yields:

   button "Bob"

But:

   put the short name of button 1

...yields:

   Bob

Fortunately most properties work as expected, and the anomalous behavior
of the name property (and only a few others) are easily learned and
quite useful.

But posts like yours are VERY helpful for those of us who teach
newcomers.  When we've learned these things too long ago it's easy to
forget they were ever unintuitive at first, which may miss opportunities
for more effective on-boarding.

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
Richard:
Thanks for the kind words. I think that comments by relative newbies, who don’t have the same experience with LC are very important. I’ve mentioned several times that some of the tutorials and lessons can miss things that the author takes for granted. I’m particularly sensitive to this because of my long experience teaching college students having them use my software.

It is very difficult for the developer of the software to avoid making assumptions based on experience and it takes special attention. One organization I worked with did eye-tracking with naive users to validate their web applications. I don’t think that’s needed for livecode, but more attention to this, when publishing teaching documents would be very helpful.

This was a very significant problem with the first course on using LC to make apps that came with the iPhone. I ended up dropping out because I was wasting so much of my time trying to figure out bugs and what should have been in the tutorial. These resources may be the first time a person really gets into Livecode and the kinds of difficulties I encountered could be very off-putting to a new user.

Anyway, I encourage the authors of tutorial software to pay significant attention to learning resources they put out for the public to make sure the learning goes smoothly.

Best,
Bill


>
> But posts like yours are VERY helpful for those of us who teach newcomers.  When we've learned these things too long ago it's easy to forget they were ever unintuitive at first, which may miss opportunities for more effective on-boarding.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Richmond Mathewson via use-livecode
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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
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 <
[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Richmond Mathewson via use-livecode
Mark

You are a big Tease.

Lagi

On 24 May 2017 at 13:13, Mark Waddingham via use-livecode <
[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
On 2017-05-24 14:52, Lagi Pittas via use-livecode wrote:
> Mark
>
> You are a big Tease.

Hehe - I don't mean to be a tease - making correct/good technical
choices as to how things should work under the hood opens up an array of
options for the future. We always try and design things with that in
mind.

The 7 refactor was a large and rather difficult project, the full fruits
of which have yet to become apparent. I can't say when some of the
things we might like to do might happen, but at least they are possible
now; when they weren't before.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

dunbarx
There is a far more important issue here. New learners are far more likely to be coaxed into continuing to spend the time and effort, and to put away their fears, if they see and use "put x into y". It is why we have stacks and cards, and in the olden days, rolodexes. The original HC team did all that on purpose.

Remember "for the rest of us"?

Experienced users are being academic and pedantic to raise this issue as if it were something important. We need new users, not old ones.

No offense, please.

Craig Newman
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
That is certainly true.  The approachability of the language is the hook
that got me hooked, even though HC was my...8th?  9th?  15th? language.
For beginners, we should be asking what else we can do to make their life
easier.  Community is free and it gets you in, but you can't build even the
simplest ios app without paying apple and then fighting through all of the
other things you have to do to get the app built and on your device just so
you can play with it.  That would be a nifty service to provide for
learning.  The n00b would have to upload their stack, and the ID of the one
device they want to mess with it on.  Hmm......

On Wed, May 24, 2017 at 9:45 AM, dunbarx via use-livecode <
[hidden email]> wrote:

> There is a far more important issue here. New learners are far more likely
> to
> be coaxed into continuing to spend the time and effort, and to put away
> their fears, if they see and use "put x into y". It is why we have stacks
> and cards, and in the olden days, rolodexes. The original HC team did all
> that on purpose.
>
> Remember "for the rest of us"?
>
> Experienced users are being academic and pedantic to raise this issue as if
> it were something important. We need new users, not old ones.
>
> No offense, please.
>
> Craig Newman
>
>
>
> --
> View this message in context: http://runtime-revolution.2783
> 05.n4.nabble.com/English-Like-tp4714951p4715143.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
The problem with this idea is the need to register the device through
apple's developer portal, but I wonder if testFlight could be leveraged to
make that work.  TestFlight apps are time-limited, so that takes care of
that problem...

On Wed, May 24, 2017 at 10:13 AM, Mike Kerner <[hidden email]>
wrote:

> That is certainly true.  The approachability of the language is the hook
> that got me hooked, even though HC was my...8th?  9th?  15th? language.
> For beginners, we should be asking what else we can do to make their life
> easier.  Community is free and it gets you in, but you can't build even the
> simplest ios app without paying apple and then fighting through all of the
> other things you have to do to get the app built and on your device just so
> you can play with it.  That would be a nifty service to provide for
> learning.  The n00b would have to upload their stack, and the ID of the one
> device they want to mess with it on.  Hmm......
>
> On Wed, May 24, 2017 at 9:45 AM, dunbarx via use-livecode <
> [hidden email]> wrote:
>
>> There is a far more important issue here. New learners are far more
>> likely to
>> be coaxed into continuing to spend the time and effort, and to put away
>> their fears, if they see and use "put x into y". It is why we have stacks
>> and cards, and in the olden days, rolodexes. The original HC team did all
>> that on purpose.
>>
>> Remember "for the rest of us"?
>>
>> Experienced users are being academic and pedantic to raise this issue as
>> if
>> it were something important. We need new users, not old ones.
>>
>> No offense, please.
>>
>> Craig Newman
>>
>>
>>
>> --
>> View this message in context: http://runtime-revolution.2783
>> 05.n4.nabble.com/English-Like-tp4714951p4715143.html
>> Sent from the Revolution - User mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> 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."
>



--
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."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by dunbarx
On 2017-05-24 15:45, dunbarx via use-livecode wrote:
> There is a far more important issue here. New learners are far more
> likely to
> be coaxed into continuing to spend the time and effort, and to put away
> their fears, if they see and use "put x into y". It is why we have
> stacks
> and cards, and in the olden days, rolodexes. The original HC team did
> all
> that on purpose.

Which 'new learners'? I can absolutely assure you there is no homogenous
group there.

At one point after years of collecting surveys and analysing data we
managed to divide up users and non-users into 7 (or thereabouts)
distinct groups. Recently, taking a slightly different approach we have
reduced this to 3 (7 was too fine-grained to actually be able to do much
with, 3 is more manageable and seems to work much better in terms of
targetting).

Why have we done this - because we need to actually *sell* LiveCode -
nothing sells itself. Market segmentation and understanding your users
and potential users is perhaps the most significant piece of selling.

( Okay, that's my marketing brain cell exhausted for a while ;) ).

It is quite possibly true that as many people get put off by LiveCode
because of its 'English-like' language, who get sucked in because of it.
We have to concede that point - if it weren't (at least in some part)
true we wouldn't hear such phrases as 'babyish' and 'insult to
intelligence' that are often heard about xTalks (and LiveCode in
particular).

(Btw, @WilliamProthero: Please don't think I'm singling your comments
out or taking offense by them - you echo words I have heard many times -
as have all of us I suspect when we get asked by some - 'so what's
LiveCode like').

> Remember "for the rest of us"?
>
> Experienced users are being academic and pedantic to raise this issue
> as if
> it were something important. We need new users, not old ones.
>
> No offence, please.

No offence taken - it is a discussion :)

However, it is important to realize that whilst it is not important to
you (I get you are quite invested in LCS - as am I, much more than is
ever apparent at times), it *is* important to others (otherwise we
wouldn't get some comments about the language that we do).

Syntax is an emotive issue (I could beat Python to death with some of
the decisions they have made about syntax - but yet I still use it and
slightly enjoy doing so for the purposes I use it for) - but it is not
the be-all-and-end-all.

I mentioned in my last post about the 'high priest' mentality - let us
not risk falling into the same mentality but in reverse. The time for
being an island in our own right passed with the passing of HyperCard. I
think it is fair to say that, these days the world of computing is
inordinately larger and much more diverse (look at the rise in the
HTML/JavaScript world for just one example). There is huge value in
being 'maverick', but it perhaps makes things much harder than they
would be otherwise.

In reality the scripting language LiveCode has, whilst one of its
greatest strengths IMHO (otherwise I can quite honestly say I wouldn't
be here), is only one part of the ecosystem:

   - we have an interactive IDE which allows to edit and run code 'live'
(for some definition of live)

   - we have a large GUI framework

   - we have large collections of libraries (script, externals, LCB) all
giving high-level access to new
     features

   - in order to build and maintain LiveCode we have a large
infrastructure which allows us to build
     on 7 different platforms.

Furthermore, we all want more features - we all want LiveCode to do
everything in a way commensurate with how LiveCode 'is'. However, the
breadth of knowledge that requires is immense - we do quite well as a
team, sitting here (mostly in Scotland), we also do well as a (small, in
the grand scheme of things) global community. Our current solution to
help achieve this 'doing everything goal' is LCB and expanding its FFI
capabilities - but that is a tool - it still needs knowledge and a great
deal of effort to use.

We need to attract people from other worlds, and as many as possible -
in there heads lies so much knowledge about how to use the concrete
things which do exist in other language ecosystems (whether it be
JavaScript libraries, Java libraries, C# libraries, ActiveX widgets, the
list goes on and on) it seems quite sensible to ensure that we can fold
that knowledge into our own so we can benefit from all that currently
exists, and not just what a team of a few can generate, or a small
community can generate.

Pre-7 what I suggested in my previous email was just not possible (in
terms of a different syntax style) - or, should I say, the cost of
attempting to do it would be far in excess of its potential benefit at
the time. However, the main part of the refactor is done, we are in a
very different situation technically - perhaps it really is something to
seriously consider *if* the cost of doing so pales in comparison to the
growth it could engender in terms of the reach of LiveCode.

I think a lot of us get hung up on the syntax (even me - who will always
be quick to point out that 'syntax is just sugar' in many situations -
I'm a polyglot when it comes to programming languages but many people
are not and never will be). I can certainly say that whilst I am in the
position I am in, I will not see LiveCode Script become some sort of
syntactic mongrel (indeed the places where it is slightly 'mongrelic', I
would quite like to have alternative non-mongrel forms much more in
keeping with the language as a whole). However, again, there is more to
LiveCode than just the syntax of the language.

Anyway, I shall now get off my (small?) soap-box. Again this is a
discussion, there are lots of reasons why people don't choose LiveCode
and we try our very best to determine them, and deal with them. There
are certainly easier ones to tackle than adding a new 'syntax style' and
of course we intend to address those first...

However, let us imagine that we were able to demonstrate that a
significant proportion of people who might use LiveCode end up not doing
so because of the language itself, and *if* the language had a different
syntactic style then we would have significantly more users... Then
surely it is worthy of some discussion and consideration?

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Richmond Mathewson via use-livecode
Ok,ok, I hear y'all about the approachability of the htalk language. I do know that when we get familiar with an intellectual construct, we tend to give validity to information or attitudes that agree with that construct. Confirmation bias seemed to be a huge factor in news "facts" acceptance in the recent US election, as well.

As to the subject at hand, experienced programmers are going to favor constructs they are already familiar with. It will not be possible to settle the question of whether using x=3 or put 3 into x is more logical using this audience. In addition, the question is ill-posed. One question is whether programmers experienced in other high level languages would find livecode an attractive option for their work. Or conversely, would people new to coding find htalk easy and intuitive? These are two different questions and a rigorous answer will most likely not come from knowledgeable livecode programmers. No insult is intended, as I accept that I am guilty of the same bias.

In my humble opinion, the proof is in the pudding. What can I build with this application and how easy will it be to build what I want? I may prefer other syntaxes, but what the heck? As long as I can find what I need to make what I want, and have this fantastic array of users who help me out, I'm a very happy camper. So, for a bottom line, I really don't give a hoot about the "put 3 into x" syntax as long as I can build what I want. My initial posting was to comment that a LOT of the syntax for important operations is neither English-like, nor intuitive.

The reason I moved to Livecode was its capabilities, multiple platform deployment, but mostly the potential of the development team and the dynamic way they are improving the product and keeping up as technology continues to evolve. The refactoring of a very mature code base was a very positive development, in my view. The responsiveness and engagement of the development team is another huge positive for me.

One of the sayings among academic departments is that "the battles are so fierce because the stakes are so small". The discussion is fun and interesting, but ....... maybe less important.

Off to breakfast on a foggy Santa Barbara morning.

Best,
Bill P

William Prothero
http://es.earthednet.org

> On May 24, 2017, at 7:13 AM, Mike Kerner via use-livecode <[hidden email]> wrote:
>
> That is certainly true.  The approachability of the language is the hook
> that got me hooked, even though HC was my...8th?  9th?  15th? language.
> For beginners, we should be asking what else we can do to make their life
> easier.  Community is free and it gets you in, but you can't build even the
> simplest ios app without paying apple and then fighting through all of the
> other things you have to do to get the app built and on your device just so
> you can play with it.  That would be a nifty service to provide for
> learning.  The n00b would have to upload their stack, and the ID of the one
> device they want to mess with it on.  Hmm......
>
> On Wed, May 24, 2017 at 9:45 AM, dunbarx via use-livecode <
> [hidden email]> wrote:
>
>> There is a far more important issue here. New learners are far more likely
>> to
>> be coaxed into continuing to spend the time and effort, and to put away
>> their fears, if they see and use "put x into y". It is why we have stacks
>> and cards, and in the olden days, rolodexes. The original HC team did all
>> that on purpose.
>>
>> Remember "for the rest of us"?
>>
>> Experienced users are being academic and pedantic to raise this issue as if
>> it were something important. We need new users, not old ones.
>>
>> No offense, please.
>>
>> Craig Newman
>>
>>
>>
>> --
>> View this message in context: http://runtime-revolution.2783
>> 05.n4.nabble.com/English-Like-tp4714951p4715143.html
>> Sent from the Revolution - User mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> 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."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Martin Koob
In reply to this post by Richmond Mathewson via use-livecode
I agree that LiveCode script should become more English like as time goes on not only with english words but also with more natural(or intuitive) grammar.

From your examples I think it would be more natural to type.

   put the third index of tNumericArray into tFoo

OR

    put the backColor of control "foo" into tVarBackColor

(in this example have the engine know it has to get the long id of control "foo" to access the backColor than for the programmer to remember to assign it first.)

Often when I am typing a script and I am not sure how to do it I wing it first to see if what I intuitively write will work.   If that fails then go to the dictionary or then forums.  

One example is the following.

I wanted a button in a group to access a property of the group so I typed.

   put the width of this group into tWidth.

When I apply that in the script editor it shows no errors but when I run it it stops with the following error:

 (Chunk: can't find background)

The above line would work if I used card or stack instead of group.  In this case I had to put.

   put the width of the owner of me into tWidth

So that is grammatically English but not the way I intuitively thought of it and the sentence is a little unnatural.

I can fake a more natural sentence using a function to hide the way of accessing the group to get it to read better.

   put the width of this_Group() into tGroupWidth

   function this_Group
      return the owner of me
   end this_Group

It would be nice if this is the direction of the language.

My nickel's* worth.  

* in Canada we ditched the penny a couple of years ago so every purchase is rounded to the nearest nickel. :-)

Martin

Mark Waddingham via use-livecode wrote
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


Just my two pence :)

Warmest Regards,

Mark.



--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Richmond Mathewson via use-livecode
On Wed, May 24, 2017 at 11:03 AM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2017-05-24 15:45, dunbarx via use-livecode wrote:
>
>> There is a far more important issue here. New learners are far more
>> likely to
>> be coaxed into continuing to spend the time and effort, and to put away
>> their fears, if they see and use "put x into y". It is why we have stacks
>> and cards, and in the olden days, rolodexes. The original HC team did all
>> that on purpose.
>>
>
>
> I think a lot of us get hung up on the syntax (even me - who will always
> be quick to point out that 'syntax is just sugar' in many situations - I'm
> a polyglot when it comes to programming languages but many people are not
> and never will be). I can certainly say that whilst I am in the position I
> am in, I will not see LiveCode Script become some sort of syntactic mongrel
> (indeed the places where it is slightly 'mongrelic', I would quite like to
> have alternative non-mongrel forms much more in keeping with the language
> as a whole). However, again, there is more to LiveCode than just the syntax
> of the language.
>
> Anyway, I shall now get off my (small?) soap-box. Again this is a
> discussion, there are lots of reasons why people don't choose LiveCode and
> we try our very best to determine them, and deal with them. There are
> certainly easier ones to tackle than adding a new 'syntax style' and of
> course we intend to address those first...
>
> However, let us imagine that we were able to demonstrate that a
> significant proportion of people who might use LiveCode end up not doing so
> because of the language itself, and *if* the language had a different
> syntactic style then we would have significantly more users... Then surely
> it is worthy of some discussion and consideration?
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>

Firstly, THANK YOU for standing on that small soap-box, Mark.  LC and it's
English-likeness is well worth defending, IMHO.  I wouldn't be here if it
were too much more like 'standard' programming languages.  The great thing
about LC for those who prefer the more arcane syntax is they can fork it
and make it their own.  Yay OSS!

~Roger
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Richmond Mathewson via use-livecode


On 5/24/17 6:19 pm, prothero--- via use-livecode wrote:
> Ok,ok, I hear y'all about the approachability of the htalk language. I do know that when we get familiar with an intellectual construct, we tend to give validity to information or attitudes that agree with that construct. Confirmation bias seemed to be a huge factor in news "facts" acceptance in the recent US election, as well.
>
> As to the subject at hand, experienced programmers are going to favor constructs they are already familiar with.

Yup: but that is has no more objective validity than people from the
British Isles favoUring different spelling conventions.

Whether someone spells the word "quha" or "who" is, ultimately neither
here nor there. If I were ti hire a computer programmer to do a job
I would be concerned whether that programmer could produce a finished
product for me that looked and functioned the way I wanted
it to: I really wouldn't give a tuppeny toss which language/development
environment s/he used to achieve that.

>   It will not be possible to settle the question of whether using x=3 or put 3 into x is more logical using this audience. In addition, the question is ill-posed.
This question is about a matter of taste, not logic, and those who think
that it refers to logic are unaware of how they have let
themselves be lulled into accepting one way of doing things as "the
logical way".

> One question is whether programmers experienced in other high level languages would find livecode an attractive option for their work.

Probably most of those programmers (like many well-established LiveCode
programmers) have invested so much time and effort
in learning the high level language(s) they already use that they are
unlikely to switch.

> Or conversely, would people new to coding find htalk easy and intuitive?

 From a marketing point of view I believe that this question is more
pressing than the other one, just because people new to coding have not
got stuck in the groove of a particulalr programming language.

The other day I revived my BBC Master Compact that I bought in 1989 and
started doing some programming on it and was both surprised and
enlightened that I took quite some time to get up to speed after some 27
years not touching BBC BASIC.

Surprised because I had not realised how much the "LiveCode way" had
permeated my way of doing things.

Enlightened because I began to remember what life was like before
HyperCard, Graphic User Interfaces and all the stuff we now all
too readily take for granted with computers.

I'm trying to get a FORTRAN IV ROM chip to install in my BBC . . . .
>   These are two different questions and a rigorous answer will most likely not come from knowledgeable livecode programmers. No insult is intended, as I accept that I am guilty of the same bias.
>
> In my humble opinion, the proof is in the pudding.

Indeed: and different people like different puddings.

What does need to be born in mind is that most of LiveCode's installed
user-base like their pudding the way LiveCode serves,
and changing the recipe to attract other people might only serve to
alienate current users rather than attarct others;
probably not worth the risk.

For those who like salt in their porridge there's LiveCode, and for
those who prefer sugar, or syrup, or prunes in their porridge
there are other puddings on offer.

When I started my EFL school in Bulgaria 12 years ago I was "up against"
4 major 'factory' EFL schools, and people were telling me all sorts
of "good" advice as to how I should drive them out of business and
become "Mr English" in the town. I didn't listen.

My school now runs at exactly the size I want it to; those 'factories'
still run. Nobody, as far as I can tell, feels threatened by my operation,
and I don't feel threatened by them. This is because, although we all
"sell" English as a Foreign Language, we do it in different ways; and
the children who come to my school are quite unlike those who go to the
other ones (which suits me 100%). There is room in the
multiverse of EFL for a variety of products.

>   What can I build with this application and how easy will it be to build what I want? I may prefer other syntaxes, but what the heck?

Well, there are probably nearly as many variables to be weighed up as
there are potential LiveCode programmers; here's one more:

1. Can I afford the necessary time needed to get reasonably competent at
programming in LiveCode and will that be justifiable
    when I can develop my next-big-thing in language X that I already know?

>   As long as I can find what I need to make what I want, and have this fantastic array of users who help me out, I'm a very happy camper. So, for a bottom line, I really don't give a hoot about the "put 3 into x" syntax as long as I can build what I want. My initial posting was to comment that a LOT of the syntax for important operations is neither English-like, nor intuitive.

No: a lot of the syntax isn't English-like, and the claims that have
been flying around about that ever since HyperCard seem almost
as crook as the "programming is easy" porky.

"Intuitive" . . . ha, ha, ha. Human languages are not intuitive:
otherwise we'd all be learning a new language every 3 or 4 weeks
and the Tower of Babel wouldn't look like Trump Tower!
>
> The reason I moved to Livecode was its capabilities, multiple platform deployment, but mostly the potential of the development team and the dynamic way they are improving the product and keeping up as technology continues to evolve. The refactoring of a very mature code base was a very positive development, in my view. The responsiveness and engagement of the development team is another huge positive for me.

The reason I moved to HyperCard was that was what came installed on the
Macintosh LC 475 that I bought in Montgomery Ward in 1993.

The reason I moved to LiveCode was that, after getting badly
side-tracked with ToolBook and MacroMedia Director, I discovered MetaCard
by accident and then found that the interface provided by Revolution was
more to my taste.
>
> One of the sayings among academic departments is that "the battles are so fierce because the stakes are so small". The discussion is fun and interesting, but ....... maybe less important.
>
> Off to breakfast on a foggy Santa Barbara morning.

Hope that's fog and not smog!

Richmond.

>
> Best,
> Bill P
>
> William Prothero
> http://es.earthednet.org
>
>> On May 24, 2017, at 7:13 AM, Mike Kerner via use-livecode <[hidden email]> wrote:
>>
>> That is certainly true.  The approachability of the language is the hook
>> that got me hooked, even though HC was my...8th?  9th?  15th? language.
>> For beginners, we should be asking what else we can do to make their life
>> easier.  Community is free and it gets you in, but you can't build even the
>> simplest ios app without paying apple and then fighting through all of the
>> other things you have to do to get the app built and on your device just so
>> you can play with it.  That would be a nifty service to provide for
>> learning.  The n00b would have to upload their stack, and the ID of the one
>> device they want to mess with it on.  Hmm......
>>
>> On Wed, May 24, 2017 at 9:45 AM, dunbarx via use-livecode <
>> [hidden email]> wrote:
>>
>>> There is a far more important issue here. New learners are far more likely
>>> to
>>> be coaxed into continuing to spend the time and effort, and to put away
>>> their fears, if they see and use "put x into y". It is why we have stacks
>>> and cards, and in the olden days, rolodexes. The original HC team did all
>>> that on purpose.
>>>
>>> Remember "for the rest of us"?
>>>
>>> Experienced users are being academic and pedantic to raise this issue as if
>>> it were something important. We need new users, not old ones.
>>>
>>> No offense, please.
>>>
>>> Craig Newman
>>>
>>>
>>>
>>> --
>>> View this message in context: http://runtime-revolution.2783
>>> 05.n4.nabble.com/English-Like-tp4714951p4715143.html
>>> Sent from the Revolution - User mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> 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."
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
Hehe - what an enjoyable post to read - I couldn't resist 'biting'
on a few things though ;)

On 2017-05-24 17:57, Richmond Mathewson via use-livecode wrote:
> Probably most of those programmers (like many well-established
> LiveCode programmers) have invested so much time and effort
> in learning the high level language(s) they already use that they are
> unlikely to switch.

But if we can make them switch, that benefits LiveCode as a whole.

> From a marketing point of view I believe that this question is more
> pressing than the other one, just because people new to coding have
> not got stuck in the groove of a particulalr programming language.

This is partly true - however, 'no man is an island', people develop
preconceptions about things over time which influence the choices in
the future.

I think it would be fair to say there might well be some sort of general
'meme' which floats around with regards to 'English-like' languages
and not necessarily a positive one.

Ergo - someone who has never been a programmer, who perhaps is thinking
of dabbling, might get put off by LiveCode because of its language, just
because they have that 'meme' embedded in that psyche without even
trying
it properly.

> What does need to be born in mind is that most of LiveCode's installed
> user-base like their pudding the way LiveCode serves,
> and changing the recipe to attract other people might only serve to
> alienate current users rather than attarct others;
> probably not worth the risk.

So we must make sure that the 'pudding' our current user-base isn't
diluted in the process. Most companies might start out producing only
one
kind of 'pudding', but if they never diversify they risk ceasing to be
at some
point when some other company produces 'pudding+' which people like
better;
or if they can no longer produce 'pudding' because some 'nanny' decides
that
a key ingredient should not be allowed anymore for the health of all.

Having all your eggs in one basket is a little risky...

> My school now runs at exactly the size I want it to; those 'factories'
> still run. Nobody, as far as I can tell, feels threatened by my
> operation,
> and I don't feel threatened by them. This is because, although we all
> "sell" English as a Foreign Language, we do it in different ways; and
> the children who come to my school are quite unlike those who go to
> the other ones (which suits me 100%). There is room in the
> multiverse of EFL for a variety of products.

It is great that you've reached a 'steady state' with your EFL school :)

However, it is perhaps fair to say that the world of EFL teaching does
not move at quite the same rate as the world of computers, there are
lots
of very large 'pudding behemoths' out there who care not one whit for
small
'pudding' manufacturers - and quite often trample them under foot
without
a moment's thought.

I would also conjecture that the infrastructure requirements for our
particular kind of 'pudding' are somewhat larger than for a single
successful EFL school - and when combined with the fast paced
environment
our 'pudding' is couched in, one needs to be careful that one can
support
one's 'pudding' manufacture now and into the long term future.

> No: a lot of the syntax isn't English-like, and the claims that have
> been flying around about that ever since HyperCard seem almost
> as crook as the "programming is easy" porky.

I agree with the statement that 'programming is easy' in general is a
bit of a porky.

Most things are not easy when you get below a certain depth (kind of a
tautology,
easy things generally being quite shallow in any domain).

However, I am firmly in the belief that many of the reasons why it is
not 'easy'
right now are not because they could not be easier, but because like
most
industries there is a huge inertia with how things are currently done
and
when you are in the midst of doing something, you have to get it done,
and perhaps
thinking about 'how to make it easier' is a distant thought.

In general I'd like to think that LiveCode does make some things easier
than
other languages - and, in general, it is going in the right direction.

<insert tongue into cheek>
In regards to 'English-like' - then well let's just say LiveCode is
'fibbidy-dab'
if 'English-like' is considered too inaccurate. In comparison with
pretty much
ever other programming language which exists today and is still
maintained,
I'd say LiveCode is significantly more 'English-like' than any of them
thus
justifying its tag of 'English-like' ;)
<removes tongue from cheek>

> "Intuitive" . . . ha, ha, ha. Human languages are not intuitive:
> otherwise we'd all be learning a new language every 3 or 4 weeks
> and the Tower of Babel wouldn't look like Trump Tower!

Indeed - human languages have evolved organically - but they have some
nice properties which most programming languages do not (particularly
in terms of how they reflect, at least in some part, how our brains
would appear to work - being something which has resulted from our
brains
rather than the other way round).

At the end of the day computers dislike ambiguity intensely - yet
ambiguity
is almost a principal part of natural language (automatically resolved
in our
brain by context and experience).

So ideally we want a programming language which is intuitive - which we
have
a fair stab at achieving because they have to be unambiguous.

I'd say that even being a little bit 'English-like' might help in this
regard,
although you do have to dump a whole heap of compromise into such
thing's design
to pass the 'unambiguous' requirement.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Richmond Mathewson via use-livecode
On 05/24/2017 08:03 AM, Mark Waddingham via use-livecode wrote:

> Anyway, I shall now get off my (small?) soap-box. Again this is a
> discussion, there are lots of reasons why people don't choose LiveCode
> and we try our very best to determine them, and deal with them. There
> are certainly easier ones to tackle than adding a new 'syntax style' and
> of course we intend to address those first...

I just want to say that in spite of all the verbiage that showed up
overnight, this has been a most enjoyable thread to wake up to.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
In reply to this post by Martin Koob
On 05/24/2017 08:11 AM, Martin Koob via use-livecode wrote:
> I agree that LiveCode script should become more English like as time goes on
> not only with english words but also with more natural(or intuitive)
> grammar.
>
>>From your examples I think it would be more natural to type.
>
>     put the third index of tNumericArray into tFoo

The one that's always bugged me is

put item 2 of the rect of someObject into tVar

Rects have a defined order of items, and I can never remember whether
it's "left,top..." or "top,left..." and I end up looking it up every
time. I'd love to have a more normal (all right, English-like...
there... I've said it) way to remember and write this.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: English Like?

Richmond Mathewson via use-livecode
On Wed, May 24, 2017 at 10:27 AM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> Rects have a defined order of items, and I can never remember whether it's
> "left,top..." or "top,left..." and I end up looking it up every time. I'd
> love to have a more normal (all right, English-like... there... I've said
> it) way to remember and write this.


You seem to be a bit  LTRBed by this . . .

:)

--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
1234
Loading...