Slashdot Mirror


Perl 5.6 Release Candidate Announced

thing12 wrote to us to say that the fine folks of Perl have a 5.6.0 release candidate announced.

22 of 105 comments (clear)

  1. Upcoming version... by deuteron · · Score: 3

    Expect 5.6.00001_0000320026800023 to be out soon.

  2. Don't download it all at once, guys! by pb · · Score: 2

    Beta release. For developers only.

    Not even a writeup on it yet, so don't slashdot the site any earlier than you have to!

    It is great to see some Perl development, though.
    We're one step closer to version 6.6.6!

    Anyone know when they're rewriting it all in C++?
    (or are those two statements related? :)
    ---
    pb Reply or e-mail; don't vaguely moderate.

    --
    pb Reply or e-mail; don't vaguely moderate.
  3. Re:No Python Advocacy, please... also, what bugs? by Anonymous+Coed · · Score: 2

    Can we please not have every perl advocate on slashdot jump out and shout about how hard a time they have understanding a language where every third character isn't an @, brace, or semicolon? I'm sure perl is a great language, though I have no interest in maintaining any code from such an "expressive" language.

  4. Perl 6 by Catatonic+Dismay · · Score: 2

    Perl 6, nicknamed Topaz is the one that is going to be rewritten with C++. Go to Perl.com and you can find a good realaudio thingy of the person who is writing the core of it and he talks about what's going to be in it and why C++, etc.

    --
    rm -rf ~/.signature
  5. Old news :-) by tilly · · Score: 3

    ActiveState has been offering betas based on this software for nearly a month!

    OK, OK, so they just released an earlier snapshot all packaged together. Same development series. And it was not a release candidate (meaning the developers were not prepared to call it a final release if nobody found any bugs).

    But still. :-)

    Cheers,
    Ben

    --
    My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
  6. Happened before, will happen again... by tilly · · Score: 2

    You are wrong. :-)

    Topaz is the C++ version. When that stabilizes it will be called Perl 6.0.

    This is another in the 5.x series.

    Cheers,
    Ben

    --
    My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
  7. Re:The nice thing about Perl by slashdot-terminal · · Score: 2

    Ummm... welll
    thats a nice little theory, BUT
    the reason why 'certain' apps/software/whatever are bloated and unstable is because they try to make everyhting backwards compatible, and end up with 5 times more shit than they need to have. Lets face it. Do realy need to run
    software that was desighned for Win3x. Ofcourse not. You have to break 'compatibility' in order to persue new goals and to embrace new technology. Fuck all of this 'I wanna remain compatible' bs.


    Ok I have a little problem with this. I have just finished a rather long and difficult program (for me) and I would rather not have to port it to a new and "improved" version of the compiler when it is "upgraded". Backwards compatability is not necessarily a bad thing. It just insures that people will be able to compile the program and use language constructs that they are used to.

    The perfect language would have the ability to use hundreds of different structures and things (including all the "bad" things like goto's and other evil things) then the programmer could use whatever they like for whatever task that they like and not have to wory about what the person who designed the language cared about at the time.

    --
    Slashdot social engineering at it's finest
  8. Actually no... versioning has changed by ggoebel · · Score: 3

    Perl has moved to Linux style versions. Where even numbers are stable and odd are development:

    • v5.6.0 = stable
    • v5.7.1 = development track

    Expect to see v5.6.0.1-n soon ;)

    --
    Life is like an egg better scrambled than fried. -- Ken Sawatari
  9. Perl and Python wars by Anonymous Coward · · Score: 2

    In order to bring peace to the community, I'm proposing two great projects:

    1) Perlipy -- re-write Perl in Python.

    2) Pythiperl -- re-write Python in Perl.

    This will be a great advance and bring peace and joy to us all.

  10. Re:Then we're agreed by Anonymous+Coed · · Score: 2
    For some reason, one particular way of doing things has become codified in pyton-land as the "right" way.

    I think you're showing your lack of experience in actually working with Python. You seem to base this on the philosophy espoused by the Python.org tutorial, or from one of many articles written by blowhards that don't know anything about actually working Python. It's actually pretty flexible in terms of different approaches to solving problems, or design. There tends to be only one way to express each individual language feature, which to me is a good thing! It's easier for beginners (not "morons" as you call them) to learn, and IMHO doesn't hamper an advanced programmer at all, and does not restrict problem solving flexibility.

    Python doesn't even have a goddam for statement.

    for i in range(1, big_num):

    print i * i

    What are you missing?

    Oh, and can python do anything like the -e 'code' functionality of perl, where you can do simple tasks without having to pull up a file editor?

    $ python -c "import sys, string; print 'Python', string.split(sys.version)[0], 'is keen.'"

    I admit that functionality similar to perl -pi would be cool. There's nothing fundamental about the language preventing you from doing that.

    I don't need the crutch of whitespace indenting on every line to be able to read a program.

    Maybe you don't need it, but why does the interpreter need semicolons to know where a statement ends? Isn't that a crutch? One would think the 'natural' behavior is that the end of a line ends a line of code. Maybe you've just been hacking Perl and C to long to see any other way.

    Btw, can python do multi-threading?

    Sure, but what's your point? It's actually pretty easy in Python.

    Though maybe you're one of those companies who's trying to hire a lot of morons rather than a few skilled people. In that case by all means use python.

    Hrm. You're being completely facecious here, though I'll take your statement at face value for a moment. Though there are fewer of them, most dedicated Python hackers I've talked to have been extremely intelligent, thoughtful developers who are interested in maximizing productivty and maintainability. I've also talked to a lot of equally bright Perl developers, but I've also seen a few who resemble the characiture of a bad Perl programmer who uses line-noise identifiers. These are the people who hear the word "object oriented" and weep. In their hands, Perl becomes a blunt object to be wielded as a weapon, whereas Python tries to guide developers away from the worst offences. These bad Perl programmers seem to far outnumber the equivilent in Python-land, but this could be a function of the size of the Perl community. Personally I think it also has something to do with Perl's philosophy and language features.

    I guess my point is that knowing a particular language inside and out does not make one an all-around good developer.

    Ultimately, language choice is a very personal thing to people, almost like religion in very real ways. Boosting Perl is fine, but it's kind of sad when you feel you have to diminish Python to do it.

  11. Re:'PERL' does not exist by happybob · · Score: 2

    I hate to say this, but it's sort of annoying.

    PERL does not exist. This is a cruel hoax foisted off by stupid publishing companies that write crappy technical books.

    The language is 'Perl'. The implementation is 'perl'. There is no 'PERL'.

    --
    -- Beer. It's what's for breakfast.
  12. Favorite language war by slashdot-me · · Score: 2

    Now that the language wars are going to start...

    What's you favorite quote from a language advocate?

    My favorite was from Philip Greenspun. He's a professor of CS at MIT and runs the www.photo.net site. He was at my school giving a lecture on database backed web sites. Having heard of Zope and Python I asked him "what do you think of Python?" He gave me a blank look and said "better languages have been designed 30 years ago" (obviously lisp). This from a guy who writes his web stuff in tcl. ROTFL.

    Ryan Salsbury

    1. Re:Favorite language war by HP+LoveJet · · Score: 2

      My personal favorite (from a Bjarne Stroustrup interview years and years ago):

      "There are two kinds of languages: the kind everybody bitches about, and the kind nobody uses."

      --
      spawn_of_yog_sothoth
  13. Re:Then we're agreed by HP+LoveJet · · Score: 2

    You are under-informed.

    Perl4 *was* a scripting language; perl5 is what you make of it. I choose to use it as a rapid development language with object orientation, efficient string handling, native interfaces to scores of useful system calls, process management and signal handling. In other words, just about everything I used to use C for in the application realm.

    Is C still useful? Extremely. There are certain things it does do better. But don't sell perl short just because it's interpreted--any reasonable environment in which people use perl in real life--e.g., mod_perl--incurs the interpreter spin-up penalty very infrequently (ideally no more than once), and the language itself is extremely fast. Don't take my word for it; try benchmarking a set of programs that do the same complex regex match/subst in C and in perl. Guess who wins. Also, try writing a hashtable implementation in C (with arbitrary key data) that's anywhere close to as fast as perl associative arrays. Good luck.

    --
    spawn_of_yog_sothoth
  14. Re:What does Python have that Perl doesn't? by HP+LoveJet · · Score: 2
    I think the last time you checked was a long time ago.
    use Error qw(:try);
    use overload;
    --
    spawn_of_yog_sothoth
  15. But double-check the gotchas by tilly · · Score: 2

    I believe that if you fork() then exec() you will have problems.

    Why?

    Because to get around limitations of Windows the fork() is emulated within a multi-threaded program by a new thread...

    Cheers,
    Ben

    --
    My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
  16. Re:Then Perl is perfect for you :-) by Abigail-II · · Score: 3
    Yes, it even supports goto().

    Actually, it has 3 forms of goto. Plain goto LABEL, computed goto (ala Fortran, IIRC), and deep voodoo magic goto, which can be very useful (in AUTOLOAD() for instance).

    -- Abigail
    perl-Mstrict-we'$_="gotoF.printchop;\n=rekca HlrePrehtonatsuJ";F1:eval'

  17. Re:What does Python have that Perl doesn't? by Abigail-II · · Score: 2
    Does Perl have exceptions or try/finally blocks? How about operator overloading?

    Perl has had die and eval for longer than Python exists. It might be not just as nice as Pythons - as you can only throw a string - but that's being worked on. Perl has had operator overloading for many years now.

    I just happen to prefer Python.

    How can you be sure? Clearly from your questions you don't know Perl, and it seems like "preference" is based on FUD.

    There are a lot of things in Perl that could have been done better, and some things are really awkward. But when you hear Python zealots (who always pop up as soon as Perl is mentioned - I wonder why? Doesn't Python ever get mentioned?), 99 out of 100 times, they hardly know anything about Perl. That isn't going to win them any friends in the Perl community. In fact, it works against them. I often try to explain to Perl people that Python is a nice language as well, but the Python zealotry puts them off, and they don't want anything to do with Python. Unfortunally, there are a lot of Perl zealots as well.

    -- Abigail

  18. Re:What does Python have that Perl doesn't? by elflord · · Score: 2
    I've used perl for a while and like it. I've also started dabbling with python and like that too. I don't really agree with any of the "standard" criticisms of perl or python.

    Personally, I don't see what all the wars are about.

  19. Re:Then we're agreed by elflord · · Score: 2
    I "use strict;" in all of my programs. Writing maintainable code and writing "good" code are two different things. Sometimes it makes code more maintainable to violate standard spacing practice (rarely, but I've seen it in most of the code that I've looked at).

    Depends. In perl, maybe. I haven't seen any python programs that would benefit that much from substantial respacing. And losing those braces makes the code a hell of a lot more readable. Whitespace is not a crutch. It makes your code more readable even if it's already coherent. I write readable perl programs, but the same thing in python is usually more readable ( and I've written more perl than python )

    Sometimes faster code is perfectly maintainable but not asthetically pleasing to a python programmer.

    If you want faster code, you can always use C from python or vice versa. I don't get why you think python is "slow". One usually doesn't use python for speed-critical tasks. You write ( or rewrite ) the speed-critical stuff in C. Ditto for perl -- a lot of perl isn't terribly fast or efficient either ( which is why several of the modules are not pure perl )

    [ nonsense snipped ]

    A lot of these comments are outright wrong. There is a for statement. You can run python straight from the command line. If you bothered to learn about python ( rather than just prejudging it ), you would know this.

    I use perl and python, and like both. I could see good arguments for using either depending on circumstances. For example, there's no way I'd do any serious GUI development in perl ( don't talk to me about perl-Tk. I've used it. One word: "spaghetti" ) However, I'd prefer perl for string manipulation. For this task, Python is functional, but doesn't "feel" as easy.

    However, it seems that you're dismissing python on the basis of it's whitespace formatting alone. Well if you're too narrow minded to learn something new, that's your problem (-;

  20. Re:What does Python have that Perl doesn't? by Abigail-II · · Score: 2
    So when one has an opinion that differs from your own, that's illegitimate? Can one simply not have a "preference"?

    Of course you can have a preference. Have all the preference you want. But let me quote the posting I was replying to for you:

    Does Perl have exceptions or try/finally blocks? How about operator overloading? Personally, I don't care much if Perl has them or not - but last time I checked it didn't. So that's a couple things. Perl is nice. Python is nice. I just happen to prefer Python.

    That shows the poster doesn't know much about Perl. So, yes, he's entitled to a preference, but said preference is not based on actual knowledge of the language. In fact, it seems to be based on common myths, also known as FUD.

    How about the fact that perl's syntax is HAIRY, *much* hairier than python's, and you don't need to know heaps of stupid niggly things to write programs more than a few lines long. That's a legitimate gripe, if you deny it, you're full of shit.

    That's of course utter bullshit. You don't need to know heaps of "niggly things" to write programs. Not at all. Don't let the richness of the language confuse you. You don't have to use it.

    Programming Perl: 619 pages
    Programming Python: 857 pages
    Learning Perl: 256 pages
    Learning Python: 356 pages

    -- Abigail

  21. Re:What does Python have that Perl doesn't? by Abigail-II · · Score: 2
    The first impression of many people (depending of course on their taste) of perl is "ick". This is a legitimate reaction, and is all you need to really have a preference.

    The first reaction of many people to Python is: "whitespace is significant, ICK!", and they never look at the language again, claiming significant whitespace as the reason to hate Python. That's also a preference, but do you think that's justified? I don't.

    How about fine-grained semantic stuff like context-dependencies. Not hairy?

    Eh, no. Natural actually. Many natural languages are context sensitive. And since the majority of the programmers masters at least one natural language, I don't see what's so hairy about that.

    I haven't read any of these books, but that's a stupid argument.

    Really? If Python is so trivial, and Perl so hairy, then why are both the learning books and the reference books larger for Python, instead of being significant smaller?

    Comparing religions by the size of their bibles

    Guido and Larry are neither dieties, or prophets.

    -- Abigail