From ... From: Erik Naggum Subject: Re: Macro question (bizarre) Date: 2000/03/20 Message-ID: <3162508890587433@naggum.no>#1/1 X-Deja-AN: 599767492 References: <38D22BF9.DFFE6E3E@emi.u-bordeaux.fr> <8atcu9$f6m$1@nnrp1.deja.com> <3162359744057189@naggum.no> <3162477927563017@naggum.no> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 953520178 15790 195.0.192.66 (20 Mar 2000 02:42:58 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 20 Mar 2000 02:42:58 GMT Newsgroups: comp.lang.lisp * Tom Breton | One of the best things I learned as a programmer was *not* to grab at | everything that looked like an opportunity to optimize. I'm sure that's true for you. one of the best things I learned as a novice programmer was that no matter what I choose to do, it has impact on performance, and if I want to waste as little time as possible going back over code and rewrite it, it would help me a lot to understand as much as possible both about the hardware and the language used. the more factors I can deal with at the same time, the less time I spending fixing up code that ignored one or more factors that turned to be important. the only way to deal with a whole bunch of factors at once is to work so much with them they migrate into your automated, emotional response system, just like people walk and type and talk without actually thinking about _any_ of the specific physical operations involved. | I find I rarely actually want the optimization enuff to be worth doing | later. of course not. that's the problem with doing optimization too late. premature optimization can hurt you, and real bad at that. that doesn't mean thinking in terms of optimization is bad. it means that you don't do optimization stuff that is likely to hurt you, and you spend a fair amount of your working life acquiring the experience that tells you that some things may hurt a little, yet need to be done, anyway. avoiding all kinds of hurt is a very good way never to acquire _any_ experience. tell you what. I recently got a position where I'm about to hire a sysadm and some programmers. I'm looking for people who are good at what they do, obviously, and to me, that has always meant an interest in stuff that happens "below" whatever you're "supposed" to be doing, as in _caring_. a sysadm who doesn't care about hardware is obviously going to run into a situation one day where his non-caring will impact everyone else badly. it is less obvious with a programmer, but I have decided that I'm not going to hire Common Lisp programmers who don't want to know how to read the disassembled code of a compiled function. neither will I let anyone who is unwilling to read RFCs to understand TCP/IP and other networking fundamentals work on network protocol implementations, even high-level ones. likewise, if someone told me that he'd always optimize late, I'd assume that he'd be a really bad programmer whose brain didn't work or fast well enough that he could deal with economy of expression and algorithm and resource use at the same time, and would have to take care of each one at a time. just as you don't disassemble code all the time, and certainly don't think about IP packets and network issues all the time, the fact that you care about it means you don't ignore it, and not ignoring it means not overlooking something that can save you days in debugging, weeks in design, and months in customer relations. I'm not sure what you're trying to tell us, except that I get this really bad feeling you're defending a programming style that optimized very much for you not being hurt again. if you optimize so heavily for that, I'm sure you'll appreciate that other people may optimize for other factors with at least as much effort. the result for you is reinforced efficacy in dealing with programming problems by removing a whole slew of issues. the result for those who have automatized their optimization of code is reinforced efficacy in dealing with programming problems by removing a whole slew of issues. the net result, however, is that you all feel good, but their code also runs much more efficiently in the same time. now, I want programmers who feel good about themselves, but I'm not going to pay more than half the money for one that doesn't write good code. #:Erik