Re: succinctness = power

[Paul Graham <address@hidden>]

--Paul Prescod wrote:
> Anton van Straaten wrote:
> > 
> > Because lack of succinctness usually means your systems are not as
> > "normalized" or well-factored as they could be, which means that they won't
> > be cheaper, to develop or to maintain.  
> 
> So you're talking about other factors (extent of normalization) that are
> *reflected in*, not *caused by* succinctness. It is the other factors
> that are the power. Succintness is a side-effect of optimizing for them.
> 
> > ... I'm not really talking about
> > token-level issues, I'm talking about capabilities a language provides for
> > high-level reuse and architecture.
> 
> The paper under discussion talks about parse tree tokens:
> 
> "I think a better measure of the size of a program would be the number
> of elements, where an element is anything that would be a distinct node
> if you drew a tree representing the source code. The name of a variable
> or function is an element; an integer or a floating-point number is an
> element; a segment of literal text is an element; an element of a
> pattern, or a format directive, is an element; a new block is an
> element. There are borderline cases (is -5 two elements or one?) but I
> think most of them are the same for every language, so they don't affect
> comparisons much."
> 
> "This kind of metric would allow us to compare different languages, but
> that is not its main value. The main value (at least for me) of the
> succinctness test is as a guide in designing languages. The most useful
> comparison between languages is between two potential variants of the
> same language. What can I do in the language to make programs shorter?"
> 
>  * http://www.paulgraham.com/power.html
> 
> That way madness lies. You can *always* make any given program shorter
> by adding special cases or short-cuts or simply more primitives to the
> library or (even more succinct!) to the language. If you use that as
> your success metric you will end up with a terrible programming
> language. 

Certainly you want to look at what can make program*s* shorter,
not just a particular program.  Is there stuff you can do that 
makes all or most programs shorter and yet is a bad idea?  
Arguably not; presumably to do that you'd have to be capturing 
some common abstraction.

> There are
> languages out there that have been way down that path.

Examples of that type are exactly what I'm asking for.  So
if you (or anyone on LL1) can think of languages that force
programmers to be excessively terse, let's see them.  I'm
not proposing this as some kind of challenge.  I think this
is an important question, and such examples if they exist
would be very interesting to see.

> 
> I agree that "ability to factor out common patterns" is a vital feature
> of programming languages. We usually call that "extensibility" or
> "expressiveness" or mabye even "power", but not succinctness. It is
> *reflected in* succinctness (partially), not *caused by* succinctness.
> Python is designed to be powerful in that way (though not necessarily
> the MOST powerful). It is not designed to be succinct. Sometimes what is
> one line in another language will be two lines in Python because the
> Python version is optimizing for something other than token count or
> line count. 

Well, if the power of a language as a tool is reflected in
something other than succinctness, tell us what.  The reason
I wrote that essay is to propose succinctness = power as
kind of the first step in a newton's method-like approach
to figure out what we should be aiming for in language design.
To refine the estimate we need counterexamples, if there
are any.

I figure if any group can come up with good answers, it is
this mailing list.