14 ms·

Perl7 is a fork of values

151 points by lizmat 6y ago

rurban 6y ago
Exactly. "7.0 doesn't aim to bring new features, it doesn't enable us to do anything that isn't possible without it (other than not writing that guard). Instead, it aims to change perl culture as we know it. The whole point of perl7 is radically choosing approachability over stability." Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide. They even broke back compat in 5.30 with the change of attribs on subs, which is heavily used outside of perl5, but not at all within. Totally unjustifiable.
- tomphoolery 6y ago
  > Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide. I disagree. EmberJS is a great example of this philosophy done right. Major releases of Ember typically have no new features, they just break backwards compatibility in favor of more efficient ways to do things. This "sets the stage" for features that get added in minor releases. So when Ember releases a new major, you typically don't have to upgrade to it if you don't want the new features. But it's released so you can measure the level of effort as well as the impact the upgrade would have on your codebase. Contrast this with the way Ruby on Rails releases new major versions, with one giant release every couple years that either breaks compatibility, causes performance/cognitive issues, or some combination of the two. In my opinion, major versions shouldn't have new features. The way Ember gets away with this is by sometimes releasing two versions simultaneously, a major "X.0.0" version for upgrading apps to measure the level of effort, and a minor "X.1.0" for new apps. Want to start a new app? Choose the first minor. Want to upgrade your old app? Choose the major.
  - rkangel 6y ago
    That's so counter-intuitive and makes so much sense.
    - wruza 6y ago
      Not so much, as they only shifted semantics by -0.1. You cannot expect that your 2.0->x.0 will be as trivial as 1.9->2.0, because now ->2.1 is that hard upgrade that is called ->2.0 everywhere else.
  - jlg23 6y ago
    I am not sure one can compare some JS framework with a language that was already 8 years old when JS as a language appeared. By the time JS was invented, there was already legacy perl code in production that needed to be maintained.
    - tomphoolery 6y ago
      I don't see how that's relevant to software project management. The ways we release software and plan out roadmaps don't really have much to do with what language or framework the software was made in. Just because Ember is "some JS framework" doesn't mean it has no good ideas.
      - richard_todd 6y ago
        To me it's really not about whether it's a good idea or not. What works for an 8-year-old project that has always done it that way, may not work for a 33-year-old project which has never done it that way. The latest perl will run a huge chunk of the perl 1.0 test suite unmodified. That's a long history of backwards compatibility. This sudden change in focus and project-management may really backfire on them.
      - jlg23 6y ago
        > Just because Ember is "some JS framework" doesn't mean it has no good ideas. No, but time-scales matter. A good idea in a notoriously short lived ecosystem is not necessarily transferable to an environment in which one has to maintain 20 or 30 year old, mostly write-only code.
    - hibbelig 6y ago
      I don't quite understand this point. Perl has a major version, Perl 5. They want to offer a new major version, Perl 7, now. If Ember has already release a couple of new major versions, then why not learn from it? Maybe the Ember approach doesn't fit Perl, but without taking a look we won't know. Also, based on the GP, it seems like Perl is planning something similar to what Ember has been doing: They are planning for Perl 7 to offer no new features, just change behavior. Then users can take their Perl 5 software and try it out with Perl 7 to see how much work it is to upgrade. Or they comb the source code to look for constructs that are deprecated.
  - onionisafruit 6y ago
    Putting Perl aside for a bit, I don’t quite understand the benefit of the Ember strategy you described. If I have existing code that uses Ember x-1 when x.0.0 and x.1.0 are released, what is my reason for scoping the upgrade with x.0.0 vs x.1.0? If I don’t want to implement the new features, couldn’t I still update to x.1.0 without using anything new calls?
    - malinens 6y ago
      similar strategy is for Symfony in PHP for major versions and it works well. For example next major version 6.0 will have the same features as 5.4 version with removed BC layer (deprecations etc.). This allows for smoother upgrades. You just fix all deprecations and then You can upgrade major version without stress
kinow 6y ago
Had a chance to work with Leon on the TestAnything protocol. Really great guy to work with. >I don't know where we're going. I'm not even sure if this forking is good or bad in the long run (it could be good if managed well, but so far it isn't). And that terrifies me. Hopefully this new version will make Perl easier for newcomers. But maybe before the final decision they will find a compromise solution where some old features may be dropped, while making it not-so-hard to migrate Perl5 to Perl7.
- leont 6y ago
  > Had a chance to work with Leon on the TestAnything protocol. Really great guy to work with. Why thank you :-)
nintendo1889 6y ago
I always wondered what the trolls on slashdot posted about Tom Christiansen when he died. The posts were all deleted.
- gjm11 6y ago
  Huh? Last I heard, Tom Christiansen is still alive. And I'm not sure what the connection is, other than that he's done a lot of work with perl.
  - Kye 6y ago
    nintendo1889 is clearly a confused time traveler. The posts haven't been deleted. They just haven't been made yet.
  - jph00 6y ago
    I believe he's talking about the thread when W Richard Stevens died.
    - boring_twenties 6y ago
      What happened? Stevens had some kind of hate club? Why?
    - gjm11 6y ago
      (Apologies for the very slow response.) W Richard Stevens died in 1999. HN started in 2007. Is it possible that you're thinking of someone else?
      - jph00 6y ago
        They said slashdot, not HN.
        gjm11 6y ago
        Ohhhh, duh, so they did. Thanks.
lmiller1990 6y ago
I think most people using Perl for anything non trivial (eg, large web app with Catalyst) are unlikely to be changing their version of Perl without a good reason, and very few people are starting large Perl projects now days. My day job is working on a fairly complex app running 5.28.1, we have no desire to change the Perl version without a very good reason to do so. I find this post a little unsettling. It seems like even the Perl community is unsure why they are doing this. At least for me, Perl === Perl 5 (and probably always will). It works, and it's ecosystem is very mature.
- vikramkr 6y ago
  I think the reason is probably what you mentioned - very few people are starting large Perl projects nowadays. And I think they'd like that to not be the case anymore by making it attractive to newcomers. Feels a bit like a bird in the hand vs two in the bush type thing honestly - be a bit antagonistic to your existing user base and make up on the hope that you'll get a new rush of users to make up for it. Edit - to be clear - I don't think this is a good idea. I'm not inverting the meaning of the "bird in the hand" idiom, I used it specifically because I think this is an example of chasing after a fantasy that's going to leave them worse off in the long run by compromising their existing user base. I don't know why you'd expect a sudden rush of new users coming to Perl today and try to tailor a release to new users when, as the parent comment mentioned, new uptake is really limited and most users are working with existing systems/value stability.
  - greggyb 6y ago
    Just a note, that the idiom, "bird in the hand" is a statement that one should value that which they already possess over that which they do not yet possess, even if the latter is ostensibly worth more than the former. The full proverb is "a bird in the hand is worth two in the bush." I recognize that you didn't quote this directly. I am not sure if you meant to invert the common meaning here. The thrust of your post reads as if favoring this new direction for Perl, on the basis that it will bring in new users. The "bird in the hand" proverb would counsel the opposite - favoring stability to cater to current users, regardless of the impact on potential new users.
mkoubaa 6y ago
a similar argument is going on in c++ community - whether to value stability or performance. one thing that always struck me is that the number of developers of X language is some factor times the number of developers at the point in time when it first had a strong community. if that factor is greater than 2, and it usually is, then to me dividing the language into two distinct dialects with different values makes sense.
- paulryanrogers 6y ago
  Perhaps spreading out the breaking changes as PHP has done from 4 through 7.
  - dgellow 6y ago
    One thing specific to C++ is that the main point of discussion isn't necessarily about the language itself, instead it is about breaking the ABI or not moving forward. Breaking the ABI would allow for significant performance improvements, but that would require a huge amount of libraries to be recompiled, which is something a lot of vendors don't want and sometime cannot because sources aren't available anymore.
    - im3w1l 6y ago
      What about something like this? https://devblogs.microsoft.com/oldnewthing/20040108-00/?p=41163 https://devblogs.microsoft.com/oldnewthing/20040108-00/?p=41...
  - AlexMax 6y ago
    As somebody who used PHP through that transition, I have to say that the 5-7 (skipping 6) transition was especially well handled from my perspective. There was certainly breakage, but the amount of things you had to fix was relatively small. https://www.php.net/manual/en/migration70.incompatible.php https://www.php.net/manual/en/migration70.incompatible.php It was really easy to write code that worked in both 5 and 7. Most of my time was spent waiting for dependencies or frameworks to make the same jump. Then again, I suppose PHP developers had the hindsight of Python 3 and Perl 6 as a gigantic warning klaxon of what not to do.
randallsquared 6y ago
I wonder if Perl 8 will also be a fork of Perl 5.
beefhash 6y ago
So now that Perl 7 wants to actively remove backwards compatibility from its culture, where are people to turn now for stable/non-moving scripting languages?
- greggyb 6y ago
  /bin/sh? I am not sure what the balance of facetious vs serious is here. The various Unix shells have been stable for quite a while. Obviously sh is very barebones, but zsh and bash, for example, have associative arrays and other modern conveniences. Outside of various shells, there are several other options that come to mind which do not teeter on facetiousness. So far as I know, tcl is also quite stable. Common Lisp is perfectly usable as a scripting language and has a very stable standard and mature libraries.
  - iso947 6y ago
    The reason I reach for Perl rather than bash is it has far more features and far easier to manage. I don’t bother with python as you get into a horrendous mess with pip breaking and the v2/v3 issue. Not every piece of code needs to serve a million people, not every piece of code needs to be sold to google, sometimes you just need code to do a simple occasional job and not change every couple of years.
    - jeffdn 6y ago
      The Python v2/v3 "issue" has been a non-issue for years now. If you're writing code to do a simple occasional job, Python is perfectly suited to that.
      - edoceo 6y ago
        So is perl, and tcl and shell and JavaScript and PHP. For a "simple occasional job" the right tool is the one you know best (or the organization knows best).
    - jefftk 6y ago
      Python is fully on v3 now. It was a terrible transition, but it's done.
