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

On Feb 20, 7:05 am, Damien Kick <dk...@xxxxxxxxxxxxx> wrote:
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.

Yes, it would be less leaky. It's not a matter of characters it is a
matter of concepts. In some cases a lambda is used without the need
for a #', but in other cases it is used with one. This is an
additional concept that has to be tended to when programming in a
lisp-2. Besides messing with Arc I've only programmed in common-lisp,
and I actually think there might be good reasons to stick with a
lisp-2 because of it's ability to cut down aliasing bugs. It's
primary drawback however, is exactly this. I don't really want to get
into the lisp-[1|2] debate though. Here the point is that it is
absolutely cleaner and clearer to use a lisp-1 when passing anonymous
functions because of both the conceptual and syntactical differences.

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?

I never said that, natural languages surely are.

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 never said any of this either. Limiting the number of extra
concepts you need to deal with when translating program ideas from
your head to your computer is good. You already saw my personal rule
for method names and length.

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.

Your either completely missing the point or bad at making insults.
Moving to higher levels of abstraction is the goal, not smaller
words. Typically moving up a level of abstraction means leaving
behind details of underlying implementation so that you can get closer
to only thinking about your specific programming problem.


> 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.

You are confusing two separate topics. One is conceptual complexity
and the other is syntactical complexity. I'm sure a lisper chunks #'
just fine, but in a lisp-2 you have to maintain two concepts of a
function: one which has #' and one which does not. (< 1 2) => T


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?

I didn't concede it, I brought it into the discussion. Yes, chunking
occurs over any sequence of characters, and yes I can feel my brain
slow down when I see long words that I am unfamiliar with and even
more so with sequences of such 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?

The first sentence of the paragraph was sufficient. I think there are
many practical reasons to have groups of developers who share code
using the same representation. Posting on mailing lists, reading
comments and examples, pair-programming, discussion, editor macros,
name aliasing where one persons nickname or abbreviation is the same
as another persons new method name...

> 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.

Yup, now you get it.

> Look at Ruby for a very

well done standard library that uses clear names which arediverse
considerably shorter than what common-lisp has.

Here, you're just begging the question.

I didn't ask any questions. There are many great things to learn from
Common Lisp and its followers, but this thread shows an amazing level
of closed mindedness that makes me think it could never become the
type of vibrant community I enjoy working in. Maybe Arc could.

-Jeff
.