Re: succinctness = power

[Paul Prescod <address@hidden>]

Anton van Straaten wrote:
> 
>...
> 
> > 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.  

We could list a dozen goals for programming languages. I would agree
with you that succinctness is on the list. Paul Graham said, more or
less, that it *is* the list. Or to be more serious, he said that the
*primary goal* of programming languages is succinctness. So for
instance, Python's predecessor was usability tested. During the
usability test it was found that adding a colon to the end of
suite-introducing operators decreased the number of errors
significantly:

if x:
	foo()

According to the idea that a programming language is first and foremost
about succinctness, that would be a bad choice, no matter whether it
made reading programs easier, or increased the Gross World Product by 5%
or whatever.

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

Adding a primitive takes more code than using one built into the
programming language. Therefore a programming language that already
anticipates every programming style will always produce more succinct
code than one that is extensible.

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

That's not something to be shown. It is a well-known fact. lambda is
syntactic sugar in Python.

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

Or perhaps to use a word that English speakers would be able to
remember.

 Paul Prescod