im3w1l 6y ago
Which kind of greenfield projects would the perl community like to claim? Is there anything it's particularly suited for?
CydeWeys 6y ago
Wait, hold on. They're talking about Perl7. Is this the next version after Perl6, which is called Raku? Or is Raku already completely forked off and now they're talking about another fork of what remains of Perl?
- tyingq 6y ago
  It's the next logical major version for Perl 5. Consider "Perl 6" to be a dead term.
- PCChris 6y ago
  They are talking about the next iteration of Perl 5. https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/
- em-bee 6y ago
  perl7 is the continued development of perl5. they skipped 6 to avoid confusion with raku.
jarym 6y ago
Perl does have a fair few quirks but those that know it are probably content for it to stay the way it is and those who don't like it have probably moved to another language. Personally, I don't like a major version of a programming language making major breaking changes because upgrading a programming language is not at all like upgrading an app. Would it be so bad of them just to keep Perl as it is and imagine the 'new shiny' and give that a new name - maybe Porl or something?
- evilsnoopi3 6y ago
  I mean they already tried that with Raku (Perl6) and it didn't gain the adoption they wanted.
deleted 6y ago
[deleted]
dilandau 6y ago
Love to see the Perl team discussing these issues in such a thoughtful way. Over the years I have learned to value stability and backwards compatibility, through hard lessons (which were often quite expensive to my employer). But no one value is good or bad, per se, rather they should be selected carefully: and that is the point I took away from this article.
systems 6y ago
I am honestly disappointed, I think Raku is a much nicer language than Perl 5 or 7 And I really wish, if those working on Perl 5 would have switched to Raku, but sadly i think CPAN for Perl 5/7, have a lot more activity than the equivalent at Raku Most new and modern languages are Compiled, Functional or targeting the JVM or .Net frameworks Raku is I think the last and only modern scripting language , it could have used the helping hand of the Perl 5/7 community
- goto11 6y ago
  There is a lot of Perl 5 code around though. Improving 5 (in a backwards compatible way) therefore provides a lot of value. But a Perl 7 which is not focused on retaining backwards compatibility with 5 is worst of both worlds. Existing code bases will not upgrade, and nobody will start a green field project in it when Raku (not to mention Python, Ruby etc) is available. It would be dead in the water.
- Icathian 6y ago
  Isn't Python typically considered a scripting language, and usually ranked as at least top 3 in popularity?
  - systems 6y ago
    Yes, but the way i see it, Raku (Perl6) was a complete rewrite of Perl .. was a radical change (rational numbers, grammar, multimethods, ...) Python 3, is in my opinion more of an incremental and conservative change
- moonchild 6y ago
  Raku is JIT-compiled, same as JVM/.net languages. And python and javascript and ruby and lua and...
  - systems 6y ago
    Clojure and F#, have some complexity that you wont find in Raku, try installing all 3 and run a simple script Clojure, you will need boot or leiningen , or use the new command line tools which are not supported on windows F#, you will install dotnet core and will have to learn about the differend SDKs and compatibility differences between OSes Next try to find, install use package, its a lot less obvious how to do this compared to what I call a pure scripting language like Raku And compared to Ruby and Python, I think Raku have more modern features , gradual typing, rational number, grammars, unicode operators etc .. Raku is one very few pure scripting language where innovation is still happening
jpz 6y ago
what happened to perl6? I'm confused :)
- qalmakka 6y ago
  Perl6 became Raku, a whole different language, something that should have happened since the very beginning instead of putting on a totally different project the label "Perl" and thus funneling in a truckload of FUD that only harmed the language.
- systems 6y ago
  They renamed it to Raku, the renamed have two benefits in minds 1. Reintroduce Perl 6 (Raku) as a completely new language, since some thought that being linked to Perl prevented adoption 2. Open the road for Perl 5 to evolve and add features, many people in the Perl 5 community thought that Perl 6 prevented Perl 5 from growing In Summary, the sentiment was, Perl 5 and Perl 6 are two different languages each with its own roadmap, but that the name gave the impression they are one, and prevented both from evolving
  - jpz 6y ago
    cheers, TIL :)
