Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday June 29 2020, @08:43AM   Printer-friendly
from the out-with-the-old,-in-with-the-new dept.

Submitted via IRC for TheMightyBuzzard

This morning at The Perl Conference in the Cloud, Sawyer X announced that Perl has a new plan moving forward. Work on Perl 7 is already underway, but it's not going to be a huge change in code or syntax. It's Perl 5 with modern defaults and it sets the stage for bigger changes later. My latest book Preparing for Perl 7 goes into much more detail.

Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults. You won't have to enable most of the things you are already doing because they are enabled for you. The major version jump sets the boundary between how we have been doing things and what we can do in the future.

Remember, Perl was the "Do what I mean" language where the defaults were probably what you wanted to do. In Perl 4 and the early days of Perl 5, that was easy. But, it's been a couple of decades and the world is more complicated now. We kept adding pragmas, but with Perl's commitment to backward compatibility, we can't change the default settings. Now we're back to the old days of C where we have to include lots of boilerplate before we start doing something:
[...]
This is slightly better with v5.12 and later because we get strict for free by using setting a minimum version:
[...]
Perl 7 is a chance to make some of these the default even without specifying the version. Perl 5 still has Perl 5's extreme backward compatibility behavior, but Perl 7 gets modern practice with minimal historical baggage.

Source: https://www.perl.com/article/announcing-perl-7/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by Anonymous Coward on Monday June 29 2020, @12:39PM (10 children)

    by Anonymous Coward on Monday June 29 2020, @12:39PM (#1014036)

    The most likely thing that happens to Perl in the next 30 years is that it follows the footsteps of COBOL. People completely stop using it for new projects, but there are still tens of millions of lines of legacy code in use and requiring maintenance.

    But this is the first step of what could be a Perl revitalization. All of the features added to the Perl 5.x minor releases since 2002 have been placed behind optional experimental flags placed at the top of each source file. That was great for backwards compatibility, but bad for evolving the language and also more complicated for novices learning the language. With Perl 7.0, a curated list of those experimental flags from the 5.x minor releases is the default, and a new flag is introduced to restore the previous 5.x default.

    Three things could move Perl forward:

    1. They plan to use a similar development model with Perl 7 and future releases that they did with Perl 5. That is, 7.x minor releases will have new features under experimental flags, and when they do their 8.0 release they will select a set of those 7.x experimental features to make as default and add a new flag to allow using the 7.x defaults. Likewise for the 8.x minor releases and 9.0 release, and so forth. I think this will allow Perl to evolve much more rapidly than it has in the previous 20 years.
    2. As part of the 7.x minor releases they plan to build object-oriented (OO) programming into the core language, guarded by experimental flags. Perl 5 has a simple OO system that's very verbose and hard to use, and there are lots of modules in the wider ecosystem for nicer OO. It all works very well for Perl experts, but it's a real headache for novices. "How do I do OO in Perl?" "First you need to install cpan or cpanm and learn how to use it. Then you have to pick an OO system on CPAN. Then start reading the documentation." "What if I use one Perl OO module and then I have to use a module that uses another one?" "Then you have to translate between the two object types manually." Contrast that to Python, Ruby, PHP, C#, Java, and dozens of other languages. "How do I do OO in Python/Ruby/PHP/C#/Java?" "Class Foo". Also a lot of the OO modules in CPAN offer tons of features but poor performance, a builtin OO system might be faster.
    3. Some of the Perl maintainers just released an optional set of guidelines for Perl they call "Standard Perl". The guidelines restrict the Perl syntax you are permitted to use and they check it with a custom parser. Perl developers that write code with the expectation that someone would want to read it someday are already following most of the "Standard Perl" guidelines. Restricting Perl to "Standard Perl" makes it easier to read, dramatically easier to learn, and easier to write IDE tooling for. I'm hoping that with Perl 8 or Perl 9, the default is "Standard Perl" and you'll need to use a flag to get back the older behavior.

    Maybe with those changes Perl 8 or 9 could be back on even footing with Python, PHP, and Ruby. I think right now it's behind. Separately, Perl6/Raku is totally awesome and I highly recommend it for anyone who wants to play with a neat language - but industry adoption is still low, so don't expect Raku expertise to get you a job and don't wedged it into some project at work and then force a colleague to maintain or rewrite it after you leave. (I raved about Raku up-thread, https://soylentnews.org/comments.pl?noupdate=1&sid=38229&page=1&cid=1014013#commentwrap [soylentnews.org] )

    Starting Score:    0  points
    Moderation   +5  
       Interesting=4, Informative=1, Total=5
    Extra 'Interesting' Modifier   0  

    Total Score:   5  
  • (Score: 5, Insightful) by The Mighty Buzzard on Monday June 29 2020, @01:31PM (2 children)

    You wish. Perl, unlike COBOL, still has things that it is the absolute best language for. Even for brand new projects. It doesn't matter if it's the most all-around useful language or not, so long as it's the best at what it was made for. And it still is.

    --
    My rights don't end where your fear begins.
    • (Score: 3, Interesting) by gawdonblue on Tuesday June 30 2020, @07:36AM (1 child)

      by gawdonblue (412) on Tuesday June 30 2020, @07:36AM (#1014427)

      Hey, COBOL is still the best language for what it was invented for - financial systems. Java is more trendy for this, but you end up with a crap-ton more code and added libraries to achieve what COBOL could do natively, and you have no chance without an IDE holding your hand.

      It's weird, when I was first learning to program in the early 80s they used COBOL as an example of a wordy language with too much boilerplate cruft. Then someone invented Java. Ha!

      • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @04:01PM

        by Anonymous Coward on Tuesday June 30 2020, @04:01PM (#1014547)

        static.public.Integer.add(1)

  • (Score: 1, Insightful) by Anonymous Coward on Monday June 29 2020, @01:58PM (6 children)

    by Anonymous Coward on Monday June 29 2020, @01:58PM (#1014066)

    Some time in the past, we learned "scary things" like C, C++, Perl, assembly, etc. and thought nothing about it. Those tools were to HELP us do things that we needed done, is all. Is the new generation born damaged in the brain, or is the braindamage dealt them by their early education?

    • (Score: 2, Insightful) by Anonymous Coward on Monday June 29 2020, @02:51PM (5 children)

      by Anonymous Coward on Monday June 29 2020, @02:51PM (#1014094)

      For the record, I prefer Perl to Python/PHP/Ruby, and yes I'm familiar with all four.

      1. If two tools can accomplish a given task and one is harder to learn than the other, what possible reason is there for learning the harder one? I already know Perl, I don't need Python. But for someone new to programming, what are you going to tell them to convince them to learn Perl instead of Python? Likewise, if you don't need the C++ performance advantages, C# and Java are far easier to learn than C++. Again, for someone who already knows C++ it doesn't matter, but for every new person entering the industry unless they're specifically going into high performance computing why should they learn C++?
      2. Because of the previous point, there will be more job opportunities for Python, Java, and C# over time and fewer for Perl and C++. If you can learn Perl and C++, you can learn Python and C# or Java, so you will not have a problem finding work. But you won't get to work in the languages you love.

      That's the reality. "Perl is spectacular as-is, don't change a thing." -- that guarantees that Perl becomes COBOL 2. Perl's share of the market is already a tiny fraction of what it was 15 or 20 years ago, continuing with the status quo makes the problem worse.

      • (Score: 2, Interesting) by Anonymous Coward on Monday June 29 2020, @07:45PM (1 child)

        by Anonymous Coward on Monday June 29 2020, @07:45PM (#1014228)

        If two tools can accomplish a given task and one is harder to learn than the other, what possible reason is there for learning the harder one?

        Obviously, the easier accomplishing the tasks you need accomplished. What else?
        For example, C certainly can accomplish any task that Perl can; Perl itself is written in C and Perl. However, I learned Perl too as it makes complicated text processing tasks far easier.

        But for someone new to programming, what are you going to tell them to convince them to learn Perl instead of Python?

        CPAN. No abuse of whitespace. Two or three times less writing to do any given thing.

        Likewise, if you don't need the C++ performance advantages, C# and Java are far easier to learn than C++.

        Everything is far easier to learn than C++. And it was made that way incrementally, precisely through NOT "continuing with the status quo".

        Perl's share of the market is already a tiny fraction of what it was 15 or 20 years ago, continuing with the status quo makes the problem worse.

        Market shares are gained by use of marketing tools, not by any objective thing. Perl did not have a deep-pocket corp backer in the time the deep-pocket corps were divvying up the market; Perl lost.
        Community-based project do not have the money to burn on promotion, but promotion is the only thing that matters in the real world. Technical merit means nothing.

        • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @06:17PM

          by Anonymous Coward on Tuesday June 30 2020, @06:17PM (#1014620)

          Market shares are gained by use of marketing tools, not by any objective thing. Perl did not have a deep-pocket corp backer in the time the deep-pocket corps were divvying up the market; Perl lost.
          Community-based project do not have the money to burn on promotion, but promotion is the only thing that matters in the real world. Technical merit means nothing.

          That's not the whole story, because Python grabbed a huge share of the market without a corporate backer either. I think Perl lost market share for three reasons:

          1. In the dot com boom, people who were not bright enough to properly operate a toaster were writing production code, and it happened to be in Perl. Perl gained a bad reputation because of the spaghetti messes they left behind. It was just timing, if Java or Python was the hot language during the dot com boom then they would be getting lots of hatred today. (Well, Java is already pretty widely loathed. Python is generally liked or at the most gets an indifferent reaction everywhere except from Perl mongers.)
          2. Perl6/Raku was so different from previous Perl editions it should have been a separate language from the beginning. Because it wasn't, a lot of companies put existing Perl work and new Perl projects on hold in the early 2000s because they were waiting for Perl 6. A lot of momentum was lost. I love Perl6/Raku, but as much as the technical features are brilliant the marketing and transition plan were a disaster.
          3. Perl is so forgiving that in many cases TIMTOWTDI is actually TALALOWTDOI (there are lots and lots of ways to do it) and it makes the learning curve steep enough to hurt adoption. And while most Perl users don't care on an individual level whether any particular novice decides to learn Perl, on an industry level fewer new users leads to fewer new projects and job opportunities in the language we love.

          Perl is still fighting an uphill battle on the first point. The second point is finally resolved now that Raku is separate. I think the third is where there is the most room for progress.

      • (Score: 2) by The Mighty Buzzard on Monday June 29 2020, @09:14PM (2 children)

        1) Suitability to purpose is more important than ease of learning. Which is why AAA games are not written in Java.
        2) It's not an either/or situation. Learning only what you need for a job makes you a mediocre investment by a boss. Learning everything you can and being able to use the best tool for the best job makes you a fantastic investment by a boss.

        --
        My rights don't end where your fear begins.
        • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @05:25AM (1 child)

          by Anonymous Coward on Tuesday June 30 2020, @05:25AM (#1014406)

          I'd expect Java would be right at home with games eating GBs of RAM 😈