5 ms·

>For the good of any computer language, old versions need to eventually die off. I would say instead: for any good computer language, new versions need to reta

• cyphar 9y ago
  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.
  • cpncrunch 9y ago
    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.
    • ams6110 9y ago
      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.
      • cpncrunch 9y ago
        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?
        • cdelsolar 9y ago
          Python?
        • semi-extrinsic 9y ago
          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.
          • majewsky 9y ago
            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.
  • mmsmatt 9y ago
    Serious question, what was the complaint against xrange? I don’t recall it ever surprising me or behaving poorly.
    • cyphar 9y ago
      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").
      • willvarfar 9y ago
        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.
  • setzer22 9y ago
    I am wondering. Why is division of integers returning an integer an awful thing?
    • cnvogel 9y ago
      https://www.python.org/dev/peps/pep-0238/ 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__.
      • __xxxxx 9y ago
        The joys of a dynamically typed language. Most algorithms assume truncating division. I've never had a problem with truncating division even once (to be fair, also not in Python).
      • majewsky 9y ago
        What's wrong about just `float(a)/float(b)`?
        • dagw 9y ago
          not everything that can be divided can be reasonably cast to a float
          • 9y ago
  • LaGrange 9y ago
    Perl 6 is a different language. Last time I checked there was no plan to discontinue Perl 5.
    • tobltobs 9y ago
      Wont they have a naming/versioning problem?
      • LaGrange 9y ago
        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.
      • qbaqbaqba 9y ago
        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.
  • petre 9y ago
    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.
  • qbaqbaqba 9y ago
    Perl6 has nothing to do with perl5, it's a completely different language. I would call the transition fatal, not painful.
    • kbd 9y ago
      > 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.
  • ajford 9y ago
    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.
    • cyphar 9y ago
      > 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".
• kbd 9y ago
  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.
  • crusso 9y ago
    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.
    • majewsky 9y ago
      > 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.)
      • zimpenfish 9y ago
        There's 17 years between the introduction of the Schwartzian Transform (1994) and List::UtilsBy (2011 according to CPAN).
        • majewsky 9y ago
          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.
    • reacweb 9y ago
      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.
• twhb 9y ago
  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.
• bandrami 9y ago
  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.
  • collinmanderson 9y ago
    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.html https://www.curiousefficiency.org/posts/2014/08/python-4000....
  • jhall1468 9y ago
    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.
    • bandrami 9y ago
      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.
• pjmlp 9y ago
  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.