Oh, let's get campy.
In a perfect world there should not really be a need for "us" and "them"
camps with LiveCode,
it should cater to all people along a continuum stretching from "us" to
"them".
While LiveCode may be tending to introduce more "them" features
(arguably because all
"us" features are already in place), as long as that does not detract or
break any of the
"us" features there should be nothing to argue about.
When I teach programming with LiveCode I stick to the "us" features
because I believe skills
learnt there are more basic and portable to other languages; but I am
not so narrow minded to see
that many of the "them" features have their place and use in the great
scheme of things.
This is why my "prayer" is that the good folks at LiveCode central only
deprecate features
when that is absolutely unavoidable.
Richmond.
On 23.01.19 г. 7:13 ч., Richard Gaskin via use-livecode wrote:
Graham Samuel wrote:
> It’s OK, I think, to provide more facilities for the ‘big picture’
> professionals, such as making it easier to use version control and
> to work in teams, and to have an ever-expanding set of functions
> and even platforms; but it’s not OK if this is at the expense of
> the kind of user who doesn’t want to distort the way LC works,
> for example by deprecating stacks that contain both scripts and
> UI elements...
Stack files have not been in any way deprecated. Nothing has change
in that regard.
What has happened is exactly what you describe as ideal above: new
capabilities have been added that support a much wider range of uses
for LC, while preserving the methods in place for decades. Definite
win-win.
I think some of this (a lot of this?) sort of discussion comes down to
deciding who is "us" and who is "them"?
I used to be squarely in what I presume is the "us" camp, and in many
ways I still prefer the simplicity of with-the-grain xTalk workflows.
But I also work in other languages on things outside of LC, and the
tools and habits acquired there are also valuable.
Being able to adapt old habits, and enhance the learning of new ones,
by mixing the best of what I learn from each has become a rewarding
adventure.
In fact, I'm no longer sure which camp I'm in, since I'm not fully
"us" and not full "them", but a mish-mash of both and a lot of moving
around in between those polarities.
As long as each of us can use the workflows we prefer, does the
distinction matter?
> A typical casualty of this conflict is the cancelling of the ability
> of these ordinary users to add notes to the dictionary, without
> apparent thought for the negative consequences.
I'm surprised no one in the community has made a LC Plugin that acts
as a custom GitHub client for LC docs.
That would seem the best of both worlds: a pleasant UI that's as easy
to use as it is to build, and those who prefer working directly on the
docs in Markdown can continue to do so.
A custom GitHub client for the main repository solves many problems,
chiefly (and so far uniquely) the issue of having learning materials
spread out across an ever-broader range of disparate systems. All the
advantages of multiple intput streams, with the advantage of a single
output stream that we all have installed and available with LC.
_______________________________________________
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
