On Tue, Aug 08, 2006 at 10:31:30PM +0900, M. Edward (Ed) Borasky wrote:
> Charles Hoffman wrote:
> >That makes sense to me, except that it doesn't seem all that different
> >from what you do with any language by writing functions and classes and
> >the like.  You end up with all these concepts that you've defined in
> >code and given names to, and then work with those.  So why do Lispies
> >make such a big deal over it?
> >  
> I did something similar a long time ago in macro assembler, which I 
> learned a long time before I learned Lisp. Interestingly enough, I dug 
> out my copy of Leo Brodie's "Thinking Forth" last night. That 
> programming style, and the term "factoring", are prominent in that work 
> (which by the way is available on line now as a PDF). I think it's 
> something all programmers of a certain level of maturity do regardless 
> of language.

That's true, but the advantage to Lisp, it seems to me, isn't merely a
perception that has grown from "we did it first" syndrome.  I think it
boils down to the fact of Greenspun's Tenth Rule:

  Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C
  or Fortran program contains an ad-hoc, informally-specified bug-ridden
  slow implementation of half of Common Lisp."

More generalized, any sufficiently complicated program written in a
language that doesn't have the same facilities for (as I put it earlier)
jargon-definition as Lisp (which means basically all languages, still,
though some like Ruby are getting awfully close) must essentially
implement part of a Lisp semantic structure for certain types of highly
complex problems.  In the case of something sufficiently low-level, such
as C or Fortran, that pretty much means a very scattered Lisp
implementation for particularly complex problems of any type.

For a significantly Lispy language like Ruby, however, there's a
nontrivial percentage of potential problem domains for which Ruby
already contains all the necessary behaviors of Lisp to solve them in
the most efficient manner possible, and in addition to that Ruby
implements some excellent features that are not default to Lisp but
might be created within Lisp to solve certain types of problems.  This
makes Ruby more convenient for solving some problems and (roughly)
equally convenient for solving other problems.  There are then a
fairly small set of problem types for which one would have to
reimplement Lisp to most-efficiently solve the problem in Ruby.

The key, of course, is to pick the language that best suits what you do
when programming: if your language of choice already does (almost)
everything for which you'd have to create your own syntax in Lisp, you
probably have the right language for the job.  If not, you might need to
find a different language that does so -- or use Lisp to abstract the
problem sufficiently to make it easy to solve.

The way this all works can be analogized to trigonometry: in trig, there
are three basic "laws" from which all other rules for doing trigonometry
are derived.  Lisp is like those "laws" with a syntax designed to
simplify the process of derivation.  Other languages (such as Fortran,
to pick a target at semi-random) are like a set of useful derivations
that you've memorized to take a test in a trig class.  One can work
backward from those derivations to arrive at the original three "laws"
of trigonometry, and from there arrive at other derivations that can be
used to solve certain problems, and that tends to be necessary in a lot
of complex problem solving to some degree at least.  Some languages
provide closer approximations to those three basic principles by
default, so that less work is necessary to solve problems not central to
the design of the language (I'm looking at you, Ruby), and so on.

These opinions are not representative of the management.  No programmers
were harmed in the making of this lengthy ramble.  We now return you to
your regularly scheduled programming.  Hah.  Programming.  Get it?

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent:  a Signify v1.14 production from http://www.debian.org/