🚀 go-pugleaf

In article <252@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes:

> From article <Jul.7.01.19.39.1989.7792@pilot.njin.net>, by limonce@pilot.njin.net (Tom Limoncelli):
> >> Sorry, but I don't remember such terminology in Computer Science - ugly,
> >> nice, beautiful...
> > 
> > Strange.  ...........  I guess that's
> > what I get for being a CS major at a liberal arts college.
> > 
> > I recommend you read "A Mathematician's Appology" by G.H. Hardy for a
> > "technical" definition of "ugly".
> 
> Thanks, Tom. I can't help but to recommend you to read some books on CS, in
> my turn. It may enrich your lexicon with some "real" technical terms - so
> we'll not need to seek "technical" definition for UGLY. So be professional,
> please (I mean -even more (:-) - in CS, not in liberal arts...
> 
> Uri.

If you re-read what I posted, you'll see that I *am* a CS major, I'm
*at* a liberal arts university.  Though I am a student, I also run a
team of programmers at our computer center.  These are usually
medium-large applications for use by non-computer people on our VAX.

"Are you just a automaton or what?" is a question I ask many
programmers.  If you don't plan a good, sound, (may I use the word
'elegant'?) design from the start (in other words, if you don't THINK)
it will catch up with you later.

By not only designing products, but keeping a good design philosophy
in all your programs, you prevent mistakes.  For example, I'm very
consistant with my string handling and I require all my code (and the
code of people that I manage) to handle all the "what if's".  For
example, I always handle special cases like null-strings even if they
shouldn't creep into that subroutine.  Another example is that we
include ELSE clauses on more IF-THEN statements than most people
would.  Many times the ELSE just outputs "Should Never Execute: ID="
and then a unique number.  This helps out the bug-testers.

Now, you may disagree with those design philosophies or agree; there
are reasons for and against doing things that way; but it's a design
philosophy that we keep, and we all rely on them.  I would NEVER
blindly require those kind of conditions at the next site I work; but
they work well here.

It's interesting to note that recently the powers-that-be requested a
new function in something.  One asked if it could be done by leaving
something in the config file blank.  I didn't think I was pressing my
luck by attempting it in front of them because I trusted the code.
The null string was generated properly and propagated through the
entire program and it never, ever crashed.  In no way had the program
been designed to handle a null-string there but it worked.

I saved about a week of re-writes because I was careful in my
pre-planning.  Literally an ounce of forethought saved me a week in
re-writing.  Maintain a good philosophy and the good philosophy will
maintain you.

Why don't *you* become more professional, Sir.  It only hurts the
industry when a programmer can't think for him/her self.  I have seen
too many people angry at the entire industry because one consultant
provided a solution that was one kludge on top of another; all held
together by spit and glue.  ...and it fell apart at the wrong moment.
I ask you, is that design philosophy or is that ethics?

Maybe what CS majors need is a little more philosophy.

-Tom
-- 
 Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net
       Drew University -- Box 1060, Madison, NJ -- 201-408-5389
   Standard Disclaimer: I am not the mouth-piece of Drew University
  "DEC's All-In-1 isn't completely useless, but it's a nice attempt."