synonyms

[Mark Waddingham]

On 2017-06-26 21:57, Richmond Mathewson via use-livecode wrote:
> 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.

No it is not HyperCard, but it is (pretty much) a large superset of what 
HyperCard was...

Okay so there are some implementation differences - HyperCard used a 
page-based stack format, LiveCode's is in-memory; HyperCard used decimal 
arithmetic, LiveCode uses double arithmetic, HyperCard's parser was 
completely contextual, LiveCode's is a little bit of a mix (and a fair 
few other things).

> "train people implicitly" . . . hard job.

Indeed it isn't easy; and most environments don't really try and do so. 
Even LiveCode at the moment doesn't help that much.

In this case, I think 'implicit' comes from an environment which tells 
you what you are doing wrong, rather than just saying when you've got it 
right. After all, learning from mistakes is a general 'fact of life' - 
however, to learn from mistakes you have to know what they are in the 
first place.

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

I don't think the 'its an xTalk dialect' is that much of a burden - at 
least not from a syntax point of view. In many ways the abstractions 
which the syntax exposes are far far more important - and those persist 
regardless of the syntax which is wrapped around them.

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

Although I think Mark's original statement is conflating two things - 
there is the *abstract* method of solution, and the *concrete* rendering 
of the solution.

In most cases you might get 'four different solutions' - however it is 
more than likely that at least half of them will be the same if you 
strip away all the concrete baggage (i.e. syntax, variable names, choice 
of array of string-list etc.). Simply because abstractly there tends to 
be far fewer ways to solve any one given problem (in computing at least) 
than there is concretely, as computers think about things in a specific 
way (which often is nothing like how humans do on an average day-to-day 
basis).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps