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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
