Guido recently posted
an interesting thought about his recent decision to
reject two proposals to add lambdas to Python.

It’s a hard problem, but the reason why this particular aspect is interesting
is the grounds for refusal:  not only does Guido think that all the
proposals so far have failed to be "pythonic" enough (especially because they
force the language to switch between two modes, one where spaces are significant
and one when they’re not), but he flat out claims that there is no solution to
this problem.

In short, there will never be any lambdas in Python.  And a bunch of
other potential features will most likely never make it into the language for
that reason.

Of course, Python is Guido’s language and ultimately, what he says goes. 
I certainly respect his efforts to keep his language in line with his

But it makes me sad that a feature that looks so elegant (space significant
indentation) might actually spell Python’s doom.  The problems that
developers solve
every day change constantly, and languages need to evolve as well if they want
to stay relevant, but unfortunately, Python seems to be headed toward an evolutionary dead end.

In 1998, Guy Steele published a seminal paper called
Growing a
in which he spelled out a few rules to make a language as flexible
to change as possible.  Of course, we can’t expect Python to have been
designed with these rules in mind since it was created in 1990, but after 1998,
it would definitely have been wise to try and incorporate some of Guy’s ideas to
make sure that Python would be able to withstand the tides of changes.

Interestingly, Matz (the author of Ruby) saw this coming.  Three years
ago, I posted an article called
Flaws in Ruby in
which I pointed out a few aspects where I thought Ruby could improve.  One
of the improvements that I suggested was space-significant indentation. 
Matz commented on this entry and said:

"The meaningful indenting" is plain wrong for a language like Ruby,
where expressions and statements are interchangeable. See the lambda problem in
Python. Guido decided to remove it in the future. But I won’t give up lambda nor
value giving blocks.

It’s quite eerie to see Matz talk about the "Lambda problem in Python" back
in 2003.  He definitely saw that one coming, and as shown by Guido’s
article, the topic is as hot today as it has been on the Python mailing-list
these past years.

From this standpoint, Ruby seems to be better fitted to face the challenges
of the future.  First because it is not limited by the space indentation
problem (an improvement I was wrong to suggest, as it turns out), and second because it seems to have a decent amount of potential to
create Domain Specific Languages (for example, Ruby on Rails lets you use
keywords such as :one_to_many which are not recognized by Ruby but which
syntactic placement simplifies greatly programming).

I’ll conclude by quoting two
that were made by readers of Guido’s article, which summarize my point well:

Having toyed
around with Ruby and blocks, I know how nicely they work, how cool they look,
how gracefully they fit in the language. But Python’s not ruby, something that
works for ruby doesn’t necessarily work for Python, and blocks don’t. Everyone’s
time would probably be much better invested in creating useful, new, original
features (== ripping Lisp or Smalltalk ;) )

I think it
would be sad to see Python as the last kid on the block without a cool bike.

As opposed to the last person, my point is not to say that blocks are cool or
uncool:  they are just the symptom of a deeper problem in Python’s design
and implementation that will most likely prove to be a big challenge for its
adaptability in the coming years, with Ruby and Groovy setting the bar
increasingly higher.

What do you think, is Python in danger to be marginalized because it can’t
evolve any more?