Xref: utzoo comp.std.misc:145 comp.realtime:121 comp.arch:10561 comp.os.misc:975 comp.misc:6517 Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!aplcen!haven!rutgers!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli) Newsgroups: comp.std.misc,comp.realtime,comp.arch,comp.os.misc,comp.misc Subject: Re: TRON (a little long) Message-ID: Date: 9 Jul 89 16:59:45 GMT References: <252@arnor.UUCP> Organization: Drew University/NJIN Lines: 73 In article <252@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: > From article , 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."