Indentations and future evolution of languages

[bearophileHUGS]

This is an interesting post, it shows me that fitness plateau where
design of Python syntax lives is really small, you can't design
something just similar:

http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html

Living on a small fitness plateau isn't good, even if it's very high,
because it's evolutionary unstable :-(
Indentation-wise Haskell syntax seems one of the very few local maxima
that is close enough to the little fitness plateau where Python is.

Bye,
bearophile

 

[Steven D'Aprano]

This is an interesting post, it shows me that fitness plateau where
design of Python syntax lives is really small, you can't design
something just similar:

http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html

Living on a small fitness plateau isn't good, even if it's very high,
because it's evolutionary unstable :-(

You're assuming that (1) evolutionary changes occur at random, and (2)
there's value in there being many similar species/languages sharing a
fitness plateau.

Neither of those necessarily follow. Few languages (if any) undergo random
mutation -- a better model for programming language evolution is directed
mutation and artificial selection rather than evolution by natural
selection with random mutation.

It's very rare (non-existent) for two species to share a niche, and
therefore co-exist in a fitness plateau. Due to network effects, much the
same happens for languages: a few popular languages (e.g. C, Java, Perl)
overwhelmingly capture a market. Given the popularity of
Python, "Python-like" languages will be doomed to tiny niches -- unless the
language discovers some sort of distinguishing feature that shifts them
into a different, but similar, fitness plateau, where they can capture a
market large enough to get their own network effort, or if the original
language becomes moribund.

E.g. some hypothetical Python clone with optional braces might take off,
thus proving that all the l^H users begging for braces were right. Or the
shift to multi-core processors and Guido's reluctance/inability to remove
the GIL might doom Python to only being useful on an ever-shrinking pool of
single-core CPUs.

Indentation-wise Haskell syntax seems one of the very few local maxima
that is close enough to the little fitness plateau where Python is.

If the article is right, there is a fundamental incompatibility between
indentation-sensitive languages and languages with multi-line anonymous
blocks. You can have one, or the other, but not both, unless you're willing
to have a "practicality beats purity" trade-off and create a second way of
grouping blocks, and who knows whether that will turn out to *actually* be
practical?

That doesn't say anything about the narrowness of the Python fitness
plateau. There could be room for a dozen languages with the same approach
to indentation as Python.

 

[Martin P. Hellwig]

Living on a small fitness plateau isn't good, even if it's very high,
because it's evolutionary unstable :-(

<cut>
Actually I think, in biological sense speaking [citation needed], if one
path has an advantage over the other path, even if the other path is in
majority, it will grow over time in percentage and offshoot more
sub-paths the other path.

 

[Paul Rubin]

Indentation-wise Haskell syntax seems one of the very few local maxima
that is close enough to the little fitness plateau where Python is.

It is odd, the article claims indentation-aware syntax only works
in languages that separate statement and expressions, but also
mentions Haskell, which doesn't have such separation. Even things
like do-blocks are just syntax sugar for function application.

 

[Kay Schluehr]

This is an interesting post, it shows me that fitness plateau where
design of Python syntax lives is really small, you can't design
something just similar:

http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mort...

Living on a small fitness plateau isn't good, even if it's very high,
because it's evolutionary unstable :-(
Indentation-wise Haskell syntax seems one of the very few local maxima
that is close enough to the little fitness plateau where Python is.

Bye,
bearophile

This is all derived from a blog post about a language no one cares
about?

 

[Marco Mariani]

You can have one, or the other, but not both, unless you're willing
to have a "practicality beats purity" trade-off and create a second way of
grouping blocks,

I propose /* and */ as block delimiters.

There, you have auto-documenting code, ahah!

 

[Tim Rowe]

This is an interesting post, it shows me that fitness plateau where
design of Python syntax lives is really small, you can't design
something just similar:

http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html

I don't think the article is right that "it's silly to have some
expression/statement groupings indentation based and some grouped by
enclosing tokens" -- provided it's done right. The OCAML-based
language F# accepts OCAML enclosing tokens, but if you mark the groups
with indentation they're not necessary (but still legal). That seems
to me to work pretty cleanly.

 

[Kay Schluehr]

This is an interesting post, it shows me that fitness plateau where
design of Python syntax lives is really small, you can't design
something just similar:

http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mort...

Living on a small fitness plateau isn't good, even if it's very high,
because it's evolutionary unstable :-(
Indentation-wise Haskell syntax seems one of the very few local maxima
that is close enough to the little fitness plateau where Python is.

Bye,
bearophile

Here is a somewhat longer comment:

http://fiber-space.de/wordpress/?p=121

Take it with a grain of salt and have much fun.

 

[skip]

John> The only complaint I have there is that mixing tabs and spaces for
John> indentation should be detected and treated as a syntax error.

Guido's time machine strikes again (fixed in Python 3.x):

% python3.0 ~/tmp/mixed.py
File "/home/titan/skipm/tmp/mixed.py", line 3
print(a)
^
TabError: inconsistent use of tabs and spaces in indentation

Skip

 

[John Nagle]

Here is a somewhat longer comment:

http://fiber-space.de/wordpress/?p=121

Take it with a grain of salt and have much fun.

Python already has nested functions. So anything for which you really
need a lambda function can already be done. You just have to name
the function.

This isn't a popular feature, because in a language with no declarations
to determine scope, having too many nested scopes is confusing. But
it's there.

As for Python indentation, that seems to work reasonably well. The only
complaint I have there is that mixing tabs and spaces for indentation
should be detected and treated as a syntax error. (Whether to use
tabs or spaces is a religious argument, but mixing them is clearly
wrong, and results in non-visible bugs. CPython should enforce
that.)

John Nagle

 

[Kurt Smith]

   John> The only complaint I have there is that mixing tabs and spaces for
   John> indentation should be detected and treated as a syntax error..

Guido's time machine strikes again (fixed in Python 3.x):

   % python3.0 ~/tmp/mixed.py
     File "/home/titan/skipm/tmp/mixed.py", line 3
       print(a)
              ^
   TabError: inconsistent use of tabs and spaces in indentation

Or just use the '-tt' command line switch to force indentation consistency:

ksmith@work:~/tmp [366]$ python2.5 -tt mixed.py
File "mixed.py", line 6
print a
^
TabError: inconsistent use of tabs and spaces in indentation


Kurt

 

[Tim Rowe]

Boy, I really want to like F# -- a lot of smart people have worked on it --
but every program I write is completely incomprehensible to me a week
later.

The more I look around, the more I like Python.

Indentation works just fine in Python, too, just in case anybody
hadn't noticed ;-)

My point was that Python isn't alone on that whitespace-significant
plateau. F# is up here too. And so is FORTRAN, of course. We try to
ignore FORTRAN, but the distance we are able to edge away from it goes
to show how big the plateau is.