Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Perl 6 Synopsis 5 203

Posted by timothy from the making-the-impossible-accessable dept.
XaXXon writes: "perl.com has Synopsis 5 for Perl 6 up. It's a brief overview of all the changes made in Larry Wall's Apocalypse 5. Lots of stuff about the new regex syntax. I must admit, however, that I'm getting tired of reading about perl 6 -- I want to start using it." We posted Larry Wall's 5th Apocalypse in May.
This discussion has been archived. No new comments can be posted.

Perl 6 Synopsis 5 More

Perl 6 Synopsis 5

Comments Filter:
  • ... I'll finally be able to make sense of my perl code after I write it?

    ~geogeek

    • Re:Does this mean... (Score:5, Funny)

      by Fjord ( 99230 ) on Sunday July 07, 2002 @01:04PM (#3837167) Homepage Journal
      No. Perl is a write-only language. You aren't supposed to be able to read it ;)

      • I may be misremembering this, but my favorite new tool for perl obfuscation has got to be user-defined operators...in Unicode!

        "Well of course 'object1 [seated scribe] object2' means copy. It's a scribe..."

      • Perl is a write-only language. You aren't supposed to be able to read it

        Ever seen APL [umich.edu]?
        • I actually disklike "write only" language claims a lot - APL is/was one of my favorite languages -
          but, just as one does not expect to read Chinese without learning the language, one cannot read APL
          without learning the language - APL is a language based on familiar mathematical symbols, so it's not that hard (it's made much harder by (a) misguided attempts to ASCIIfy it and (b) non-APL keyboards)

          Similarly, most perl is actually quite readable once you have learned the language
          If one where to replace every $foo %bar @baz with scalar_foo, hash_bar, array_baz, it might be initially more readable for english speakers - but for the few minutes it takes you to learn the meaning of the symbols, you can save a lot of typing and increase the brevity of your work. A few things did annoy me about perl syntax - I dislike -> instead of . for member access, but guess what?, it's
          being fixed in perl 6.0...

  • So why don't you? (Score:3, Informative)

    by JoshuaDFranklin ( 147726 ) <joshuadfranklin@NOSPAM.yahoo@com> on Sunday July 07, 2002 @01:04PM (#3837171) Homepage
    I must admit, however, that I'm getting tired of reading about perl 6 -- I want to start using it.

    Well, go right ahead. From the Parrot VM, the Perl6 engine, page [parrotcode.org]:

    Can I use Parrot today?

    Well, almost. :^) Parrot is in the early phases of its implementation. The primary way to use Parrot is to write Parrot assembly code, described in PDD6.

    Use Perl6--Write some Parrot assembly, and help out!
    • But parrot isn't Perl 6. Don't believe me? Just scroll up [parrotcode.org]:
      Is Parrot the same as Perl 6?

      No. Parrot is an implementation that is expected to be used to execute Perl6 programs.

      Parrot is likely to be the runtime for Perl 6, but it isn't the language. Conceivably many runtimes could be written for Perl 6, all different. Saying writing Parrot code is the same as writing Perl 6 code is like saying writing x86 assembly is the same as writing Visual Basic.

      --Tom

    • Is it just me? I thought Perl 6 will "simply" translate from Perl to Parrot Assembly language. A usable Parrot has nothing to do with a usable Perl 6. You can use Perl 6 when both Parrot AND Perl 6 itself are done. Right?

  • Perl's had it's day - It's become like COBOL (Score:2, Insightful)

    by Anonymous Coward
    For instance there is now OO COBOL but the only people that use it are COBOL programmers who are stuck, perhaps because of their company's dictates, perhaps by choice, with COBOL. In the same way perl may be heading towards irrelevance wrt "mainstream" language. I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl.

    Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on. To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say. Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.

    I'd prefer to think of this as provocative rather than a flame, there is a difference you know.

    • Re:Perl's had it's day - It's become like COBOL (Score:1, Insightful)

      by Anonymous Coward
      I find it amazing how many clueless people like you pipe up with the demise or Perl, or its unsuitability for X task, or some other random demerit. Slashdot is useless for Perl news because 9/10ths of the posts are clueless idiots writing about how awful Perl is, whereas those of us who actually use perl (to whom the information is pertinent) have to wade through it.

      Your article is nothing but vague hand-waving. I am a professional programmer, I want specifics if you want me to take you seriously.
      • I started using perl many years ago. Back then I really liked it, then they started trying to turn it from a useful scripting language (Practical Extraction and Reporting Language, remember... It's for text processing and formatting the output) into some kind of OO wannabee.

        Read the old edition 1 camel book - it's clear and concise, easily readable and makes you want to go out and code. I have the latest edition... it's 4 times the size, rambling, and doesn't seem to ever get to the point. There's only 3 pages on the reporting side of perl now - it's like they're ashamed of it or something.

        Perl should have been left at what it was good at - there are other languages for large scale programming.

  • Good stuff (Score:2, Interesting)

    by Starky ( 236203 )
    I've been reading the Apocalypses with interest as well as the comments from the peanut gallery.

    For all of the hub bub and brouhahah, I think after it is released and people start to explore all the new (and old) features, folks are going to find Perl 6 an amazing tool that improves on an already amazing tool set.

    With all of the flame wars regarding Perl/Python/Ruby (like triplets calling each other ugly), it's good to see Perl continuing to innovate, improve and set a brisk pace for others to follow.

  • Rename it, it isn't Perl anymore (Score:4, Insightful)

    by ToasterTester ( 95180 ) on Sunday July 07, 2002 @01:47PM (#3837309)
    Wall has changed the language too much and now more regex changes. Like Pascal when major updates became Modula or later Oberon. Original Pascal was left to evolve on it own. Same with Turbo Pascal when Borland heavily changed it they changed the name to Delphi. Call Perl 6 the new beast that it is.

  • Yeah..more RegEx fragmentation (Score:5, Insightful)

    by Eol1 ( 208982 ) on Sunday July 07, 2002 @01:58PM (#3837345) Homepage Journal
    #sarcasm# Yeah!!! Just what we need more RegEx fragmentation #/sarcasm#

    Honestly, RegEx hasn't changed much since awk and when it did, Perl usually led the way. The changes though usually just added features or tweaks, my RegEx still basically looked the same though whether I used VIM, Python, ASP, C++, Perl, .

    Shortly after reading the changes, I was aghast. Sure some of the changes make sense but some are going completely against RegEx as we know them now (getting rid of character classes for one []) . Sure you can use the p5 modifier or do the funky syntax to use [] but the issue is its a radical change.

    This is a bad thing(tm). This is going to force all us RegEx people who currently using 4 or 5 different RegEx tools to not only learn minor differences based on each app, but we will be forcec to learn a COMPLETE DIFFERENT subset of RegEx syntax incompatible with anything else.

    Now wait you say, Perl has always led the way and other tools seem to use perl compatable RegEx libraries. Not so with Perl6. Have floated this question out on a couple developer lists (PHP for one) and everybody is saying, Perl 6 RegEx support isn't going to happen. They are all happy with the current state of RegEx's. This is especially go to cause hell with PHP's perl_regex functions. PHP has stated they are not going to support Perl6 RegEx. Real perl_regex compatible then huh.

    Some the Perl6 changes are pretty good for RegEx, but the complete drop of support for character clases just isn't a good thing (tm).

    My 2cents (who is glad at least Larry added the P5 modifier)
    • Go reread the Apocalypse. Character classes aren't going away at all.
      • Clarification:

        Never said they are going away. I said you now have to do some completely odd funky syntax to do character classes as we know them.

        (well not really, because it soon starts looking completely unlike RegEx... [^a-b] compared to BUT character classes have alway as long as I have know been [] ... some syntax seems essential and such, should be unchanging .+*()[] and later {}? ... This modifiers seem to be the core basic syntax of all regex engines. What next, to much a single character we replace . with (not real code), or how about * with ... my point it [] is basic syntax, it doesnt' need changing.

        Now here is my fun Perl6 question.

        Before I could do [^[:alpha:][:num:].*] .... Perl 6 is what?

        isn't correct since that is not ONE character class.

        > maybe? (though it also doesnt' look right) ... this seems to me to look like [^[:alpha:]^[:num:]^.*] which is completely wrong (and doens't work)
        • Clarification:

          Never said they are going away. I said you now have to do some completely odd funky syntax to do character classes as we know them.

          <[a-z_]> <--sure its only the addition of <> (well not really, because it soon starts looking completely unlike RegEx... [^a-b] compared to <-[a-b]> BUT character classes have alway as long as I have know been [] ... some syntax seems essential and such, should be unchanging .+*()[] and later {}? ... This modifiers seem to be the core basic syntax of all regex engines. What next, to much a single character we replace . with <!.!> (not real code), or how about * with <%many_not_zero%> ... my point it [] is basic syntax, it doesnt' need changing.

          Now here is my fun Perl6 question.

          Before I could do [^[:alpha:][:num:].*] .... Perl 6 is what?

          <-alpha><-num><-[.*]> isn't correct since that is not ONE character class.

          <<-alpha><-num><-[.*]>> maybe? (though it also doesnt' look right) ... this seems to me to look like [^[:alpha:]^[:num:]^.*] which is completely wrong (and doens't work)

        • Clarification:
          Never said they are going away. I said you now have to do some completely odd funky syntax to do character classes as we know them.
          Erm.... you did. The last line of that posting was:
          Some the Perl6 changes are pretty good for RegEx, but the complete drop of support for character clases just isn't a good thing (tm).
          Still, they're not going away as they're useful. That you don't like the syntax change is a separate issue entirely.

          Character classes have changed to <[]> which isn't that big a deal. bare [] are used for non-capturing grouping. It's a reasonable choice--most people use non-capturing groups more than character classes.

    • Re:Yeah..more RegEx fragmentation (Score:4, Insightful)

      by Anonymous Coward on Sunday July 07, 2002 @03:58PM (#3837734)
      Perl 6 "reg"exs are not regular anymore (neither were Perl 5's of course...).
      Perl 6 is now more of a concise parser builder. As Jaime Zawinski has pointed out,
      regexes are not enough for real parsing, though people used Perl ones for ad-hoc parsing all the time.
      The sweeping syntax changes are an indicator of the Perl folk mutating Perl to be better at what people actually use if for - by the looks of things, they'll even stop calling them
      regexes soon, preferirng the term "rule"

    • If the perl 6 regex's have real benefits over the old style of regex's, then everyone else will switch over. Sure it will take a while, but then what improvements in life ever happened instantly?

  • Code-names (Score:1, Funny)

    by Renraku ( 518261 )
    I guess the Christians are going to be waving banners over the naming of this one. Are they going to sue for false advertising when they realize this isn't the Apocalypse the Bible spoke of?
    • "I guess the Christians are going to be waving banners over the naming of this one. Are they going to sue for false advertising when they realize this isn't the Apocalypse the Bible spoke of?"
      Wall is a very devout Christian. Visit his website.

  • makes me glad I'm cutting back on Perl (Score:5, Insightful)

    by g4dget ( 579145 ) on Sunday July 07, 2002 @02:05PM (#3837364)
    I used to write a lot of Perl scripts and libraries. But I've been cutting back and using other scripting languages instead. Perl6 looks like it would not be a pleasant transition from Perl5; I don't want to have to learn a new, idiosyncratic language every major release. If some of the features in Perl6 turn out to be useful (like the new regex syntax), they will make it as libraries into other languages.

  • I prefer command-line PHP to Perl these days (Score:1, Flamebait)

    by Anonymous Coward
    I used to be a big fan of Perl, but I've found that I can typically code any particular application much more quickly using PHP compiled for command-line operation.

    Is it just me, or have other's found this? Also, the performance of command-line PHP is quite acceptable.

  • Perl Rocks (Score:4, Interesting)

    by Tsugumi ( 553059 ) on Sunday July 07, 2002 @02:38PM (#3837462)
    There seem to be a lot of anti-perl flames, so until someone more intelligent, charismatic and pretty deigns to post, I may as well try to defend it...

    First - the myths, untruths etc that have sprung up so far.

    Perl6 is not backwards-compatible with Perl5 - uhm, yes it is. All your perl5 scripts will compile.

    Why not contribute to phython or [insert other language here] well, python will compile through Parrot too, so who cares? If you like Python, write in Python. I prefer $%&? syntax to whitespace-as-syntax, but each to their own, but that is the joy of Parrot. Think .Net CLR without the so-far unfounded feeling that M$ are doing something underhand and nasty that you can't put your finger on. Before someone replies with "Why not just use the CLR instead of Parrot"? bear in mind this has been done to death already. It's in the FAQ, read first, flame later.

    But why Perl? Okay, so it can be write-only. But this is only because of the flexibility, There Is More Than One Way To Do It. This includes obfuscated code, and plain unreadable alien transmissions. However - if you're writing code only you will ever see, then use the short-cuts. If you are writing code that needs to be maintained, then YOU the developer have the responsibility to ensure it is readable.

    Heck, you could always use english; - but this is perl, you can also code in Latin, or, uhm, Klingon.

    Perl is simply the most flexible language out there IMHO. If you're a sysadmin, you will have the Camel and the cookbook on your desk. Our entire environment is held together with Perl. Half the Internet is running on Perl. A dead language? Sheesh, Perl is dead, long live Perl.

    If there is anything that does worry me about perl6, it is that it is becomiung too powerful, and too encompassing - it is important that the balance is maintained whereby it remains the Swiss Army Knife of languages, that it remains as easy for the casual Perl programmer to keep getting their job done with simple scripts as it is to create large projects.

    • Careful, Parrot != CLR (Score:4, Interesting)

      by Ars-Fartsica ( 166957 ) on Sunday July 07, 2002 @02:56PM (#3837516)
      PArrot will juice performance boosts at the sacrifice of built-in safety. This is by design. Dan Sugalski claimed as much in a Perl Review article - to paraphrase - "Parrot will execute the bytes sent to it by the native language compiler. IF the compiler writes improper Parrot, your app will crash.".

      He also goes on to note that the CLR could be a pluggable backend for Parrot to export to.

      • Parrot will juice performance boosts at the sacrifice of built-in safety.
        You misunderstood my comments, apparently. Perl, python, and ruby all, right now, have unsafe interpreters. This isn't anything new--you feed in bad optrees or bytecode to most interpreters and they'll do horrible things. Checking for safety at this level, when running plain code for which you don't choose to be paranoid, is a drain on performance with no corresponding benefit.

        If you do choose to not trust your bytecode, you can run it in a safe interpreter, which will check to make sure everything is proper. You'll pay the corresponding performance penalty, but that's fine as you've asked for it at that point.

        Most of the code that most people execute is trusted code, and for that there's just no win in double-checking it at runtime. And for those rare (relatively) cases where you do care, you can be paranoid and run safely.

        (The CLR's certainly not safe either. Use some unchecked code, of which there's likely to be a lot, and you're just as unsafe)

    • Heck, you could always use english;

      from the perlvar POD:
      BUGS


      Due to an unfortunate accident of Perl's implementation, "use English" imposes a considerable performance penalty on all regular expression matches in a program, regardless of whether they occur in the scope of "use English". For that reason, saying "use English" in libraries is strongly discouraged. See the Devel::SawAmpersand module documentation from CPAN (http://www.perl.com/CPAN/modules/by-module/Devel/ ) for more information.
      So that might be a good idea for Perl 6, but not for Perl 5.

      • Re:Perl Rocks (Score:2, Interesting)

        by Koschei ( 9613 )
        I'm not sure when it was introduced (I suspect it's new to 5.8), but the English module lets you do this these days:
        use English qw( -no_match_vars );
        Which will import everything, except the saw-ampersand and the other problematic variables ($PREMATCH, $MATCH, $POSTMATCH. So you can have the English, and not at the expense of speed.

        • Ah, great :) Sounds like the ideal solution. (I tend to keep my Perl to 5.004 level or below (i.e. 5.4 in the new naming scheme) as it may have to run on machines where I can't dictate that they have the latest version, so I hadn't seen this yet. And I only got halfway through the perldelta for the latest version before something more important came up. :)

          The other answer, even if you can't "use English;", is to comment your code properly, especially complex regexes. Of course no-one should need to be reminded of this, the same way no-one should need to be reminded to keep backups... right? :)
          • especially complex regexes
            Which makes it all the better that /x is the default in Perl 6. Anything that makes complex regexs more legible and more likely to be commented is good in my book.

            (Incidentally, Mastering Regular Expressions, 2nd edition, is out sometime this month.)

  • I must admit to only just having gained a handle on some of the more esoteric features of Perl 5 regex. But I have a definite opinion on the use of the /x modifier on regex - contrary to (what seems like) popular belief, I find it makes regex harder to read, not easier.

    Having to mentally scroll a line after each token impairs my parsing of the regex as a whole. It seems much easier to me to compare a sample of the input to the regex, and see how it looks. I realise it won't be mandatory to lay regexes out like this in Perl 6, but it worries me that this is seen as good programming practise. Don't even get me started on people who comment after every token...

    Still, there's hope that the introduction of this modifer as the default will work against this mindset, rather than for it. Perhaps with its common usage will come enlightenment amongst the Perl posse. I also notice that Larry doesn't use the monstrously verbose regex form during his Apocalypse. So I'm not really sure whether this is a good or a bad thing - but I'm certain that people in the Perl community need to stop preaching that excessive commenting of regexes makes for maintainable code.

    (This probably should have been posted in response to the original Apocalypse 5 thread. Tough titty. BTW, I thought Slashdot would wait for the Exegesis, and how come this is a few days late. Bah, humbug.)

  • Perl has always had ugly points, but regular expressions were always concise and well-known. And now Wall's ramblings about how he wants to change regular expressions are longer than the entire section about them in the camel book. Doesn't this strike anyone else as ridiclous? Perhaps too many special cases and too many borrowed extensions are being thrown into the language. What an ugly mess it is becoming.

    I'm not a big Python fan, but now I'm wondering why I shouldn't just switch to Python now and save myself the grief of having to switch to a completely new Perl-like language later.
    • Perl's 'regexes' are, as Larry himself put it, already well outside the realm of what was originally considered a 'regular expression'. I still remember "pure" regexps from CS101: no capturing, no character classes, not even a '+' (1 or more) operator, since it can be emulated with something like 'xx*'. However, Perl 6's new pattern-matching rules look very interesting; it's really a full-blown parsing toolkit, complete with statful match objects, named (potentially recursive) rules, full closures within matches, etc.

      The only thing that concerns me, really, is the scale of what the Apocalypes have proposed. Yes, the Parrot VM is moving nicely along, but the actual implementation of all of Larry's new design decisions seems to be lagging well behind their creation. I have a lot of faith in the core Perl hackers' abilities, but the climb from here to Perl 6 is not going to be an easy one.

      Personally, I've started looking a lot more closely at Parrot and the Apocalypses (Apocrapha?) since I saw the regex article, and am hoping to be able to get up to speed to get involved in the project over the next few months. I recommend that anyone else who shares my interest (and has any background in parsing and compilation, test case management, VM tuning, etc.) do the same.

      (Note: I'm already a fairly dedicated Python user, but as a language geek, have grown pretty seriously tired of some of the limitation of the language, like one-expression lambdas, weird "special" variable names like '__init__' and '__name__', etc. Plus, if you're trying to do code generation, the whitespace-delimited syntax is a bitch.)
    • As many languages have borrowed Perl regular expressions thay will borrow new Perl regexps at some point. It just the matter of time. You may try to switch from Perl to Python but at some point Python will have new Perl regular expressions for sure as it has now PRCE. New regexps are just too good!

      I don't get why people whine about obvious improvment in regexp engine. First of all: there always p5 modifier to turn on compatibility mode. Moreover do not afraid of complexity of new regexps. You don't have to use all features! Simple things are still easy to do (and even easier). The best thing about new regexps is that they make previously impossible possible.

    • Python is a nice language, but it's not a quick as Perl. Python enforces a lot of stylistic and linguistic structure that isn't always appropriate outside of a teaching language.

      For instance, a series of 'if' constructs in a row that all do a very simple thing (function call) are sometimes cleanest if they are all on one line ...

      example: if (foo) { bar(); }

      instead of spread across three. It makes the relationship between the condition and the action very clear, and also makes it easier to see more of the overall structure by providing more context for the same ammount of lines.

      Similarly, Perl will loop through an array with an implicit bounds check [foreach $var(@array) { }] which lets you do a common task very easily. Python is much more strict about making you check the array size and loop through, making sure not to test past the end. It's a good teaching function, to let people know what goes on behind the scenes in a high-level language so that they understand it better, but it's just as safe either way. Why make the programmer do it?

      I like C, and even enjoy the odd bit of ASM, but when I need to code a text handling application, quickly, I don't reach for those, I go for Perl. Python seems like a good cross between C and Perl, but I don't think it's a replacement for either.

      And, as for as having to switch to a new perl goes... Larry's realized that there's so much P5 code out there that will never be updated that P6 will be backward compatible. If you don't want to change, don't. Any Turing-complete language is capable of any task, there's nothing P6 does that P5 can't. If it's not worth learning, don't bother.

  • Perl Bashers (Score:2, Insightful)

    by mbrod ( 19122 )
    Seems to be a lot of Perl bashers. Surprising.

    Where I work Perl helps us with System Integration, fast scripting, production reports, database connectivity where speed of writing the application and flexibility in changing that application quickly are important, web sites for change control systems, bug reporting systems, etc. and much much more.

    If speed of creating the application and flexibility of changing that application need to be blazingling fast Perl is the choice. If Perl is not going to provide the application speed you need then use C or C++. That is why Perl is written in C :-).

    If the Perl code you are reading isn't readible it probably had to be written too fast for the programmer to accout for that or else the programmer simply didn't care. Perl is the most flexible language ever and it can be the most readible if some care is taken. Especially in a smaller size applications.

  • and I'm about to drop it altogether - both 5 and 6. Franky, coding Perl can be fun, but maintaining and debugging the code written by somebody else - isn't. THis is the implication of having the language with 'the same thing can be done in a 1000 different ways' and the language whose design mostly depends on Larry's whims - and remember that Larry is a linguist by education, and apparently he has somewhat limited understanding of all the issues concerning the 'production quality' language. So - I'll be taking a closer look to apparently minimalistic and restricted Python. Cheers.

  • Perl is beautiful (Score:4, Insightful)

    by Ender Ryan ( 79406 ) <TOKYO minus city> on Sunday July 07, 2002 @07:09PM (#3838429) Journal
    I simply don't understand what is up with all the Perl bashing going on here. I think it is mostly a sign of ignorance, because most of the negative comments about Perl are simply false.

    Many people say Perl is too big, has too many features, is too complicated, etc. This is simply false. Perl has tons of features, but, more than any other language I have ever used, you can use as little or as much of it as you want. You can pick up a Perl book and start writing Perl code in 15 minutes.

    Perl is ugly, hard to read, "write only", etc. This is complete horseshit, probably stemming from lack of experience with using Perl. Perl is very easy to write and read. Where I work, I have a co-worker who is not a programer. He learned Pascal years ago, but did not do any real coding until recently. Despite this, he can fairly easily read and modify my code. Yet, he can't read or modify my C/C++ code at all, and it's usually very readable, very clean, simple and concise.

    PHP/Python is better. A lot of people like to compare Perl to PHP and Python. Neither are "better", there really is no such thing. PHP is for web developers, and Perl can do everything PHP can do in nearly the exact same ways. Take a look at CPAN, there are so many Perl modules for use with Apache and web development in general that Perl is far, far more capable of a web programming language than PHP(IMO anyway). And Python, I've seen some absolutely fantastic stuff written in Python, but I hate Python, because it gives me a frickin headache. I cannot read/write Python, the lack of braces, indentation as syntax is just horrible on my eyes. Perhaps I'm slightly dyslexic or something, but when I'm looking at a page of Python code it all starts to swim and I cannot tell where each code block begins and ends.

    Now don't get me wrong, Perl isn't perfect. There are some things that bother me about Perl 5. # for comments, not bad but I really wish I could use C and C++ style comments in my Perl code. A bunch of #'s just look rather ugly. Threads, Perl 6 will have decent thread support from what I understand, I wish Perl 5 did, luckily for me everything I use Perl for I can fairly easily use multiple proceses instead, still would be nice though.

    I for one am looking forward to Perl 6. There will definately be a learning curve, but at least it will run most scripts without modification, will make upgrading much easier.

    Oh wait... this is /., it's easier to get modded up for bashing something... ok... Microsoft sucks! ;-)

    • Perl is ugly, hard to read, "write only", etc. This is complete horseshit, probably stemming from lack of experience with using Perl. Perl is very easy to write and read.

      gotta agree with you there. most people objecting to perl are straight programmers looking at code written by BOFHs who couldn't care less if you can read their code. But I've seen the code those programmers are writing in a variety of languages and it's no fucking better. And often it's just worse and less concise because of the straitjackets the language puts you in. One would have thought, for instance, that Java would have done better than to repeat all the tired design of the umpteenth homegrown C++ string class, but no such luck; no one else has anything to be proud of (object-oriented shouln't be a synonym for verb-deficient).

      I could go on and on but I expect to find Perl in 2023 (Perl 6.20936, btw), I have doubts about any other current language but C. Perl allows for elegance that other languages simply can't (e.g. "next if $foo;" at the beginning of a loop): bad programmers suck no matter what their language.

      I also have to agree that a block comment, say /# blah blah #/ is overdue.

      • I could go on and on but I expect to find Perl in 2023 [...], I have doubts about any other current language but C

        And what do you think is going to happen to Fortran? Millions of lines of code don't go away over night, and engineers and physicists who only know Fortran aren't going to bother learning anything else.
        • He probably means languages with people actively learning and writing all-new stuff in them. FORTRAN probably won't go away, but I expect that it will continue to stagnate as the people who only know it retire.
          • I expect that it [Fortran] will continue to stagnate as the people who only know it retire.

            My cousin, who got his PhD a few years back in Chemical Engineering, wrote his thesis in Fortran, I assume because he was most familiar with the language. Intro to Engineering Programming at OSU teaches Fortran 90. There are no other Engineering Programming classes at OSU. So there's both new writing in Fortran, and a body of new users.

      • It's not elegance unless Perl allows you to add constructs such as "next if $foo;" to the language yourself, via the language.

        Lisp does. Lisp has been around for 40 years. And I guarantee you that a Lisp will still be here 40 years from now. Languages like Perl, Python, and Ruby continually try to measure up to it, XML tries to imitate its data structure, and most people could learn a few lessons from it. Dynamic semantics and structured data/code aren't going to vanish on a whim, unlike certain other languages tied to a particular creator's looniness (not naming names, but you know who I mean).

  • Just thought I'd rerun my previous comment producing post. Despite all of the ranting that generated I think I'll stick with my contention that Perl is COBOL for the 21st Century. In this respect perhaps perl 6 is going to be ADA, a wonderful language with lots of nice features that NOBODY USES. Perhaps abandon the backwards compatibility and design a new language with all of the features that modern languages should have. Surely that's less effort, and time better spent, that trying to maintain backwards compat. with perl 5. I mean, what can't you do with perl 5 now? Will perl 6 attract a single non perl user that perl 5 wouldn't have attracted? I'm sure perl 6 will be a great language, and a great monument to something, rather like
    "My name is Ozymandias, king of kings: [yoga.com]
    Look on my works, ye Mighty, and despair!"
    Nothing beside remains. Round the decay
    Of that colossal wreck, boundless and bare
    The lone and level sands stretch far away.
    • Sorry, Java will be the COBOL of the first half of this century. Ubiquitous in "business" applications, considered boring, retrograde, old hat, etc.

      You may be completely satisfied with Perl 5, though many others aren't. Perl 6 may keep some of them from migrating to Ruby or Python, as well as attracting new programmers. I did my first "web" programming in Perl (4 actually), though I'd never suggest Perl to a newbie now.

  • Don't complain. It's Larry's language. He can do whatever the hell he wants to do, and still call it perl. If he wants to add support for punching monkeys to it, it's still perl. If you don't like it, make up your own language. Same goes for Linus, if he wants to make the Linux kernel panic every time the clock rolls over to midnight for full BSOD-compatibility, that's his right.

    The reason that perl is successful is because it's useful. Only time will tell if people think perl6 is useful. If they do, they'll use it; if not, they'll stick to perl5.

    Ob regex troll: I think the new regex handling kicks major ass. The new regexes have been promoted to true first-class variables, cleaning up a lot of messy syntactical issues. In addition, everyone who says it's not backwards compatible, well you're right. That's because the current regex libraries SUCK in comparison to the features offered by perl6. That's right, they SUCK, and it would be impossible to be backwards compatible with all the new (useful) features that have been added. If you don't believe the new syntax useful, try backtracking a 100,000 character repetitive string only to discover that the 15th matched number is too large or too small. Now think <{ ... }>.

  • I've read every Apocalypse, Exegesis and, err, "Synopsis" (why the namechange?) so far. Almost everything I've read so far has seemed like a good idea. I've personally run into quite a few of the exact issues they're attempting to solve with these changes. Regexps are just as problematic as the rest of it, and I agree with the changes. And since they're ensuring reverse compatibility with every aspect (usually via a flag), even if I didn't like a particular aspect, I wouldn't have to use it.

    Frankly, I'm looking forward to it. Parrot is nice, and if it weren't for the memory management issues from string-scalar registers, I'd be seriously looking into implementing it in hardware, but its still not too impressive without the Perl6 parser. So I'm waiting patiently, but I feel it'll be well worth it.

    The changes may seem like a lot, but far more will actually be staying the same. Perl's already by far the easiest language for me to implement things in (and I've given basically everything a good try), and it seems as if this batch of changes will solve the few remaining rough areas. Except the learning curve - I think BASIC (for initial concepts) and Pike (for C syntax and functional structure) still have it beaten in that area. Still, it's kinda funny how many apparent perl-haters (old perl and new perl) there are, posting to a forum thats, err, written in Perl =)

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close