Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Perl Programming IT Technology

perl6 and Parrot 0.5.2 Released 229

mAriuZ writes "Bob Rogers just released Parrot 0.5.2. This monthly release includes a couple of interesting new features. First, we've bundled Patrick Michaud's Rakudo (thats the implementation of Perl 6 on Parrot) such that you can type make perl6 on Unixy platforms and make perl6.exe on Windows and get a working standalone Perl 6 binary. This is experimental and we hope to iron out some installation and deployment issues by next months release, but it was important to demonstrate our progress. The second new feature is a toolkit for starting your own compiler. Max Mohun built a prototype several months ago, and we've added a stripped-down version for now that builds the skeleton of a compiler for you using the Parrot Compiler Tools. I mentioned the LOLCODE compiler in What the Perl 6 and Parrot Hackers Did on Their Christmas Vacation; this is how Simon and Company were able to get LOLCODE up and running so quickly."
This discussion has been archived. No new comments can be posted.

perl6 and Parrot 0.5.2 Released

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

    by kcbanner ( 929309 ) * on Monday January 21, 2008 @01:36AM (#22123520) Homepage Journal
    hai
    can has stdio?
    visible "frist p0st!!"
    kthxbye
    btw damn you lameness filter!
  • by 0xC2 ( 896799 ) on Monday January 21, 2008 @01:51AM (#22123610) Homepage
    Eleven months early!
  • Perl 5 to Perl 6 (Score:5, Interesting)

    by cynicsreport ( 1125235 ) on Monday January 21, 2008 @02:02AM (#22123676) Homepage
    In the time it took to develop Perl 6, other programming languages have been conceived, implemented, used and abandoned.
    While I am relieved that Perl 6 is finally showing signs of life, I have concerns:
    1. Can Perl 6 take the place of Perl 5?
    Perl 5 is integral to Unix/Linux systems; it is pretty much taken for granted. To switch to Perl 6 seems like a monumental task. It seems more likely that those wishing to use Perl 6 will have it installed along with Perl 5 (not instead of).
    2. Did it take too long?
    Perl 6 received a fair amount of hype when the project began. With no realistic timetable publicly announced, it seems that people forgot or gave up on it. In fact, in that time Python has become very popular; I wonder if it has taken some of the 'market share' that would have otherwise gone to Perl 6.
    3. Is it any good?
    Perl 6 was supposed to be the "community's" rewrite of Perl 5. The word 'community', when it comes to programming language design, is a bit concerning.... It almost sounds like a euphemism for 'committee'. And that makes me shudder. I once heard the expression "A camel is a horse designed by committee." And I can think of a few programming languages that go along with that saying (No offense to camels).

    Either way, I will download it. I will use it. I will see if it's any good. And, despite all of the issues, I am glad it's finally here!
    • Re:Perl 5 to Perl 6 (Score:5, Interesting)

      by synthesizerpatel ( 1210598 ) on Monday January 21, 2008 @02:20AM (#22123774)
      1. No. Nobody will care about Perl 6, plus, it's not integral to Linux/Unix. The reason Unix is popular is that you have options. Perl works if you like it, but you don't have to use it or be aware of it.

      2. It took far too long. They had books out about Perl6 after the announcement, consisting of reprints of whitepapers and proposals.. Years later, still no perl 6 for real.

      3. Nobody will care how awesome Perl 6 is. The audience of Perl 6/5 doesn't care about single binding vs multiple binding objects -- they won't even get out of bed to have an argument about strongly typed languages vs. weakly typed languages. They just like easy programming -- the metric of Perl 6's success is how much it caters to lazy people. If you want glue, use perl, if you want cement you use something stronger.

      (I was a Perl guy for 15 years, used to love it, now Perl and Ruby both look like line noise that's been encrypted -- compared to my new girlfriend, Python.)
      • How long should it have taken? Is there some standard for how long a new language and VM are supposed to take to implement?
        • Re: (Score:2, Insightful)

          by Anonymous Coward
          Six years later and it is still in the experimental stage.

          In those six years, my former company built and twice re-engineered a forex trading platform written in Java. We went from four machines to over hundred. This is on a shoestring budget with less than twenty engineers (developers and QA). We developed integration components to FIX, SWIFT, and custom projects to banks.

          How many VMs are there to use as reference? The list is long. This is not rocket science. Perl6 is a joke in the same vain as Duke Nukem
        • Re: (Score:2, Insightful)

          A good rule of thumb for your programming language rewrite is, get it done before you lose programmers who jump ship for: a) something 'cooler' b) something better There are lots of things out there now that have one or both of those qualities. Perl just has awesome advocacy and marketing at this point probably only because it's the tradition to treat Perl with respect as it made unix programming easy for newbie Linux people. Times have changed. There are other better options. It took too long.
      • Re: (Score:2, Insightful)

        by Anonymous Coward
        PHP demonstrated that language users don't really care whether a language was "planned" or not.

        Perl was planned by a *linguist*. It may look like noise, but there is a method to the madness, overall, it is well thought out.

        If the amount of time is any indication, I'd expect perl6 to be far more planned out and well reasoned than most other languages.

        Think about this:

        if(! $bool){ ... }

        unless($bool) { ... }

        The unless actually makes it easier to read, it is more "natural" to human
        • do_something() unless($did_it_already);
          obfuscates the instruction order. It can also be problematic if you're working in a text editor on a heavily indented set of instructions and it looks like this:

          $default = DEFAUL_ORD...

          where ... is where the text editor scrolls the text off the screen. If I'm skimming a file, I'm probably not going to scroll to the right because I'll assume DEFAULT_ORD is DEFAULT_ORDER, defined near the top of the file like so:

          use constant DEFAULT_ORDER => 'name ASC';

          Except

        • I have no mod points today, so someone please mod the parent up from 0 points. His example is perfect, and people who know Perl can think of hundreds like this one.

          I totally agree that the linguist's design made Perl much more readable than many other languages. Provided the author actually knows Perl, and cares to write in a readable way. And also much less boring and more creative, as a side-effect.
      • Re:Perl 5 to Perl 6 (Score:4, Interesting)

        by ajs ( 35943 ) <ajs.ajs@com> on Monday January 21, 2008 @09:05AM (#22125444) Homepage Journal

        Nobody will care how awesome Perl 6 is. The audience of Perl 6/5 doesn't care about single binding vs multiple binding objects -- they won't even get out of bed to have an argument about strongly typed languages vs. weakly typed languages. They just like easy programming -- the metric of Perl 6's success is how much it caters to lazy people. If you want glue, use perl, if you want cement you use something stronger.
        I care how awesome Perl 6 is. I care about all of the language design points you raise. I am a current Perl 5 user and will be a Perl 6 user. I'm a minority, and I know it.

        However, it's also true that Perl 6 has been designed to cater to both crowds, and that's one of the myriad reasons it took so long.

        while =STDIN {
          say;
        }
        Is just as short and sweet as it always was in Perl 5, but if you want to get under that hood, you can.

        (I was a Perl guy for 15 years, used to love it, now Perl and Ruby both look like line noise that's been encrypted -- compared to my new girlfriend, Python.)
        Frankly, I think Python is a great little language. It filled the gap between Perl and Java very, very nicely (though Groovy also does that now). Perl 6 won't replace Python, but I think it will become the way people write medium-to-large systems in certain niches, replacing some C++, Java, Python and Perl applications. PHP is probably safe where it is as a rapid Web prototyping system. Ruby will likely evaporate (being largely absorbed into the feature-set of Perl 6) but there's a large Rails community that will take some time to convert even if Rails is directly portable, and it probably will be at some point.

        Perl 5 is a toy language (it's arguable that CPAN is Perl 5's most valuable feature, and that without it, Perl would not have a community today). It's a great little toy, and powerful in its own right, but it's a toy. Line noise? Eh, perhaps, but I started as a C programmer, and thus was trained early in how to write code in an unmaintainable syntax in a maintainable way. The largest problem is that Perl is far easier to be effective in than C, and that breeds long-standing unmaintainable code on its own. That problem is, unfortunately, the curse of all easy languages to use (PHP and Python suffer equally there, though Python has been somewhat stricter on not allowing the bad code to become community code). Perl 6, on the other hand is not a toy, and I'll use it for very different reasons.

      • by Chelloveck ( 14643 ) on Monday January 21, 2008 @10:26AM (#22126086)

        (I was a Perl guy for 15 years, used to love it, now Perl and Ruby both look like line noise that's been encrypted -- compared to my new girlfriend, Python.)

        I've been a fan of Perl ever since the 3.x era. A couple years ago I got a job at a place where the scripting language of choice is Python. My take on it is that Python is that cute, quirky goth chick you met at the bar. She's fun for a while, but once you get to know her you realize that she's got some pretty deep emotional issues that drive you absolutely nuts. And she's really, really obsessive about her appearance.

        No, I'm more than happy to stick with Perl. She may be a little older and not quite as attractive, but she has a wonderful personality. Plus, there's more than one way to do her.

      • Duke Nuke'm Forever is just waiting for HURD 1.0....
    • by zappepcs ( 820751 ) on Monday January 21, 2008 @02:22AM (#22123790) Journal
      Actually, evolution developed the camel and the horse for different environments, but that is not really the issue.

      PERL6, like those before it, is just a tool. It will either work or not. Some don't like PERL because it can be messy and perhaps unstructured. I submit to you that some coders can make a mess of any language. PERL has its advantages, and like everything else, its disadvantages.

      I too will use PERL6, no matter what name it is given. I find PERL is quite useful, and I presume that many others do also as it still seems to be relevant to all but the prophets of the latest Web2.0 gizzmo language thingies.

      In any case, a hammer is a hammer, and when you have to drive some nails... well, damnit, use a hammer.
      • by Hucko ( 998827 )
        so evolution is a committee composed of anthropomorphised Laws of Nature?
      • by chromatic ( 9471 ) on Monday January 21, 2008 @03:49AM (#22124174) Homepage

        I too will use PERL6, no matter what name it is given.

        That's good; that name will likely be "Perl 6".

        • All the more reason for the design of Perl 6... Dialects!

          Now we can have simplified, easy-to-read code that's real Perl, but looks JUST LIKE COBOL /Pet peeve - PERL JAVA RUBY PHP... all OBNOXIOUS! /yes, I know PHP is OK - but it's not the capitalization of the name that annoys me with that language ;)
      • by Thrip ( 994947 )

        I submit to you that some coders can make a mess of any language.
        True, but I submit to you that precious few programmers can make a not-a-mess out of perl.
      • by Coryoth ( 254751 )

        I submit to you that some coders can make a mess of any language.
        Well yes, and some coders can write very clear easy to understand code in perl. On the other hand, there's really no reason to make it too easy for coders to make a mess, just because there are some who will make a mess no matter what you do. A bad coder can make a mess in any language, but for a good coder to make a mess, that takes perl (or, let's be honest, PHP).
        • That might be true, and I like to think of PERL is to coding like LEGO is to model building. Sometimes it's nice to have a pretty and efficient function to hand (PERL Module) and other times it's just a case of build your own. With LEGO you don't have to build the tires, but the car is going to look home made.
      • I hate to break it to you, but Perl 6 is one of the "latest Web2.0 gizzmo language thingies."

        It's Perl 5 trying on Ruby's clothes.
    • Re:Perl 5 to Perl 6 (Score:5, Informative)

      by Killer Eye ( 3711 ) on Monday January 21, 2008 @02:27AM (#22123810)
      Switching may not be that bad, since they built in an incremental mechanism (the same mechanism that lets you put code from ANY two supported languages into the same source file). You could take your 99%-Perl-5 source and add a Perl 6 segment to it, and over time make it fully Perl 6.
    • by Anonymous Coward on Monday January 21, 2008 @04:15AM (#22124296)
      The supposed "community" rewrite started with a bunch of actual community requests, which Larry Wall then waded through increasingly slowly, pretty much taking the little bits he liked, then proceeded to add on a huge set of requirements that he cared about personally (and to be fair, probably the core Perl devs too). Things like extending regex into a full grammar that could parse Perl and be used to extend the language. And linguistic and abstract gumbo like how regular control flow (returning for a fucntion) was some specialization of the exception mechanism.

      Dont get me wrong, I loved reading the Apocalypses. I thought, "wow, Larry really has a deep vision of where he wants things to go". I thought is was pretty neat and hoped to play with it. But in my mind I was thinking that Perl 6 would keep to the general strengths of Perl, in that it was FAST to get done what you wanted.

      That was YEARS ago. I'm abstractly interested but have no desire to use Perl anymore. The "community" rewrite was sprinkled with requests that addressed what people were actually trying to do (certainly NOT trying to parse Perl, NOT taking 6 years, and NOT trying to get a VM running), they were a hodgepodge but every submission was pretty much focused on a narrow problem and in themselves would be achievable in less than 6 years. Instead it's become Larry's Odyssey. I also no longer harbor any expectation that Perl 6 will be FAST (to learn incrementally, to develop a quick solution, or to execute). Great if it does, I just don't believe or care.

      I wish Perl 6 had been the 'shortsighted' approval of perhaps a quarter or a third of the RFCs, rolled out within a year or two. Maybe Perl 7 could have continued this stupid trajectory it's on to irrelevance. More importantly, the volunteer development and donations would be much higher because people would actually CARE about the progress and the features.

      This wasn't what it should have been. It is like this because Perl 6 was overrun by Larry's priorities instead of the community's.

      • by mr_mischief ( 456295 ) on Monday January 21, 2008 @06:21AM (#22124808) Journal
        If you're looking for incremental improvements, you might take a look at Perl 5. In 2001 there was 5.6.1 and now there's 5.8.10 with many improvements.

        Want a few examples of improvements? The regex parser recently went from mostly recursive to mostly iterative. it also has many new features and has other efficiency gains. Unicode handling exists and continues to get better. Several things take less memory than previously. Lexically-scoped pragmas can now be implemented in pure Perl without resorting to C. A simpler and clearer way to handle static lexical variables has been introduced. Perl's default variable can now be lexically scoped. Many new language features have been introduced. Perl has a switch statement in the core now. There's a new defined-or operator. The user-defined sorting subs can now be recursive if you need them to be. Compress::Zlib, Archive::Tar, and Archive::Extract are among some exciting new core modules.

        Most of what I just mentioned were changes between 5.8.8 and 5.10.0, so there's quite a bit more between 5.6.1 and the current Perl landscape. There were also a lot of changes to Perl 5 back in the 2001 to 2002 time frame, and have been all along since.

        Some changes between 5.6.1 and 5.8.0 included changing to a stable algorithm for sort(), changing the default IO layer from the system stdio to the PerlIO system for more predictable cross-platform behavior, safe signal handling, the UTF8 encoding being changed from lexically scoped with the program to being associated with a file handle, and a much better threading model.

        Important changes during the 5.8.x series include extra randomness in the order of hash keys, Config.pm being shrunk by about 90%, better handling of UTF-16 encoding, the elimination of some temporary lists during certain operations, and smarter malloc() handling.

        Perl 5 isn't exactly sitting still, and it hasn't been. Perl 6 is, IMHO, not so much a simple upgrade of Perl as a new language in the family of Perl-like languages. Perl 6 will be to Perl 5 much what Perl 5 was to Perl 4. People will notice some syntax changes, but many people will program in it like they were using the previous version with a tweaked syntax. Others will take advantage of all the new features. Eventually most Perl programmers will find a portion of the language that suits their tasks most readily and will become most comfortable with that. Perl 5 isn't going away for a long time, so people who really can't stand the idea of a new Perl will be able to do a lot of Perl 5 work.

        Yeah, there are other languages that will wax and wane. Ruby looks interesting, and a lot of people seem to like it. I have a general distaste for personally using languages with so much significant whitespace as Python, but lots of people really like it and there's really good software being written in it. I can't fault a language or its designer for my having other preferences. JavaScript is pretty handy, and it's getting better tools and implementations all the time and a new standard soonish. I've picked up HaXe recently, and it's an interesting alternative to ActionScript and JavaScript. I am considering learning D. Java's really popular. Yet many people still program in Perl, C++, C, Ada, Pascal derivatives, Basic, Fortran, and even COBOL. People said Basic was dead, but Visual Basic is still around.

        Like Perl, though, what we call Basic these days doesn't much resemble Basic from 20 years ago. Visual Basic doesn't even look like older versions of itself, let alone QuickBasic or the even older and even more severely limited GWBasic or Dartmouth Basic. If Perl 6 is a few years separated and a bit different, it doesn't mean it's not Perl or that it was a waste to create it. The only way it would be a waste is if nobody used it.
        • Re: (Score:3, Informative)

          by mr_mischief ( 456295 )
          Crap... that first line should read '5.10.0' where it says '5.8.10'.

          s/8\.10/10.0/;
        • The problem I have with Perl 6 is that they plan on changing core operators. A lot of Perl 4 code will run on Perl 5. Perl 5 code will run on Perl 6... in compatibility mode.

          The catch is this: Perl 6 code can't be mixed with Perl 5 code. There are differences [perl6.nl] even in basic syntax and operators [perl6.nl].
      • I wish Perl 6 had been the 'shortsighted' approval of perhaps a quarter or a third of the RFCs, rolled out within a year or two. Maybe Perl 7 could have continued this stupid trajectory it's on to irrelevance. More importantly, the volunteer development and donations would be much higher because people would actually CARE about the progress and the features.

        We're awash in projects that took a more pragmatic, tactical approach.
        Larry, while falling short of a Stallman-esque non-approach to getting a releas

      • by epine ( 68316 )

        I just need to remind a few people that in the past both Postgres and Mozilla were written off for dead in the minds of many. Postgres was lacking one critical performance feature (something to do with row locking), and went dark for a quite during the pursuit of this feature while the developers struggled to wrap their heads around the code base.

        Netscape source code was released into open source in early 1998. The project was renamed Firefox in early 2004, around the time that Firefox was gaining credibi
    • by IkeTo ( 27776 ) on Monday January 21, 2008 @05:48AM (#22124686)
      > 2. Did it take too long?

      > Perl 6 received a fair amount of hype when the project began. With no realistic timetable
      > publicly announced, it seems that people forgot or gave up on it. In fact, in that time
      > Python has become very popular; I wonder if it has taken some of the 'market share' that
      > would have otherwise gone to Perl 6.

      I tend to think Perl 6 as a completely new language, rather than a new version of an old language. If you have even the concatenation operation changed from "." to "_", and if array indexing that you had written as "$arr[$i]$" now must look like "@arr[$i]" instead, and if you'd lose RAII on the way because garbage collection is now no longer at predictable time, it mean all programs will have to be significantly modified or at least converted. This is not exactly what I'd expect from a new version.

      As a new language, it emerge probably slower than what most of us hope, but is probably not as slow as most of us perceived. After all, Perl 6 is a very ambitious language that have all features of Perl 5 and quite a bit more, and it has a completely new low-level engine as well. That slowness is probably due to the lack of any people dedicated to its implementation until very recently.

      By the way, Python is not new. The first version of Python is released in approximately the same time as the first version of Perl. Python is first conceived in the 80's, first implementation started being written late 1989, completed 1991, and did not gain general acceptance until 2000. FYI, Perl 6 is conceived in 2000, Pugs starts to be implemented in early 2005, although it is still quite rudimentary.
      • Actually, somewhere along the line, concatenation changed again, to "~"

        So, now, variable binding with RegExs are done with "~~" instead of "=~".
    • Re: (Score:2, Insightful)

      by WWWWolf ( 2428 )

      In fact, in that time Python has become very popular; I wonder if it has taken some of the 'market share' that would have otherwise gone to Perl 6.

      Yes, in meantime, Python has gained ground - as has Ruby.

      But I think there's one thing that's easy to forget - Perl6 has also been losing ground to Perl5. People need to get their jobs done; if you need Yet Another Hack Built Around An Awesome CPAN Module to keep stuff working, you really have no choice but to write it in Perl5. People have jobs to do.

      Before the P6 hype, I used to write stuff in Perl, after hype, I was like "Ooh, it will really rule one day," and now I also write a lot of stuff in Rub

      • That's the main reason I don't see Perl6 being particularly relevant. Perl may be ugly but it's everywhere. You'd be hard pressed to find a system administrator who never wrote in it. You'd be hard pressed to come up with a file format or API without at least one CPAN module for it.

        With the changes to Perl6 being so drastic, that advantage evaporates and it becomes Yet Another Language. Already have several of those I like far more than Perl. :)
    • by ajs ( 35943 )

      In the time it took to develop Perl 6, other programming languages have been conceived, implemented, used and abandoned.

      That's true, but I don't think anything as ambitious as Perl 6 has made it this far. Haskell is really the only language that I know of that's been even nearly as ambitious in recent memory and then you have to go back to the likes of CommonLISP to find another. There are HARD problems to solve for Perl 6, and you can't just write a simple parser and be done. This isn't Perl 5 or Python or Ruby. This is real change in programming language design. If you disagree, sit down and try to take any given modern s

  • by 5E-0W2 ( 767094 ) on Monday January 21, 2008 @02:25AM (#22123804)
    This is not the release of Perl 6, this is merely another release on the branch that will one day become the perl6 release. The interesting change is that you can now build a proper binary version of perl.
  • About Parrot .. (Score:2, Interesting)

    by systems ( 764012 )
    Does Parrot work like the .Net framework in the sense that libraries say writen in Perl can be used in Python or Tcl! (note that Tcl is a completly different paradigm than Perl or Python)

    I do know that for .Net to achieve this it forces languages to implement certain set of features, and that the libraries to be shareable to be written using a subset of the CLI or CLR. Are there any Parrot plans for something similar, the idea of a single Libarary archive for all the free languages out there sounds amazin
    • Re:About Parrot .. (Score:5, Informative)

      by Anonymous Coward on Monday January 21, 2008 @02:59AM (#22123962)
      Yeah, the idea is that you can write Python code that has access to all of CPAN, for instance. In fact, the whole Parrot theme came from an April Fool's joke referencing the Monty Python skit, saying that Perl and Python would converge into a language called Parrot. Thus, Perl and Python are Parrot's two canonical languages.

      Of course, you can also write a CGI script in Perl that can import some PHP library, for another example.

      This is much like Microsoft's DLR (Dynamic Language Runtime), which intends to make the world of .Net libraries available to dynamic languages, with Python, Ruby, and JavaScript as its headliners.

      dom
    • Re:About Parrot .. (Score:5, Informative)

      by egarland ( 120202 ) on Monday January 21, 2008 @03:39AM (#22124130)
      Yes.. but.. (from what I understand) unlike .net and java, you will be able to compile binary versions of your applications for distribution that don't rely on a giant, bloated, pre-installed runtime *and* they aren't compiled to bytecode at program launch. Also, the register based parrot engine underneath is supposed to be much faster than the purely stack based .net and java VMs.

      Binaries that launch and run at the speed of C with the ability to write in a high level language? Sounds like the future of programming to me.

      The big question I have is will multiple programs be able to share memory to store a commonly used library like C can. One of the things I think causes big inefficiencies in modern languages is the way they don't share memory well. If I have a C library that has, say, 5 megs of pure code in it and I'm running 10 copies of a program that uses it, all 10 can use the same 5 meg copy with only parts that are written to localized to the application. With high level languages, I need to use 50 megs of memory for each. Can Parrot share like C does and have all copies of the program reference the one copy stored in memory? Java and .net can't use this since their libraries aren't implemented on a level where that is possible. Parrot probably could but I'm not sure if it does. Does anyone know the answer to that?

      • Re: (Score:2, Insightful)

        by chromatic ( 9471 )

        Parrot probably could but I'm not sure if it does. Does anyone know the answer to that?

        That's definitely a goal. I think we'll need to make at least one change to the garbage collector such that we don't trigger copy-on-write for shared memory pages of internal data structures and dirty pages unnecessarily, but I think it's possible to fix that without too much trouble.

      • Re: (Score:3, Interesting)

        by Jugalator ( 259273 )

        Yes.. but.. (from what I understand) unlike .net and java, you will be able to compile binary versions of your applications for distribution

        Well, Parrot is actually much like the .NET VM. One reason Parrot was invented according to their own FAQ was because at the time, the .NET VM hadn't been released. Indeed, the .NET CLR now supports dynamically typed languages by making use of the Dynamic Language Runtime [wikipedia.org], like IronPython and IronRuby already use.

        Compare the Parrot PIR and PASM intermediate languages to the .NET IL language. Basically, Parrot does a similar thing as the .NET Dynamic Language Runtime running on top of the Common Language Ru

        • Parrot's one target for multiple languages, but it's also only one target of Perl 6. Goals include that Perl code will be able to be targeted to either a JIT native compiler or a traditional object code compiler as well as targeting Parrot.
        • .net programs require the .net framework to be installed to be used. Its my understanding that one of parrot's goals is to be able to create standalone OS binaries that don't need a giant environment be installed to run. This may seem like a small issue, temporary and easy to fix, but its not.

          Say, for example, .net 4.2 includes this great new feature that will make your little tool that you want to run on the 4000 machines you administrate that much better but they all have 3.5 installed. Unfortunately..
          • by F1re ( 249002 )
            Um, your 3.5 app still uses the 3.5 libraries and and 4.2 app uses the 4.2 libraries? Side by side is a wonderful thing...
      • by cxreg ( 44671 )
        The big question I have is will multiple programs be able to share memory to store a commonly used library like C can. One of the things I think causes big inefficiencies in modern languages is the way they don't share memory well. If I have a C library that has, say, 5 megs of pure code in it and I'm running 10 copies of a program that uses it, all 10 can use the same 5 meg copy with only parts that are written to localized to the application. With high level languages, I need to use 50 megs of memory for
        • Parrot might be able to give you what you are looking for if it saves compiled bytecode, or something like that, to disk and then mmap() it back into memory to actually execute it.
          You are assuming that parrot isn't creating a libfoo.so.0 file. Parrot is designed to be able to compile programs the old-fashioned way (once, not on the fly, saved to a file) as well as on the fly.
      • by Hatta ( 162192 )
        Binaries that launch and run at the speed of C with the ability to write in a high level language? Sounds like the future of programming to me.

        C is a high level language [webopedia.com], so that sounds like the present and past of programming too.
        • Re: (Score:3, Insightful)

          by egarland ( 120202 )
          C might be "high level" by some definition of the word but where I come from C is a low level language one step up from assembly. Calling C a high level language with Java, C# and Ruby around is like calling a 4 story building tall when theres a 400 story skyscraper next to it.
          • by Hatta ( 162192 )
            Yes, high level language means it's one step higher than assembly (the low level language). Java, etc, are "very high level languages".
          • by ameoba ( 173803 )
            There's a problem when you describe a continuously evolving thing in terms of absolutes - just like how 'Modernism' describes what was going on from the 1880s to 1920.
      • Im proud of this little project in a sort of mortified way; it just writes out a C file that wraps a tiny exectuable header around the PBC file and calls a couple of functions in libparrot to run that code, much like the parrot executable does (but without all of the latters command-line options).

        Maybe it will eventually be as fast as C, or faster, but that seems unlikely.

        What's interesting about this perl6 binary isn't that it's actually fast, but that it's as usable as a perl5 binary in that you don't h

  • by ImustDIE ( 689509 ) on Monday January 21, 2008 @03:32AM (#22124096)
    Very sorry for double posting, but I checked the wrong formatting box on the previous post.

    This post is a little misleading. Perl 6 is not done, this isn't a 'Perl 6 release'. It's just another Parrot release, with the neat feature that you can finally run a perl 6 binary instead of going through the parrot one. This, by itself, is nothing major. The main reason for this post is to publicize the great amount of progress Perl 6 and Parrot have made, particularly within the last few months. And by publicizing that, to hopefully get more people involved.

    If you're interested in running Perl 6 now, check out www.pugscode.org -- Audrey's compiler is still further along than the official 'Rakudo' one (although it shouldn't be for too much longer ;-). However, this is still great news to Perl fans. I'm not a contributor, but I do subscribe to the parrot mailing list; the fact that the real Perl 6 interpreter (although incomplete) is finally underway and making great progress, and the momentum that comes with that, is exciting.

    Even if you're not a Perl fan, the Parrot bits should still be quite interesting to anyone that enjoys language implementation. The PCT (Parrot Compiler Toolkit) is maturing nicely and many languages have working interpreters/compilers (to various levels of completion) using it. The amazing thing about it is the sheer speed that you can get a working language together. Rakudo is built on top of NQP (not-quite-perl6) -- a subset of perl 6 built in a matter of (a very few) weeks. And it's important to keep in mind that while Perl 6 is the star of the show for Parrot, Parrot is being designed to fit all dynamic languages; so don't be scared off because you think Parrot is too Perlish. I regularly see posts on the mailing list helping to make Parrot friendlier for other languages (particularly TCL) as people develop using parrot.

    For open source fans, I think Parrot is our best bet for a VM to give .NET a fight (although feel free to reply with other suggestions, I don't keep up with too many others ;-).
    • by dkf ( 304284 )

      I regularly see posts on the mailing list helping to make Parrot friendlier for other languages (particularly TCL) as people develop using parrot.

      Interesting, especially as I don't follow ParTcl (Tcl on Parrot) closely. Care to point us to any performance figures? A comparison of the speed of Perl5 with this release of Perl6-on-Parrot would also be interesting, since Perl5 is a reasonably well-known quantity.

      And before anyone else points this out, yes, I do know that all benchmarks are misleading. Those of us who are language developers are allowed to use them despite their flaws.

  • by Evets ( 629327 ) * on Monday January 21, 2008 @04:25AM (#22124354) Homepage Journal
    I'm not sure why anybody is up in arms about a Perl6 release date. It takes a long time to get done. That's the way the world works. This isn't a platform with a fixed set of requirements, a predictable user base, and limited scalability requirements.

    People have been arguing for who knows how long about syntax. At some point the argument has to end and someone has to implement that syntax. It's not an easy thing to bring either of these points to conclusion.

    Parrot is register based, not stack based. Perl has been developed using Haskell, and eventually it will come to the point where perl can be compiled with itself. These are monumental tasks for volunteer workers pursuing some pretty hefty goals for the sake of pursuing them.

    Pugs [pugscode.org] has been working for quite some time already, and its an easy transition for anybody already familiar with perl.

    I can see criticizing the project because it's hard for a newbie to figure out how to help, or criticizing the syntax in favor of ruby/python/etc, or criticizing performance (although both Perl6 and Parrot perform very well IMO), but criticizing the time it has taken to build? Get off your high horse and go build your next big Web 2.0 script that can do anything as long as you have less than 100 daily visitors.
    • by will ( 6647 ) on Monday January 21, 2008 @07:27AM (#22125062) Homepage

      Get off your high horse and go build your next big Web 2.0 script that can do anything as long as you have less than 100 daily visitors.

      That's not really very helpful. I still feel like an expat perl programmer but I have rails/nginx sites that see over 100,000 people a day without any difficulty. They're clustered over four servers, none of which peaks at more than a half of its capacity. Five years ago I was running similarly busy sites under mod_perl and apache 1.3.x. The architecture was more powerful but less robust. I could do much all sorts of interesting things with the apache lifecycle - rails feels like lego by comparison - but the whole assembly was flaky and temperamental, each mod_perl process took up to 50MB and I lived in constant fear of the whole thing falling over.

      That probably has as much to do with my code quality as anything else (and the 'interesting things') but it does show that the modern high level frameworks are a viable alternative. Rails doesn't scale well but it does cluster well, and hardware is cheap. I miss the quality of people you get in the perl community, the quality of documentation (out here they think that having a blog counts) and the cheerful absurdism. I don't miss the posturing and strop, and in terms of getting things done I'm much better off than I was.

      • I have rails/nginx sites that see over 100,000 people a day without any difficulty. They're clustered over four servers, none of which peaks at more than a half of its capacity. Five years ago I was running similarly busy sites under mod_perl and apache 1.3.x. The architecture was more powerful but less robust. I could do much all sorts of interesting things with the apache lifecycle - rails feels like lego by comparison - but the whole assembly was flaky and temperamental, each mod_perl process took up to

        • And...? You can write the same in Java/.NET. I'm not sure what convinced you people that "Web 2.0" is some kind of trend and that it performs poorly. Most Perl die-hards writing stuff in Perl that shouldn't be written in Perl are just old UNIX geeks unwilling to move on like the rest of the industry has.

          When I need to munge some text or interact heavily with UNIX CLI tools I use Perl, otherwise I use a real language and not a glue/scripting language.

      • Rails and Ruby have nothing at all to do with your site's scalability, that credit goes to switching webservers and architecture. I am currently working on a perl/Catalyst app using lighttpd as the webserver, which should be able to scale insanely well because it's using load-balanced fastcgi with the static stuff handled entirely by lighty. Modern high-level frameworks exist that use perl, which let you get on with the development of your app while still using all of CPAN.

        I've yet to find anything in R
    • Re: (Score:2, Interesting)

      by adamkennedy ( 121032 )
      People have been arguing for who knows how long about syntax. At some point the argument has to end and someone has to implement that syntax. It's not an easy thing to bring either of these points to conclusion.

      Actually, this is kinda wrong. Both have been happening simultaneously.

      The entire point of Pugs was to have a reference implementation of the syntax.

      And the mere existence of that implementation has meant that the language folks have gotten insight into how they designs work when you actually impleme
    • So which implementation is of Perl6 faster? Pugs or perl6 on parrot?
  • April 1st already ?
  • by LuckyStarr ( 12445 ) on Monday January 21, 2008 @09:13AM (#22125482)
    Perl 6 != Perl 5++

    Perl 5 is a interpreter which happens to grok Perl 5. It's the one and only implementation that implements all features (by definition). There is no other specification.

    Perl 6 is not a interpreter or compiler. It's a specification and as such there will be many implementations. Do you know what the current "release" of C++ is? See...

    Want to use Perl 6 today? Use Pugs [pugscode.org].
  • My wish list for Perl 5 was not all that long, but it looks like I get none of it:
    • Goodbye to $ @ and %. There's no reason you should need them if you have declarations.
    • Nested subs with lexical variables that work as expected.
    • Memory management that's not Flintstone-level.
    • Built-in interpreter level profiling.
    • by hey ( 83763 )
      I agree with that. I would add one more thing... compiling.
      Compiling to a bytecode is good enough -- doesn't have to be to the raw metal.
      For years Perl has almost had it bit it still doesn't work :(
  • by egarland ( 120202 ) on Monday January 21, 2008 @01:01PM (#22127836)

    In the time it took to develop Perl 6, other programming languages have been conceived, implemented, used and abandoned.
    Fortran has sucked since the 1950s. C has sucked since the 1970s. Java has sucked for 13 years. How long should "doing it right" take?

    Theres a lot of revolutionary features in parrot. Its unpopular so its fun to bash it but I expect the .net people are laughing publicly and privately frantically trying to catch up so as to not lose market share permanently. If parrot does nothing else but push widespread adoption of the technologies they pioneered, it'll be huge. If the other guys are asleep at the switch.. I expect it will gain lots of fans.

    The same way people who bash Linux just don't get it, the people who bash parrot just don't get it. Peel back the covers and you'll be impressed.

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...