On May 23, 8:28 am, "John Thingstad" <··············@chello.no> wrote:
> Let's say you have 50 developers. You need to fix a bug in code you didn't
> write.
> You extract the file from CVS. You track down the offending code.
> Now you discover that the problem is in a macro written in another module.
> Changing that affects other uses as well.. so you need to write an new one
> when you
> have figured out what this guy was trying to do in the first place.
> This can be more wasteful than helpful.
Judging from experience, that paragraph applies to at least C and C++
as well.
> You could say the more homogeneous the style the easier to maintain
> because it is easier
> for another person to read and understand. This and not the amount of code
> is more
> important for maintaining the program.
Homogenous style? In a C project involving more than 20 programmers?
Good one :)
Each developer doing his own syntax will conceivably lead to problems
- I couldn't say, I've yet to find the opportunity to use Lisp in a
team.
But the better teams I've worked in were organized so as let the
better/older/lead developers do the design and the others do the brunt
of the coding. Shouldn't that work in Lisp teams as well? Letting them
who know what they're doing create the application-necessary
abstractions and design guidelines, and then letting the junior coders
use those abstractions and adhere to those guidelines?
From: John Thingstad
Subject: Re: I finally understand why I'm not allowed to use Lisp
Date:
Message-ID: <op.tsrrybbppqzri1@pandora.upc.no>
On Wed, 23 May 2007 09:40:52 +0200, Christopher Koppler
<········@chello.at> wrote:
>
> Each developer doing his own syntax will conceivably lead to problems
> - I couldn't say, I've yet to find the opportunity to use Lisp in a
> team.
> But the better teams I've worked in were organized so as let the
> better/older/lead developers do the design and the others do the brunt
> of the coding. Shouldn't that work in Lisp teams as well? Letting them
> who know what they're doing create the application-necessary
> abstractions and design guidelines, and then letting the junior coders
> use those abstractions and adhere to those guidelines?
>
Yes. But if you look at the post it is written by one of the rookie
programmers
who wanted to introduce new syntax for his code and the experienced
programmer
that refused him.
What I disagree is that this is C#'s fault.
I have experience with developing large systems in C++ but not in Lisp
yet so it is hard to tell. I do know that this is why designers like design
patterns. (Most programmers like me hate them I guess..)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Christopher Koppler wrote:
> On May 23, 8:28 am, "John Thingstad" <··············@chello.no> wrote:
>> Let's say you have 50 developers. You need to fix a bug in code you
>> didn't write.
>> You extract the file from CVS. You track down the offending code.
>> Now you discover that the problem is in a macro written in another
>> module. Changing that affects other uses as well.. so you need to write
>> an new one when you
>> have figured out what this guy was trying to do in the first place.
>> This can be more wasteful than helpful.
>
> Judging from experience, that paragraph applies to at least C and C++
> as well.
>
>> You could say the more homogeneous the style the easier to maintain
>> because it is easier
>> for another person to read and understand. This and not the amount of
>> code is more
>> important for maintaining the program.
>
> Homogenous style? In a C project involving more than 20 programmers?
> Good one :)
>
> Each developer doing his own syntax will conceivably lead to problems
> - I couldn't say, I've yet to find the opportunity to use Lisp in a
> team.
> But the better teams I've worked in were organized so as let the
> better/older/lead developers do the design and the others do the brunt
> of the coding. Shouldn't that work in Lisp teams as well? Letting them
> who know what they're doing create the application-necessary
> abstractions and design guidelines, and then letting the junior coders
> use those abstractions and adhere to those guidelines?
Once again, apologies for my noobishness, but surely the way a team works is
for a senior developer(s) to do the top-level design of the whole shebang,
but leave the implementation details of each programmer's assigned work to
the programmer? Otherwise, wouldn't you effectively be using the junior
programmers as mere typists?
Jeff
Jeff Rollin wrote:
> surely the way a team works is for a senior developer(s)
> to do the top-level design of the whole shebang,
Both top and bottom. Regarding the twenty-different-styles
issue, someone should be in charge of compiling one or more
libraries, both application-specific and [company|department]-wide.
Junior staff should be working in the middle, everyone using
the same conventions. That can be done in any language.
--
Dan
www.prairienet.org/~dsb/