Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Open Source Perl Programming Upgrades

Perl 6 In Time For Next Christmas? 192

An anonymous reader writes Larry Wall has reportedly announced at Fosdem that "Perl 6 Developers will attempt to make a development release of Version 1.0 of Perl 6.0 in time for his 61st Birthday this year and a Version 1.0 release by Christmas 2015." From the article: "There is going to be the inevitable discussions, comments and probably some mileage from detractors to come. However ever were it so, for us in the Perl Community these are quite exciting times. We have two strong languages and a strong community, I think there is a lot that binds us together so here's looking forward to Christmas."
This discussion has been archived. No new comments can be posted.

Perl 6 In Time For Next Christmas?

Comments Filter:
  • by Qzukk ( 229616 ) on Sunday February 01, 2015 @08:27PM (#48954589) Journal

    How's Python 3 adoption coming along? (and they worked so hard to make it forwards and backwards compatible if you remember to put parentheses around your print arguments!)

    • by fisted ( 2295862 ) on Sunday February 01, 2015 @09:02PM (#48954731)
      Sorry to break it to you, but perl has use <version>; for a long time now.

      That the Python people went about the version bump in about the most ham-fisted way imaginable does not mean that this would somehow be the case for all languages now.
      • by skids ( 119237 ) on Sunday February 01, 2015 @11:21PM (#48955389) Homepage

        Also I'll be enjoying (really, not sarcastically) years of using Perl5 and Perl6 in the same file due to the easy integration between the two, replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.

        I really like this language a lot.

        • by Marginal Coward ( 3557951 ) on Sunday February 01, 2015 @11:48PM (#48955493)

          ... replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.

          I actually did that about 15 years ago. I switched to Python, then transliterated all of my Perl code into it.

          BTW, it was remarkable to me at the time that in every case of transliteration, the resulting Python files were smaller in terms of both number of lines and number of bytes. Then I realized that since the two are semantically similar in so many ways, Python's lack of braces was a big advantage in terms of code compactness. To be fair, though, I never was one to pack as much code into a single line of Perl as possible. Which is, of course, why I prefer Python: it was never designed for that sort of thing.

    • My understanding is they've developed a way to integrate Perl 5 and Perl 6 code together. I think that's the whole point of Parrot.
      • by skids ( 119237 )

        Current intergration is through libperl, and future integration will likely be independent of the VM, just a "slang" using the grammar engine and MOP on the backend. Parrot was aimed at being a polyglot VM, but other VMs started to catch up in that regard so Perl 6 began to target those runtimes as well.

  • by Okian Warrior ( 537106 ) on Sunday February 01, 2015 @08:38PM (#48954649) Homepage Journal

    Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.

    In the demo phase, you're not really worried about performance. The goal is to have something showing as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language which can be more easily optimized.

    Languages which are simple to learn (c++, for example) are generally not very expressive. You end up spending tons of time debugging issues of memory allocation, library interface details, and datatype conversion.

    Expressive languages are harder to learn, but any individual line in the expressive language does a lot more. Since you are writing fewer lines, and since the fewer lines do more, you end up making programs more easily and in less time.

    Yes, the programs will execute a little slower, but as mentioned, this is not important in the demo stage. Your productivity will be much higher. And there are lots of places where performance simply doesn't matter. Scripts usually fall into this category.

    Perl was designed by a linguist, not an engineer. As such, it's harder to learn (it's got tons more keywords and context), but once you get the hang of it coding is much more efficient. The following single line:

    @Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;

    unfolds into several lines of C++, plus a subroutine definition with datatype definitions. The following line:

    @Files = <c:/Windows/*.exe>;

    can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.

    And note that writing unreadable/unmaintainable code is an aspect of the *coder*, not the language. If you disregard perl because "other people use it to write poorly" you are probably one of those people, in which case you should avoid coding altogether.

    • by Anonymous Coward on Sunday February 01, 2015 @09:02PM (#48954733)

      std::sort(lines.begin(), lines.end(), [](auto &l, auto &l2) { return l1.name l2.name; });

      Pretty simple in c++14 as well

      • std::sort(lines.begin(), lines.end(), [](auto &l, auto &l2) { return l1.name l2.name; });

        Pretty simple in c++14 as well

        Mod parent up.

        It is funny as I have not coded in either language in over 10 years but this C++ version is very readable compared to the perl version. Also mentioning STD in C++ can be a little nasty and difficult to read yet I understood this much easier.

        • Well, they are both tending towards line noise in my opinion, but doesn't the c++ version have a typo :) ? (auto &l should be auto &l1).

          Personally, I find the Perl version a little clearer, but to a c++ geek, the familiarity probably makes the construct obvious and the Perl version ugly; a Perl geek draws the opposite conclusion.

          • by skids ( 119237 )

            Perl6 version, FWIW:

            @Lines .= sort: *.Name

          • by tepples ( 727027 )

            doesn't the c++ version have a typo :) ? (auto &l should be auto &l1).

            One advantage of C++ over dynamic languages is that name typos like this get detected at compile time, not much later.

      • That's a fair point.

        Thanks for the info - I'll go brush up on C++ again.

      • std::sort(lines.begin(), lines.end(), [](auto &l, auto &l2) { return l1.name l2.name; });

        If I may paraphrase an old saying, "You can write Perl in any language."

    • by NoNonAlphaCharsHere ( 2201864 ) on Sunday February 01, 2015 @09:05PM (#48954745)

      And note that writing unreadable/unmaintainable code is an aspect of the *coder*, not the language.

      That's the funniest thing I've read today. We're talking about a language that has 82 ways to say a = a + 1, 81 of which are completely, gobbletygookly incomprehensible (and look like cartoon swearing) to the average (non-brain damaged) programmer. The FACT is, the language is deliberately designed to reward the cuteseypoo "I (self) graduated from VisualBasic, and I'm WAY cleverer than the rest of you", combined with the "this is a contract job, and I've never ever ever had to maintain somebody else's code" effect, produces the worst, most unreadable, most unmaintainable code on the planet. Get the average Perl programmer, point a .357 magnum at their heads, and ask them to modify something they wrote six months ago, and watch the bloody hilarity ensue.

      • by dskoll ( 99328 )

        I think it's the contract jobs that produce bad code. My company produces commercial software mostly written in Perl. It's been under development for 15 years and the code base is quite readable and easy to understand. That's because the programmers are not contract programmers and they have sufficiently good taste and motivation to avoid the worst of Perl's cuteness. You can write readable, maintainable Perl. It just takes a lot of work.

        Of course, that applies to any other programming language as we

        • by skids ( 119237 )

          Languages need to scale to talent, so a codebase maintained by veterans of the language can use advanced constructs, while a codebase meant to be maintained by newbies can stick to the babytalk. Which is where Perl 5's flexibility can be leveraged well. I think you'll find Perl 6 to be a joy to work with, and if you have the privilege of working with a devel team that gets good at it, it will be an awesome experience, plus you can still "talk down" for stuff you need to throw to the public to maintain.

          • by dskoll ( 99328 )

            Actually, from what I've seen of Perl 6, I think I'll stick to Perl 5. Perl 6 is much more complicated and is waaaay over-engineered. If the Moose is any indication (I believe that's an attempt to back-port P6's object model to P5), P6 will be a bit of a bloated mess.

      • by hondo77 ( 324058 )
        Give people a sharp chef's knife and they will find 81 ways to cut themselves. Give a skilled chef a sharp chef's knife and he/she will get the job done correctly and injury-free. The lesson is not that chef's knives are bad tools, it's that the unskilled are better off with plastic because they're not ready for the real thing and they'll hurt themselves, otherwise (and then blame the tool).
      • by Wee ( 17189 )
        Get the average Perl programmer, point a .357 magnum at their heads, and ask them to modify something they wrote six months ago, and watch the bloody hilarity ensue.

        Funny you mention it. Not an hour ago, I added some stuff to a perl script I wrote in 2009. It's not a large script (barely 1,000 lines), but my 150-line addition didn't seem to cause any great mirth or merriment.

        If you write shit code, you're writing shit code. The choice of language doesn't matter, aside from the insignificant notion t
    • by paskie ( 539112 )

      C++ is the wrong language to compare Perl to. Python is what you need to align with it. And it is so much tougher to build a good case for Perl in that light. (Not impossible, but it probably won't be very convincing. Perl is the anarchocapitalism of programming languages - you have near-absolute freedom to choose your ways, which is delightful for the top 20% users, but unfortunately most people choose the most awful and dirty ways in the face of this freedom, typically just for lack of experience.)

      (I love

    • Nah, a programming langauge needs to be well designed, by an engineer type, so the clean and expressive way comes out naturally without a dozen hard to read and difficult to maintain variations.

      Lines.sort_by! { |hsh| hsh[:Name] }

    • Ok, in this thread there are already C++, Ruby, and Perl 6 versions of your snippets, so I'll add the Python ones.

      @Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;

      lines.sort(lambda a, b: a.name < b.name)
      or
      lines.sort(key=lambda o: o.name)

      @Files = <c:/Windows/*.exe>;

      from glob import glob
      files = glob("c:/Windows/*.exe")

      I think a good analogy would be Perl is Finish, Python is Esperanto. When you have hundreds of thousands of LoC to maintain, I guess a more direct and unambiguous language is preferred.

      It occurred to me that perhaps Perl is an attempt to seduce the computer... too bad

    • The problem with Perl is not just the time to learn it. The biggest problem is that Perl developers believe in TMTOWTDI (There is more than one way to do it) principle. As a result, numerous Perl idioms exist for doing the exact same thing. No matter how much time you spend reading Perl programming books and coding yourself, you keep running into idioms that look slicker and better (or just bizzare) relative to what you know.

      Why is this bad? This is a difficulty for big application development projects wher

    • Perl was designed by a linguist, not an engineer.

      Now you've got me wondering: was Esperanto designed by an engineer, not a linguist?

    • Languages which are simple to learn (c++, for example) are generally not very expressive.

      This is the first time I've ever heard someone say C++ is easy to learn. I've been programming in it for years and I still don't feel entirely confident.

    • by unity ( 1740 )
      "Perl's strength is that it's expressive. It's not a language which is easy to learn "

      Meh, Perl4 was the first programming language I ever learned and first got a job doing. I found it all rather intuitive and easy to learn.
  • I thought it was done over a decade ago but was so different due to strange stuff like 100 different identifiers that no one used it?

    • by skids ( 119237 )

      No, you may be thinking of an early prototype, named pugs, written in Haskell as part of the whirpool design process. The pool has whirled several times since then. I really admire the attention to detail that's been put into the Perl 6 specification and the implementation is coming along nicely and is already very usable for both small ad-hoc scripts and larger stuff, too. Just not for high performance quite yet and a few places where you have to work around some TODOs.

  • It's farking 6.0. That *is* the farking version. What is the "6.0" thing if 1.0 is the version?
  • by duckgod ( 2664193 ) on Sunday February 01, 2015 @10:20PM (#48955107)
    I look forward to seeing what Perl 6 brings. However, I can't imagine it makes any improvements on the core reason I use Perl5. Perl puts no restrictions on how I program and I am able to get something running by myself faster than any other language.

    I am an adult and when I am programming for my own enjoyment I don't want to be told how I have to program. I definitely don't want to have to worry about squeezing my design into some Object Oriented bullshit. I want to tabulate my code the way I feel best. If I want to enjoy some dynamic variable scoping so be it. Mix up some functional with some procedural go for it. Create some cryptic one liner that I won't understand later, live and learn.

    Bonus points for still serving its original purpose stellarly. Give me some text and I will mold it to how I want. This is what a majority of commercial software does anyways.
    • by jandrese ( 485 )
      A lot of the wins from Perl6 have already been backported to Perl5. At this point I'm in no rush to switch to Perl6 even if it does come out.
      • A lot of the wins from Perl6 have already been backported to Perl5. At this point I'm in no rush to switch to Perl6 even if it does come out.

        The easy wins, yes; the low-hanging fruit, yes, absolutely. Perl5 really does benefit.

        But there is some stuff in Perl 6 that requires you to think about languages differently - stuff that doesn't map well to perl5. New stuff unless you're an academic language geek, that's just creeping out of the lab. Stuff that's hard to wrap your head around at first, and then you

    • I'm a huge fan of Perl... Perl5 that is.... I'm just hoping they don't screw up the language with 6. Perl5 works great for me---the few bits of Perl6 that I've seen look akward :-/

      • by skids ( 119237 )

        You don;t have to worry -- your Perl 5 code is safe, since there is no directive at all being pushed to "replace" Perl 5 with Perl 6. They will exist as sister languages, won't fight each other when installed together, and there is a thriving Perl 5 community actively developing and maintaining Perl 5 for the forseeable future.

    • by CAIMLAS ( 41445 )

      I agree with everything you said. Having said that, however, perl should not be used but for the simplest of things in the professional world... it's simply not maintainable, because its use encourages the "many ways to do it" mentality, and then nobody can grok what over developers have done. It's certainly at least part of the saying "perl is the only thing that can interpret perl" saying.

      • it's simply not maintainable, because its use encourages the "many ways to do it" mentality,

        No. Much perl code is simply not maintainable, because perl is easy enough to grok that people who are not good coders are capable of producing relatively powerful code. Good coders will produce comprehensible code in any language which permits it, and perl does that. It's not brainfuck.

  • I was actually not aware that Perl 6 was still, actually, being developed as "someone may use this for real".

    I, unlike many people, like perl. Please don't get me wrong - I'm not trying to flame here. I personally love perl (5), and I'd say it's the language I'm most comfortable/familiar with. It's what I've used for years when I've needed to write something.

    But I fully realize that perl is not preferred by many, if not most, these days. It has been replaced in preference by python for many (most?) sysadmin

    • by Mr Z ( 6791 )

      We actually use Perl quite heavily where I work, and its use is only growing. We've built rather significant pieces of our infrastructure around it, including a rather impressive internal project that uses Perl as a metaprogramming language. You'll get yelled at if you deviate from the standard perl-based development flows we've put in place.

      So, "isn't used all that much anymore" may be more anecdotal than not? I guess it really depends on the shop whether perl use is increasing or decreasing.

  • by jensend ( 71114 ) on Monday February 02, 2015 @12:25AM (#48955723)

    With all the work that has been poured into MoarVM, MoarVM Perl 6 is now painfully slow.

    This is a tremendous improvement. The best they'd ever managed with Parrot was "abysmally slow." Before that, perl 6 implementations ranged from "diabolically slow" to "the madness-inducing manifestation of the visage of Gn'oguracha, Elder Slug-God of Unspeed."

    A typical statement from a recent presentation [act.yapc.eu]: "2013.08 was about 3,600x slower than Perl 5. 2014.08 is 34x slower. Better. But still sucks."

    If they keep pouring in the effort, eventually they may reach parity with Perl 5, which was simply very slow. It is unlikely they will ever approach the performance of modern javascript engines, which are just plain slow.

    • by skids ( 119237 )

      This is a tremendous improvement. The best they'd ever managed with Parrot was "abysmally slow." Before that, perl 6 implementations ranged from "diabolically slow" to "the madness-inducing manifestation of the visage of Gn'oguracha, Elder Slug-God of Unspeed."

      Hilarious. And yes it was very, very, very, slow. And yes it continues to speed up. At this point it's OK for scripts that run occasionally, and for some medium-duty stuff if you don't mind spending a bit of time doing some tweaking-you-shouldn't-have to.

  • who is waiting for this with bated breath? i think the wait is over, we've moved on from needing anything from perl6.

  • With all the delays I hope the first and not the second.

    Whatever happens: congratulations and thanks to a team who have done so much over the years!

  • The likes of Python, Ruby and Node.js have eaten much of Perl's lunch and what they haven't eaten is already served by Perl 5. Unless migration is relatively simple (unlike some previous Perl upgrades), I could well see the world choosing to stay with 5.

Sometimes, too long is too long. - Joe Crowe

Working...