On Wed, 22 Aug 2001 16:55, Leo Simons wrote:
> > Most developers are arrogant and stubbon.
>
> <snip>
>
> > Now the above statement can be seen as both a good thing and a
> > bad thing.
>
> Really? In any case,
> "Most developers are _not_ arrogant or stubborn" sounds
> better to me than "Most developers are arrogant or stubborn".
> But that might just be me =)
Well .. actually I agree. It just doesn't tend to work in opensource
projects. I would love to go through remove all code-ownership, make flat CVS
permissions and generally institute ego-less programming everywhere. Thats
how buisnesses (or at least good ones) work and is relatively effective.
Everyone works to make themselves redundent (thus increasing their value) and
decisions are based on merit etc.
However this does not build a community ;( The reason being that in OSS code
ownership increases pride and sense of belonging. Also OSS participants are
rarely working towards identical goals and rarely willing to defer to others.
Most work on problems they need fixed or on things they find interesting etc.
> The key is in standardising the things that can be standardised at
> no cost to the maximum extend possible. I think the build systems are
> one area where things are improving. I can simply install and configure
> ant with all modules you can think of, download all that's in Jakarta
> CVS, do a search for all build.bat files, double click those, go drink
> some coffee, come back, and have lots of cool software.
>
> It's nice to have universal build systems. Fortunately, it is not a lot
> of work to do it once you convince people we should make them universal.
>
> Something else is the variety of coding conventions.
Some of the variance is needed/wanted. Some build systems have to do odd
things while others are arbitrary decisions (ie intermediate output dir
name). For instance in code conventions my personal aims are
1. maximize safety/typing/compile-time checks
2. maximize information transferal/understanding
3. minimize variance over time
Many other people don't consider some (or all) of those points as important
and they may add something like "shortness of code length". Thus it is
natural that variance exists. However even then there is arbitrary decisions
about implementations of those aims. ie do you mark scope like
_myVar, _myStaticVar, MY_CONST
m_myVar, c_myStaticVar, MY_CONST
fMyVar, gMyStaticVar, MY_CONST/kMyConst
which should be eliminated.
> But a lot more important than those, imho, is the variety of design
> patterns in use for different things. It's clear that somewhere, someone
> figured out that it'd be useful to follow aforementioned
> Kernel-App-Component structure. This insight was not put to use in
> other projects (or even heard of) because it was not communicated
> as well as it should have been.
Well .. I am not so sure about that. There is plenty of research on most of
the concepts. Dare I say it, most of Avalon Framework is not original but
rehashes of ideas dating back a long time. Hell - most of the concepts,
predate computers and are near identical to concepts "discovered" in 1200's
when architects stopped being "artists" and started being "engineers" ;)
I agree - the problem is one of communication. The GoF book "Design Patterns"
was labeled as revolutionary (and it is/was for computer technicians) and is
one way to share the designs. I guess we could do similar ... now thats
actually a good idea. A Repository of pattern ideas .... hmmmm ... I like.
Kinda like the ACE project but OSS rather than academic .... definetly kool
idea.
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
