Python's Original Sin
andreyf.tumblr.com
andreyf.tumblr.com
Yeah, and nobody is upgrading because it doesn't give you much incentive unless you enjoy breaking backwards compatibility. It has also been in development for at least 5 years.
I don't get why people get version numbers so literally. Perl6 is a new language inspired by Perl5. Python 3 is just a minor enhancement that happens to break backwards-compatibility. The two are not comparable.
Hrm, I think it is only even version numbers, maybe 5.28. :-)
(And check the Modern Perl movement and the backports of Perl 6 stuff like Moose. Arguably, Perl 5 should change name, too...)
they should have called it Perl++
The libraries becoming available is going to take a little while... work is being done to make pygtk available.
Numpy is a big library widely used - when this arrives then others will follow (I'd give it two years or so).
All of the semantic changes I can think of in Python could easily be implemented as syntax transformations in a way portable across implementations. Decorators, the with statement, print-as-a-function, etc... There might be some I'm missing that would be non-trivial as macros, but I'd benefit significantly just from having the ones that are plain syntax sugar without having to convince my team to use a py3-to-2 compiler.
Maybe my point was a little on the subtle side: being able to implement changes to a language's syntax and semantics without doing it again for each and every implementation is a better solution to one problem the moratorium is solving.
Also, his argument that the compatibility issues between JPython and CPython are because python isn't implemented in itself also don't hold water. One very simple counterexample would be Ruby and JRuby. Ruby isn't implemented in itself, and like JPython and CPython, JRuby and MRI are two different code bases written in two different base languages. Despite this, JRuby has kept very close syntax compatibility with the standard Ruby 1.8.x interpreter. The secret in their case isn't self hosting, but rather a very comprehensive unit testing suite for the language. (interestingly enough, developed initially by yet a third implementation of Ruby).
Didn't say that. Said that self-hosting is one solution (one Perl 6 uses), not the only one.
[Ruby's secret] isn't self hosting, but rather a very comprehensive unit testing suite for the language
No, Python also has a comprehensive test suite. The difference between Jython and Ruby is that Jython isn't as well maintained as the Ruby branches. Self-hosting the syntax is an architectural solution which requires zero additional effort to implement syntax upgrades.
Ruby has a very flexible syntax, but there's no particular reason to call it extensible. It's also not a great example of forward progress considering that the latest language version (1.9) has been around for years and none of the alternate implementations fully support it, not even the one that is now on the verge of release (Rubinius).
Possible reasons for this: People working on alternate implementations of Ruby started on 1.8.x. 1.9 has been evolving over time (even after its release) , and is different enough from the 1.8 version that having a single interpreter that can handle both 1.8.x and 1.9 is non-trivial. The 1.8.x version is by far the most popular, so people working on other implementations focus on them, looking to fix bugs, make them faster, etc.
I think that were there a big demand for JRuby 1.9 or IronRuby 1.9 then the appropriate teams would have it done, but right now it isn't (I imagine) a big priority.
Not to argue against your point (you don't need self-hosting to get cross-implementation compatibility), Jikes RVM < http://jikesrvm.org/ > is a JVM written in Java itself.
A good example of this is generators. Via PEP 255 they were introduced in Python 2.2, and required the addition of the "yield" statement to the syntax. Recently Squeak (an open-source Smalltalk implementation) added generators to the standard library, with no syntax changes required. It was a much smaller project, and the change can easily be ported to other Smalltalk implementations without participation from the maintainers of the core libraries or virtual machine.
So languages with very simple syntax, like Smalltalk and Lisp just don't suffer from the high level of language evolution friction that Python does. In practice, the diversity of dialects and the ease with which the language can change creates the kind of market system of language features that andreyf mentioned here on HN.
The neat thing about Perl6 is that it takes a different approach. Perl doesn't have a simple syntax like Smalltalk or Lisp. Instead it has a very powerful system for text manipulation that can handle the complexity of Perl's syntax. In theory, that's even more powerful than Lisp macros or Smalltalk's implemented-in-Smalltalk compiler. It'll be very interesting to see how it plays out in practice.
I'm hitting one related issue right now at work: we want to switch to Jython to take advantage some JVM features, but need to weigh the risk that it might never move past Python 2.5 syntax [1]. That's not a deal-breaker, but I'm an enormous fan of where Python syntax has gone since then, so it pains me especially. With a self-hosting syntax interpreter, even a minimally maintained project like Jython could keep up with most changes.
Another less-practical issue is that of syntax evolution: like Apple, Python has taken the route of benevolent-overlord to make design decisions. Thanks to the good taste of Steve and GvR, I think that's worked out really well. But neither is perfect, and especially in the case of programming language design, I'd wager the end product could benefit from having a market system of minor syntax features competing in user-space, not just in Guido's head. Just as "from __future__ import print_function" changes the syntax of a file, so could "from __macros__ import anaphoric_if".
1. The Jython project lead is no longer working on it full-time: http://fwierzbicki.blogspot.com/2010/02/my-new-job-at-sauce-...
With this in mind, wouldn't his move away from Jython full time actually make it better (ie infuse new ideas) so we might get 2.6 comparability sometime down the line?
Would it be easier to for alternative implementations (non-CPython ala Jython, IronPython, etc) to keep up if the syntax was portable between them? Yes, of course. Is this a "Design Flaw"? Not in any way.
Portable syntax between implementations is not a primary goal of Python (the language) so I don't see any merits for criticizing it for not taking a feature never previously desired (most of the alternative runtimes are relatively young) into account in the underlying design.
If you need to alter/extend the syntax to python at some point I'd advising looking at the python magazine article on implementing DSL's w/pyparsing noted here: http://pyparsing.wikispaces.com/Publications
If are in frequent need to alter/extend the syntax of the language you are using, and it is a non-trivial task, then you are using the wrong language.
PyPy is taking precisely this approach, and GvR in an interview or two, has blessed it as the way forward.
So I think OP is a little late to the game.
Python's sin is that it has statements at all.
a < b
ifTrue: [^'A is less than B']
ifFalse: [^'A is greater or equal to B']
Such a Lisp also has no users.
Hands up, who has heard of ACL2 before?
In fact, I am appalled so few people, apparently, heard of it.
What's next, you're going to tell me you write unit tests? Hahahahah.
I was under the impression that def x(a):... was only a pretty way to say x = function(a)...
I have to agree print is a weird thing, but what other statements bother you so much?
The benefit of self hosting is that all libraries are instantly available on every implementation. That's important because the libraries comprise hugely more code than the language itself I would think.
Edit: Only in a language group like rubyists do you see quick adoption and change and for many applications this isn't always great I'll take stable libraries over ever changing applications any day.
Now, I'm not sure if he still thinks Python is dead or not, but that's not what his post is about. He was just stating his opinion that Python has a "[...] fundamental design flaw: a syntax which requires human compilation."
Python is not dead. Python is hurting from a bad design decision that doesn't let multiple interpreter implementations share components that they could have. This makes it impossible for minimally maintained branches (like Jython) to keep up with the language, and so hard for better-maintained branches (like IronPython or pypy) that it necessitates a moratorium on the syntax as a whole.
I still think python's focus is in a slower world and as a python user I am okay with that.
As many others have said, changing syntax is really one of the most trivial parts for alternative implementations to keep up with when moving to new versions. That "hurt" hasn't been fixed because it doesn't really hurt very much...
Yes, Python has put a moratorium on syntax changes in part because IronPython, Jython, and pypy aren't keeping up with changes. As felideon points out, I regret saying it's dead - it's just that syntax innovation that's dead (and only for a little bit), and that's a shame.