Subject: Re: Macro question (bizarre)
From: Erik Naggum <>
Date: 2000/03/20
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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.