RE: succinctness = power

["Anton van Straaten" <address@hidden>]

> > If so, to say that the aim of a language is not to
> > be succinct seems almost to say that its aim is not
> > to be a good programming language.
>
> Not unsurprisingly, I disagree.

The way I see it, you actually agree:

> So you want a programming language that maps as closely as possible on
> the *way you think about the problem*. You want to model the problem
> domain, not tell the computer in mind numbing detail how to compute
> something. Let's call this property expressiveness. Succinctness flows
> from expressiveness, not vice versa.

I think that's an important and valid point, but it doesn't negate the goal
of succinctness.  I proposed in another message that the real issue is how
succinct one can be and still meet all the diverse goals inherent in a given
program.

> Also, neither succinctness nor expressiveness can be
> treated as absolute drivers for language design.
> Otherwise you are forced to add primitives for every
> domain and programming model.

Those two sentences may not be related.  An expressive, succinct,
*extensible* language allows users to add primitives for their own domains
and programming models.  Which is why extensibility features, such as
objects or data types, closures, macros, and continuations, are so useful
for the kind of programming where you're attempting to move the level of
expression closer to the problem domain.

> There is a tradeoff between expressiveness and
> language size (similar to size of alphabet versus length of words).

Hmmm, if anything, it seems to me that some of the most expressive languages
are the smallest, Scheme and Smalltalk being two prime examples.
Domain-specific functionality only increases the size of the underlying
language if it has to be added as a built-in language feature rather than
something that could be easily implemented by a user of the language.

> For many programmers, Python demonstrably succeeds at fitting their
> mental models:

I don't think the discussion should really be framed in terms of Python vs.
Lisp or anything else.  It seems to me none of us would be on this list if
we thought we had found the one perfect language to express all the
computations we want to be able to express (unless we're simply here to
impose our favorite language on everyone else).

But it makes sense to talk about how certain capabilities are or aren't, or
should or shouldn't be expressed, in different languages.  Python already
has a lambda feature, which in the latest versions seems fairly complete.
To argue that Python:

* shouldn't have that feature, or
* doesn't need it, or
* that it doesn't add anything, or
* because it isn't complete (if it isn't) it shouldn't be used, or
* that it shouldn't be completed

seems to me simply to be an argument for limiting a certain kind of
extensibility, and thus for a restriction to expressiveness, unless of
course it can be shown that anything that can be done with lambda can be
done as expressively without it, in the language in question.

The problem with showing that lambda isn't needed is that an anonymous
function feature alone (even ignoring other aspects of lambda) is very
expressive, and if you implement anonymous functions using anything less
than lambda-like functionality, it's not likely to be as expressive.
Therefore, lambda is essential.  :)

Jumping threads:
> At the very least, the name of the [lambda?] operator is brain-dead.

It's just terminology.  It's actually a very specific concept, with rather
broad ramifications, and a commonly accepted definition.  The only good
reason to call it something else would be for brevity, or perhaps internal
consistency (e.g. "function" in Javascript).

Personally, I like the backslash often used in textual LC representations,
e.g. \x.x*2 - but that's largely because it's reminiscent of the lambda
symbol, which is where commonly accepted definitions come in again.

Anton