>As long as programmers think that way, their employers will continue to >pay people like me big bucks to come in and make the code more efficient.
Like I said, at 175 an hour the ***client*** preferred the quickest coding method. So sometimes you get the big bucks to save time in **programming**. (This was when my boss collected the money - I charge less now that I'm independent) And have you tested both methods to even see which is faster? I have and to tell the truth I could not see any difference in speed between opening the file and putting it in common and readv'ing the attributes and just using the TRANS'd code. I didn't use any fancy methods, just listed the file and saw that it apparently didn't make any visual difference in speed. Since Uniquery *is* opening the file and keeping it open internally, what *exactly* is the difference between letting the system do the work for you or doing the same thing in a program? Other questions: How often will this dict item be used in a report. Once a month? Ten times a day? These make the decision to code more efficiently an issue, or not. And after 31 years of programming, I only use one hand to type if the other has a big honkin chicken taco in it. Rest of the time I type at about 120wpm. Speaking of which, I forgot to finish my second taco....yum. Being independent, you have to listen to what the *client* wants. Do they need me to spend an additional 40 hours at $110 an hour to make something run faster? Most clients say NOOOOOOOOOOOO!!!!!! Allen www.tortillafc.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Timothy Snyder Sent: Friday, October 07, 2005 14:21 To: [email protected] Subject: RE: [U2] OPEN vs TRANS "Allen E. Elwood" <[EMAIL PROTECTED]> wrote on 10/07/2005 12:53:47 PM: > The way I look at it, when I started programming 30 years ago systems were > millions of times slower, and in another 30 years they'll be so stinking > fast that coding for speed will go the way of the Suchomimus and the > Iguanodon! As long as programmers think that way, their employers will continue to pay people like me big bucks to come in and make the code more efficient. ;-) Sometimes more powerful systems can make bottlenecks more prominent. Today's systems are expected to process more data in a shorter time, and to provide more functionality than in days of yore, so even minor inefficiencies are encountered over and over again. IMHO, there will always be room for efficient coding techniques. Some folks claim you have to sacrifice maintainability and readability for the sake of efficiency - I've rarely found that to be true. As long as you care about and consider both performance and maintainability as you develop code, it all just falls together. Now, as to people who want to code one line instead of two (e.g.: the topic of this thread), I say take a touch typing course so you don't mind a few extra keystrokes. (I've always been amazed watching seasoned professionals using only one finger on each hand to write programs.) I would much rather inherit a program that does its own opens and reads instead of doing translates. Sooner or later somebody will want to get a second field from the record and you'll be faced with doing two translates or changing it to the way it should have been done in the first place. Plus, the OCONV with a translate isn't nearly as obvious to the casual observer of the code. Of course, you could put in some comments to make it clear, but those keystrokes could have been spent opening the file at the top of the program. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
