Why questions don't get answered, or "No, I've already RTFM, tell me the answer!"

[David G. Miller (aka DaveAtFraud)]

jdow at earthlink.net wrote:

> From: "John Summerfied" <debian at herakles.homelinux.org>
>
>> Mike McCarty wrote:
>>
>>> John Summerfied wrote:
>>>
>>>> Mike McCarty wrote:
>>>
>
>>> I'd be ashamed if my C code were so incomprehensible and
>>> poorly documented.
>>>
>>> We obviously have different ideas about what good programming
>>> really means. To almost quote Hoare: There are two ways to
>>> write programs. One can make them so simple that there
>>> obviously are no defects, or one can make them so complicated
>>> that there are no obvious defects. The former is much more
>>> difficult.
>>
>>
>> and nobody does the latter.
>>
>> If you don't understand the language, you're not qualified to judge 
>> the quality or qualities of the code.
>
>
> Negative. Undocumented code is "a bad thing." Sadly, we all seem to
> commit to much of it. We presume the next poor sod who gets to play
> with the code will understand the subtleties of the language and see
> what we're doing instantly. We discover, when we are the next poor
> sod some years down the line that we've forgotten that language after
> picking up 7 others.
>
> Regular expressions are a feature that could use more documentation
> than they usually get.
>
> {o.o}

Ever since serving said sentence, I have been of the opinion that all 
newly minted programmers should first serve time in the purgatory known 
as "software maintenance programming."  Only after getting an 
appreciation for how hard it is to divine someone else's obscure code 
should they be unleashed on the world and allowed to create their own 
inscrutable incantations.

That being said, I probably do most of my current development in perl 
which has been described as a "write only" language.  I prefer to call 
it the Swiss Army Knife of programming languages.

Cheers,
Dave