synonyms

Richmond Mathewson richmondmathewson at gmail.com
Mon Jun 26 15:57:13 EDT 2017


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 at 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
>> ahsoftware at gmail.com
>>

Richmond.



More information about the use-livecode mailing list