qalmakka 6y ago
I like Perl, and I think that changing the defaults is a sane thing to do. Starting a new script with dozens of "use strict", "use v5.30", etc is less than ideal and it's easy to forget something and shoot yourself in the foot. Almost 30 years will pass between Perl 5 and 7, and going back to the old values is just a matter of adding a few lines at the beginning of your old script. It's not a mess like the whole "Python 2/3" ordeal that was deeply more complex and painful. Heck Perl in the last 30 years has been even more stable than C. I remember when gcc and clang switched from a default of GNU89 to GNU99 and it broke several packages who didn't set or check for the right flags; nobody bitched about it and just went on to fix their Makefiles.
- cwyers 6y ago
  I am not a Perl person, but it does sound to me like a lot of this thread is is missing what's going on, yeah. They're not changing the language, they're just changing the runtime to use better, more modern defaults. I don't know if you would be able to put in "use unstrict" or something and get back the old behavior, but any actively-maintained code is probably using most of these newer defaults anyway.
  - HighPlainsDrftr 6y ago
    Brian D Foy wrote a pretty good post on this. https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/ Essentially, it is just perl 5.32 with more modern defaults. They will keep evolving the language. Perl 5 isn't going anywhere.
gjvc 6y ago
Much of the problem is that people see things like Perl or Python as holy grails that must not be changed or questioned. This stance mainly comes from these languages having been installed by default on almost all Unix platforms for the past 25 years. That's quite a long time to bludgeon people into thinking that these things are sacred and fixed. Computerists should not be afraid to try something new at every turn, and then reject that something if it does not measure up. In the short run, change is often scary, but in the long run it is the only way to survive.
nige123 6y ago
Expressiveness + Extensibility + Stability Sounds like excellent values for a programming language. I'm interested to hear what the top three values for Perl 7 are? Exciting times for Perl!
py_or_dy 6y ago
I really don't get any of this. Here's the full picture: Larry Wall mostly gave up on Perl 5 in 2000 and announced the next release would be "Perl 6". A few small updates happened to perl 5 up until 2002. Larry started working on Perl 6, forever leaving perl 5. Perl 5 goes stagnant for 5 years, meaning it had no updates released for 5 years. During this time, droves of people picked up python. Perl 6 was no where near complete in 2007, and a small team of devs pushed out perl "5.10" after a 5 year hiatus. Perl 6 was finally released in ~2018 but by this time no one cared. The perl 6 team feels because of the name 'perl', people aren't adopting this new language, so they change the name. And now a year later, the small perl 5 team is wanting to take perl into the modern age by breaking backwards compatibility. It makes no sense at all, that was the job of perl 6. It would no different if I started complaining about python 2 not getting any updates and then making a plan to better improve its parser and object model and break backwards compatibility and bring it into the modern age. Python 3 already did that, so like what the heck are you doing??? And then the comments from the perl 7 supporters... saying things like we can either "fight or die" or doing nothing is "certain death" but the alternative is "uncertain hope". I just don't see the point in fighting for something the original author of gave up on over 20 YEARS ago. I've stated my points [0] before on how companies that stick with perl 5 do so at their own demise. They get cultured into a train of thought where updating software is seen as bad and unhealthy. And if they are a consultancy, their downstream customers also get cultured in to never having to worry about "updates" and/or paying for updates. So then long term contracts with said customer only take into account the cost of feature enhancements instead of "maintenance". So then it becomes impossible to move either consultancy or customer off of the "perl platform" because going to something like django, while a big cost in its own right, would involve a different long term contract that would require paid support and downtime for future django updates/releases. Never mind that finding devs would be easier (and probably cheaper), and the fact that django gets regular security audits and has a much larger plugin/library support ecosystem. Anyway, to each their own. And godspeed to the perlings out there, I just don't see how any of this is worth it... [0]:https://news.ycombinator.com/item?id=23633478 https://news.ycombinator.com/item?id=23633478
jlokier 6y ago
If I understand right, all they are doing is changing the per-script, per-module defaults to enable current language features, instead of having most features since about 2005 disabled by default. Perl5 has a very strong position on backward compatibility. Even when they change behaviour or add new syntax, that's disabled by default unless a script or module explicitly asks for the new behaviour. Each significant feature can be switched off or on per module. Even if the main program turns on features, they remain off for the modules used by the main program. So as far as I can tell, the proposal is just to change this default, so that modern Perl5 features are available to new code by default, instead of having to be explicitly requested, and there's no radical change or incompatibility planned for v7. That's a change of compatibility-first culture. It means scripts which don't specify what they do and don't want will indeed break with newer versions, occasionally. However Perl5 changes quite slowly, and it's unusual for something new to break something old anyway. But it should be easy for scripts to specify what they want. If there's a "no v7" directive that should be enough at the start of any script or module that wants to keep working while being insulated from future changes. That's not much different, in practice, than what they already have to do to ask for features they do use. Another idea would be to have two search path directories, with different defaults in each, and modules install into the appropriate one according to module metadata. This would allow existing, old modules to carry on working in v7.
amai 6y ago
Perl7 is as important as Rocky 7 or Terminator 7.

151 points by lizmat 6y ago

Exactly. "7.0 doesn't aim to bring new features, it doesn't enable us to do anything that isn't possible without it (other than not writing that guard). Instead, it aims to change perl culture as we know it. The whole point of perl7 is radically choosing approachability over stability." Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide. They even broke back compat in 5.30 with the change of attribs on subs, which is heavily used outside of perl5, but not at all within. Totally unjustifiable.

tomphoolery 6y ago
> Breaking back compat without any new features on the horizon to justify them is not only ridiculous, it's suicide. I disagree. EmberJS is a great example of this philosophy done right. Major releases of Ember typically have no new features, they just break backwards compatibility in favor of more efficient ways to do things. This "sets the stage" for features that get added in minor releases. So when Ember releases a new major, you typically don't have to upgrade to it if you don't want the new features. But it's released so you can measure the level of effort as well as the impact the upgrade would have on your codebase. Contrast this with the way Ruby on Rails releases new major versions, with one giant release every couple years that either breaks compatibility, causes performance/cognitive issues, or some combination of the two. In my opinion, major versions shouldn't have new features. The way Ember gets away with this is by sometimes releasing two versions simultaneously, a major "X.0.0" version for upgrading apps to measure the level of effort, and a minor "X.1.0" for new apps. Want to start a new app? Choose the first minor. Want to upgrade your old app? Choose the major.
- rkangel 6y ago
  That's so counter-intuitive and makes so much sense.
  - wruza 6y ago
    Not so much, as they only shifted semantics by -0.1. You cannot expect that your 2.0->x.0 will be as trivial as 1.9->2.0, because now ->2.1 is that hard upgrade that is called ->2.0 everywhere else.
- jlg23 6y ago
  I am not sure one can compare some JS framework with a language that was already 8 years old when JS as a language appeared. By the time JS was invented, there was already legacy perl code in production that needed to be maintained.
  - tomphoolery 6y ago
    I don't see how that's relevant to software project management. The ways we release software and plan out roadmaps don't really have much to do with what language or framework the software was made in. Just because Ember is "some JS framework" doesn't mean it has no good ideas.
    - richard_todd 6y ago
      To me it's really not about whether it's a good idea or not. What works for an 8-year-old project that has always done it that way, may not work for a 33-year-old project which has never done it that way. The latest perl will run a huge chunk of the perl 1.0 test suite unmodified. That's a long history of backwards compatibility. This sudden change in focus and project-management may really backfire on them.
    - jlg23 6y ago
      > Just because Ember is "some JS framework" doesn't mean it has no good ideas. No, but time-scales matter. A good idea in a notoriously short lived ecosystem is not necessarily transferable to an environment in which one has to maintain 20 or 30 year old, mostly write-only code.
  - hibbelig 6y ago
    I don't quite understand this point. Perl has a major version, Perl 5. They want to offer a new major version, Perl 7, now. If Ember has already release a couple of new major versions, then why not learn from it? Maybe the Ember approach doesn't fit Perl, but without taking a look we won't know. Also, based on the GP, it seems like Perl is planning something similar to what Ember has been doing: They are planning for Perl 7 to offer no new features, just change behavior. Then users can take their Perl 5 software and try it out with Perl 7 to see how much work it is to upgrade. Or they comb the source code to look for constructs that are deprecated.
- onionisafruit 6y ago
  Putting Perl aside for a bit, I don’t quite understand the benefit of the Ember strategy you described. If I have existing code that uses Ember x-1 when x.0.0 and x.1.0 are released, what is my reason for scoping the upgrade with x.0.0 vs x.1.0? If I don’t want to implement the new features, couldn’t I still update to x.1.0 without using anything new calls?
  - malinens 6y ago
    similar strategy is for Symfony in PHP for major versions and it works well. For example next major version 6.0 will have the same features as 5.4 version with removed BC layer (deprecations etc.). This allows for smoother upgrades. You just fix all deprecations and then You can upgrade major version without stress

kinow 6y ago

Had a chance to work with Leon on the TestAnything protocol. Really great guy to work with. >I don't know where we're going. I'm not even sure if this forking is good or bad in the long run (it could be good if managed well, but so far it isn't). And that terrifies me. Hopefully this new version will make Perl easier for newcomers. But maybe before the final decision they will find a compromise solution where some old features may be dropped, while making it not-so-hard to migrate Perl5 to Perl7.

leont 6y ago
> Had a chance to work with Leon on the TestAnything protocol. Really great guy to work with. Why thank you :-)

nintendo1889 6y ago

I always wondered what the trolls on slashdot posted about Tom Christiansen when he died. The posts were all deleted.

gjm11 6y ago
Huh? Last I heard, Tom Christiansen is still alive. And I'm not sure what the connection is, other than that he's done a lot of work with perl.
- Kye 6y ago
  nintendo1889 is clearly a confused time traveler. The posts haven't been deleted. They just haven't been made yet.
- jph00 6y ago
  I believe he's talking about the thread when W Richard Stevens died.
  - boring_twenties 6y ago
    What happened? Stevens had some kind of hate club? Why?
  - gjm11 6y ago
    (Apologies for the very slow response.) W Richard Stevens died in 1999. HN started in 2007. Is it possible that you're thinking of someone else?
    - jph00 6y ago
      They said slashdot, not HN.
      - gjm11 6y ago
        Ohhhh, duh, so they did. Thanks.

lmiller1990 6y ago

I think most people using Perl for anything non trivial (eg, large web app with Catalyst) are unlikely to be changing their version of Perl without a good reason, and very few people are starting large Perl projects now days. My day job is working on a fairly complex app running 5.28.1, we have no desire to change the Perl version without a very good reason to do so. I find this post a little unsettling. It seems like even the Perl community is unsure why they are doing this. At least for me, Perl === Perl 5 (and probably always will). It works, and it's ecosystem is very mature.

vikramkr 6y ago
I think the reason is probably what you mentioned - very few people are starting large Perl projects nowadays. And I think they'd like that to not be the case anymore by making it attractive to newcomers. Feels a bit like a bird in the hand vs two in the bush type thing honestly - be a bit antagonistic to your existing user base and make up on the hope that you'll get a new rush of users to make up for it. Edit - to be clear - I don't think this is a good idea. I'm not inverting the meaning of the "bird in the hand" idiom, I used it specifically because I think this is an example of chasing after a fantasy that's going to leave them worse off in the long run by compromising their existing user base. I don't know why you'd expect a sudden rush of new users coming to Perl today and try to tailor a release to new users when, as the parent comment mentioned, new uptake is really limited and most users are working with existing systems/value stability.
- greggyb 6y ago
  Just a note, that the idiom, "bird in the hand" is a statement that one should value that which they already possess over that which they do not yet possess, even if the latter is ostensibly worth more than the former. The full proverb is "a bird in the hand is worth two in the bush." I recognize that you didn't quote this directly. I am not sure if you meant to invert the common meaning here. The thrust of your post reads as if favoring this new direction for Perl, on the basis that it will bring in new users. The "bird in the hand" proverb would counsel the opposite - favoring stability to cater to current users, regardless of the impact on potential new users.

mkoubaa 6y ago

a similar argument is going on in c++ community - whether to value stability or performance. one thing that always struck me is that the number of developers of X language is some factor times the number of developers at the point in time when it first had a strong community. if that factor is greater than 2, and it usually is, then to me dividing the language into two distinct dialects with different values makes sense.

paulryanrogers 6y ago
Perhaps spreading out the breaking changes as PHP has done from 4 through 7.
- dgellow 6y ago
  One thing specific to C++ is that the main point of discussion isn't necessarily about the language itself, instead it is about breaking the ABI or not moving forward. Breaking the ABI would allow for significant performance improvements, but that would require a huge amount of libraries to be recompiled, which is something a lot of vendors don't want and sometime cannot because sources aren't available anymore.
  - im3w1l 6y ago
    What about something like this? https://devblogs.microsoft.com/oldnewthing/20040108-00/?p=41163 https://devblogs.microsoft.com/oldnewthing/20040108-00/?p=41...
- AlexMax 6y ago
  As somebody who used PHP through that transition, I have to say that the 5-7 (skipping 6) transition was especially well handled from my perspective. There was certainly breakage, but the amount of things you had to fix was relatively small. https://www.php.net/manual/en/migration70.incompatible.php https://www.php.net/manual/en/migration70.incompatible.php It was really easy to write code that worked in both 5 and 7. Most of my time was spent waiting for dependencies or frameworks to make the same jump. Then again, I suppose PHP developers had the hindsight of Python 3 and Perl 6 as a gigantic warning klaxon of what not to do.

randallsquared 6y ago

I wonder if Perl 8 will also be a fork of Perl 5.

beefhash 6y ago

So now that Perl 7 wants to actively remove backwards compatibility from its culture, where are people to turn now for stable/non-moving scripting languages?

greggyb 6y ago
/bin/sh? I am not sure what the balance of facetious vs serious is here. The various Unix shells have been stable for quite a while. Obviously sh is very barebones, but zsh and bash, for example, have associative arrays and other modern conveniences. Outside of various shells, there are several other options that come to mind which do not teeter on facetiousness. So far as I know, tcl is also quite stable. Common Lisp is perfectly usable as a scripting language and has a very stable standard and mature libraries.
- iso947 6y ago
  The reason I reach for Perl rather than bash is it has far more features and far easier to manage. I don’t bother with python as you get into a horrendous mess with pip breaking and the v2/v3 issue. Not every piece of code needs to serve a million people, not every piece of code needs to be sold to google, sometimes you just need code to do a simple occasional job and not change every couple of years.
  - jeffdn 6y ago
    The Python v2/v3 "issue" has been a non-issue for years now. If you're writing code to do a simple occasional job, Python is perfectly suited to that.
    - edoceo 6y ago
      So is perl, and tcl and shell and JavaScript and PHP. For a "simple occasional job" the right tool is the one you know best (or the organization knows best).
  - jefftk 6y ago
    Python is fully on v3 now. It was a terrible transition, but it's done.

