Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday June 29 2020, @08:43AM   Printer-friendly [Skip to comment(s)]
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.
(1)
  • (Score: 3, Interesting) by coolgopher on Monday June 29 2020, @08:49AM (35 children)

    by coolgopher (1157) Subscriber Badge on Monday June 29 2020, @08:49AM (#1014000)

    So this is their admission that they took a bad step with Perl 6 then?

    • (Score: 5, Informative) by Anonymous Coward on Monday June 29 2020, @09:22AM (33 children)

      by Anonymous Coward on Monday June 29 2020, @09:22AM (#1014002)

      Perl 6 had too many breaking changes from 5, that they decided to treat it like its own language and added even more changes people thought were long overdue. Hence they changed the name of what used to be 6 to "Raku." They are also skipping this version to 7 to skip the issue of people running into old and inaccurate information about this new version. They are still pushing both branches forward on their respective roadmaps.

      This is also what some people said Python should have done as well. Since you are already breaking things, change everything that you wished you could change but didn't due to backwards compatibility. Then rename this new language to something related, like anaconda, viper, or DropboxLang and start clean. It not admitting either was a mistake but that they are different and you let each go their own way based on who cares enough to invest the time. Either they survive or they don't. The real interesting suggestion is the dual (or duel, depending on your POV) interpreter suggestion, but that has never really taken off in any language.

      • (Score: 2) by coolgopher on Monday June 29 2020, @11:07AM (8 children)

        by coolgopher (1157) Subscriber Badge on Monday June 29 2020, @11:07AM (#1014011)

        Thanks! I had completely missed the Perl6->Raku bit.

        • (Score: 0) by Anonymous Coward on Monday June 29 2020, @11:51AM (7 children)

          by Anonymous Coward on Monday June 29 2020, @11:51AM (#1014023)

          You and everybody else. That's because nobody cares about Perl 6. It doesn't make the news.

          • (Score: 1, Flamebait) by The Mighty Buzzard on Monday June 29 2020, @01:25PM (6 children)

            I care about it. It deeply comforts me that Perl 6 was given the boot. It took all the ease and utility goodness of Perl and Python'd it into a cocktacular mess.

            --
            When responding to comments, please do not use phrases like "just how stupid can you be". Some take that as a challenge.
            • (Score: 2) by dmbasso on Monday June 29 2020, @01:41PM (5 children)

              by dmbasso (3237) on Monday June 29 2020, @01:41PM (#1014062)

              If it had "Python'd" as you said, the language would be successful, as Python 3 is. But in actuality, Perl is not even a blimp in the radar, with less than 1% usage.

              --
              `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
              • (Score: 3, Insightful) by RS3 on Monday June 29 2020, @02:53PM (4 children)

                by RS3 (6367) on Monday June 29 2020, @02:53PM (#1014095)

                Not to be argumentative, but imho very little in computing is successful because it's truly better. Non-technical business people often make the decisions about what technologies to use, often completely at odds with technical staff. Those idiots wouldn't tell their plumber or auto mechanic which tools to use, but they'll tell their engineers which tools to use.

                • (Score: 3, Interesting) by dmbasso on Monday June 29 2020, @06:42PM (3 children)

                  by dmbasso (3237) on Monday June 29 2020, @06:42PM (#1014203)

                  Except you'll notice that Python is also used for personal projects in a much higher ratio relative to Perl.

                  But my point was about the "Python'd" as derogative... sure, the Python 3 release could perhaps have been handled better, but after the initial friction the language has been adopted and is successful - and that was certainly by its merits. Otoh, take a crappy language and try to polish it somehow, and you'll not get that same result. Ofc you can say my use of the word "crappy" is subjective, but that's my experience... the only language worse than Perl I used in the 30 years since I started programming was Authorware's built-in scripting (back in 1994). I could add BASIC as worse than Perl too, but fortunately I never had to anything professionally with it. :p

                  --
                  `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
                  • (Score: 4, Touché) by The Mighty Buzzard on Monday June 29 2020, @09:04PM

                    Except you'll notice that Python is also used for personal projects in a much higher ratio relative to Perl.

                    Yes, because it's trendy and easier for idiots. I am not an idiot though and am going to use the best tool for the job.

                    --
                    When responding to comments, please do not use phrases like "just how stupid can you be". Some take that as a challenge.
                  • (Score: 2) by RS3 on Monday June 29 2020, @09:06PM (1 child)

                    by RS3 (6367) on Monday June 29 2020, @09:06PM (#1014250)

                    Absolutely, all good points. I have a friend who refers to certain things as "polished turd".

                    Again, really don't mean to be argumentative, but I know that when I see the business market (job ads) is driving a specific technology, I develop interest. If it's difficult or annoying, it might become a personal challenge to deal with it. It's all part of me trying to accept a reality I really hate: non-technical business-types making the decision about what tools I should use. And yes, it has been a big problem for me in my professional life.

                    I've done some BASIC professionally! Way back when 1) I knew BASIC, and 2) it was included in IBM PCs and Macintoshes. I even wrote an FFT and plotting algorithm. But the fun BASIC was for an industrial control system's PLC. There were pressure and temperature monitor instruments that had an RS-232 port. BTW, I didn't design nor spec out any of this stuff. Anyway, there was a PLC module that ran BASIC and had a serial port, so my sw "talked" first to a code operated switch- you just sent a string that told the switch which port to switch to, and then my code gave commands to the selected pressure or temperature instrument, then received the data, and put it into PLC memory. It ended up being a very complex task because someone else had started the project. I assume they had quit the company- I never really knew. It was the most horrible spaghetti code ever written. There were long variable names that were only ever used once, and "i" for a major global. Anyway, their code never worked, and was far too slow. Somehow it hit me, and I ran experiments to prove it, that if you did any kind of branch / jump / goto, the stupid interpreter started at line zero and scanned through everything, every time. So I did as much loop-unrolling, and anything that really needed to loop or be a frequent subroutine was at the top, and init code was the very bottom. The line-number scanning stupidity was never documented.

                    And I've done some VB and frankly I don't hate it but ironically had huge trouble getting serial port stuff to work...

                    • (Score: 2) by dmbasso on Monday June 29 2020, @09:58PM

                      by dmbasso (3237) on Monday June 29 2020, @09:58PM (#1014274)

                      Nice stories, thanks for sharing! It made me recall that I actually used BASIC professionally, but nothing really interesting (as your cases are). I made some interactive graphics materials for an "intro to computers" course I lectured back in 92 or 93. I used Borland's Turbo Basic to compile them; it was really nice to have small executables, specially in comparison to Clipper's output (the language that I used most at that time).

                      --
                      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
      • (Score: 3, Interesting) by Anonymous Coward on Monday June 29 2020, @11:08AM (23 children)

        by Anonymous Coward on Monday June 29 2020, @11:08AM (#1014013)

        I would add that Perl6/Raku has been out for 4.5 years, and it's spectacular. Performance was terrible with the initial release, but now it's within 2x of other scripting languages in most cases and ahead in a few, and more optimizations are in development. You get much simpler and more consistent syntax than Perl5 (or 7), full OO with multiple inheritance and a full meta-object protocol, function signatures with named and default arguments, optional static type checking (and it is enforced), multi-methods, operator overloading, optional generics, adjustments to the regular expression syntax to improve readability, async/await, promises, and other concurrency primitives, enums, guards on function parameters, and a built in grammar system to simplify writing all kinds of Deals. A macro system also exists but is being rewritten.

        Raku covers all of the territory from "improved Perl" through Python, Ruby, Java, C#, and most of Scala or even Haskell.

        • (Score: 2, Disagree) by The Mighty Buzzard on Monday June 29 2020, @01:27PM (16 children)

          Dude, if you want Python just use Python. There are plenty of us who know why Perl is way, way more useful for specific tasks. Perl6 staying in the formal release chain would have killed that utility.

          --
          When responding to comments, please do not use phrases like "just how stupid can you be". Some take that as a challenge.
          • (Score: 0) by Anonymous Coward on Monday June 29 2020, @01:42PM (2 children)

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

            "Dude, if you want Python just use Python"

            There are many many programming patterns that work in other languages that don't work in Python. Python is mostly useful because it is trivial to export C++ API's into Python. If it was even remotely near as easy in Perl, there would be no Python.

            For the previous post, thanks, I will take a look at Raku. My issue is whether I can use a toolchain to make clean C++ API extensions in an interpreted language. This is the number one reason for using Python. It isn't faster or cleaner or easier to debug as most people claim because it requires way more orthoganality. So the #1 issue for me is: Can I take a C++ API, run a simple toolchain and make an interpreted language API.

            In my experience that is the only practical reason to use Python over another language.

          • (Score: 1, Insightful) by Anonymous Coward on Monday June 29 2020, @02:54PM (9 children)

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

            I like Perl, I like Python, and Raku blows them both to hell. As I said, it covers all of the territory occupied by Perl, Python, C#, and Java and most of the territory occupied by Scala and Haskell. The only place Raku isn't prepared to compete is maximum performance computing - C, C++, Fortran, ATS, (maybe) Rust. Even then, the Raku syntax for FFI is much easier to work with than XS.

            The Perl6 name was a mistake, because nearly zero Perl5 code will run unmodified in Raku. It's a different language, and both Perl and Raku would have benefitted immensely if they had the foresight to label it that way from the beginning. But Larry Wall and co knocked this one out of the park.

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

              Raku isn't compared to compete in the place Perl is most useful: arbitrary text mangling, quickly coded.

              --
              When responding to comments, please do not use phrases like "just how stupid can you be". Some take that as a challenge.
              • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @12:32AM (7 children)

                by Anonymous Coward on Tuesday June 30 2020, @12:32AM (#1014319)

                ?? Perl has the amazing and significant advantage of much faster startup and lower overhead than Raku, and the even more significant advantage that it's rare to find a *Nix installation without it. And those are completely valid reasons to use Perl over Raku for a task.

                But did you really think Larry Wall was going to try to make a language in the Perl family and kick text wrangling to the curb? That would be like having Guy Fieri and Mario Batali announce that they were going to collaborate on a new nail salon. Raku is excellent for text wrangling.

                • (Score: 2) by The Mighty Buzzard on Tuesday June 30 2020, @12:51AM (6 children)

                  I've used Perl6. Built an IRC bot in it a year or three ago here on our IRC server. It sucks all of the cocks for text wrangling compared to Perl5. It's not quite as ass licking as Python for the job but it's close.

                  --
                  When responding to comments, please do not use phrases like "just how stupid can you be". Some take that as a challenge.
                  • (Score: 2) by maxwell demon on Tuesday June 30 2020, @12:45PM (5 children)

                    by maxwell demon (1608) on Tuesday June 30 2020, @12:45PM (#1014467) Journal

                    Not having experience with heavy text wrangling, I'd be interested what the issues were.

                    --
                    The Tao of math: The numbers you can count are not the real numbers.
          • (Score: 2) by VLM on Monday June 29 2020, @06:24PM (2 children)

            by VLM (445) Subscriber Badge on Monday June 29 2020, @06:24PM (#1014194)

            If I don't care about performance I already use Ruby. Raku is pretty much "NIH version of Ruby".

            Honestly I have severe problems using Raku and Ruby because the syntax is practically the same but not quite.

            Quick trivia question to demonstrate the agony, which is proper Ruby syntax and which is proper Raku syntax? I just can't program in both languages without trying to write Ruby in Raku and Raku in Ruby, and there's more cool stuff out there for Ruby, so ...

            bigassArray[5..10].join(',')

            @bigassArray[5..10].join(',')

            I like Perl and I like that Perl 7 is something like "lets take the modern perl book and shrink it from a book to a page".

            I have a nifty book named "Modern C" which is unfortunately long as hell list of things not to do. There are languages where the "modern wtfLang" book would be a couple pages long at most. Clojure I guess.

            • (Score: 2) by maxwell demon on Tuesday June 30 2020, @12:48PM

              by maxwell demon (1608) on Tuesday June 30 2020, @12:48PM (#1014469) Journal

              I've never programmed in either Perl 6/Raku or Ruby, but the trivia answer is easy. The second one is the Perl6 version, as it has the Perl-typical "@" for arrays.

              --
              The Tao of math: The numbers you can count are not the real numbers.
            • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @06:06PM

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

              Obviously Ruby has a > 100x advantage when it comes to the list of available software already written in it, and it's a good language.

              If I was just working on something because I needed to get it done for a job, or even a project a friend asked for help on, or some annoyance, I would pick the language that offered the quickest path to a maintainable solution. I pick Raku when I'm coding for fun. I would love for it to reach the point where it is the first tool I reach for to solve problems quickly and maintainably, but for now it's just my favorite toy.

        • (Score: 3, Interesting) by bzipitidoo on Monday June 29 2020, @01:33PM (5 children)

          by bzipitidoo (4388) on Monday June 29 2020, @01:33PM (#1014056) Journal

          When I last tried Perl 6, some 3 years ago, it was dog slow. Just to read in a 100M file, one byte at a time, took 20 minutes. Same program in C took 2 seconds. Good to hear that they've optimized. Wonder how fast it could read 100M now?

          I saw the Perl 6 -> Raku name change a few months ago. The fact that they're rolling out Perl 7 for the new name, rather than Perl 6, suggests that the renaming to Raku will never totally stick.

          • (Score: 1, Interesting) by Anonymous Coward on Monday June 29 2020, @03:59PM

            by Anonymous Coward on Monday June 29 2020, @03:59PM (#1014125)

            I think the jump to Perl 7 is so that if someone did a web search for "Perl 6 do X" they don't get code snippets from Raku instead of for Perl 6.

            I just tested file IO and you're correct, it is horrifically slow. Small files are fine - I have a web media server written in Raku running right now without issues. But reading a 100MB file from a spinning platter drive took almost 10 minutes and used many GB (?) of memory. There are features you can use to improve speed and reduce memory usage, but the defaults shouldn't be this wildly bad. Thanks for mentioning it, I'm going to open a Github issue.

          • (Score: 1, Interesting) by Anonymous Coward on Monday June 29 2020, @04:53PM

            by Anonymous Coward on Monday June 29 2020, @04:53PM (#1014154)

            There must be some things I misunderstand in their IO subsystem. I took a random 100MB file and this C program (my C is rusty, I just downloaded it and hacked it until it worked):

            #include

            struct rec { unsigned char x; };

            int main() {

            int counter; FILE *ptr_myfile; struct rec my_record;

            ptr_myfile=fopen("junk.bytes","rb");

            for ( counter=1; counter
            fread(&my_record,sizeof(struct rec),1,ptr_myfile);

            if (counter > 99999990) {

                  printf("%d\n",my_record.x);

            } // end if

            }// end loop

            fclose(ptr_myfile);

            return 0; } // end file

            That took 1.06 seconds to run, unoptimized (just "gcc main.c; ./a.out").

            This Raku program ran in 0.34 seconds (faster than the C, not a typo):

            my $fh = open "junk.bytes", :r, :bin;

            my $x = $fh.slurp;

            say "Read " ~ $x.bytes ~ ".";

            for (1..10) { say $x.pop(); }

            That gave the same final bytes as C, but in reverse order (because I'm in a hurry). So Raku can be fast, but some of the IO calls that seem intuitive must be bad/odd ?

          • (Score: 0) by Anonymous Coward on Monday June 29 2020, @06:57PM (2 children)

            by Anonymous Coward on Monday June 29 2020, @06:57PM (#1014211)

            Okay, I've done more testing because you got me interested. Short summary: unbuffered IO is dreadfully slow, buffered IO is adequately fast but still not as fast as other scripting languages.

            I took a 100 million byte binary file and then wrote six programs to traverse the file and print the last few bytes. Raku 2020.06 single byte read: almost 14 minutes. Raku 2020.06 read in 64k buffered chunks: 0.35 seconds (Raku 'Hello World is 0.22 seconds.), and Raku on my machine has a 0.22 seconds tartup time. C single byte read: 1.04 seconds. C read in 64k buffered chunks: 0.021 seconds. Python single byte read: 17 seconds. Python read in 64k buffered chunks: 0.06 seconds (Python 'Hello World' is 0.01 seconds.).

            So with 64k buffered reads, Raku is 6 times slower than C and 3 times slower than Python (if you ignore the startup overhead). With the single byte (unbuffered) reads, Raku is around 750 times slower than C and 50 times slower than Python. Damn.

            • (Score: 2) by bzipitidoo on Monday June 29 2020, @09:46PM (1 child)

              by bzipitidoo (4388) on Monday June 29 2020, @09:46PM (#1014267) Journal

              I expect one reason the C program is so fast is that, under the hood, the C stdio library really is buffering the file read even when the program is reading only one byte at a time. Evidently, Raku is not.

              I guess it comes down to whether an app programmer should have to worry about I/O buffering, or not. And the way programming has evolved over the years, with the pushing of everything that can be pushed off to the computer, such as memory management (smart pointers) and hashing, then, absolutely yes, buffering for fast I/O should be the system's problem, not the programmer's problem. Thanks for looking into this.

              • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @12:35AM

                by Anonymous Coward on Tuesday June 30 2020, @12:35AM (#1014320)

                Thank you - I jump at any excuse to play with Raku, and I was upset when I saw such terrible performance. I'm not thrilled with a 6x gap, but for most tasks that's acceptable.

    • (Score: 0) by Anonymous Coward on Monday June 29 2020, @01:46PM

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

      And about a similar development from that age, I expect to hear about IPv8 soon.

  • (Score: 2) by Arik on Monday June 29 2020, @09:33AM (1 child)

    by Arik (4543) on Monday June 29 2020, @09:33AM (#1014003) Journal
    Do what I say.

    As long as the two are the same, then that motto is fine. The moment they're different, it's not.
    --
    - Sig not found. Self destruct initiated. Please clear the area.
    • (Score: 0) by Anonymous Coward on Monday June 29 2020, @09:52AM

      by Anonymous Coward on Monday June 29 2020, @09:52AM (#1014004)

      That's when you fall back on the other motto: TIMTOWTDI.

  • (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] )

    • (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.

      --
      When responding to comments, please do not use phrases like "just how stupid can you be". Some take that as a challenge.
      • (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.

          --
          When responding to comments, please do not use phrases like "just how stupid can you be". Some take that as a challenge.
          • (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 😈

  • (Score: 2, Interesting) by Anonymous Coward on Monday June 29 2020, @02:01PM

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

    Wow that is nice.

    I love perl, but the big hangup was always XS. It was a huge PITA to write glue code for existing well documented libs. Raku seems to have fixed that with the nativecall() function. If it works, then it deprecates Perl, Python and a couple of others. Imagine having a language with the flexibility of Perl with the API integration of Python? Way way cheaper to use than either perl or python.

    The issue is of course maintaining that level of integration. My expectation is certain vendors will not take kindly to the sudden explosion of portable FOSS code on their platforms.

    So choosing between the forks? Yeah, Raku it is.

     

(1)