> On Oct 5, 2016, at 10:22 , Richard Gaskin wrote:
>> Like Bill Appleton told me shortly after he left his point-and-click
>> authoring tool CourseBuilder behind to make SuperCard, there's a
>> limit on the complexity of systems that can be expressed clearly in
>> any point-and-click UI, and ultimately code becomes the more
>> readable option for any but the most trivial of programs.
>> After all, how many point-and-click tools used their point-and-click
>> tool to build their IDE? :)
>> Today most of the point-and-click are gone, even the industry-
>> leading Authorware, while scripting language have taken over much of
>> the world to dominate applications development.
> Well, where does that put Livecode?
It leaves LiveCode where it's designed to be: among the world's most
useful scripting language IDEs.
> Or, rather, are you, Richard Gaskin, suggesting that Livecode should
> be shedding its point-and-click heritage in favour of becoming a
> scripting-only language?
> While I am sure that is possible, at that point all the hard work
> that Kevin Miller did to extend the WYSIWYG aspect of MetaCard will
> go for nothing, and a very large part of what makes Livecode so
> strong will be lost.
I guess my writing was unclear.
I wasn't distinguishing between command-line tools and GUI tools, but
between IDEs in which *programming* is done through typing or via a
Of course LiveCode has a GUI for layout, as does XCode, Visual Basic,
Xojo, and many others.
And like those, the *programming* within the tool is done by typing.
This is a clear distinction from tools like Authorware, IconAuthor,
Scratch, and that whole category of VPLs, in which the *programming* is
done via a point-and-click GUI.
Of course no one's advocating that Kevin turn LC into a
command-line-only tool. Please.
But no matter how much time we spend doing layout in the GUI, the
objects we create are for the most part static. If we want them to do
anything we write code. And when we write code we do so by typing.
> **Livecode* is not a point-and-click authoring tool, and nor is it
> something like C++; but it can be seen as a *hybrid* of these two
> extremes, where end-users can choose where along that*point-and-click
> to** **scripting language continuum* they want to work.
There's not much of a continuum there now. There wasn't much in
In HyperCard, the range of things you could code via its point-and-click
auto-scripting palette was limited to simple navigation and little else.
Want to put the contents of one field into another? Add two numbers and
display the result? Read a file from disk? In Authorware and other
VPLs you can do those things via point-and-click, but all those and
nearly everything else we do require scripting in HyperCard, as it does
Without scripting, LiveCode is only slightly more capable of making
interactive media than any drawing program. Which is to say close to NIL.
Responding to user actions with meaningful behavior in any scripting
language requires, well, scripting.
My point wasn't that we should turn LC into a command-line tool.
My point was merely reinforcing what Bill Appleton observed, and what
the market has demonstrated since: point-and-click *programming* can
sometimes lower cognitive load in early stages of learning, but at the
cost of inhibiting the range of complexity it can gracefully support as
one's skills grow.
While VPLs have for the most part come and gone, scripting has become
the dominant means of applications development in the 21st century.
Scratch is an undeniably valuable tool for young minds. But for
delivery of professional applications, even richer VPLs than Scratch,
like Authorware and IconAuthor, have waned while typing in scripting
languages has only continued to grow.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription