Re: Paul Graham's Arc is released today... what is the long term impact?

Jeff wrote:

On Mon, 18 Feb 2008, Damien Kick wrote:
Kjetil S. Matheussen wrote:
[...] I still end up writing the macro version instead
only because "(when a b)" is faster to read
than "(when a #'(lambda () b))".
>>>>
Really? Faster to read. If you sat down with a stop watch and actually
timed yourself, how long do you think it would take you to read either
form.

In a round-a-bout way I think you have hit the nail right on the head,
except you are wrong. [...]

So wouldn't that be hitting the nail right on the point?

> Of course the mess that he was referring to in
the second example is everything that is not in the first example. It
is a mess because it has nothing to do with the task at hand. In
fact, the #' syntax is a leaky abstraction. It is a piece of the
underlying implementation of a lisp-2 that is bubbling up into the
programmers point of view, and it is necessary to talk to the
compiler.

I agree that the mess in the second example has everything to do with its not being related to the task at hand. But why do you think that syntax is to blame for that? Is it somehow less of a leaky abstraction to write (lambda () b) instead of #'(lambda () b) because it has two less characters? The mismatch is semantic, not syntactic.

(when a (fn () b))

Would be no better. And, if I recall one of Kent's posts correctly, one of the advantages of Lisp-2 as a syntax is that it works well in situations in which ones does not expect everything to be passed as a function argument. (lambda (f) (funcall f *x*)) brings attention to the fact that something "different is happening".

> Liking lambda's for historical reasons is quaint, but we
are talking about how to improve a programming language, not how to
hold them back for historical warm fuzzies. In this case, the goal is
to find the most efficient way to translate ideas in our head into a
language that both people and computers can understand.

What makes you think that language is not intimately related to history? Entwined in it. Produced by it. Do you really think that the most efficient way to translate ideas in our head into language is to shorten words and reduce variety in representation by removing things like synonyms, abbreviations, and puns? I realize that programming languages are not natural languages but, seriously, if nice short, concise names was all it took to have something that worked well, why aren't we all programming in machine code? It really doesn't get much less ambiguous or pithy than that.

> When you read any words or groupings of
words for the first time you have to parse them piece by piece to map
them to their meaning. After having seen the same words or groupings
over and over your brain actually learns to recognize them as a single
unit, which lets you read and understand their meaning in much less
time.

So explain to me how seeing #' over and over again somehow does not fall victim to this process of "chunking" (IIRC, this is the term that Douglas Hofstadter uses and I kind of like the term). Explain to me how seeing the same sequence of characters repeated over and over again in a horrendously long symbol name does not somehow lend itself to recognizing them as a single unit. Do you not think that this kind of "chunking" is what allows us to subconsciously correct the spelling mistakes in a word, such that it can become difficult to even see them?

<grumble> So now I'm wallowing in the very pop physiology I am supposed to dislike. Oh, well. Always knew I was a hypocrite. And at least when I spouting *** about which I am not an expert, I'm going to at least quote somebody who is.

<blockquote cite="_Where Mathematics Comes From_, page 19">
All human beings, regardless of culture or education, can instantly tell at a glance whether there are one, two, or three objects before them. This ability is called /subitizing/, from the Latin word for "sudden." [...] In addition to being able to subitize objects in arrays we can subitize sequences. For example, given a sequence of knocks or beeps or flashes of light, we can accurately and quickly tell how many there are [...] These results are well established in experimental studies of human perception, and have been for half a century. Kaufmann et al. observed that subitizing was a different process from counting or estimating. Today there is a fair amount of robust evidence suggesting that the ability to subitize is inborn. A survey of the range of subitizing experiments can be found in Mandler and Shebo (1982).
</blockquote>

Its something similar to that about which you were writing in being able to recognize a grouping of words as a single unit. The bull*** aspect of my quoting this, however, is that they're referring to an innate arithmetic ability. I'm trying to use this somewhat unfairly to extend to language recognition. But you yourself have conceded that "chunking" allows for treating a sequence of words as a single unit and yet somehow you think that this kind of process does not also turn a sequence of characters into a single unit, such that this sequence of characters is subitized into a word, almost instantaneously. Are you really that slow of a reader that you can actually feel your brain slow down while trying to chew over big words?

> It is a bad idea if everyone is looking at things in different
ways, and depending on what editor, or browser or mail reader you are
looking at things look different.

But if I'm looking at my things in the same way every time, why do I even have to think about whatever degenerate representation you want to use? Sure, I might feel a disturbance in the force if you decide to start replacing every symbol with its Huffman encoding so that its shorter, but unless you actually force me to use your scheme, why should I even know what you're doing? And if having different ways of saying the same thing are such a bad idea, why do we have synonyms or nicknames? Thesauruses? Does your head explode whenever you find, one day, that someone used the package COMMON-LISP while, another day, someone used CL? You are aware that entire books are translated from one language into another, and yet the presence of a Portuguese translation of _Practical Common Lisp_ (well, it that ever happens) in now way makes it more difficult for me to understand the edition I have printed in English?

> Methods that are used often should
have short names because you will type them often and remember them
anyway, while methods which are used less should have more descriptive
names to remind the user of their meaning.

As it was written, the word of the Jeff. The truth made manifest in the very utterance.

> Look at Ruby for a very
well done standard library that uses clear names which are
considerably shorter than what common-lisp has.

Here, you're just begging the question.
.