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/