LiveCode Forums.

https://pdos.csail.mit.edu/6.828/2007/r ... script.pdf

“The experiment in designing a language that resembled
natural languages (English and Japanese) was not success-
ful. It was assumed that scripts should be presented in “nat-
ural language” so that average people could read and write
them. This lead to the invention of multi-token keywords
and the ability to disambiguate tokens without spaces for
Japanese Kanji. In the end the syntactic variations and flex-
ibility did more to confuse programmers than to help them
out. It is not clear whether it is easier for novice users to
work with a scripting language that resembles natural lan-
guage, with all its special cases and idiosyncrasies. The main
problem is that AppleScript only appears to be a natural
language: in fact, it is an artificial language, like any other
programming language. Recording was successful, but even
small changes to the script may introduce subtle syntactic er-
rors that baffle users. It is easy to read AppleScript, but quite
hard to write it.
When writing programs or scripts, users prefer a more
conventional programming language structure. Later ver-
sions of AppleScript dropped support for dialects. In hind-
sight, we believe that AppleScript should have adopted the
Professional Dialect that was developed but never shipped.
Finally, readability was no substitute for an effective se-
curity mechanism. Most people just run scripts—they don’t
read or write them.”

The main problem is that AppleScript only appears to be a natural
language: in fact, it is an artificial language, like any other
programming language.

I am not sure why that is a problem unless end-users are so naive that they are unaware
of the fact that AppleScript is an artificial language, or have fallen for the myth that a
human brain and a computer are in some strange way similar.

even small changes to the script may introduce subtle syntactic
errors that baffle users.

Well, even small changes in "a natural luggage might interdict a boffle," whoops!

Well, even small changes in a natural language may introduce subtle syntactic errors that baffle learners/users;
so why the big surprise?

Any 'big surprise' will only be experienced by end-users who:

1. Expect computers to do more than they are capable of.

2. Expect the programming language they are working in to be 100% identical to the natural language it superficially resembles.

The main reasons that #1 and #2 seems prevalent seems to come down to this:

3. The widespread myth of the all-powerful, omnipotent computer; a sort of god replacement.

4. The feeling that because a language (whether natural or artificial [i.e. a computer language]) superficially
resembles another language in terms of its surface features other aspects of it are also the same.

[A particularly good example of this is when people see a written language and think it is somehow "wrong"
because it contains a lot of words in one language but is in fact another language, such as mistaking,

"All my work wi computers an aa has left me unco disjaskit." for English.]

I am sure that all of the above comes down to a social trend; that of dumbing everything down and
giving people an unrealistic view of things insofar as to the level of work and effort required to produce
a desired result.

Silly examples of this are:

"Learn programming in 12 hours."

"Learn French in 3 weeks."

writing programs or scripts, users prefer a more
conventional programming language structure.

That's a horrible generalisation, and probably refers to people who
have learnt 3rd and 4th generation languages such as FORTRAN, PASCAL, C++
and so forth.

Teaching children they far prefer LiveCode to BBC BASIC (itself a brave attempt
to bring programming nearer to a natural language). AND, given the choice they
prefer code blocks!

I'll read all the way through the article tonight as this looks as though it contains
an awful lot of "meat" to chew on.

users prefer a more
conventional programming language structure

- -
I wonder what the author meant by "conventional . . . structure"
as the word conventional is about as subjective as one can get.

Hard to believe they dropped HyperTalk as the Mac system programming language in favour of the clumsy AppleScript!

Dropping HyperTalk is a point, but not one that's particularly relevant to the 'academic' paper.

I have a large number of Macintosh computers and never attempt to do anything whatsoever with AppleScript,
but mainly because I am not that keen on macros, it seems a "half-cock job" and when I want to do
some 'real' programming I can use LiveCode.

The author apparently finds that 3rd generation languages are easier to understand than programming languages
such as AppleScript, HyperTalk and so on.

