A critic of Guido's blog on Python's lambda

[Bill Atkins]

brian at sweetapp.com writes:

> Bill Atkins wrote:
>> brian at sweetapp.com writes:
>>
>>> Bill Atkins wrote:
>>>> Buh?  The project doesn't have to be late for Brooks's law to hold;
>>>> adding programmers, so goes Brooks reasoning, will always increase the
>>>> time required to complete the project because of various communication
>>>> issues.
>>> 1. This is not what Brooks says. Brooks was talking about late
>>>    projects. Please provide a supporting quote if you wish to continue
>>>    to claim that "adding programmers will always increase the time
>>>    required to complete the project".
>>
>> The "always" in my claim should not be there, I admit.  Brooks didn't
>> claim that.
>>
>> I refer you to pages 17 - 18 of The Mythical Man-Month:
>>
>>   Since software construction is inherently a systems effort - an
>>   exercise in complex interrelationships - communication effort is
>>   great...Adding more men then lengthens, not shortens, the schedule.
>>
>> It is totally absurd to assume that, simply because a project has not
>> yet passed its deadline, it will somehow become immune to the kinds of
>> things Brooks is talking about.
>
> Right. But only when a project is late does Brooks say that adding
> programmers will always make it later (the claim that you made). In
> other cases he says "Add manpower, ..., this may or may not help". That
> seems intuitively obvious to me. If the programmers being added require
> extensive training [1] by the team to become productive, and their
> contribution to the project will be smaller than that amount (e.g. it
> is a small or nearly completed project) then their net impact on the
> project will be negative. If, OTOH, the new programmers are able to
> quickly understand the project/organization/technologies and almost
> immediately make useful contributions, then they are likely to have a
> net positive impact.

There is another essay in TMM-M that discusses the difference between
essential complexity and accidental complexity.  You might think
Python is really swell, and I might think Common Lisp is really swell,
but at the heart of it there is still what Brooks calls "essential
complexity" - the difficulty of mapping a complicated real-world
situation into a model a computer can handle.  So I think using Python
or Lisp will help get rid of a lot of the accidental complexity that
would arise from using C or C++, but it can only do so much; there is
still a lot of complexity involved even in projects that are written
in very high-level languages.  IMHO.

>>> 2. There has to be a mechanism where an organization can add
>>>    developers - even if it is only for new projects. Python advocates
>>
>> Obviously.
>
> It's good that you agree. I think that the ability to add new
> productive developers to a project/team/organization is at least part
> of what Alex means by "scaleability". I'm sure that he will correct me
> if I am wrong.
>
>>> [list of proposed Python advantages snipped]
>> These are not things I look for in a programming language.
>
> Fair enough. That doesn't mean that these advantages aren't important
> to others or, in some situations, objectively important in the survival
> of a project/organization.

Sure, agreed.

> For example, imagine that Google had used language X instead of Python
> to develop their tools (assume they started with 10 expert X
> programmers). Expert X programmers are Y percent more productive than
> expert Python programmers. Now Google wants to grow aggressively and
> needs 100 times more developer productivity (and expects to need even
> more productivity in the future). If it is harder to find/hire/create
> experts in language X than Python, then Y will have to be large to make
> language X a better choice than Python. Also, if non-expert Python
> programmers can be more productive than non-expert X programmers, then
> Python also has an advantage. Eric Raymond claims that Python has very
> high initial productivity and that becoming an expert is fairly easy.
>
> BTW, I'm not saying that Common Lisp fits X in this example.
>
> Cheers,
> Brian
>
> [1] I'm considering introducing bugs or misdesigns that have to be
> fixed
>     as part of training for the purposes of this discussion. Also the
>     time needed to learn to coordinate with the rest of the team.
>

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan