Slashdot Mirror
Perl 5.8.0 Released
twoshortplanks writes "The latest version of Perl has been released, with new features such as better Unicode support, a new threads implementation, new IO layer support, and a whole plethora of bundled modules - plus a wonderful collection of regression tests and new documentation. The release notes and links to mirrors for download are on dev.perl.org." This is not a release candidate, it's the real thing, representing over two years of work by patch pumpkin holder Jarkko Hietaniemi and his merry band. Hugo van der Sanden is the new pumpking for perl 5.10.
or at least make it easier to write readable code...
The fundamental point of perl is its a quick way to write one-off scripts to do quick repetitive jobs - therefore maintainable code is not necessary. I accept there are other times when it needs to be readable tho...
Nonsense.
Would you say
" quick way to write one-off scripts to do quick repetitive jobs"
Accurately describes the slashdot application?
I suppose it's only a 'real' language if you have to compile it? I'll never understand that mentality.
It's been done. They are called Python and Ruby.
Frankly, Ruby has a lot of promise. I've been toying with it, and it feels like a pretty good compromize between java and perl.
Stop the brainwash
Got FINK? There's the problem. You can try this it has worked for some.
/sw/lib/perl5/darwin/Storable.pm /tmp /sw/lib/perl5/darwin/auto/Storable /tmp
/sw/lib/perl5 to @INC, and exhibits
/sw/lib/perl5.
RESOLUTION:
The following three commands will correct the above issue by removing
the current Storable and replacing it with a recompiled version. These
commands must be executed as the superuser. After these commands are
executed the aforementioned issue will be resolved.
mv
mv
fink rebuild storable-pm
It IS first necessary to do the mv's, before the rebuild, since fink is
a perl script that explicitly adds
the behavior mentioned above.
You will need to execute the above commands for every XS module that
is contained within
This
Good coders use "ugly" pointers that scares C++ coders away. Good coders use complex structures that might give Visual BASIC aestetic freaks goose bumps. Heck it's even better to know some assembly with it's ugly jmp and branches. So I agree with the PERL philosophy, it ain't pretty to look at but then again it works. If you want cute readable code where you spend 60% of the time writing comments because you never when you gonna get fired from the project and some other company/guy will take over who might not know advanced stuff or read code, then somehow that might explain why code is getting even more sloppy these days.
/* */ Don't forget, you write for the computer in the end.
I met a PIC chip coder last day... 16 instructions, things that work in less then 20k and that can be timed at the m.second, now that is beauty in code! It's when it works that the beauty is, not when you cut and paste cute lines of
Now if only Apple would get the Cocoa bindings for Perl cooked up, so I could back-end in Perl and GUI in Cocoa...
I am concerned about any program, any piece of hardware, any treaty, any law that treats me as a consumer, not a citizen
not true, here is a sample brainfuck program :
;)
hello world
I would include it in this body but it fails the lameness filter for having too many 'junk' characters, but its a program....
as you are not allowed comments and none of the operations are particularly obvious because of the lack of verbosity, its very hard to understand what it does even if you know brainfuck.
it prints out 'Hello World' by the way.
things are even worse when programming in machine code, because the commands' binary syntax is not very human readable, although at least you can put comments in machine code.
In short, some languages are better than others for promoting code readability, but I think the exact opposite of your statement is true : you can write unreadable code in any language.
I for one think Perl suffers from write-only tendancies, mainly due to the horrible mess that is called array access. Good clear types really help maintainability, and the last time I saw Perl's collection type(s) it was neither good nor clear.
I was happy to move over to Python mainly based on the quality of its type system, not that this was the only strength. But I must confess to being fully able to produce unreadable bits of Python that could make some Perl fragments look like angels.
At Yet Another Perl Conference this year there was a book auction to raise funds for Perl development. Tons and tons of O'Reilly, Manning, and other books, and not just Perl books. It was interesting to see where the interests lay. There were plenty of wisecracks and groans for Java, Python, and PHP books. (I picked up Learning Python for $10.) Interestingly enough, there was intense interest in the Ruby books, and no wisecracks. Went for a higher than average price, I believe.
Secession is the right of all sentient beings.
I agree. I'm a graduate student overseas at CERN. For my thesis, I'm working on prime number factoring sieve algorithms. I initially used "Fortran", but there were performance issues, so I switched to perl. It's much faster at matrix operations than the cobol libraries I was previously using, and since it's interpretted, I don't have to worry about long recompiles or syntax errors.
TMTOWTDI!
ActiveState Perl is still 5.6. Any ideas when it'll be updated?
I run the scripts on Linux, but I do my coding on a WinAMD machine.
No boom today. Boom tomorrow. There's always a boom tomorrow. - Cmdr. Susan Ivanova
Minus the flamebait of the original poster, I think what he may have been getting at is that Ruby perhaps errs too much on the side of an "academically clean" language -- where a set of basic rules are followed strictly. Some would say to excess, for instance in Ruby, "if(0){print "yes"}else{print "no"}" prints "yes" -- that's counterintutive from the perspective of just about every other programming language. But, it follows Ruby's set of basic, strict rules. (Though I'd like to point out it can still be clean OO can get that behavior. Like in C++, the if() construct takes a boolean and objects can specify implicit conversion functions. So int can cleantly map to boolean... but I digress.)
Perl, while complicated, maps more directly to the idea of human (err.. English) language with exceptions to the rules and exceptions to the exceptions -- but with everything behaving the way you'd implicitly except in a given context.
Oh, and arguing about the size of the code-base is just silly.
A while back sockets under perl 5.6.0 stopped working on all of our Sun Solaris 8 systems. I tried recompiling it, 5.6.1, and 5.8.0rc2 (I plan on trying perl 5.8.0 final soon), but all of them fail on the socket tests, which include:
- lib/io_multihomed..Protocol not supported at lib/io_multihomed.t line 83.
- lib/io_sock........Protocol not supported at lib/io_sock.t line 37.
- lib/io_udp.........Protocol not supported at (maybe your system does not have a localhost at all, 0.0.1) at lib/io_udp.t line 60.
(Note: We do have localhost defined in our host table).It was a while before we noticed the error so I do not know what could have changed on our system to cause this problem. The only thing I can think of it being is that we patch all our systems between the time it last worked and when it did not. I did note that one of our installed Solaris patches is 111327 which does replace the socket libraries. We recently got a new SunBlade 2000 Workstation and I tried it again on it, and it too has the problem. It came prepatched and includes 111327 amongst many others. I have yet to try taking that patch off (mostly because of the logistics involved in removing one of our active Sun off the network for the test, and I am not willing to take a security patch off our system with it on the network).
This is not the same as noted in PerlFAQ 8, though I guess somebody at Sun could have deceided to change the Protocol numbers again, but I think it unlikely. I even went as far as modifying the test routines to add "use Sockets;", but no help.
Also, where can one submit and view bugs reports for Perl?
On the contrary, if the choice was the developer's and he/she made a poor choice, that is very much a reflection of their (lack of) ability.
The language used has little to do with the quality of the final result, and has a lot more to do with the person coding with it.
Generally speaking, given the choice, a good programmer won't make a poor choice of language for a project. (We don't always have that choice, of course, but a good programmer knows the difference and will readily admit to suboptimal management constraints.)
The maintainability of a language seems weakly related to individual languages.
Most of the garbage code I see these days, both proportionally and in absolute terms, is written in Perl. I believe that this is due to design problems with the language itself, and due to the fact that the language is so popular, therefore drawing to it many unskilled programmers, and due to the compounding interaction of these two factors.
Perl was there first, and Larry Wall deserves accolades for it, IMO. These days, though, is there anyone that doesn't cringe at the thought of having another bale of newbie Perl code dumped on them to maintain?
--Mike
"Not an actor, but he plays one on TV."
Huh?
No, Perl was removed becuase it has started to become very bloated, plain and simple. 5, 10 or even 20 MB could be handled, but it is starting to get a little bit bigger. Plus the language bigots had crept in too...:)
Atleast I got Perl in there, JKH and others were voting for TCL instead. (YUCK)
When I added Perl to FreeBSD 2.0 way back when, it came in very handy for things which needed to be written. In this day and age, FreeBSD has started to take more and more things out of the base installation and allow people to add them back in via a port. Which I agree with, why does a web server need Sendmail installed???
BWP