Team Development / Exporting stuff to text files

[David Bovill]

On 08/03/2008, Richard Gaskin <ambassador at fourthworld.com> wrote:
>
>
> A stack can be used as a data store only, separate from other stacks
> which can be used for the UI, separate still from stacks used as
> libraries to drive it all.


True.

Quite flexible, the stack object.


Hmmmm -  lets put it the other way around. When is it a good idea to store
data in a format other than a stack? How about:

   1. If there is a need for the data to be used by other non-rev
   software or tools
   2. If using a database makes the data easier to organise, maintain, or
   faster to access.
   3. If very frequent changes to the data are likely and a full history
   of these changes is needed => use svn /cvs to save space?
   4. ?


Actually, in that case it wasn't for the lack of collaborative tools.
>
> In fact, rather the opposite:  it's just so easy to write stuff in Rev
> that simply doing so took less time than even talking about it.
>
> That's the other side of the collaboration equation which may have
> little opportunity for tools support but where the greatest loss of
> per-person productivity lies: talking, getting other team members to
> first understand your own ideas and then to adopt them as their own.


Yes - thats the other side of the equation, and yes talking is nearly always
a waist of time :)  I'd only add that svn / cvs collaboration tools aim to
support collaboration via "talking through improving shared code".

Adding programmers is expensive, and more expensive the more closely
> their work overlaps, as it requires more talking.
>
> Splitting work up into black boxes lets each programmer contribute with
> the productivity of a solo effort, yet allow the project to benefit from
> having multiple components developed simultaneously.


Yes. But you are not mentioning the dangers of such an approach. What
happens when you want to update the software and the  original programmer is
not around??? The reason for paired programmers or svn like  collaborative
process is to evolve a code base which you can change programmers on without
having to start again from scratch. Code written by an individual remains
that - individualistic. Is this not one of the reasons why there are so few
commercial quality community created libraries or components?

Stacks work well for organizing the work into black boxes.


True. It does seem a slight waist though to lock up all that super easy to
read code in a black box - I mean I can understand that with C++ - but one
of the great strengths of xTalk languages is the common sense easy to read
nature of the code.

An interesting point that Ben brought up off list was the ongoing change to
the Flash community caused by moving over to text based file formats - the
most obvious for now being the adoption of svn for source code management.
Companies are already using cvs / svn systems for their
php/python/ruby/html/css/javascript/whatever development.

I'd also expect to see a much more robust open source community developing
around the new XML based file formats - at least Adobe are betting on that?
Certainly when I looked at Adobe AIR I thought that's exactly what I'd
recommend for future Rev based tool  development (though maybe not pure
XML).