Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Perl Programming

Perl 5.6 Release Candidate Announced 105

thing12 wrote to us to say that the fine folks of Perl have a 5.6.0 release candidate announced.
This discussion has been archived. No new comments can be posted.

Perl 5.6 Release Candidate Announced

Comments Filter:
  • Expect 5.6.00001_0000320026800023 to be out soon.
  • 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 [].
  • by Anonymous Coward
    I like how Perl keeps things nice & standard. It's not like *$ome* companies where when they update, things you previously coded suddenly becomes useless. Then you have to adjust it to the new compiler/program/whatever.

    I tried this up against some old Perl scripts and it runs fine and that's all I really care about.

  • Anyone know when they're rewriting it all in C++?

    IIRC, 5.6 was supposed to be the C++ rewrite. I've been wrong before.. stranger things have happened. :)

  • 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.
  • Perl 6, nicknamed Topaz is the one that is going to be rewritten with C++. Go to 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.
  • by tilly ( 7530 ) on Friday March 10, 2000 @10:54AM (#1211697)
    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. :-)

  • 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.

  • PERL and Python have their uses and strongpoints.

    Two of my domains are hosted by a company that does not have Python capability. All of the hosts I use have PERL. Therefore, I use PERL.

    Does that mean I will avoid Python? No, since I enjoy learning new things and when I have a use for learning Python, I will. PERL is just more prevalant right now. Should there be a huge upswing towards Python, we'll all learn it.

    Choosing between the two, at this juncture, is like choosing what distro you want to use. All are good, but there's just something about one that gets your attention. The folks who visit here are not idiots, for the most part. If scripting is your bag, you'll choose what's more comfortable for you.

    I'm downloading it so I can see what's changed. If noone uses it, it can't improve or get bugs ironed out.
  • Ive been waiting for a good reason to replace bash with perl! Muahahaa. I wonder if any of my system users would notice...

    (sorry if this posted twice:-)

  • 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.
  • by ggoebel ( 1760 ) on Friday March 10, 2000 @11:15AM (#1211709)

    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 ;)

  • Yes, it even supports goto().

    I tried it, it worked, I shuddered...

  • I suppose you are not in the mood for humor ehh?
    Go troll someone elses comment :P

  • I have no desire to maintain code from any language where doing things "right" is more important than getting things done or writing efficient code. So I won't maintain your python code and you won't maintain my perl code. Sounds good to me.
  • Yes, there was no python advocacy in this thread, though that's probably because the thread is so new. Prettymuch every thread I've seen on slashdot in the last six months having to do with perl, even just by offhandedly mentioning it, has gotten a whole collection of python advocates flaming perl and getting marked as insightful for some reason.

    And no, I'm not expressing any insecurity. I started learning perl about two and a half years ago. I haven't really done much with it until a few months ago. Everything that I've had to learn has been very easy to learn, I've just learned it as I need it.

    If anyone has to be insecure about a language, it's you python people. The best attribute of python in its advocates eyes at least is that you don't have to actually be intelligent to learn the syntax. Big deal. Wow. So you have to learn Perl's syntax. Is learning really that painful for you?

    It's also quite amusing that python advocates often talk about Perl's OO parts being bolted on. I know that they're quite easy and not pervasive, if that's what's meant. Thank God. OO has many legitimate places, it's also not the best way to do everything. Python doesn't even have a simple C-like for statement. Python goes back to the good old days of fortran-77 when whitespace was significant. Even fortran got rid of that stupid shackle.

    Oh, I'm nearly done with a graphical checkbook register written in perl, it was quite easy to do. I'm working on a web-based email program that's also pretty easy in the programming side (it's just a big project). I've got a web index-generating program written in Perl, and a message-board written in Perl. Perl is quite nice for small jobs and large ones. As the motto goes: make the easy stuff easy and the hard stuff doable.

    Just out of curiosity, does python force you to handle all exceptions the way that Java does?

  • by Anonymous Coward
    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.
  • You misunderstand me. I care quite a bit about maintenance. have you ever read the linux coding standard? It probably violates quite a bit of what's considered "good" coding practice in python-land.

    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). Sometimes faster code is perfectly maintainable but not asthetically pleasing to a python programmer.

    The point isn't about maintainable versus untmaintainable, it's about the python way versus flexibility. For some reason, one particular way of doing things has become codified in pyton-land as the "right" way.

    Python doesn't even have a goddam for statement. At least not one that iterates like a C for statement. Instead you have to pull some bullshit about taking pieces of an array. I didn't even bother trying to follow at that point in the tutorial. If you really like python, fine. I'm sure that you'd love cobol, too. That one has a leg up on python as it's supposed to be self-documenting.

    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?

    I have my serious doubts about python. The only virtue that I've ever heard extolled by its admirers is that it makes life more doable for the unintelligent. Well, maybe what you need is morons on your staff who have a few programming skills and pretend to be programmers. Maybe you even have a few good ones who prefer python. But please don't make the presumption that because not everyone needs crutches those who don't can't walk properly? I don't need the crutch of whitespace indenting on every line to be able to read a program. It can help so I always put it in my programs, but then again there are places where it hurts more than it helps. So Perl trusts that the people programming in it aren't idiots. Python doesn't. Fine. Just because you have no judgement and can't write readable code without help doesn't mean that other people can't.

    To date none of my perl code comes close to being able to win the obfuscated perl contest. Why? Because I'm writing code for people to maintain. It's quite doable, you simply have to want to do it.

    If you hire programmers who don't want their code to be readable but think that python is the magic cure, then you deserve what you'll end up with.

    Oh, and you know what? Sometimes it's the right thing to do to have some sections of code which need to be blazingly fast and as a result are hard for all but a few really good people to maintain. You can have the slow video drivers, I'll take the ones with inline assembly thank you. The same things goes for everywhere. Sometimes the more important thing is execution time. Remember that there are going to be people who occasionally use your programs (at least there are people who use Perl programs) and their time isn't so tremendously less valuable than yours. So some sections (well contained if done right) will take more time to maintain and require more skill to do so. Big deal. To do things exceptionally well requires exceptional people. This is no different in programming than any other field.

    Note, this is only applicable to small and well-contained areas. Inline assembly is only used in certain places in video drivers. In all things, do the task in such a way as to save the most human time. Somtimes that is the programmers time, sometimes the user's time. And always balance this with having programs which work properly.

    Thankfully, computers should eventually be fast enough where you don't need competent programmers to write usuable programs, then everyone can use python.

    Btw, can python do multi-threading? Once you start to get that complex, you'll need intelligent programmers anyhow, so the whole having to learn the syntax argument will be lost. And so will, in most cases, the argument about readability. When you hire good people one of the things that you should hire them for is their ability to write readable programs. Note: that's readable by other competant and skilled people, not readable by morons.

    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. You'll need all the help you can get to get your people to write mediocre programs.

    If you ever switch to a company where skilled people are hired and they take pride in what they do, then use whatever language you want. Programmers who write readable code write readable programs. It really is as simple as that.
  • 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.
  • Just out of curiosity, does python force you to handle all exceptions the way that Java does?
    In JavaSpeak, all Python exeptions are runtime exceptions. It won't complain at compile time if you don't catch them but it will be lethal to your app if it propagates to the top. Sometimes this is the desired behavior (I/O errors) and sometimes you'd best put some checks in place (tuple accesses).
  • Oh, and while I'm at it, FSCK-ing STOP ALL OF THIS RELIGIOUS WAR CRAP! Whenever I hear all of these flame-heads saying, "Perl Sux, Python Rox!" "No, Python Sux, Perl Rox!" , it sounds like a bunch of morons in a garage going "Hammers Rule, Wrenchs Suck" "Phillips Screwdrivers Rule, Flathead Screwdrivers Suck." FACE IT. These are all TOOLS!
    Yeah. One of the signs of an immature programmer, IMO, is an irrational attachment to one language or another. Languages are just tools ... (of course, I would like seeing templates in Java :)
  • Anybody know what's new in this release?
  • 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 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.

  • by Anonymous Coward
    Be sure and tell that to your potential manager when you graduate and go to look for a job. Actually almost every place i've worked, getting code written fast and efficiently is more important than doing it 'correctly'. What's also not very surprising (to me at least) is that code developed in this fashion is actually easier to maintain because its SIMPLE too. Yessir -- arrogant hacks fresh from college who get hard-ons from writing unmaintainable line noise because it makes then feel smart Well the only arrogant hacks fresh from college ive met are ones who get hardons talking about object purity, and abstracting what should be 2 or 3 simple classes into something like 3 layers of countless abstractions and interfaces. Academically correct ? Perhaps. Rapid development ? Hell No. Easy for another developer to rapidly pick up ? No chance.
  • You forgot the obvious.

    Rewrite perl in perl.

    Just like gcc.
  • 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'.

  • 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 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
  • 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.
  • I think the last time you checked was a long time ago.
    use Error qw(:try);
    use overload;
  • Yes, I've been waiting for this.

    the availability of fork() on Win32 ActivePerl will be a big step forward. I'll use it even more than I do now.
  • 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."
  • "C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg."
    -- Bjarne Stroustrup

    "Programmers are smart people. They are engaged in challenging tasks and need all the help they can get from a programming language as well as from other supporting tools and techniques. Trying to seriously constrain programmers to do "only what is right" is inherently wrongheaded and will fail. Programmers will find a way around rules and restrictions they find unacceptable. The language should support a range of reasonable design and programming styles rather than try to force people into adopting a single notion.

    "I am well aware that not everyone appreciates choice and variety. However, people who prefer a more restrictive environment can impose one through style rules in C++ or choose a language designed to provide the programmer with a smaller set of alternatives."
    -- Bjarne Stroustrup

  • Thank you for the insite. I stand corrected, and I will try and purchase better technical books :)
  • The best thing about python is Zope []. It is quite an impressive Open Sourcetool. Even though I am a C/perl fan, I was forced to figure out some python/Zope stuff at work and found Zope quite usable. Unless I am out of touch, I have not heard of any perl equivelent.

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


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

  • When your hammer is C++, everything begins to look like a thumb.
    -- Steve Hoflich on comp.lang.c++

    As nasty and tasteless as Tcl is, it is a positive dream compared to Perl...Perl 5 does indeed offer 1000 times the syntactic complexity of Common Lisp, 10 times the semantic complexity of Common Lisp, and 1/10th the power of Fortran II.
    -- Philip Greenspun

    Greenspun's Tenth Rule of Programming: ``Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.''

  • What's wrong with multithreading in an interpreted language? It's useful for all the same reasons it's useful in C. You seem confused...

  • by Abigail-II ( 20195 ) on Friday March 10, 2000 @07:27PM (#1211760) Homepage
    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'

  • The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.
    - E.W. Dijkstra

    For more of Dijkstra's evaluations of programming languages (Fortran, BASIC, and PL/I) click
    here. []
  • 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

  • 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.

  • 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.

    Using C++ / STL, it's probably doable. It's not the kind of thing I'd do myself in C, since someone's already done a better one.

  • 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 (-;

  • ``If one wants to learn good OO techniques, then it's best to avoid C++ altogether.'' - Dave Cook, on c.o.l.a

    ``I invented the term 'object oriented', and I can tell you I did not have C++ in mind.'' - Alan Kay

    ``This, by the way, is a document telling you all of the features of C++ that you must not use if you want your code to run on all platforms commonly deployed today. When you print it out, it's a quarter inch thick. If that doesn't say to someone, "don't use C++", there's probably no hope of ever reasoning with them.'' - Jamie Zawinski

    Personally I dislike Python and the Pascal family of languages far more than C++ - purely on based syntactical grounds. I am weird like that. I like elegant languages - like Scheme and Haskell. I use practical languages - like Perl, C and C++.

  • I don't know anything about Python except that it uses whitespace for blocks. The funny thing is that I have to maintain two huge Perl scripts written by a guy who doesn't care at all about indentation. I am sure that if there's hell he'll be forced to write in some language like Python until the end of times in order to pay for his deeds. I would choose the self imposed discipline any day of the week but some people just need it fixed in the language otherwise they won't bother.
  • by Anonymous Coward
    You might want to try HTML::Mason (MasonHQ []) it hasn't got all of Zope's features, but it is less complex, and easier to learn (especially when you know Perl).
  • 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

  • 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

  • Isn't that what the Ruby [] project was??? ;-)
  • Er, which part of the version number do you mean? In 5.6.0, is it the 6 or the 0 that I should be looking at?

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller