Re: Language Marketing (was: What design is: 911 vs. Fleetwood)

[Michael Vanier <address@hidden>]

> Date: Fri, 14 Dec 2001 21:18:42 -0800 (PST)
> From: Paul Graham <paulgraham@yahoo.com>
> 
> You're right of course; more important to have few tokens
> than short tokens.  
> 
> I have found though that short tokens have some unexpected
> benefits.  In Lisp there are some names that send your
> code flying toward the right side of the screen, and 
> often eventually force you to break lines you'd rather not.
> The CL
> 
> (mapcar #'(lambda
> 
> becomes
> 
> (map (fn

or "(map (lambda" in scheme, which is much less crufty feeling than the
CL.  I like the Arc syntax better though.

> 
> in Arc, and trivial as this kind of renaming seems I've
> found it makes a difference in the way the language feels.
> 
> Arc right now is half written in Arc and half in CL, and
> the CL bits are starting to feel like ill-fitting shoes.
> I find myself writing macros to make the CL code look
> more like Arc, because e.g. I can't stand all the extra
> parens I have to type in a CL let now.
> 
> The J quicksort is impressively short in tokens as well as
> characters.  Is that the canonical way to write it?
> 
> --pg

I assume so, since I took it from the "J phrasebook" (which is downloadable
for free).  The first function:

    sel =: 1 : ']#~]x.{.'

is actually an explicit definition, because it uses the x. operator (which
means, I believe, the leftmost argument to the function being defined).
There is probably a way to define it in a more variable-free manner (a
tacit definition using J terminology), but I don't know enough J to attempt
it myself :-)

Let me be clear: J is undoubtedly a brilliant creation.  But I find the
code to be unreadable, and I think using longer token names might fix that
to a large extent.

Mike


> 
> --- Michael Vanier <mvanier@bbb.caltech.edu> wrote:
> > 
> > > Date: Fri, 14 Dec 2001 15:45:13 -0800 (PST)
> > > From: Paul Graham <paulgraham@yahoo.com>
> > > 
> > > We're designing Arc roughly for the language equivalent
> > > of the 1970 Porsche 911 market.  People who want to 
> > > solve hard problems with few tokens, and who are not
> > > going to be intimidated by what a language has to look
> > > like to do that.
> > > 
> > 
> > I think you also have to distinguish between conceptual density and
> > token
> > density.  I like languages that allow interesting programs to be
> > expressible using a minimal number of language constructs.  I care
> > much
> > less whether the language construct is called "fn" or "lambda" or
> > "make-function".
> > 
> > To give an extreme example, the language J (a modern APL;
> > http://www.jsoftware.com) has a high conceptual density (good) and
> > also
> > encourages programs that are written in a line-noise syntax with very
> > few
> > characters (bad, IMO).  This gives rise to programs like this one,
> > which
> > does quicksort:
> > 
> >     sel =: 1 : ']#~]x.{.'
> >     qs  =: ] ` ($:@(<sel),=sel,$:@(>sel))@.(1:<#)
> > 
> > I think the J designers could have produced a much clearer language
> > if they
> > expanded some of the functions into full names instead of one- or
> > two-letter abbreviations.  Of course, you can do this yourself in J,
> > so
> > it's not really a swipe at the language as much as at the culture.
> > 
> > Mike
> > 
> > 
> >