Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Perl Programming

Perl 7 Announced As Evolving Perl 5 With Modern Defaults (phoronix.com) 86

Taking place this week is the virtual Perl + Raku "Conference in the Cloud" as a result of the COVID-19 pandemic causing the event to go virtual. A big announcement out of it is Perl 7. From a report: Perl 7 basically amounts to Perl 5 with more modern defaults and foregoing some of the extensive backward compatibility support found with Perl 5. News of Perl 7 comes a few days after the release of Perl 5.32. Perl 7 succeeds Perl 5 due to the Perl 6 initiative previously for what is now known as the Raku programming language. So to avoid confusion, similar to the PHP 6 debacle, Perl 7 is the next version. For the most part though Perl 7 is close to Perl 5.32 with changed defaults and is more forward looking with less commitment to backward compatibility support.
This discussion has been archived. No new comments can be posted.

Perl 7 Announced As Evolving Perl 5 With Modern Defaults

Comments Filter:
  • but (Score:5, Funny)

    by hjf ( 703092 ) on Wednesday June 24, 2020 @01:48PM (#60223056) Homepage

    Unicode support? Can we upgrade Perl so Slashdot can finally support foreign characters?

    • Re: (Score:3, Informative)

      by Shaitan ( 22585 )

      Why would we WANT foreign characters? That would encourage people to inappropriately post foreign language content and help support Apple's broken quotes.

      • Re: (Score:3, Informative)

        Unicode support would also likely mean Slashdot being blocked in China.

        Slashdot is currently available in China because it can't be used for one-to-many communication in Chinese.

        So please, no Unicode. Slashdot is, and should be, an English language forum.

        • Re:but (Score:5, Informative)

          by tlhIngan ( 30335 ) <slashdot&worf,net> on Wednesday June 24, 2020 @04:37PM (#60223826)

          Slashdot is currently available in China because it can't be used for one-to-many communication in Chinese.

          So please, no Unicode. Slashdot is, and should be, an English language forum.

          Except Slashdot has supported Unicode for around two decades now. Yes, two decades. Basically it was added when Slashdot Japan was a thing.

          The thing is, Unicode support is tricky. It's not just "more characters" but a whole can of worms. Even companies like Apple and Google get tripped up by it all the time.

          Things like character decorations - accents and other things you can attach to a letter. Some languages support a ton of them, and Unicode makes no restriction on what happens when you go and combine a million decorations on a character, which basically end up with a vertical black line that runs from the top of the page to the bottom obscuring hundreds of comments. Add in a whole row and you now have made the page black and unreadable while serving up plain Unicode text.

          Of course, it didn't get that bad because on Slashdot, trolls only abused the RTL/LTR override codes in the beginning causing the entire page to be rendered backwards.

          In the end, blacklisting every "bad" Unicode codepoint is a monumental task so Slashdot simply whitelisted the allowed character set instead - basically the ASCII printable set. A few years ago Slashdot filtered the output through the filter as well - before it did it, there were some nice examples of the RTL/LTR abuse still searchable. (You can still find them, but it loses its meaning as it's rendered LTR - just Google for ":erocS" yes, that's a colon in front and a capital S at the rear. Just think what RTL override might do and it makes sense)

          Any popular website that doesn't use a black or white list gets rapidly taken over by comments that make a page unreadable if they remain unmoderated. And at least on Slashdot, it's a meme.

          • by DrXym ( 126579 )
            It's not just ÁSCII.

            But anyway even if Slashdot were to restrict to Latin-1 chars it should still be using UTF-8 as its internal representation since it can be a subset of valid Unicode should they ever decide to offer other languages. I suspect the real reason they don't go Unicode internally is because the code is antiquated and tainted, and there is an enormous database of comments which is tainted too.

            As an aside it still amazes me how incompetently most projects deal with making their code loc

      • Re: (Score:2, Funny)

        by fahrbot-bot ( 874524 )

        Why would we WANT foreign characters?

        Besides, the President issued an executive order banning foreign characters until the pandemic subsides -- or he leaves office. I think I read that right anyway, not 100% sure ... :-)

      • Slashdot is literally the only site on the entire internet that has unicode problems. Go ahead and find me one single other example. I'll wait.

    • Perl has unicode (Score:4, Informative)

      by bussdriver ( 620565 ) on Wednesday June 24, 2020 @02:14PM (#60223190)

      Perl had better unicode support before most the others and handled messed up unicode better than some others too. but free zero labor transitions didn't exist.

    • Uh... no (Score:3, Informative)

      Unicode support? Can we upgrade Perl so Slashdot can finally support foreign characters?

      That won't work because unicode is fundamentally different from ASCII.

      Unicode is simply a coded list of characters seen in documents across the world, throughout history, and occasionally in fiction (ie: Klingon). The code number per character is arbitrary, and only reflects the order of when the glyph was added to unicode.

      UTF8 is a common way to encode unicode in byte strings, and is done by bytes. If the high order bit is zero, then the next 7 bits are mapped to regular ASCII. If the high order bit is 1,

      • Re:Uh... no (Score:5, Informative)

        by isj ( 453011 ) on Wednesday June 24, 2020 @04:07PM (#60223708) Homepage

        Changing Slashdot to UTF8 is a full-fledged project.

        Yet the red site [soylentnews.org] did implement it.

      • So no, converting strings to UTF8 in perl is simple, but would break a lot of things. Changing Slashdot to UTF8 is a full-fledged project.

        A project that was handled by one programmer on SoylentNews in less than a couple months.

        • A project that was handled by one programmer on SoylentNews in less than a couple months.

          Oh, you mean, the site where it's now possible to fill the comment section thereof with megabyte-worth walls of Zalgo [wikipedia.org] text [eeemo.net]?

          Thing is forum like /. are extremely popular for trollposting/shitposting/memeposting.

          People are only half-joking when they say that Unicode is only this short of being a Turing-complete language:
          Seriously, it can already be abused to completely fuck up the fromatting of a webpage.

          That is 100% to happen the moment Slashdot stops explicitely whitelisting a small list of Unicode code-poin

      • Thanks for this. It is very informative. I'd mod you up if I had some points, but i'm the quiet type and don't get them often.

        Cheers!
      • > The strlen($String) function will take a LONG time to complete, because the result is characters, not bytes, and the framework has to count chars from the beginning to see how many there are, and of course this isn't the bytes of storage you need to allocate on disk. That's not true in Perl, because Perl stores characters not as a simple array of bytes (as C would) but an array of *codepoints*. Perl's unicode support is very very good. I don't know why slashdot does what it does.
        • by thogard ( 43403 )

          Slahdot does what it does because some of it is still Perl 4 code.

        • by piojo ( 995934 )

          Perl stores characters not as a simple array of bytes (as C would) but an array of *codepoints*.

          Does that describe all perl strings, or just those that have been decoded from bytes as utf-8? And is that not incredibly slow, or is the contents typically not copied often enough to matter? (I'm assuming you don't mean strings are stored as UTF-16 including surrogate pairs as in C# and Java, since I believe that's not an array of codepoints.)

          Edit: I just found some info [perl.org] about Perl's internal data representation and it looks like strings are just stored as a byte array plus metadata that flags whether the

      • by spitzak ( 4019 )

        If you think strlen() should return anything other than the number of bytes then you don't understand Unicode or strings.

      • You can change a perl string to unicode directly, but then a lot of things will break. The strlen($String) function will take a LONG time to complete, because the result is characters, not bytes, and the framework has to count chars from the beginning to see how many there are, and of course this isn't the bytes of storage you need to allocate on disk.

        I've looked at this quite a bit, and I think the only thing that works across languages is to get rid of the concept of a character entirely, and think of things as substrings. Thus toupper() would take a string, and return a string. ischar() might return true if the entire string is composed of printable characters.

        I wouldn't try working with standard C strings, I would make a new C string class (or set of functions combined with a C struct, however you want to interpret it). Then you can implement help

    • Re:but (Score:4, Interesting)

      by phantomfive ( 622387 ) on Wednesday June 24, 2020 @02:59PM (#60223406) Journal
      Slashdot had unicode support, but explicitly blocked it because people were using the weird characters in strange ways (like writing vertical English text that overflowed the comment field). Their solution was to block most unicode. Effective, but not without annoying side effects.
    • by Ecuador ( 740021 ) on Wednesday June 24, 2020 @03:02PM (#60223422) Homepage

      Perl had quite good unicode support since at least 2002 (although 5.10 in 2007 was more complete). But somebody has to actually code to take advantage of it. Having helped convert old code for unicode, it is not hard, but, still, somebody has to do it!

      • by Shaitan ( 22585 )

        Perl had had quite good XXXXX support/implementation since at least 20XX (although 5.XX in 20XX was more complete). But somebody has to actually code to take advantage of it and everybody thinks Perl 5.x is old and that the Perl guys are still working on the new one, Perl 6...

    • Surely youâ(TM)re joking.

    • by jjn1056 ( 85209 )

      Perl has had great support for unicode for many years. Not familiar with Slashdot code so can't comment on that

    • by Megane ( 129182 )

      slashdot.jp (now srad.jp) had no problem supporting unicode

      I think there are two problems. The first is that almost all of the unicode code space is explicitly blacklisted. (Even most of the HTML entity codes are blacklisted!) Some of that was to avoid artposting, but that doesn't explain things like smart quotes. The second is that apparently there's some fucky handling of the encoding in the HTML headers that causes browsers to send Latin-1 or some other screwy encoding instead of Unicode when they use t

  • As a perl guy... (Score:5, Insightful)

    by Shaitan ( 22585 ) on Wednesday June 24, 2020 @02:00PM (#60223134)

    I support this measure.

    The Perl 6 fiasco has seriously inhibited Perl. While Perl itself HAS continued to progress in leaps in bounds in both capabilities and internal compilation and function, adopting all the legitimate shiny advances that have come along over the years, it is often seen as ancient, still stuck on Perl after all this time.

    As long as they have the compat mode so you can still write code that supports that one crappy ancient system in your portfolio that is boxed in and regulated in such a way that you can't get anything better on it... this is all to the good.

    • Re:As a perl guy... (Score:4, Interesting)

      by 93 Escort Wagon ( 326346 ) on Wednesday June 24, 2020 @02:57PM (#60223392)

      Yeah, this seems to be an admission by the core perl maintainers that they're aware "raku" was pretty much DOA.
       

    • The idea is a terrible idea. Its one of the dumbest things Ive ever heard of. Perl 5 is supposed to be about backward compatibility and Raku is the new language. If you want new, use Raku, this is for you. So Perl 7 makes absolutely no sense and creates more confusion. Raku is the next generation Perl, so what is this Perl 7 thing. The whole thing should be scuttled and instead people who want new modern or whatever should be instructed to use Raku. Its such a ludicrous idea I dont have words for it. Larry

      • by thogard ( 43403 )

        At what point do you change bad defaults? I have Perl 5 code that will run in Perl 3 if the now standard "use warnings ;use strict" are removed. The 5->7 change will result in updating some file handles and the ability to remove some standard boilerplate and maybe cleaning up some early OO stuff. If I have to run very old code, I assume I can tack on "use v5.00" to the top of the old Perl 3 code. If I was concerned, it should be trivial to replace /usr/bin/perl with something that looks at the times

  • maybe it'll save it from a slow death?

  • by Shazatoga ( 614011 ) on Wednesday June 24, 2020 @02:09PM (#60223178)
    This looks like a good opportunity to implement the new OO proposed to replace the awful existing one.
    https://github.com/Ovid/Cor/wiki [github.com]
    • by raymorris ( 2726007 ) on Wednesday June 24, 2020 @02:28PM (#60223264) Journal

      The Cor proposal has some advantages. As pointed out in the Cor proposal, most of what Cor would add is already available by using Moose. Cor looks like a perfectly reasonable way to do objects.

      What I friggin LOVE about the basic built-in OO system in Perl is that it's transparent - you easily see exactly how it works. $thing->do($args) is just syntactic sugar for do($thing, $args) !

      It's pretty much how all/most OO languages work under the hood, Perl doesn't hide it - you can see and understand how it works. I love that and use it to teach about OO.

    • According to Sawyer X the plan is to include Cor as a feature you can enable in Perl 7 and make it enabled by default (along with signatures it requires) in Perl 8.

    • No, its not. Just use Moose, problem solved. Its just ridiculous this whole OO-thing keeps getting rehashed when the needs have been solved very well with Moose.

    • Just use Raku.

  • Perl was my love and I still write code faster in it than in any other language. Yet, the language has always suffered from the fact that the code is hard to read and hard to maintain. Back in the 90's one could put up with that as it was a huge improvement over C, awk, and shell, but no longer.

    Perl 7 will carry on the same problems, with the additional complication that there is no backward compatibility. The Python 2 to 3 switch showed just how painful that can be. Keeping compatibility is very importan

    • Re: (Score:3, Informative)

      by ufgrat ( 6245202 )

      Yes, but if you're writing a script that needs to run on 200+ systems across your completely heterogeneous environment, it's much easier to count on Perl 5 being available-- whereas python might be version 2, or it might be version 3, and as you point out, that's a headache.

      Sure, you can push out a script written for virtualenv, but now you're pushing out not just a script, but an entire environment to go with it.

      Perl-- when bash isn't enough, and python is too much.

    • by Shaitan ( 22585 )

      "Yet, the language has always suffered from the fact that the code is hard to read and hard to maintain."

      Everyone who felt that way moved to Python. Buzz off python fan. :)

      Perl regex are difficult to read but then nobody else has a better answer either, the best option in any language is an equally difficult to read Perl style regex implementation.

      "Now we have Python, which is very mature and can do anything Perl can do and is much easier to maintain and with a lot more packages by now." ...and now I read f

      • True, Python also uses Perl's regex. But you see, _all_ of Perl reads as a regex! Python at least cleaned up everything else except pattern matching. Oh, the $, #, %, ~ and other such ASCII noise. I miss them sometimes.

        I agree Python and Perl are equivalent, and yes, Perl still hangs on. But that's about it. Python in my usage superseded not just Perl, but also Matlab. The whitespace indentation is the only thing I still find awkward.

    • by hughbar ( 579555 )
      It needn't be. I've worked on big Perl systems that 'grew' out of the first web boom. Like all other languages, comments, good structure/indentation and good variable names. As with C, don't do half a million things in one line.

      I've moved to Python for some things and for work, but I'm currently remaking a 15 year old project using Mojolicious, finding it excellent. Really glad about this, because like Erlang, for example, it's actually a substantially 'different' language.
  • I remember using Perl 5 20 years ago. I remember getting interested in Perl 6 over 15 years ago as an idea. I moved on, a lot.

    Perl 7 sounds sensible - up to date defaults, dump the ancient stuff, and presumably include some new modules by default that make sense for 2020 (or at least 2010).

    • by Shaitan ( 22585 )

      Yeah but the only thing changing is the defaults. That is what is sad, Perl 5 has actually been getting updated and revamped all along with all kinds of hot support in modules. Perl 6 was never the new Perl, it they hadn't called it the new Perl and updated the Major number a few times the myth of Perl being dead wouldn't have been so easy for the python mongers to sell.

  • Comment removed based on user account deletion
    • Re:Per...l, wut? (Score:5, Insightful)

      by MachineShedFred ( 621896 ) on Wednesday June 24, 2020 @03:02PM (#60223426) Journal

      You used Perl when you just posted that, as Slashcode is Perl.

    • Re:Per...l, wut? (Score:4, Insightful)

      by 93 Escort Wagon ( 326346 ) on Wednesday June 24, 2020 @03:06PM (#60223440)

      I see perl lots of places. Even some fellow sysadmins who "hate" perl seem to still find use for it, even if they prefer to write in other languages most of the time.

      I was really surprised a few months ago when I came across a recently-written perl script which was put together by a colleague who has repeatedly expressed his partiality for php (yeah, there's no accounting for taste). Sometimes, hacking something together quickly in perl is still the easiest solution because it's so adaptable - especially with the metric f***-ton of modules in CPAN covering just about any conceivable use case.

    • Re:Per...l, wut? (Score:4, Insightful)

      by gwyrdd benyw ( 233417 ) on Wednesday June 24, 2020 @03:37PM (#60223570) Journal
      classic "I don't see how it's relevant to me so it can't be relevant to anyone else". Huge parts of the internet still run on Perl. booking.com is entirely Perl. Do you use git? then you use Perl.
    • by gweihir ( 88907 )

      Perl is excellent for text-centric write-fast-use-once stuff. It is a valuable thing to have in ones toolbox.

  • They go and do this. Perl really does seem intent on digging a hole and burying itself.
  • by michael_cain ( 66650 ) on Wednesday June 24, 2020 @06:45PM (#60224408) Journal
    Since it's a new major number, and it's 2020... Can the new major version have a simple mandatory GUI library? One of the good things that Guido did for Python was tkinter. Any Python programmer on anything with a minimal bitmap display can reasonably expect "import tkinter as tk" to work right out of the box. Tk may not be great, but it's not heavy, and it will put bits and buttons up on the screen. Asking the development team to include Tk and a cleaned up supported version of one of the interface modules isn't asking that much.

    Please?
    • by gweihir ( 88907 )

      A mandatory GUI library in a system that runs on lots of things that do not have a GUI? Strikes me as a really bad idea. Maybe a "highly recommended GUI Library" instead.

  • The most common thing people mention is the object system , but it does have several advanced object systems like Moose and Moops which are available. So that has been solved. So in the area of object oriented systems look at Moose,

    Backwards compatability is important and there is a lot of existing code, I am not a big fan of wasting time redoing code because people decide to change some language every 10 years. Python 3 was a debacle and a big mistake. Always provide backward compatibility so you dont make

  • Perl 7 succeeds Perl 5 due to the Perl 6 initiative previously for what is now known as the Raku programming language.

    I don't usually bother to post anymore, but what the holy hell is this supposed to mean? This isn't a sentence.

  • Basically "second system effect" with delay but on steroids. If you put in everything and the kitchen sink, the result is pretty much unusable. Glad to see they have realized that too.

Some people manage by the book, even though they don't know who wrote the book or even what book.

Working...