41–50 of 55 posts
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.
Earlier quoted context omitted.
> Say what you will about python 3, but at least it exists and has been released. 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 b…
Yea Perl 6 is a new language, but Perl 1-5 were the same language just like Python 1-3 are. What should have been Perl 6 or even 7 just got released as Perl 5.12. Perl 5 isn't going anywhere, I can imagine in 10 years we'll be seeing Perl 5.27. It doesn't really make sense, if they wanted to write a new language but they wanted to use the Perl moniker for marketing purposes they should have called it Perl++
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...)
Earlier quoted context omitted.
> Say what you will about python 3, but at least it exists and has been released. 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 b…
Yea Perl 6 is a new language, but Perl 1-5 were the same language just like Python 1-3 are. What should have been Perl 6 or even 7 just got released as Perl 5.12. Perl 5 isn't going anywhere, I can imagine in 10 years we'll be seeing Perl 5.27. It doesn't really make sense, if they wanted to write a new language but they wanted to use the Perl moniker for marketing purposes they should have called it Perl++
they should have called it Perl++
You're still a few layers above the truly fundamental issue. Python's sin is that it has statements at all.
Can you explain what you mean by this please?
Earlier quoted context omitted.
I did re-read the post and it just seems like perl 6 has reassured him that python is dying but I have to disagree, maybe jython is dead for what he wants but python is not dead and from the looks of it jython is not dead.
Err, I guess this teaches me to not to even mention simplistic emotional responses like "Python is dead". Let me try to be as clear is possible: 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 fo…
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...
I'm not sure I buy this argument. The author seems to be arguing that it's a fatal design flaw for a language not to be implemented in itself. But as near as I can tell not that many languages are implemented in themselves. I'm pretty sure Java and C# (as examples) are implemented in C. Also, his argument that the compatibility issues between JPython and CPython are because python isn't implemented in itself also don…
I think the important property the author is talking about is not self-hosting, but rather extensible syntax . But your point still stands in that very few languages have this feature. 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 alt…
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.
Earlier quoted context omitted.
Can you explain what you mean by this please?
There's no reason why there should be two kinds of things code can be made up of. (statements vs expressions) In a well-designed language, everything that is a statement in Python would just be implemented as an expression that returns nil.
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?
Earlier quoted context omitted.
Incorrect: ACL2, an industry-standard automated theorem-prover, is written in a side-effect-free variant of Common Lisp. It has both an implementation and users, including users outside of academia. http://en.wikipedia.org/wiki/ACL2
I guess both (no implementations, no users) were meant in relative terms, and in that light they describe reality pretty well. Hands up, who has heard of ACL2 before?
In fact, I am appalled so few people, apparently, heard of it.
"band-aids like the moratorium become necessary solutions, alleviating the symptoms of a more fundamental design flaw: syntax and semantics which require human implementation instead being portable from one implementation to another." 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 Fla…