Subject: Re: new to lisp (3rd time lucky)
From: Erik Naggum <erik@naggum.no>
Date: 2000/03/24
Newsgroups: comp.lang.lisp
Message-ID: <3162901564202112@naggum.no>

* Natalia <nati@one.net.au>
| lisp is frying my brain, i think i will stick to
| subjects that program in c from now on.

  well, take it from an old hand: the only reason it would be easier to
  program in C is that you can't easily express complex problems in C, so
  you don't.  I have 17 years of C programming experience, and I'm damn
  good at it, but that's also _why_ I program in Common Lisp.  but perhaps
  you need a few years of C programming to appreciate better languages -- I
  have repeatedly said that programmers graduate into Common Lisp as they
  tire of inferior languages.  however, getting too good at something that
  is not good for you is _really_ bad for you, as it means you'll have to
  accept a temporary reduction in living standards if you switch, and lots
  of hard work on the side with little or no pay if you decide to combine
  the two.  therefore, another saying: life is too long to be good at C/C++.

  it is probably C that _has_ fried your brain, by the way.  not that this
  will comfort you or anything, but note that if you are used to C, the
  utter pointlessness of most of the exercises in recursion that Lisp and
  Scheme teachers tend to push on unsuspecting students become so glaringly
  visible that you would never even think of recursion again, even when it
  is clearly the best solution.  this doesn't mean that recursion is bad,
  it only means that iteration is better in a lot of cases where recursion
  adds nothing to the understanding of the task at hand.  the lesson to be
  learned from this is that giving exercises in the proper use of recursion
  is much harder than giving lessons in the proper use of iteration, and
  indeed requires a much deeper understanding of the problems for which
  recursion is the optimal solution, both in terms of what you describe to
  the intelligent programmer and what you execute on the hardware.

  e.g., in your current problem, it is obviously a lot smarter to iterate
  over a list than to recurse over it (despite what your teachers may tell
  you about the "instructiveness" of such endeavors), yet you must recurse
  if and when the element in the list is itself a list, and that's the
  valuable part of the exercise.

#:Erik