Well . . . here we are all going to draw ourselves up to do battle . . .
On 6/26/17 9:48 pm, Mark Waddingham via use-livecode wrote:
I'm against synonyms being part of the core language - they have no place there
as they are 'tailorings'. Indeed a good part of the argument for them could be
solved by better tooling - e.g. autocomplete and suggested tokens if one isn't
quite right.
Every single property in the engine could have synonyms and some many (see the
recent discussion about clipsToRect). An attempt to 'normalise' hilite and its
various compound forms would have resulted in 40 (iirc) additions to the token
table.
Moreover every single synonym reduces the set of possibilities of things we
could add in the future and can cause backwards compatibility issues in
existing scripts (as they become for all intents and purposes reserved).
I suffer from a horrible tendency to see both sides of an argument.
What you have stated above, Mark, makes 100% perfect sense in terms of a
"tight", efficient programming environment.
It doesn't make sense if one wants to preserve a programming language
which can largely be self-taught rather than didactically
spoon-fed to learners.
That last point was one of the main ideas behind the development of
Hypercard.
-----------------------------
Most of us are well aware that LiveCode is NOT Hypercard any more than I
am not a small, furry mouselike mammal that danced around
the toes of dying dinosaurs: LiveCode is descended from HyperCard, and I
may be descended from small, furry mammals.
What LiveCode (the company) have to decide (and it's a tough call) is
how much they want their LiveCode to hold onto the HyperCard
legacy (and probably as a result continue to be regarded by programming
snobs as a kid's toy) and how much they want LiveCode to
"grow up" and try to displace some of the serious market leaders (C++,
C#, VBasic, Python).
----------------------------
My position is well-known, but I am an educator, and an educator who
does not favour didactic teaching.
There is no easy way to administer synonym additions centrally and each one
increases the maintenance burden in the current architecture.
So the only 'synonyms' which it makes sense to adopt right now are the ones
which help move the current syntax to having a consistent and sensible
canonical form which is easy to document and explain.
This allows, in the future, for a far more general and decentralised way to
tailor syntax *in general* whilst ensuring there will always be one canonical
form to which scripts can be translated to enable them to be compiled and (more
importantly) be translated to people's preferred form.
So, I get the reasoning behind them (although I still think it better to train
people implicitly to use canonical forms via better tooling, as if everyone
'sings' with the same language, uniform understanding is increased) so in the
future everyone will be able to 'knock themselves out'...
"train people implicitly" . . . hard job.
However, I'd point out that the primary reason for the architecture to allow
that is specifying custom syntax, and non-English language variants. The fact
that the 'synonym problem' would also be 'fixed' by it Is but a happy
by-product.
Warmest Regards,
Mark.
Sent from my iPhone
On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode
<use-livecode@lists.runrev.com> wrote:
On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:
I think it is probably generally true that the more consistent and simpler the
language is, the easier it is to learn.
...and I would follow that with the (long-running by now) argument that synonyms provide for an
ease-of-use facility in coding and therefore a simpler approach to using the language. For the
trivial case here, if I can't remember whether the language supports "is" or
"=" for variable assignments, I can use one or the other without having to interrupt my
train of thought to look it up in the dictionary/guides.
One of LiveCode's strengths is the fact that there are many possible solutions
to a given problem, and the xtalk language allows much flexibility in solving
it.
Yes; but that presupposes LiveCode is going to be burdened with the
"it's an xTalk dialect" label forever, and whether "xTalk"
continues to make sense seeing how far the xTalk outgrowths from
HyperCard have diverged.
For a problem placed before any three coders, you will find at least four
different solutions. Limiting the language limits the ways in which a problem
may be thought of - that's the basis of the linguistic relativism, and it
applies to programming languages as well as to natural languages.
Of course.
--
Mark Wieder
ahsoftw...@gmail.com
Richmond.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