im3w1l 6y ago

Which kind of greenfield projects would the perl community like to claim? Is there anything it's particularly suited for?

CydeWeys 6y ago

Wait, hold on. They're talking about Perl7. Is this the next version after Perl6, which is called Raku? Or is Raku already completely forked off and now they're talking about another fork of what remains of Perl?

tyingq 6y ago
It's the next logical major version for Perl 5. Consider "Perl 6" to be a dead term.
PCChris 6y ago
They are talking about the next iteration of Perl 5. https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/
em-bee 6y ago
perl7 is the continued development of perl5. they skipped 6 to avoid confusion with raku.

jarym 6y ago

Perl does have a fair few quirks but those that know it are probably content for it to stay the way it is and those who don't like it have probably moved to another language. Personally, I don't like a major version of a programming language making major breaking changes because upgrading a programming language is not at all like upgrading an app. Would it be so bad of them just to keep Perl as it is and imagine the 'new shiny' and give that a new name - maybe Porl or something?

evilsnoopi3 6y ago
I mean they already tried that with Raku (Perl6) and it didn't gain the adoption they wanted.

deleted 6y ago

[deleted]

dilandau 6y ago

Love to see the Perl team discussing these issues in such a thoughtful way. Over the years I have learned to value stability and backwards compatibility, through hard lessons (which were often quite expensive to my employer). But no one value is good or bad, per se, rather they should be selected carefully: and that is the point I took away from this article.

systems 6y ago

I am honestly disappointed, I think Raku is a much nicer language than Perl 5 or 7 And I really wish, if those working on Perl 5 would have switched to Raku, but sadly i think CPAN for Perl 5/7, have a lot more activity than the equivalent at Raku Most new and modern languages are Compiled, Functional or targeting the JVM or .Net frameworks Raku is I think the last and only modern scripting language , it could have used the helping hand of the Perl 5/7 community

goto11 6y ago
There is a lot of Perl 5 code around though. Improving 5 (in a backwards compatible way) therefore provides a lot of value. But a Perl 7 which is not focused on retaining backwards compatibility with 5 is worst of both worlds. Existing code bases will not upgrade, and nobody will start a green field project in it when Raku (not to mention Python, Ruby etc) is available. It would be dead in the water.
Icathian 6y ago
Isn't Python typically considered a scripting language, and usually ranked as at least top 3 in popularity?
- systems 6y ago
  Yes, but the way i see it, Raku (Perl6) was a complete rewrite of Perl .. was a radical change (rational numbers, grammar, multimethods, ...) Python 3, is in my opinion more of an incremental and conservative change
moonchild 6y ago
Raku is JIT-compiled, same as JVM/.net languages. And python and javascript and ruby and lua and...
- systems 6y ago
  Clojure and F#, have some complexity that you wont find in Raku, try installing all 3 and run a simple script Clojure, you will need boot or leiningen , or use the new command line tools which are not supported on windows F#, you will install dotnet core and will have to learn about the differend SDKs and compatibility differences between OSes Next try to find, install use package, its a lot less obvious how to do this compared to what I call a pure scripting language like Raku And compared to Ruby and Python, I think Raku have more modern features , gradual typing, rational number, grammars, unicode operators etc .. Raku is one very few pure scripting language where innovation is still happening

jpz 6y ago

what happened to perl6? I'm confused :)

qalmakka 6y ago
Perl6 became Raku, a whole different language, something that should have happened since the very beginning instead of putting on a totally different project the label "Perl" and thus funneling in a truckload of FUD that only harmed the language.
systems 6y ago
They renamed it to Raku, the renamed have two benefits in minds 1. Reintroduce Perl 6 (Raku) as a completely new language, since some thought that being linked to Perl prevented adoption 2. Open the road for Perl 5 to evolve and add features, many people in the Perl 5 community thought that Perl 6 prevented Perl 5 from growing In Summary, the sentiment was, Perl 5 and Perl 6 are two different languages each with its own roadmap, but that the name gave the impression they are one, and prevented both from evolving
- jpz 6y ago
  cheers, TIL :)

qalmakka 6y ago

