Script Only Stack Architecture

[Richard Gaskin]

William Prothero wrote:

 > I put almost all of my code in substacks, but haven’t tried text only
 > stacks yet. I can’t see having a jillion small text files to keep
 > track of. But then, a lot of folks seem to love them, so I wonder at
 > the advantages. Of course, there’s the github thing.

That's pretty much it.  Xtalks give us the option of sharing code 
between projects in stack files, or keeping lots of stacks tidily tucked 
away in substacks if they're only used in one project.  And with the 
flexibility of LC's Standalone Builder, we can even have shared library 
stacks included with out mainstack at build time, to deliver a 
convenient single-file standalone that truly stands alone.

Chipp Walters, Ken Ray, and others have made check-in/check-out style 
tools for many years to handle multi-person team development rather 
well.  In Gain Momentum (an xTalk I once used made by Sybase) they had a 
system like that built in.

But that's just us, here in our relatively small corner of the world.

Then there's the rest of the world: a landscape filled with text files. 
  Lots of them. An app made in C++ or Python or most other languages is 
a rather sizable collection of text files.  The LC code base, for 
example, has hundreds.  The Linux kernel, one of the largest software 
projects on earth, uses more than 38,000 source files.

Given how those languages work, it made sense for version control 
systems to be created which are based around managing lots of tiny text 
files.

Our world and theirs happily coexisted much as Native Americans and 
Europeans did for so many centuries:  life was easy for centuries, until 
they met.

LiveCode's audience is growing, and the use of traditional version 
control systems has also grown.

Today, so many dev shops are so attached to the work flows afforded by 
modern VCSes like Github that it would be a severe impairment for them 
to do without.  And unless LiveCode could adapt to those VCSes, that 
would mean no LiveCode for them.

So script-only stacks are part of an evolutionary process for LiveCode, 
a way to play nice with others.

Now that behavior scripts (which I still believe would be less ambiguous 
and more descriptive if called by their original name, "parentScripts") 
can use script-only stacks as well, and now that Widgets are externally 
written script files, most of the code in even the most complex LiveCode 
app can be put into text files for those that need it, leaving only 
relatively small UI stacks as binary files, no worse than XCode's NIB files.

I still feel there's a role for other versioning systems, including the 
sorts of stack-file-based check-in/check-out systems we've seen.  But I 
believe it's a limited one, best suited for certain type of development 
shops.

As much as those may seem like with-the-grain solutions for LiveCode, 
they also arguably contribute to LiveCode being a sort of island, 
marginalized outside of the infrastructure through which the rest of the 
world shares code.

And best IMO is that this is not merely a theoretical exercise:  the 
team is eating their own haggis by putting these features to work in the 
IDE, one of the most complex LiveCode apps around.

And if you follow the team's progress on Github you can see the benefits 
for large projects immediately:
https://github.com/livecode/livecode/pulse

It would take significant effort to make a VCS ourselves that was as 
complete, but that and more is available for free there.



 > Code that’s portable between apps is important. Perhaps that would
 > be something to discuss. And I really haven’t messed with
 > implementing personal code “Libraries”. The requirement for strict
 > ID’s for behaviors makes them less portable. Do text only stacks help
 > in this regard?

Not necessarily, but if you're working in teams they can be tremendously 
beneficial by allowing you to use common diff tools to quickly identify 
changes.

And for those working on open source projects I would consider 
script-only libraries almost essential, since folks likely to contribute 
to such projects are already on Github and know the flow.


 > So, I think what I’m “seconding” is that a higher lever than “newby”
 > tutorials on code organization through Libraries, Text only stacks,
 > substacks, etc, would be useful and I would give it a hard look-see.
 > Currently, I’m pretty satisfied with my current approach, but over
 > the last year, I’ve changed it so much as I learned more about
 > LiveCode, that I wonder what I’m missing.

You and me both.  Just like the LC IDE now undergoing its fourth major 
revision, every few years I look at my code and the mix of new language 
features plus what I've learned since I wrote it and I dive in for a 
rewrite.

In other language the scope of materials Bramanathaswami described is 
handled in a book, of which several compete in the pursuit of a "best".

All I know is I can't write one of them:  given how long it takes to 
write a good book by the time I finished I'd be doing things differently 
than what I'd written. :)


 > Thanks, Richard, for all your comments and help on this list.

That's very kind of you, Bill.  Given your many accomplishments over the 
long years I've known you that means a lot to me.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com