Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition.

Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc). And while no single issue alone would justify Python 3.x, the combination of all of these issues as well as some other semantic problems justified the need for Python 3.

Of course, that being said, Python 3 also had some issues that it took several versions to iron out.

I am wondering. Why is division of integers returning an integer an awful thing?

https://www.python.org/dev/peps/pep-0238/

{Describing the old python-2 behavior:}

-------- Quote: -------

The classic division operator makes it hard to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs. For all other operators, one can write down a formula such as xy*2 + z, and the calculated result will be close to the mathematical result (within the limits of numerical accuracy, of course) for any numerical input type (int, long, float, or complex). But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division.

-----------------------

To guarantee the correct mathematical behavior in python2, one would probably have to write:

    def true_math_div(a,b) :
        if type(a) is int or type(a) is long :
            a = float(a)
        if type(b) is int or type(b) is long :
            b = float(b)
        return a/b

as a and b could be int, float, complex, or some object defining the method __div__.

What's wrong about just `float(a)/float(b)`?

not everything that can be divided can be reasonably cast to a float

Also, it's ugly as sin

I wouldn't call it awful, but it is slightly annoying. In a dynamically typed language it's hard to know apriori if a variable is an int or a float with a whole number value and you end up having to write x/float(y) all over the place just to make sure your code does what you want it to do.

The new case of / always being float division and // always being integer division just makes everything more explicit.

This particular language quirk I don't think has anything to do with dynamic typing: it's equally annoying in C-style languages where 3/2 and 3/2.0 mean different things.

sure, but in C if you have a line that looks like

   z = 3/y

you'll know that y is either always a float or always an int depending on its type and thus you'll 'know' what z is.

Because it's a duck that doesn't quack.

Perl 6 is a different language. Last time I checked there was no plan to discontinue Perl 5.

Wont they have a naming/versioning problem?

No. Perl 6 has its own version scheme, and the number at the end of the language name is just a number.

I'm not a particular fan of that - they should have changed the name entirely, IMO, eg. to Rby - but Perl 5 is not getting discontinued.

They have it already. Perl6 is about 10 years old, had at least 4 virtual machines. When it was announced people thought perl 5 was obsolete. And in the same time came RoR. A few years(like 7 maybe?) ago a some new developers took over perl5 and added some really interesting new features. That made some perl6 developers unhappy, wanting to focus community around perl6. Perl5 developers believe a completely new language should have a different name. Some suggested renaming perl5 perl7. Then there was a website perl11.org redirecting visitors to scala-lang.org. That was about 3 years ago. Since then - I don't care:) Perl6 will have to find itself a niche. The one once occupied by perl5 - a ducktape of the web is now taken by js. So, a long transition is better than a remote perspective of unknown transition.

Good point, I didn't realise Perl6 was in a similar situation. However it seems that adoption of Perl6 is very low, so I suspect Perl5 isn't going to get killed off any time soon.

Very little new stuff is being developed in Perl, period. I don't know anyone working in Perl who is not maintaining existing codebases. I haven't heard Perl proposed for anything new in over a decade. That further reduces the motivation to move to Perl 6.

