| Damien Kick 2008-02-20, 4:48 am |
| Jeff wrote:
>
> 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 shite 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 bullshit 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.
|