As far as I can see it seems that all that really comes out of the section quoted by the OP
(haven't had time to read the whole article yet) is that some people are 'goofy' enough to expect
a more natural-like programming language to behave exactly like a natural (i.e. human) language
and that confuses them.

Personally I've never had that problem, never having had a conversation with a computer.

What does need to be done to redress this problem, in my opinion, is to impress on people learning their
first programming language that no programming language will ever be the same as a natural language as the
first is used for a unidirectional delivery of instructions to a machine, while the second is used for
interaction between people.

Certainly, from the limited purview of Bulgaria, teachers seem to use phrases such as "talk to a computer"
when teaching what passes for computer programming round these parts.

Somewhere between "those boxes we jacked into the back of valve TVs" and today, the plain and unvarnished fact
that a computer is not much more than a souped-up vacuum cleaner has been lost sight of.

My interest in this area lies with education and steepness of learning curves.

Children have absolutely no problem with distinguishing a computer language from a natural language
whatsoever once they realise that a computer, when it is communicated with, does not understand
what linguists term modality; only 'Yes' or 'No.' I always have to start any course
I teach by explaining that, because of this sort of thing:

"I wrote a fantastic program, but the stupid computer did not understand it."

Computers are NOT stupid.

If I stroke my cat I have no way of telling whether the outcome will be a bite, a yawn, a purr or she just runs off to the other side
of the room: but, then, she's not a computer. But, then, I don't stroke computers, honest.

The author is one who was involved intimately with creating AppleScript.

That will make reading the full paper even more interesting.

Multi-word property names was one of the reasons I found AppleScript so hard to use. It doesn't fit the pattern of any programming or natural language.

It is perhaps the premier example of what can go wrong when attempting to prioritize natural language ideas in a language designed for communicating with machines.

I was so grateful LiveCode stopped emphasizing "English-like" in its marketing, focusing on tangibles like productivity and cognitive load instead.

Hypertalk and LiveCode strike a nice balance, keeping code readable without sacrificing learnability.

LiveCode stopped emphasizing "English-like"

I can see how that could have been misleading.

There's a reason mathematical formula's don't use English like syntax. It's tedious and cumbersome.

Say I want to work with a rect structure. Refer to it with rect.x, rect.y, rect.width, rect.height is much easier on the eye (and hands) than the width of x, the height of rect. People also just say 'consider x is (=) 100' instead of put 100 into x. Code completion is not possible with 'detail first, parent later' syntax. The IDE needs to know the parent object to display its children. Window.Width . 'the width of window' can't use autocomplete or any helpful tooling, only can hope for basic keyword completion. LiveCode's refusal to incorporate some OPTIONAL additional syntax options is ... Already said once I hope they take a good look at SenseTalk (http://docs.testplant.com/ePF/SenseTalk ... erence.htm).

AppleScript has syntax like set {position, size} of window to {myPosition, mySize}. It has thisApp's name notation (also name of thisApp), but no easy dot syntax. Anyway, nowadays macOS scripting also supports a JavaScript like syntax, but of course everyone who is using it, is by now used to the quirks of AppleScript, and especially stay there because of availability of many examples. You don't figure out what exact 'English like' line you need, but someone else did. So Google, test, adjust and reuse...

But it is also quite obvious Apple pushes end user scripting back by making it harder to create generic solutions because of all 'security' features which are a PITA for a lot of system utilities now on macOS and Apple is killing features without decent communication about it. Even enterprise network admins don't have a way to manage these permissions resulting in confirmation dialogs everywhere. Think different? Think Vista UAC... And the push to code signing/control... 99 euro per year for anyone doing anything.

Anyway, seems LiveCode language is not evolving. Just adding more libraries now and then. Old pains remain. No decent UI on mobile out-of-the-box. No performant and easy to use grid control or any modern controls. I guess touch scrolling still needs boilerplate code on mobile? I liked what I saw with version 5.5 and hoped they would work on improvements to the core language (syntax, tooling and speed) and controls, but since then hmmm . App size for one exploded. 5.5 won't run anymore on Catalina btw 32 bit and all..

I was kind of surprised by the professionality and team size btw back in the day.

I do not agree with this part:
"
HyperCard 2.0 was released in 1990. HyperCard was very influential and widely used. Developers could easily create some applications in HyperCard, but to create more complex applications, they had to switch to more difficult general-purpose development tools. The need for unification of these approaches was recognized early at Apple, leading to the formation of a research and development project to build a new development platform for the Mac, discussed in the next section. Looking forward, the rapid develop- ment capabilities pioneered by HyperCard were added to more sophisticated general-purpose development environ- ments. This gradually reduced the need for systems like Hy- perCard, which was discontinued in 2004."

There still is need for a HyperCard like tool to quickly create custom tools. I never saw those capabilities of HyperCard being moved to somewhere else useful for the same audience...

enough rambled..
Have a good day

rinzwind wrote: ↑

Sat Nov 16, 2019 8:33 am

There still is need for a HyperCard like tool to quickly create custom tools. I never saw those capabilities of HyperCard being moved to somewhere else useful for the same audience...

What would you like to see moved?

enough rambled..
Have a good day

Good ramble.

seems LiveCode language is not evolving

What do you mean by "evolving" ?

If you mean that each new version of LiveCode retains most of the language which is in previous versions
(because it is tried and tested and works) then I suppose it is not "evolving."

If you mean that new features which require new elements to be added to the language, then you are wrong.

Down in Dorset (in England) where my Mother was brought up, locals have never seen a need to drop
the Viking verb 'beon', so say, "I be, Thee be, He be, She be, We be" and so on. Frankly it has always
struck me as much easier than the "fancy Latin" present tense that is used in 'standard English.'
The reason that in Dorset and Somerset that verb has been retained is because it is tried and tested and works.

Now I can see no very good reason why bits of a programming language should "evolve" just for the
sake of "evolution" (and, using the verb "evolve" about a programming language that is created is
a bit odd); and that is one of the reasons why, two summers ago, having sat myself down to get my
act together with Python I stopped after 3 weeks because I got "effed off" with the fact that having
learnt Python 2 I realised to use Python 3 I had to undergo a large reorientation.

As LiveCode is meant to be more accessible than "clunky jobs" such as Python, its continuity through
versions is something to be celebrated and admired. It also means that I can teach LiveCode to almost
anyone on whatever hardware comes to hand, and if I teach them using LiveCode 8.1 they will be able
to use all that hard-learnt knowledge with LiveCode 9.5, and that is a tremendous benefit.

Just got "my knickers in a twist" trying to write something in BASIC on an AMSTRAD as the BASIC
there is just sufficiently different from BBC BASIC (which I tend to program with on my BBC MODEL B
and my BBC MASTER) to cause me 'cognitive problems.'

Refer to it with rect.x, rect.y, rect.width, rect.height is much easier on the eye (and hands) than the width of x, the height of rect.

Not on mine,

If one wants to have a serious discussion about the relative strengths of different
programming languages one needs to stop be so subjective and lay one's hands
on some valid data.

Quite apart from my personal prejudice (as opposed to yours), Primary school
children find "the width of x" very easy indeed to understand, while
"rect.width" throws them right off into the left field, or just demotivates
them because it is a long, long way away from their mental maps of
the world.

https://www.techrepublic.com/article/wh ... ipt-and-c/

The "trouble" about things like this is that the focus is not on usability or whether things "rest easily on the eyes."

This does state the screamingly obvious:

"Ultimately, your preferred language is going to be the one with which you're most comfortable and that gets the job done most effectively."

But then goes on to plug Python in a completely different way:

"One reason for Python's popularity is its strong support in the area of artificial intelligence (AI),
according to the IEEE. Python also offers a healthy number of libraries and packages that programmers
can use so they're not building certain code from scratch."

What it does NOT do is address:

1. Whether its syntax is in some way close to natural language.

2. How "easy on the eyes it is." [Which, admittedly is so subjective as to have almost no value.]

This reminds me of arguments I have been hearing over the last 16 years since I have been plugging desktop Linux:

"Windows has more applications available." - It may do, but most people only use about 5 or 6 applications anyway.

"Everyone else uses Windows." - They may do, but those Romans died out who sweetened their wine
with Sugar of Lead, while those "stupid" people who used honey lived on.

Having been slightly rude about Python, I do wonder if this might help things:

https://playentry.org/?fbclid=IwAR1KQGR ... lineEditor
- -
While this is a block-coding setup, it does have a "Python Mode", which:

"'Entry Python' mode acts as an intermediate bridge from block coding to text coding. If you have learned the principles of software through block coding and have become accustomed to logically solving problems, then you should try Entry Python mode.
<How to convert to Entry Python mode>
1. Click [Create] - [Create Project], and select 'Entry Python' menu.
2. Entry block codes will be automatically converted into Entry Python command according to the Python grammar.
3. Previous projects built with block codes can be opened and converted into Entry Python codes.
* Click the [?] button on Entry [Create] - [Create Project] menu, and click 'Entry Python Guide'. You can find basic grammar guide and other examples.
<Cautions when using Python mode>
1. Entry Python follow basic Python language, but does not support all the function and grammars.
2. If you run the project that contains functions in text mode, the result of the execution may not be the same as of the block mode.
* When special characters are used for variable/list/function name, it would not run normally after converting to text mode."

https://playentry.org/#!/faq?all
- -
If that really works (which I doubt, at least in terms of teaching kids Python) it should not be that difficult for someone
clever to make a code-block "thing" to strap on the front of LiveCode.

Frankly I wouldn't bother as kids I have had to classes every summer get their heads round LiveCode "as it is" with very little trouble at all.