The Art of Lisp and Writing (2003) (dreamsongs.com)

Choice quotes:

"Lisp is a medium for working with a computation until it is in balance with its external and internal requirements. At that point it can be decorated with performance-enhancing declarations and perhaps additionally modularized. In this it is more like an artist's medium than what many think of as a programming language."

"Writing a beautiful text takes sitting before a medium that one can revise easily, and allowing a combination of flow and revision to take place as the outlines and then the details of the piece come into view. Changes are made as features of the writing emerge—first the noise, then the sense, the force, and then the meaning—and the work of the writer is to continually improve the work until it represents the best words in the best order. Great writing is never accomplished through planning followed by implementation in words, because the nature of the word choices, phrasings, sentence structures, paragraph structures, and narrative structures interact in ways that depend of each other, and the only possible plan that can be made with which a writer can "reason" about the piece is the piece itself."

"The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James [Gosling] says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you're inadvertently making. There are, of course, many situations when making change more difficult is the best thing to do: Once a program is perfected, for example, or when it is put into light-maintenance mode. But when we are exploring what to create given a trigger or other impetus—when we are in flow—we need to change things frequently, even while we want the system to be robust in the face of such changes."

  Nobody is writing satellite code in CLOS, though. 

  Even C++ would be a bit more safer depending on what flavor of CLOS you are using.

This person isn't a very good writer. I've read through it once and I'm not sure what the point is supposed to be. LISP and Java are different -- ok, that's pretty obvious. Some fuzzy stuff about embracing creativity, ok, fair enough but also fairly trite and more suited to an Apple TV commercial. Programming is an art as well as a science, yes, that's nice. Some things are plainly false, for example, "the theory of quantum mechanics and the expanding plausibility of complexity science threw everything we knew about the world into doubt." Did it really? So before we knew that London was the capital of the UK and that 2+2=4 but the "expanding plausibility of complexity science" caused people to doubt that?

In sum, a tedious and pretentious article.

"Lisp is the language of loveliness. With it a great programmer can make a beautiful, operating thing, a thing organically created and formed through the interaction of a programmer/artist and a medium of expression that happens to execute on a computer."

It's this kind of statement that makes me suspect Lisp is not very practical. I'm not programming for the sake of programming to create something that "happens to execute on a computer." There are other artistic endeavors for my free time that are more interesting than a lovely computer language.

  def f()
    puts "f1"
  end

  f()

  if true
    def f()
      puts "true"
    end
  else
    def f()
      puts "false"
    end
  end

  f()

  f1
  true

  (defun foo ()
    (progn (format t "~a~%" (read-line))
           (foo)))

  (defun foo ()
    (progn (format t "~a and john~%" (read-line))
           (foo)))

  $ irb
  >> def go
   >   puts "what"
   >   debugger
   >   go
   > end
  >> go
  "what"
  # stops on debugger line
  >> Object.module_eval "def go; puts 'wat'; end"
  >> continue
  "wat"

  class Object
    def defsetf(name)
      $setf[self.class] = name
    end
  end
  def setf(class, *args)
    class.send($setf[class], *args)
  end
  class Whatever
    defsetf :set_something
    def set_something; end
  end
  
  # elsewhere...
  setf Whatever, instance, value

Ignorance more frequently begets confidence than does knowledge. such a good summary of Java (and now Javascript) madness.)