Subject: Re: bin/12838: new expr(1) is totally broken
To: None <firstname.lastname@example.org, netbsd-bugs@NetBSD.ORG>
From: Ross Harvey <email@example.com>
Date: 05/04/2001 19:51:41
Regarding the initial reply by Mr. Woods.
I never thought, in a million years, that anyone would write in to argue
with an elementary, kindergarten-level collection of obvious and universally
accepted (or so I thought until today) software engineering basics. Although
it was clear that some people were _ignoring_ the inconvenient ones, I
didn't think anyone anywhere could possibly _disagree_ with any of them.
It was mostly intended sarcastically, as, "of course everyone knows this",
and to tease our fearless leaders for letting people do stuff in less
But apparently, there is -one guy- who wants to argue. After seeing Mr.
Woods _consistently_ disagree with every consensus on the lists, I now
think that the arguments are just a challenge, and the more obvious the
position, the more challenging it must be to find some way to argue the
opposite. Take, for example, this part of Mr. Woods reply:
> Seriously speaking all complex software should be re-written from
> scratch as often as humanly and economically possible. And maybe even
> more often than that.
Wow. The appropriate response in a technical forum would be to ignore a
statement like this, or give a patient and reasoned reply on the subject.
But I'm incapable of that, I doubt if I and the person who could write a
statement like that would have any common ground on which to discuss it.
So I will reply with an unprofessional and inappropriate label; my apologies
in advance: that statement is the single most insane technical thing I have
ever heard. (Now, the original developer of something will often do an
excellent job and make a big improvement with a rewrite, but that's a
different subject, and even then it doesn't always apply to tested and
maintained software that has stood the test of time.)
And in any case, rewrites have their place. What I actually said was: "don't
replace SW that has been tested for years with _casual_ rewrites", emphasis
I also object to the apparent assumption that yacc is better. I have done
big projects in yacc and recursive descent. I wrote a C parser in yacc, I
did a dBASE III compiler for Ashton-Tate in yacc. I wrote the Green Hills
assemblers, except for 68k, and did them RD. I did lots of other parsers.
In the end, I decided that recursive descent was faster to write, had far
fewer wierd and subtle bugs, and was easier to maintain. (Things that people
just assume are true about yacc. Go figure.) If you don't program very
fast, yacc is needed, but otherwise yacc is just a choice, not an advantage.