Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Perl Programming Upgrades

Larry Wall Unveils Perl 6.0.0 163

Posted by Soulskill from the onward-and-upward dept.
An anonymous reader writes: Last night Larry Wall unveiled the first development release of Perl 6, joking that now a top priority was fixing bugs that could be mistaken for features. The new language features meta-programming — the ability to define new bits of syntax on your own to extend the language, and even new infix operators. Larry also previewed what one reviewer called "exotic and new" features, including the sequence operator and new control structures like "react" and "gather and take" lists. "We don't want their language to run out of steam," Larry told the audience. "It might be a 30- or 40-year language. I think it's good enough."
This discussion has been archived. No new comments can be posted.

Larry Wall Unveils Perl 6.0.0 More

Larry Wall Unveils Perl 6.0.0

Comments Filter:

  • It's about time (Score:5, Interesting)

    by geekd ( 14774 ) on Tuesday October 06, 2015 @06:15PM (#50674487) Homepage

    I went to a presentation at a Unix convention in San Diego in 2000, 15 years ago, where Larry Wall talked at length about Perl 6, and how he was hard at work on it.

    Well, better late than never.

  • Neither perl6.org and its mailing lists seem to mention anything about this. The links in TFA are blocked by OpenDNS too.

  • How about that (Score:1)

    by Anonymous Coward

    Didn't quite believe it would ever happen.
    Not that I'm eager to adopt it, we have lots of perl5 code and the conversion would be significant.

    • it hasn't happened, just a dev release. so Perl 6 not ready still, after 15 years of screwing around

  • The race is on (Score:4, Funny)

    by Anonymous Coward on Tuesday October 06, 2015 @06:21PM (#50674539)

    Perl 6 vs. Python 3 - who will get to 1000 users first?

    • I actually use Python 3 for most of my work. Once I learned to put () around my prints like in nearly every other language I was fine.

    • Re: (Score:1)

      by Anonymous Coward

      considering perl5 code runs in perl6... it'll happen pretty quick

  • In related news, Larry has announced he is changing spelling of his name to more accurately describe his life's work:

    Larry
    W(rite)
    O(nly)
    L(anguage)

  • I saw that there are several implementations that use JVM. For those who have been following the situation a bit closer is there any progress behind a non JVM Perl6?
    • The "Compilers" section at Perl6.org talks about Rakudo as being "a compiler running on MoarVM, the JVM and other backends."

      At the presentation last night, Larry said they'd plan to focus just on MoarVM, but they were pleased with the progress of the JVM, so there's some support for that too.
      • That should be "planned". (Larry said they'd PLANNED to focus just on MoarVM, but they were pleased with the progress of the JVM, so there's support for that too...)

  • Bugs mistaken as features? (Score:4, Funny)

    by mbkennel ( 97636 ) on Tuesday October 06, 2015 @07:15PM (#50674979)
    | Last night Larry Wall unveiled the first development release of Perl 6, joking that now a top priority was fixing bugs that could be mistaken for features.

    Sounds good.

    | The new language features meta-programming — the ability to define new bits of syntax on your own to extend the language, and even new infix operators.

    Hey Larry, I found a huge bug which could be mistaken as a feature!

    • Re:Bugs mistaken as features? (Score:5, Interesting)

      by lgw ( 121541 ) on Tuesday October 06, 2015 @07:44PM (#50675177) Journal

      It gets better, in addition to "comefrom" (OK, "react"), the only branching construct worse than goto, you can change operator precedence. How'd you like to maintain that code?

      • Re: (Score:2)

        by Amouth ( 879122 )

        i was thinking the same thing, while i look at it and say "neat" and think about how much fun that would be to use.

        Then i also stop and have to ask, Isn't it already hard enough to read someone else's perl code? with this having to pickup someone else's perl code will be a nightmare.

        • Re: (Score:2)

          by Wee ( 17189 )
          Isn't it already hard enough to read someone else's perl code?

          If they are shit programmers, yeah. You can write garbage in nearly any language. Perl just makes it easier to write shitty code.

          -B

      • Re:Bugs mistaken as features? (Score:4, Interesting)

        by alvinrod ( 889928 ) on Tuesday October 06, 2015 @09:27PM (#50675893)

        How'd you like to maintain that code?

        No one would, which sounds like job security to me.

      • Re: (Score:2)

        by KGIII ( 973947 )

        Meh... I kind of like Perl. Nobody can tell the difference between my gibberish and good code. Given my roundabout logic process I look like a straight up genius. Well, that and I can't actually manipulate data well so a flat file is about as complex as I tend to get.

        Yes, yes there's a bunch of reasons I hired professionals.

      • Features like that wouldn't be so bad if there were a way to isolate their use. For example, ordinary Perl files could be .pl and not allowed to change the language. Perl files that mucked with the language in various ways would be required to have a .pld (Perl Language Definition) suffix. That way you could make rules like, "No PLD files in this project" or "only Joe has permission to change the PLD and you'd better have a damned good reason for asking him to change it".

        There are legit reasons to modify

        • Re: (Score:2)

          by lgw ( 121541 )

          Larry certainly one-upped C++ operator overloading!

          But of course, you could enforce just what you suggest with code reviews and a grep or two just to be sure.

      • I'm primarily a C++ guy these days. C++ has plenty of ways to write unmaintainable programs, so I'm used to having to make sure the code I write is maintainable. (I also write maintainable Perl.)

        What you do not want to do is accept code from a C++ developer who knows how to use all the neat features but not when not to. This has been true of Perl, also, ever since I encountered it.

    • Where are my + mod points when I need them?

  • No Coroutines (Score:5, Insightful)

    by Anonymous Coward on Tuesday October 06, 2015 @07:20PM (#50675019)

    No coroutines. So sad. That still leaves Lua and Stackless Python as the only languages with symmetric, transparent coroutines without playing games with the C stack.

    Neither Lua nor Stackless Python implement recursion on the C stack. Python and apparently Perl6/More implement recursion on the C stack, which means that they can't easily create multiple stacks for juggling multiple flows of control. That's why in Python and Perl6 you have the async/await take/gather syntax, whereas in Lua coroutine.resume and coroutine.yield can be called from any function, regardless of where it is in the stack call frame, without having to adorn the function definition. Javascript is similarly crippled. All the promise/future/lambda stuff could be made infinitely more elegant with coroutines, but all modern Javascript implementations assume a single call stack, so the big vendors rejected coroutines.

    In Lua a new coroutine has the same allocation cost as a new lambda/empty closure. And switching doesn't involving dumping or restoring CPU registers. So in Lua you can use coroutines to implement great algorithms without thinking twice. Not as just a fancy green threading replacement, but for all sorts of algorithms where the coroutine will be quickly discarded (just as coroutines' little brothers, generators, are typically short lived). Kernel threads and "fibers" are comparatively heavy weight, both in terms of performance and memory, compared to VM-level coroutines.

    The only other language with something approximating cheap coroutines is Go.

    I was looking forward to Perl 6. But I think I'll skip it. The top two language abstractions I would have loved to see were coroutines and lazy evaluation. Perl6 delivered poor approximations of those things. Those approximations are okay for the most-used design patterns, but aren't remotely composable to the same degree. And of course the "most used" patterns are that way because of existing language limitations.

    These days I'm mostly a Lua and C guy who implements highly concurrent network services. I was really looking forward to Perl6 (I always liked Perl 5), but it remains the case that the only interesting language alternative in my space are Go and Rust. But Rust can't handle out-of-memory (OOM). (Impossible to, e.g., catch OOM when creating a Box). Apparently Rust developers think that it's okay to crash a service because a request failed, unless you want to create 10,000 kernel threads, which is possible but stupid. Too many Rust developers are desktop GUI and game developers with a very narrow, skewed experience about dealing with allocation and other resource failures. Even Lua can handle OOM trivially and cleanly without trashing the whole VM or unwinding the entire call stack. (Using protected calls, which is what Rust _should_ add.) So that basically just leaves Go, which is looking better and better. Not surprising given how similar Go and Lua are.

    But the problem with Go is that you basically have to leave the C worldbehind for large applications (you can't call out to a C library from a random goroutine because it has to switch to a special C stack; which means you don't want to have 10,000 concurrent goroutines each calling into a third-party C library), whereas Lua is designed to treat C code as a first-class environment. (And you have to meet it half way. To make Lua coroutines integrate with C code which yields, you have to implement your own continuation logic because the C stack isn't preserved when yielding. It's not unlike chaining generators in Python, which requires a little effort. A tolerable issue but doable in the few cases it's necessary in C, whereas in Python and now Perl6 it's _always_ an issue and hinderance.

  • Saw this and had some bad flashbacks to using Perl. What a monstrosity. Even a friend of mine who loved it admitted he could read his own code later on. If you have to write a one liner, fine, but I had to maintain actual code written in Perl. It makes my skin crawl just thinking about it.

    • Re: (Score:2)

      by murdocj ( 543661 )

      duh... "admitted he could NOT read his own code later on"

    • Now this can be fixed because it has:

      >> ability to define new bits of syntax on your own to extend the language :-)

      • Re: (Score:3)

        by murdocj ( 543661 )

        This reminds me of the old joke about Forth: Real programmers can tell the difference between Forth and line noise.

    • Re:Oh no (Score:4, Insightful)

      by Greyfox ( 87712 ) on Tuesday October 06, 2015 @08:45PM (#50675635) Homepage Journal
      Well you CAN write maintainable code in perl, you just have to use some discipline. Turn "use strict;" on everywhere, break your project up into packages across functional lines and have unit tests on everything. You know, all that stuff that no companies ever do. Given the choice between having to maintain a perl project and a ruby one, I'd take the perl project every time. At least you'll have some chance that the developers wrote some decent code, if only in self defense since they usually end up maintaining it themselves for a few years.

      • Re:Oh no (Score:4, Funny)

        by KGIII ( 973947 ) <uninvolved@outlook.com> on Wednesday October 07, 2015 @01:01AM (#50676829) Journal

        The best part is you can append gibberish to it and tell everyone that you've done lots of work and nobody will know the difference. Hell, it might actually do something useful!

        I am going to admit that I write (or have written) some Perl. I've even given it away. I'd also like to take this time to apologize for my Perl.

        I wrote a "safe list" script for a friend, it was really damned simple. People signed up and sent email messages to each other for the purposes of MLM - that's not why I wrote it, that's just what people did with it. It had a small but functional administration panel. It was about as secure as a screen door. Usernames and passwords were in a plain text file - you were SUPPOSED to move it and chmod it but I don't think anyone ever did even though it was mentioned a few times in the README.TXT.

        Anyhow, he wanted to sell the script. I said that was cool. I was more interested in the code so I made a few versions. It was usually purchased a few times and then hit Usenet in .zip form. They could have at least taken my email out of the damned thing if they were going to steal it. I've long since dropped that email. The last version (released in something like 2002) was free for the taking and my friend charged to install and customize it as he'd learned a little by then.

        So here's the easiest to install script and the least secure thing on the internet - plain text files, indeed, and I *still* see it installed from time to time. I can only imagine that the email address still gets emails from people asking what chmod means or how to upload the file or how they put it in their C drive and nobody seems to be able to access it from the internet.

        Yup... My Perl... Breaking machines, frustrating users, and being insecure for 25 years and running.

        A little part of me is kind of proud of that but my formal statement is, indeed, an apology.

      • Re: (Score:2)

        by jd2112 ( 1535857 )
        Comment, comment, comment. And don't get too creative with your regular expressions.
        And don't try to make your script into one line unless it is in fact trivial. Just because you can do something doesn't mean you should.

  • "First Development Release" ? (Score:4, Interesting)

    by murr ( 214674 ) on Tuesday October 06, 2015 @09:13PM (#50675793)

    If that was the first development release, what on earth was the 2010 release of Rakudo Star?

    The problem with Perl 6 was never a lack of development releases, it's 15 years of NOTHING BUT development releases.

  • Perl (Score:5, Insightful)

    by randalware ( 720317 ) on Tuesday October 06, 2015 @10:03PM (#50676095) Journal

    I used perl a lot over the years.

    comparing it to a compiled language (C, Ada, Fortran, etc) or a web centric (java, java script, php, etc) language is not a good comparison.

    when I need something done (and needed more than the shell) and I had to maintain it.
    I wrote it in perl.

    all sorts of sysadmin widgets.
    many are still being used today (15+ years later)
    I wrote clean decent code with comments & modules.
    finding the cpu & disk hogs, by the day, week & month.
    who was running what when the system crashed.
    cgi code for low volume web server tasks
    updating DNS
    queueing outgoing faxes & saving history
    rotating log files and saving a limited number of copies.

    how much code have you written ? and had it stay running for decades ?
    the people that took over my positions when I changed jobs never had a problem updating the code or using it.

    • Perl is awesome for system scripting. It's a UNIX shell replacement on steroids. Nevertheless it is no longer a good choice to use for serious projects spanning multiple modules, accessing database, etc (see my post below)

  • Once a subject goes over the mock horizon, it gets pretty hard to distinguish entire discussion threads from line noise.

  • I wrote a couple of large projects in Perl last year, before switching to Python3 and never looking back. There is a plethora of reasons why Perl is ripe for abandonment:
    - Hard to read code with multiple '$'s and '@'s on every line
    - In-place string modification is asking for bugs
    - Clumsy OOP
    - Poor selection of publicly available libraries; some have critical bugs that have not been fixed for years
    And all this before having to maintain code written by someone else, in a language better suited for one-li

    • Re:Why stay away from Perl (Score:5, Insightful)

      by truckaxle ( 883149 ) on Wednesday October 07, 2015 @01:18AM (#50676871) Homepage

      - Hard to read code with multiple '$'s and '@'s on every line

      I prefer to have variables differentiated (scalars, arrays and hashes) and clearly identified from other syntax or text. It makes code more readable IMHO.

      - In-place string modification is asking for bugs

      You mean string interpolation? This in fact is one of Perl strengths

      $str = "There are $num apples".

      is clearer and less busy, easier to remember than

      str = "I have {a} apples".format(a=num)

      - Clumsy OOP

      Specifics? There are some valid criticism of Perl's 5 OOP but the success of CPAN and a long list of highly successful reusable OO modules highlights its practical side.

      - Poor selection of publicly available libraries; some have critical bugs that have not been fixed for years

      Now you are well into troll territory or you really haven't used Perl much. DBI, CGI, LWP, IO::Socket, HTML::Parser, GetOpt::Long, Devel::NYTProf (not really a module but a totally awesome profiler) the list goes on.

      • To be fair, Perl 5's OOO implementation does feels like it was tacked on at the very last minute. It doesn't even qualify as OOO by some definitions (lack of encapsulation, for example).

        Having said that, OOO in Perl is VERY clever in the sense that it extends the language in a big way with very minor changes. bless and @ISA might look unintuitive on a first glance but are very simple at their core and integrate with existing language seamlessly.

      • > I prefer to have variables differentiated (scalars, arrays and hashes) and clearly identified from other syntax or text. It makes code more readable IMHO.

        Not sure if that argument for perl is valid anymore, in the current age of IDEs and syntax highlighting text editors like Sublime etc. All the visual differentiation is done for you.

      • - Hard to read code with multiple '$'s and '@'s on every line

        I prefer to have variables differentiated (scalars, arrays and hashes) and clearly identified from other syntax or text. It makes code more readable IMHO.

        I am sorry, how is $$this->{that} for readability? If you still have doubts please show this to a non-zealot for comment.

        - In-place string modification is asking for bugs

        You mean string interpolation? This in fact is one of Perl strengths

        $str = "There are $num apples".

        is clearer and less busy, easier to remember than

        str = "I have {a} apples".format(a=num)

        No I do not mean interpolation, but all the regex transformations modify string in place, sometimes inadvertently destroying needed stuff. Python takes the opposite approach -- to NEVER modify string in place. Compare
        $text =~ s/^ *//;
        $text =~ s/ *$//;
        to
        text = text.strip()
        Perl modified the string in-place in each line, while in Python I made an explicit assignment (normally

    • - In-place string modification is asking for bugs

      Have you ever seen a program where that caused a bug? Serious question, I never have.

      • In a large project of mine, several times. I probably did not develop a habit to look out for these, but the main issue that there is no way to meaningfully transform strings without in-place modification in Perl. For example chop, s///, etc

    • Re: (Score:2)

      by jjn1056 ( 85209 )

      I don't think this is insightful, its just a repeat of the same criticisms I've heard for 15+ years. Sorry you had to work on a crappy project, but Perl can be written in a modern manner that addresses the issues you've brought up. That being said I am glad you are happy with Python. Can't you just let me be happy with Perl?

    • The $ and @ are what I like best about perl. You can spot a variable or array immediately.
      • Except it becomes $ during access, And we always pass array by reference. So it boils down to just $. A sea of $.

  • The ability to add custom syntax.... Because regular perl syntax isn't confusing enough!!

  • So, both Perl 6 and GNU/Hurd are finally production-ready? So let's start migrating Facebook and Google then...

  • Finally! :D (Score:1)

    by Anonymous Coward

    Back in 2005 I remember hearing about how the fancy new Perl 6 VM was going to be super awesome. So I waited and waited. And then I waited some more.
    Meanwhile, I'm 5 years into a personal project that's nowhere near ready to ship, so I think I finally understand what took him so long.

    Congratz, Larry. You da man.

    p.s. Obligatory: What year is it? [knowyourmeme.com]

  • Perl syntax, as is, is already pretty hard for everyone to digest (if you have never maintained any perl written by a bunch of self-declared genius, don't try to comment), wait till all the geniuses can extend that language. I'll need to keep a machine gun under my desk, in case I go ballistic.
  • Thanks Larry :)
  • But still no "advanced macros, non-blocking IO or much of synopsis 9 and 11"...

  • "It might be a 30- or 40-year language. I think it's good enough."

    No, actually Perl6 is not 30+ years old. Its not a replacement for Perl5, no matter how much Mr. Wall would like it to be. There's a lot of working Perl5 programmers that wish the community calling itself Perl6 (which is totally distinct from the Perl5 community for all practical purposes, despite some attempts be leaders to force coordination on us) would acknowledge the fact that Perl6 is Perl Not at all, and call this language something different.

    I don't know if Mr Wall realizes how much harm he's done to working Perl5 programmers by continuing to insist on calling this thing he's worked on "Perl" at all.

  • Is it true that Duke Nukem Forever was the first commercial software written entirely in Perl 6?

  • Back in the late 1970s - early 1980s, I was approached by an engineer at a local company to test FORTH. A really cool language that was based on building your own new command built from base syntax. Isn't the idea of functions the same basic thing?

Slashdot Top Deals

Genetics explains why you look like your father, and if you don't, why you should.

Close