It depends what you're using it for. Certainly it wouldn't make sense to use it for web stuff. However I use perl exclusively for server-side "shell" scripting, and it excels at that. More powerful than bash, less compatibility worries than python (I've had issues even between 2.* versions). If I have perl5.* on a server my scripts work everywhere. I regularly start new server-side scripting projects using perl, including a recent webpage-to-video conversion batch script. To be honest there is no other platform that I would even consider using for this kind of thing. Is there even anything that comes close to perl's cross-platform, rapid development, stability and general compatibility?

I dunno, on Arch I've seen several times as Perl 5.x updates roll in, Perl scripts will break on stuff. Especially Perl 5.22 and 5.26.

That's because of binary API changes, and only affects Perl modules with C parts in them. Source compatibility has been preserved at least across the entire 5.x line.

Python?

The plan for Perl6 is to eventually run Perl5 code with the `use v5` statement. You just don't throw 30 years worth of CPAN into the garbage bin. Meanwhile, Perl5 is being actively developed, new minor versions are released at least once a year, people are actively improving the language via extensions and even the core is evolving slowly but steadily. I don't thing it will be abandoned any time soon. Perl6 is being developed separately, mosty by other people.

Perl6 has nothing to do with perl5, it's a completely different language. I would call the transition fatal, not painful.

> I would call the transition fatal, not painful.

It's really sad. In retrospect they certainly should have named it something different. The Perl 5 community could have progressed, maybe even made a Perl 6, while the NGPerl skunkworks project continued independently for 15 years.

I never quite understood why the division of integers resulting in integers was a problem.

I get that for people with no knowledge of programming whatsoever it can be confusing, but it's standard behavior in nearly every typed language.

In C/C++, you divide an Int and you get an Int. If you want floating point division, you divide by a float. Problem Solved.

Almost EVERYTHING else could have been done with slow migration, or simply documenting the odd or quirky behavior.

Iterator variable leaking is just a result of poor programming.

Raw_input vs input could have been solved by slowly deprecating input. Or just left as is.

xrange is the same story.

It all seems like someone just decided to throw their hands up in a fit, throw their toys on the ground, and make a new Python. I enthusiastically jumped at Python 3 in the begining, then ran into problems, and crawled back to my 2.7 and decided I could let others fight the stupid cult war that was coming over 2 vs 3. I'd rather use a tool that works than change all my code over someone's idea that newer is better.

> I never quite understood why the division of integers resulting in integers was a problem [...] but it's standard behavior in nearly every typed language.

And hence why it's a problem in Python. If you have a function like

    def foo(a, b):
      return a / b

What are the types of a and b? You don't know. Sure, you could check with isinstance, but now you've broken the illusion of duck typing. The argument is that Python should just do "the right thing". Just because 3/4==0 in most languages doesn't justify repeating that mistake. Not to mention that float(a)/float(b) -- aside from being incorrect in the general case -- is ugly as hell.

> Iterator variable leaking is just a result of poor programming.

I think it's a language bug. Why? Imagine if you could do this in C:

    for (int a = 1; i <= 3; a++)
      foo(a);
    printf("%d\n", a);

People would think this is clearly a language bug because it breaks the scoping semantics (not to mention common sense). Now, you could argue that Python supports this sort of nonsense so it's "fine":

    # a is not defined
    if something:
       a = 1
    else:
       a = 2
    print(a)

But the reason that works is because otherwise Python would need to have JS-like "var" syntax to declare a variable. Personally I think that'd be better, but the for-loop situation is different.

> raw_input vs input could have been solved by slowly deprecating input. Or just left as is. xrange is the same story.

And this is how PHP ended up having three different string escaping functions for SQL statements. The first one (escape_string) was broken, so they added real_escape_string, and then they needed to handle connection-specific quirks so they added mysqli_real_escape_string.

Some people still use escape_string even though it's broken -- and the language devs cannot fix it because "that would break users".

Serious question, what was the complaint against xrange?

I don’t recall it ever surprising me or behaving poorly.

The issue is that "xrange" does the right thing, but the seemingly-more-correct (unless you happen to know about "xrange") "range" does the wrong thing (create a list rather than a generator, which is inefficient). Same thing with "raw_input" doing the right thing, but "input" being completely wrong (and an attack vector because it's just a glorified "exec").

And instead of behind-the-scenes lazily creating the range, so you have a generator that reifies when its modified and has a nice __str__ etc they go make incompatible changes; got it! ;)

I know rather too much about how CPython and other VMs work under the hood and am in no mood to try and save the day any more. I still use python, but the latest stuff around MyPy and async io just make me despair frankly. I think rust+go will probably pick up a lot of people who used to care deeply about python. So it is.

Perl is a weird language language for you to cite when we're talking about languages that do major transitions well. Perl 6 was created because Perl 5 was an evolutionary dead end, took 15 years, has no adoption, and Perl 5 usage shrunk tremendously in the meantime. Not saying this glibly as I love Perl and I hope Perl 6 sees some adoption, but come on now. Also remember that Perl 5 itself was nearly a complete rewrite from 4.

Exactly my thought regarding the need to evolve as a language. Perl is mostly dead because it didn't keep up with the times and I say that as a person who spent a tremendous amount of time learning and using Perl. The Schwartzarian transform was a beautiful thing to behold.

Perl is born to solve portability and limitation problems of shells (csh, sh, ksh*), awk and sed. People who do not live on the command line can not appreciate the power of perl.

> The Schwartzarian transform was a beautiful thing to behold.

Meh, more like a clutch for systems where you couldn't install List::UtilsBy. (One of my favorite Perl modules of all time.)

There's 17 years between the introduction of the Schwartzian Transform (1994) and List::UtilsBy (2011 according to CPAN).

Huh. I guess it's one of those cases where once you have a thing, you wonder how you could have gone 20 years without it. :) Although, to be fair, I only started working with Perl (beyond one-liners on the shell) in 2012.

There's also no push, whatsoever, to "get with the parrot program". Larry Wall is not holding a gun to Perl 5's head.

Unlike Python 3's relation to Python 2, Perl 6 is genuinely a new language. It would make little sense for the community to discontinue Perl 5 and push for Perl 6.

In retrospect it probably would have been better for the community if they'd given Perl 6 a new name.

Yeah, I really don't get this Python mindset at all. I have out in the wild both Scheme code that's approaching 30 years old, and Perl code approaching 20 years old, running on commercial systems. There's no real need for constant version churn.

Perl example is a bad one given Perl 6 having near zero adoption, and being incompatible with 5. And this is hardly "constant" version churn. This was a major event for Python to fix some long-running issues that needed fixing, but could only be done with an incompatible version.

Over the course of 2014, the "pip" project alone went from 1.4.1 to 6.0.6(!) through 2 minor releases, 1 major release, and 9 point releases, 6 of which were on the same day as another point release (it's called a "release candidate", people). They included regressions such as "segfaults on Windows at every invocation", "freezes if the specific server pypi.org is not reachable", and dropping support for a python version that was less than 2 years old at that point. They also introduced a third package archive format into the ecosystem.

The library ecosystem is the problem, and it's what's driving the language churn.

The python devs learned their lesson and aren’t going to do a major breakage like 2 to 3 again.

https://www.curiousefficiency.org/posts/2014/08/python-4000....

It’s a balancing act. Breaking compatibility creates work, unfixed bugs and design flaws create work, which is more work varies. Retaining compatibility can be, in sum, a harmful decision.

Only if you are pretty lucky with what you write.

Back when I cared about Perl, doing "man perldelta" was a nice way to entertain myself.