D : Not for me anymore

Georg Wrede georg.wrede at nospam.org
Fri Oct 20 18:33:11 PDT 2006


Walter Bright wrote:
> Georg Wrede wrote:
> 
>> Kristian wrote:
>>
>>> So maybe we should have contents on APIs first. When we got the base  
>>> structure right, we can make competitions on parts (e.g. functions,  
>>> classes) that should be efficient, or hard to implement. Bulk 
>>> (trivial)  stuff can be implemented outside the competitions later. 
>>> Also, API  implementations should include documentation.
>>
>>
>> I think an API competition should definitely be in two stages:
>>
>>  - compete on the most useful and best spec
>>  - then compete on the most elegant implementations of the winning spec
> 
> 
> Design, then code, is the development approach that everyone advocates. 
> It's also the approach nobody uses <g>. Design/code/design/code... 
> iteratively is the real process. There's a good reason for that - too 
> often when implementing a design we discover that the design won't work 
> or could at least be improved.

True!

However,

If we had a separate contest on the API spec, then people really would 
"restrict" their thought to the API itself. Such restriction is never 
possible in an environment where the Task is to spec-and-execute some API.

As an example of the diametrically opposite situation, we might have a 
code shop where the boss tells Niles-the-Programmer to create an API and 
implement it. Now, knowing from the outset that he's the one who has to 
actually implement whatever API he comes up with, will feed-back and 
personal beliefs on the relative required effort, hamper his judgement 
on the what-to-dos and what-to-not-dos?

In other words, hard-to-code things get reduced priority, 
hard-to-conceptualize things get lowered priority, and labourious APIs 
get less attention and respect.

An environment where the decision on APIs is disentangled from the 
decision on how to implement such, is much more fruitful for the end 
result than the former.

A contest where these two stages are separate, may eicourage quality due 
to the fact that participants in the API part may not have an intention 
of actually coding the API parts in then next competition.



More information about the Digitalmars-d mailing list