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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
