Us and them? [was Re: Livecode Dictionary]

[Richmond]

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