Hacker News Reader

Comment by GuiA | Hacker News Reader

Python 3 came from a good place, and it definitely fixes many problems that sorely needed fixing, but it was doomed to failure from the start (and many developers said that in 2008 already).

For all intents and purposes, Python 3 is pretty much a new, separate programming language. Sure, it's very close to Python 2.x, but you don't have out of the box retro-compatibility so that pretty much kills it right there.

Python 2.x is so huge in terms of its use around the world and available libraries and resources for it that you just can't say "hey, the new version of Python will in practice break everything" and expect it to fly.

I love Python and the community around it (and have several packages on pypi myself), but Python 3 is a joke.

If we didn't want to kid ourselves, we'd kill Python 3 and back port the interesting features, like Alex suggests. At this point though, too much effort and egos are involved to make this realistic.

View on HN

> If we didn't want to kid ourselves, we'd kill Python 3 ...

Using Python both personally and professionally, I do not think it is necessary. I already came across a few 3.X features, that I miss in 2.X and I write most 2.X code "in preparation" for the jump. But that's it, it is a jump, still.

The most interesting part of the post is the feedback matter, which seems to be accidental, but isn't since an open source language is shaped by the people - something you can forget, when you are not a contributor (which most of the people might not be).

But you've just missed Alex's whole point.

You're fine. 98% of PyPI downloads are not. That's a startling statistic, and argues that something IS necessary, rather than the status quo of shaming the top 1000 Python packages sans 3K support and telling people "it's really not that bad."

It is that bad, in terms of adoption of the first 5 years of 3K's release. And unless we want to spend the next decade trying to get to 50% mindshare with 3K, the community needs to suck it up and change tacks.

The definition of insanity is trying the same solution twice and expecting different results.

> but you don't have out of the box retro-compatibility so that pretty much kills it right there.

I don't know if that's necessarily a foregone conclusion. Scala releases aren't always/usually backwards-compatible, and you'd be hard-pressed to find people still using much older versions.

I'm not too familiar with Scala; but isn't its life at a different stage than Python's?

Scala releases are usually not BINARY backwards compatible. Very different from SOURCE backwards compatible.

Scala also was often not source compatible during 2.7 -> 2.8 because of the huge changes in the standard library.

I'm pretty sure they'll never be doing that again though due to the mess it caused.

That's probably related to the user base of scale being orders of magnitude smaller. The network externalities of a large language user base give it incredible inertia that makes it very difficult to change.

This sounds remarkably like Perl 5/6.

I am not at all up-to-date on the Perl side, but Python 3 is real, whereas

