Re: Using lex and yacc for parsing

From: Mark Coletti (mcoletti@listserv.clark.net)
Date: 11/07/95


Chris Herringshaw pounded furiously on the keyboard:

	Sorry for the late reply, but Dark Net (a.k.a., Clark Net) has
been having big-time problems of late.

> You have to really understand the code before you can make
> generalizations about the usefulness of any code optimizations.  You
> have to really understand and probably profile your executable to
> find out what would really help.

	Again, I stress that I'm not out to optimize the code, per se.
I'm pointing out possible problems in CircleMUD's "design" and in that
design's implementation -- _especially_ the implementation.  There are
basic things that an experienced programmer knows to do that aren't
being done in CircleMUD.  These are things that can be readily picked
out without necessarily having a deep understanding of the code
itself.  I gave a grocery list of such things in a prior post.

	[Interesting Diku timing stuff snippified.]

> This optimization issue is prevelant in today's software
> development.  A piece of code could be the worst search algorithm
> you've ever seen, but if it is not a critical path issue (affect
> execution time), that code will stay there.

	If the code is difficult to understand, then it should be
re-written to be easier to understand and maintain and to extend.  To
use Jeremy's own words, people time is more expensive than computer
time.  I just want to reduce the people time by eliminating some of
the obsfucation.

> The man-hours it costs to write a better routine don't provide any
> real benefit for the program, so it never gets done.  I think most
> people would be really surprised if they saw some of the source code
> for modern programs, especially games.  There are a ton of horrible
> hacks in most programs, but no one will ever see them, and it does
> not pay to fix them.

	This sounds like you're making excuses for coding mediocrity.
The "if it ain't broke, don't fix it" mentality which, as you point
out, is all too pervasive in software work -- still, as far as I'm
concerned, there's no excuse for shoddy work.  =8-) Always strive to
do it right the first time.  (Of course, there's a corrollary to that
that goes something along the lines that a programmer is never
satisfied with their work!)  Mind you, I do agree that if pressed for
time, that programming tasks have to be done on a triage basis; the
most important parts of legacy code have to be fixed first.

	[...]
> ---
> Christopher Herringshaw       | University of Michigan Medical Center
> Special Projects Development  | 1500 East Medical Center Dr. B1-240TC
> xxviper@umich.edu             |        Ann Arbor, Michigan 48109-0704
> http://www.umich.edu/~xxviper |                  +0101 (313) 747-2778      


Mark!
-- 
Mark Coletti                       |  DBA Systems, Inc.  Fairfax, VA
mcoletti@clark.net                 |  United States Geological Survey
http://www.clark.net/pub/mcoletti  |  Office of Standards & Technology
	      It runs much faster with a 1Gb disk cache.



This archive was generated by hypermail 2b30 : 12/07/00 PST