I like Perl, and I think that changing the defaults is a sane thing to do. Starting a new script with dozens of "use strict", "use v5.30", etc is less than ideal and it's easy to forget something and shoot yourself in the foot. Almost 30 years will pass between Perl 5 and 7, and going back to the old values is just a matter of adding a few lines at the beginning of your old script. It's not a mess like the whole "Python 2/3" ordeal that was deeply more complex and painful. Heck Perl in the last 30 years has been even more stable than C. I remember when gcc and clang switched from a default of GNU89 to GNU99 and it broke several packages who didn't set or check for the right flags; nobody bitched about it and just went on to fix their Makefiles.

cwyers 6y ago
I am not a Perl person, but it does sound to me like a lot of this thread is is missing what's going on, yeah. They're not changing the language, they're just changing the runtime to use better, more modern defaults. I don't know if you would be able to put in "use unstrict" or something and get back the old behavior, but any actively-maintained code is probably using most of these newer defaults anyway.
- HighPlainsDrftr 6y ago
  Brian D Foy wrote a pretty good post on this. https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/ Essentially, it is just perl 5.32 with more modern defaults. They will keep evolving the language. Perl 5 isn't going anywhere.

gjvc 6y ago

Much of the problem is that people see things like Perl or Python as holy grails that must not be changed or questioned. This stance mainly comes from these languages having been installed by default on almost all Unix platforms for the past 25 years. That's quite a long time to bludgeon people into thinking that these things are sacred and fixed. Computerists should not be afraid to try something new at every turn, and then reject that something if it does not measure up. In the short run, change is often scary, but in the long run it is the only way to survive.

nige123 6y ago

Expressiveness + Extensibility + Stability Sounds like excellent values for a programming language. I'm interested to hear what the top three values for Perl 7 are? Exciting times for Perl!

py_or_dy 6y ago

I really don't get any of this. Here's the full picture: Larry Wall mostly gave up on Perl 5 in 2000 and announced the next release would be "Perl 6". A few small updates happened to perl 5 up until 2002. Larry started working on Perl 6, forever leaving perl 5. Perl 5 goes stagnant for 5 years, meaning it had no updates released for 5 years. During this time, droves of people picked up python. Perl 6 was no where near complete in 2007, and a small team of devs pushed out perl "5.10" after a 5 year hiatus. Perl 6 was finally released in ~2018 but by this time no one cared. The perl 6 team feels because of the name 'perl', people aren't adopting this new language, so they change the name. And now a year later, the small perl 5 team is wanting to take perl into the modern age by breaking backwards compatibility. It makes no sense at all, that was the job of perl 6. It would no different if I started complaining about python 2 not getting any updates and then making a plan to better improve its parser and object model and break backwards compatibility and bring it into the modern age. Python 3 already did that, so like what the heck are you doing??? And then the comments from the perl 7 supporters... saying things like we can either "fight or die" or doing nothing is "certain death" but the alternative is "uncertain hope". I just don't see the point in fighting for something the original author of gave up on over 20 YEARS ago. I've stated my points [0] before on how companies that stick with perl 5 do so at their own demise. They get cultured into a train of thought where updating software is seen as bad and unhealthy. And if they are a consultancy, their downstream customers also get cultured in to never having to worry about "updates" and/or paying for updates. So then long term contracts with said customer only take into account the cost of feature enhancements instead of "maintenance". So then it becomes impossible to move either consultancy or customer off of the "perl platform" because going to something like django, while a big cost in its own right, would involve a different long term contract that would require paid support and downtime for future django updates/releases. Never mind that finding devs would be easier (and probably cheaper), and the fact that django gets regular security audits and has a much larger plugin/library support ecosystem. Anyway, to each their own. And godspeed to the perlings out there, I just don't see how any of this is worth it... [0]:https://news.ycombinator.com/item?id=23633478 https://news.ycombinator.com/item?id=23633478

jlokier 6y ago

If I understand right, all they are doing is changing the per-script, per-module defaults to enable current language features, instead of having most features since about 2005 disabled by default. Perl5 has a very strong position on backward compatibility. Even when they change behaviour or add new syntax, that's disabled by default unless a script or module explicitly asks for the new behaviour. Each significant feature can be switched off or on per module. Even if the main program turns on features, they remain off for the modules used by the main program. So as far as I can tell, the proposal is just to change this default, so that modern Perl5 features are available to new code by default, instead of having to be explicitly requested, and there's no radical change or incompatibility planned for v7. That's a change of compatibility-first culture. It means scripts which don't specify what they do and don't want will indeed break with newer versions, occasionally. However Perl5 changes quite slowly, and it's unusual for something new to break something old anyway. But it should be easy for scripts to specify what they want. If there's a "no v7" directive that should be enough at the start of any script or module that wants to keep working while being insulated from future changes. That's not much different, in practice, than what they already have to do to ask for features they do use. Another idea would be to have two search path directories, with different defaults in each, and modules install into the appropriate one according to module metadata. This would allow existing, old modules to carry on working in v7.

amai 6y ago

Perl7 is as important as Rocky 7 or Terminator 7.