> Perl 6 is currently being developed by a team of dedicated and enthusiastic volunteers. (http://perl6.org/)

Well, apparently Perl 6 is a "spunky little sister" whose spokesperson is some kind of comic butterfly character.

Perl 6 is vaporware. Python 3 is here, it's widely supported, it's faster than Python 2.7, and while Guido didn't do us any favors with his migration strategy, I don't see what the big deal is. Python 3.3 makes writing code that is compatible with both almost trivial.

People aren't using Python 3 enough because it's not the default in Debian/Ubuntu. That's about to change with Ubuntu 14.04. I expect that to tip the scales.

I have Ruby and Perl tattoos and now work at a Python (2.7) shop, so I have all of the horses in this race, but is there a significant difference between a language that's vaporware[1] and one that nobody uses?

The previous things I've seen also indicated that Python 3 _isn't_ widely supported, though I guess Django finally got support recently, and that it _wasn't_ faster than 2.7. Is this just old information on my part, or is it different for certain kinds of workloads?

> it's not the default in Debian/Ubuntu.

Yeah, that should have a large impact, for sure.

1: I have seen lots of "check out this Perl 6 code" blog posts, but I don't know to what degree it's ACTUALLY vaporware.

> but is there a significant difference between a language that's vaporware[1] and one that nobody uses?

There's a significant difference between a language for which a complete implementation does not exist such that you cannot use it, and one for which an implementation exists but few people currently choose to use it because there is a closely-related predecessor language that still has a stronger ecosystem.

As an stage in the development of a language out of an existing, widely-used predecessor, the "vaporware" stage tends to precede the "available but not popular due to predecessors ecosystem advantage" stage, which tends to precede the "displaces predecessor" stage.

Its obviously possible for a language to stop progressing at any of the earlier stages before reaching the last stage.

Quite fair.

> Perl 6 is vaporware

Perl 6 is not vaporware, you can run it today:

http://perl6.org/compilers/features

Is it 100% feature complete or fast? No. But there working code and new, stable releases on a monthly basis.

> Is it 100% feature complete or fast? No.

If it's not feature complete it's vaporware.

By that definition, basically all software is vaporware.

Well, if they are programming languages, are still unstable 10 years late, have near zero adoption and are missing half of the promised features, then yes.

Unfortunately languages like Rust perfectly fit your definition. Because Rakudo was started around the same time as Rust and Rust is aiming for may be 1% of the feature set Perl 6 aims to achieve.

Rakudo was started around the same time as Rust

That's moving the goalposts a bit! What's currently called "Rakudo" is at least the sixth or seventh attempt at an implementation, not counting Pugs, viv, v6, or Niecza.

Rust appeared publicly as a project to build a language in 2010 (it was a personal, private, project kept under wraps by Graydon a few years before which is irrelevant).

Perl 6 was first started on 2000. I've been reading Larry's apocryphal descriptions of its "features to be" for 4 times more years than Rust exists.

Rakudo is just a particular attempt at Perl 6, not the first and neither it consists of first time the language was announced publicly.

I remember Larry also saying(On a youtube video, may be at the O'reilly conference) that he has been working on Perl 6 since 1987. That's how he wishes to describe it.

Even beyond that those are not "features to be". They are already available for use - http://perl6.org/compilers/features

Therefore I'm not sure what you've been reading, or if you are even reading them. Because if you would- you would know, Rakudo covers much of the Perl 6 specification.

By the way. Rust is still not complete. The wikipedia article says, work started in 2006- Which makes it 8 years and still incomplete. And this is for a project which has by far may be even 1000x modest goals. Python 3 was itself 10 years in development, and that is for small modifications to print statement and iterators. And even after 5 years since that date, it doesn't seem to have come any where closer to achieving good production scenario adoption.

And. These are- I said by far extremely modest goals compared to the Perl 6 project.

>I remember Larry also saying(On a youtube video, may be at the O'reilly conference) that he has been working on Perl 6 since 1987. That's how he wishes to describe it.

That's all well, but he announced it circa 2000. I don't care how he feels about it or how long he hacked it alone, I care since when the language was expected.

>Even beyond that those are not "features to be". They are already available for use http://perl6.org/compilers/features

Therefore I'm not sure what you've been reading, or if you are even reading them. Because if you would- you would know, Rakudo covers much of the Perl 6 specification.

In a half-arsed form and with 1/100 the community of Perl doing anything with them. And still not all of them.

Personally I stopped caring somewhere around 2006. And I've read all of Larry's "apocalypses" back when they used to be on Oreillynet, as well as followed the internal implementation politics for a few years.

>By the way. Rust is still not complete. The wikipedia article says, work started in 2006- Which makes it 8 years and still incomplete.

No, it says that it started as a "part-time side project in 2006". That could be 2 weeks total spend in those years writing a list of desired features in a napkin and getting a hello world compiled for all I know.

I only care about the time since the project was publicly announced and the community started working on it.

If Rust had been hyped as much as Perl6 I'd call it vaporware too. It may yet turn out to be vaporware (in that it's not done), but right now I'm willing to give it the benefit of the doubt that they will actually deliver on their promises.

Being able to "run" it, and the fact that it has a release cycle doesn't mean it's a viable development platform.

Perl 6 and Duke Nukem Forever are the geriatric poster children of vaporware, and always will be, even after they finally shipped. Being able to pick up a turd floating in a urinal does not in any way deliver on all the broken promises, rehabilitate the ruined reputation, or make up for all the blustering hype that was spewed for so many years about how superior Duke Nukem Forever's gameplay would be to all the other games that were already on the market. The damage was done a long time ago, and can never be undone. And Perl 6 is perfectly analogous to Duke Nukem Forever. Fortunately, nobody ever made such ridiculous claims about Python 3 as were made about Duke Nukem Forever and Perl 6.

> People aren't using Python 3 enough because it's not the default in Debian/Ubuntu. That's about to change with Ubuntu 14.04. I expect that to tip the scales.

I doubt it will tip that much. The enterprise customers we develop for still ship on CentOS and have auditing departments that have to scour each library and package a system depends on. Adding a dependency hurts in this environment. These institutions only upgrade their interpreters once every 5 - 8 years if you're lucky.

Comparing Perl 6 with Python 3 is a big joke. Even a cursory look at the Perl 6 specification and implementations like rakudo will tell you Perl 6 is attempting to go to a place where Python may like likely go in the next 40 years, with 10 Python 3 like disasters.

Its an exceptionally ambitiously project which they are in no hurry in finishing. And that is for a good reason.

Its an exceptionally ambitiously project which they are in no hurry in finishing. And that is for a good reason.

Way back in the early days, the goal was to release a usable 6.0 in a couple of years. The "there's no hurry" line is a post hoc justification from around 2006 or so.

But has the goal of Perl 6 as a project remained static? I'm relatively new to the Perl community. I know you are around since a very long time.

But I think the goal has changed from "Let's fix Perl 5" to being a more bigger goal of developing a language what Perl 5 would likely look after say 3 decades of iterations. I can't say if that is good from a purely practical perspective. But it does sound like worthwhile goal to chase.

Lets take a look at Python 3 itself. Yes they finished the project, but 5 years after that- Now what? Users don't seem to a have a valid reason to move away from 2.x series for merely small time incremental improvements, while forced to migrate bulk of the infrastructure and code for nearly ~0% productivity gains.

Perl 6 could have come out by 2005-2006, and if it were to be merely a incremental non-backwards compatible change over p5. We would be having similar posts about p6 as we are having now about Python 3. Imagine a refined, yet not that beneficial p5 breaking CPAN. I am sure you wouldn't like such a situation.

But has the goal of Perl 6 as a project remained static?

The idea that it would be a series of incremental improvements to Perl 5 ended around 2001, and certainly by 2002 at the latest:

http://www.perl.com/pub/2000/11/perl6rfc.html

The grand unification of runtimes (Ponie) had failed long before the announcement of its demise in 2006:

http://www.nntp.perl.org/group/perl.ponie.dev/2006/08/msg487...

I suspect but can't entirely prove that the appearance, rapid ascent, and even more rapid burnout of Pugs made a lot of people realize that this would be a long slog. Even so, if you look back at mailing list messages or conference talks or blog posts in 2006, 2007, 2008, whenever, you'll see that the party line has always been "It's only a year or two away."

Nobody expects Perl 6 to be widely used yet. The Python community seems to expect Python 3 to be widely used by now.

Bullshit. I was there in 2002 looking at Perl 6 and we expected it to replace Perl 5 within a couple of years.

You're right that back then the expectations were a lot higher, but I don't think anyone even then expected it to replace Perl 5 that fast.

Also, Perl 6 turned out rather quickly to become a new language (although very much in the spirit of earlier Perls), while Python 3 was, as far as I can see (I'm not really a Python person) as an update to fix some important issues in the language, which despite by necessity being backwards incompatible, was intended to still be the same language.

You're right that back then the expectations were a lot higher, but I don't think anyone even then expected it to replace Perl 5 that fast.

The goal was to run existing Perl code in the same process, so that you could gradually adopt new features or use existing libraries with new code. If that had worked out, there'd have been less of the Python 2/3 gap.

Then again, the idea that Perl and P6 are different languages is something that's come up after the fact, after it became obvious that P6 wouldn't be ready for general use any time soon.

Reply on news.ycombinator.com