Slashdot Mirror
What's New in Perl 5.6.0
Simon Cozens writes "I've written a summary of what's new in the 5.6.0 release of Perl for this www.perl.com article. " The article does a good job of evaluating what's come out - worth reading if you're a Perl Monk
← Back to Stories (view on slashdot.org)
The number of perl programmers is so comparably high, that categorizing them and comparing them to Forth programmers is also probably a waste of time.
;-). I wasn't claiming that engineers were converting to computer programmers en masse because of Forth; I was merely claiming that Forth use in engineers is MUCH higher than Forth use in computer scientists. Engineers also tend to wind up *liking* Forth, perhaps because it gets less in the way, or perhaps because they would be good programmers but never bother to learn any other language.
I have to admit the utter and complete truth of this. In fact, in spite of the fact that I _did_ do some comparison (blush), the main thrust of my little essay was to point out that the comparison was inaccurate.
As an engineer, I can say with certainty that most engineers have never heard of Forth.
Most engineers have never heard of Java, so this is no big deal. (Of course, I'm not counting computer scientists as engineers
-Billy
Eh. References are complicated, but if you read MJD's perlreftut manpage (he is the one who wrote the sins of perl article you reference), they can be pretty easy, I think. They are also very powerful. Also consider that almost all beginners don't need to use them for anything.
Creating a new usable class is a hassle?
package My::Class;
sub new { bless {}, __PACKAGE__ }
All done! What else do you want? How about an accessor?
sub foo {
my $self = shift;
$self->{FOO} = shift if @_;
return $self->{FOO};
}
Now we use it:
my $obj = new My::Class;
$obj->foo('bar');
print $obj->foo;
It doesn't seem that hard to me.
and scope Scope SCOPE!!!
/. dev crew: please fix Preview HTML tag persistence!)
#!/usr/local/bin/perl -w
#
require 5;
use strict;
my ($global0, @global1, %global2, $debug);
# then do what you were gonna do...
(note to
Your Working Boy,
I stand by the claims - I think its a miscommunication between us.
Steep learning curve => lots to learn before you can be productive.
Long learning curve => lots to learn in total.
Perl is easy to use to start being productive. You can get a lot done with a few features. Many perl coders just do open/close/read/write/simple regexp and are happy. You don't need to know the API to sockets unless you need to use that functionality. I don't see how C lays out a path for you to do that in a way which perl does not. In fact you get docs with a perl installation which you don't necessarily with a C compiler.
I'll rephrase. Yes, there is a shedload to learn in total, but that can be a gradual process which you need never complete - more gradual than with compiled languages.
And here are highlights my final final paragraph again, with emphasis.
Perl is not a *panacea*[1]
...use "a good enough tool..." which is *often*[2] perl.
[1] - solution to *every* problem
[2] - often. Not always.
Hope that clears up the contradiction.
You are right that if I had the attitude "learn just one tool, use it always" then I would be a silly person. "I've got a hammer, that'll get those darn screws in". Thats dumb, no argument.
To stretch an analogy, I would perhaps say that instead of carrying around a set of socket wrenches, a saw and hedge clippers I'll just carry this natty little combi-tool with adjustable wrench and cutting accessories.
OK, so I still need to go to the tool shed if I want to cut a tree down, but I have a tool to hand which covers 90% of my needs in one package. Cool. Its why leatherman tools are popular. Same reasoning applies to perl (the 'swiss army chainsaw' gag is tries to get this across). It doesn't remove the need for other tools entirely, but it does cover a lot of cases.
Some theoretical point here.
//prints only lines with col3 nonzero to tab-seperated cols; [] means diamond here
I use perl a lot in everyday's work to do checks and first-round computations on my datafiles, that I aquire in ASCII text.Everything fine with that unicode, but what happens to my zero? Is it automatically translated into a multi-byte Unicode character, and so definitely not a number zero anymore?
To explain my problem, look at this filter:
while ([]) {
@line=/(\d)+, +(\d)+, +(d)+/;
if ($line[3]) {print join(/\t/,@line)."\n";}
}
I often have to make filters like these, many ad hoc. Does the unicode support make me to change my coding style, that means, translate a zero-character to zero?
Only theoretical this problem, 'cause I can use those tr// kind'o' codes and more so, because textfiles aren't read in unicode but plain ASCII instead. But anyway, I still like to know how this zero character works...
Thanx,
Jeroen
Writing about music is like dancing about words - FZ
Nope.
Perl is Perl, expecially for what the Camel book covers. That book will be the staple of every programing library for years to come =)
It's the same as you can go out and get a 5 year old book on C and start. The basics never change. And alot of the info in the camel book actually refers you to sepecific perl man pages, so some of the information it refers to is only as out of date as your man pages are.
So needless to say, your money is still well invested.
Leibniz, written in Lisp *spit* uses a complicated recursive pattern matching function to accomplish symbolic calculus through a lengthy ruleset. Since perl natively supports this kind of pattern matching now, it should be elementary to write a symbolic calculus engine in perl, or even to port Leibniz.
My biggest gripe with perl is that there seems to be no mode to require variables to be declared beforehand. I really despise when I'm coding and do something like:
/etc\n");
/home/ku02c/junk.pl line 4. /home/ku02c/junk.pl line 4, near ""This is in /etc\n")" /home/ku02c/junk.pl line 4, at end of line /home/ku02c/junk.pl aborted due to compilation errors.
;-)
/etc\n";}
/home/ku02c/junk.pl line 4. /home/ku02c/junk.pl aborted due to compilation errors.
my ($fileName) = "/etc/blah/blah.cfg";
if ( $filename =~ m~^/etc~ ) { print "This is in
add this at the beginning:
use strict;
and you get this:
Global symbol "$filename" requires explicit package name at
syntax error at
Missing right bracket at
Execution of
Oops, let's correct your bracket
use strict;
my ($fileName) = "/etc/blah/blah.cfg";
if ( $filename =~ m~^/etc~ ) { print "This is in
new output:
Global symbol "$filename" requires explicit package name at
Execution of
Try: perldoc strict for more info.
Happy?
Chris
San Francisco values: compassion, tolerance, respect, intelligence
Eric
Begin every script with:
#!/usr/[local/]bin/perl -w
# -W is highly recommended for v5.6 and upwards
use strict;
It might not be ideal for one page scripts you throw together, and it might negate many of the messy constructs we all love (e.g. "push @doesnt_exist_yet $value"), but you'll catch a fair number of errors at compile time and more at runtime that might otherwise have been mysterious errors.
Gates' Law: Every 18 months, the speed of software halves.
@letters = ('a'..'z');
print $letters[26];
produces nothing.
Well, of course it doesn't produce anything. However, you aren't use 26 as index. rand 26 will never produce 26, or anything larger than 26. rand 26 will produce something less than 26 - such that when rounded down to an integer, one gets at most 25. If you do int rand 25 the highest value you get is 24, and never 25. This is of course, spelled out in the manual.
-- Abigail
We were discussing perl 5.6. EBCDIC support has been dropped in perl 5.6, making your remark not pedantic, but meaningless. From perldelta
In earlier releases of Perl, EBCDIC environments like OS390 (also known as Open Edition MVS) and VM-ESA were supported. Due to changes required by the UTF-8 (Unicode) support, the EBCDIC platforms are not supported in Perl 5.6.0.
-- Abigail
Without looking at mysub(), how in the hell am I supposed to know this assigns to $a?
You don't of course. But you have to realize that people will nowadays write that as:
sub mysub {
...
my ($f, $s) = @_;
if ($f == 2) {$a = $s}
}
with equivalent code in C, Python, Java, whatever. And noone is whining "but how do I know it assigns to $a?
Also realize that Perl has had functions returning lvalues for many years - substr, vec and pos have done so; with noone asking "but how do I know it assigns to something?" (hint: look at the assignment operator). All that's now happening is making something buildin available to the programmer.
And the bottom line is: if you don't like it, don't use it.
-- Abigail
You got that wrong. my variables are lexically scoped; they are only known to the block they are defined in. Packages are name spaces, and not lexical entities. my variables are unaware of package boundaries.
-- Abigail
@letters = ('a' .. 'z');
print $letters [rand @letters];
-- Abigail
I disagree. The Camel isn't much more than a glorified dead tree version of the manual. But then a version that is 3.5 years and 3 versions out of date. Camel II documents perl 5.003. A lot has happened between 5.003 and 5.6. Perl isn't as stable as C which only gets a few small changes every couple of years. Each version of Perl adds a lot. There's hardly anything in the Camel II that isn't in the manual, and there is quite some stuff in the manual that isn't in the Camel. A PostScript version of the 5.005 manuals contained more than 1200 pages - each of them larger than a Camel page. And the manual for 5.6 is even larger than the one for 5.005.
If you want to buy the camel, wait till later this year. Tom and Larry are busy writing the third edition. Real busy.
-- Abigail
*cough*
Hemos, did you actually check the Perlmonks link before putting it up? It's entire possible that the site has become so overloaded that it's caused their Perlscripts to freak and die, but it looks more like a simple configuration error.. when I went there, at 12:36pm GMT, I saw the following:
--
Software error:
Can't use string ("") as a HASH ref while "strict refs" in use
at
--
That looks like either a miscompilation or a bad configuration error. I hope the Perlmonk guys will manage to fix the problem ASAP - it's not often that your site gets the opportunity to be Slashdotted by so many geeks who are genuinely interested in Perl.
Anyway, so what about PHP, then?
Alex T-B
PS: And no, this isn't meant to be a troll or flamebait against Perl. I genuinely like it. So there.
PPS: I am just being told that the site has recovered. Ah, so Perl not only solves all problems, but can be fixed easily as well? Downloaditnow!
Has anybody here dealt with graphics performance under Perl? Specifically under X?
I am wanting to undertake a project using X to develop a 3D engine (and I don't want to reinvent the wheel too much here, though I do want it to be a learning experience - I figure I will use OpenGL), and I am wondering if Perl can do this at a reasonable speed (I am not looking for 100 FPS with a bazillion texture mapped polys - though this would be cool). If not, what would be the best way?
Should I do what I planned to do in the first place (using C/C++ and OpenGL), or is there a combo of using Perl and C/C++ I could/should do?
Finally, what about handling non-standard devices (like custom home-brewed interface boards)? How can Perl handle those?
I am just looking for advice so I don't head down the wrong road to find a dead end...
Reason is the Path to God - Anon
What I want in perl is a command like this:
%cig=cgisplit;
With everything else in perl why isn't this included. This single feature would save trillions of file opens every day. I don't need Include CGI if there was a decent cgisplit included.
All that 99.99% of cgi's need is simple way to parse the input which can be done in a very few lines of C that is about 1000 times faster than loading CGI-Lite.
/; /;
Sure I can use the "use CGI-Lite;" but the following works quite well:
$query=$ENV{QUERY_STRING};
read(STDIN, $query, $ENV{'CONTENT_LENGTH'}) if ($ENV{'CONTENT_LENGTH'} > 0);
foreach (split(/&/,$query)) {
($name, $value) = split(/=/, $_);
$name =~ tr/+/
$value =~ tr/+/
$name =~ s/%([A-F0-9][A-F0-9])/pack("C", hex($1))/gie;
$value =~ s/%([A-F0-9][A-F0-9])/pack("C", hex($1))/gie;
$cgi{$name}=$value;
#print "$name = $value<br>\n";
}
So what does including something else get me that I need?
He, actually, I believe shaldannon was talking about the new support for binary integer literals added to 5.6.0. You can say stuff like 0b10000 and get 16, and so on. That'd be nice to have in C, actually. Too bad it didn't make it into C9X (the new updated C standard). Time for another GNU extension, perhaps? ;^)
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Perl is difficult to learn for anyone used to a different language with a more regular syntax, and this surely puts people off.
You're joking, right? You shouldn't generalize so much. Two years ago, when I learned perl, I already know C/C++, Tcl, VB, and a host of other languages. Guess what? I took me TWO DAYS to learn enough about perl to use it with nothing but man perl and a telnet window.
Maybe I'm a genius or something, but I doubt it. That it's hard to learn when you know other more structured languages is a claim I've never heard before.
Man's unique agony as a species consists in his perpetual conflict between the desire to stand out and the need to blend in.
72656B636148206C72655020726568746F6E41207473754A
According to the article, in 5.6.0 the warning pragma replaces the -w flag. (I'm sure they didn't actually remove the -w flag when they added the warnings pragma.) Apparently the new pragma allows you to be more specific about which warnings you'd like to receive.
use warnings;
$a = @a[1]; # This generates a warning.
{
no warnings;
$a = @a[1]; # This does not.
}
Anyway, I didn't see anyone specifically mention this in regard to the original post: With warnings turned on Perl informs you of variables that are only used once--which is greatly useful for finding capitalization errors in variables (or any mis-typed variable name.)
Also, people can say whatever they want about Perl, but I love it. I can sit down an jam out code in seconds that would take me all day to do in most other languages--not that I'm exactly a whiz when it comes to other languages. A friend of mine wanted to write a poker-bot in C--I told him he'd be able to learn Perl and write it in Perl in less time than it would take him to write it in C. After he took my advice he agreed.
Honestly I wish I were more proficient with C/C++, but the fact is I'm too lazy. So I'll stick with Perl since it does everything that I need it to do.
numb
The variable $a is a "my" variable which means it is known only inside the package in which it is declared. You got that wrong. my variables are lexically scoped; they are only known to the block they are defined in. Packages are name spaces, and not lexical entities. my variables are unaware of package boundaries. True but since the typical use of packages puts one package per .pm file, the my variables are not only scoped (which, alone, addresses the original complaint) but scoped in a way that makes sense to the module author. If people want modular code, they can use modules. Let's not lose sight of the fact that the complaint lodged against Perl is really a complaint against the use of lvalues -- which is hardly a construct unique to Perl, and is a construct that has arguable merit if not abused.
Seastead this.
What a perverse bug.
(I dare not preview this, but at least it will have some formatting.)
Seastead this.
mysub(2) = 15; Without looking at mysub(), how in the hell am I supposed to know this assigns to $a? So much for the "black box." This violates just about every precept of good programming practice I can think of. Not that it won't be useful; in perl, anything can be useful... There are plenty of idiocyncracies in Perl to get quizzical about, but this isn't one of them. The variable $a is a "my" variable which means it is known only inside the package in which it is declared -- that is to say, it is inside the "black box".
Seastead this.
To only look at Perl as a scripting language is to discount a lot of good and well implemented features in Perl.
No, Perl was originally designed with a purpose in mind, and as with all projects, when it is taken beyond that purpose things start to get messy. If you want something more than a scripting language then you need to find something designed for that purpose, rather than a useful tool that has been pushed beyond its limits.
I have used VB, C/C++, Python, RPG, COBOL, and Perl and I have not seen a language that wraps everything I need for systems administration and reporting, etc into one powerful package.
Powerful, maybe, but elegant? Not really. Perl unfortunately wasn't initially designed to have a consistant mechanism for adding new features, and as such they have been added in a rather ad hoc manner. There's no reason why it shouldn't have the same features but in a more consistant manner.
Perl is difficult to learn for anyone used to a different language with a more regular syntax, and this surely puts people off. Compare this with Python, which may not be quite as powerful, but has a consistant feel about it where new features can easily be added. Something like this is what Perl needs - consistancy and power together at last.
The Pathelogically Eclectic Rubbish Lister may not have initially been designed with OO in mind, however it was designed and revised with the perl motto in mind "There's more than one way to do it". If you do not like a feature, don't use it and if you dislike the way a project is going you have the source and the choice to stop updating. Is your argument any different to the arguments against adding features to the linux kernel, it was never deisgned for xxxx so why add it now?
Never underestimate the dark side of the Source
No, it doesn't. It just means you have to understand the constructs.
Any language can be the source of unmaintainable code; it's up to us to use the power of the language in a sensible way.
This is true. However, in all the Perl code I've written (some of it on fairly visible sites), I've taken pains to make sure I didn't use any of those unusual constructs, or to clarify them with comments if I found it necessary to use something weird.
Your example (mysub(2) = 15) is unmaintainable, but I suspect most sensible coders would have called the function something clearer than "mysub". And if necessary they may even have put a clarifying comment next to it.
This isn't my example; it came from the www.perl.com article. Funny that they should use such a bad example. I'd rather see good examples of how to put the language feature to use; they would be far more useful to me. But as for a clarifying comment, do I have to put one next to each invocation of mysub(), or should I just explain it at mysub() itself? What if I don't have the source for mysub()? Then I have to hope it's documented in the module documentation...
I realize any feature of perl, or any other language, can be used for good or ill. This one just seems to be carrying a negative bias...
---
How am I supposed to fit a pithy, relevant quote into 120 characters?
Perl regular expression engine has always been one of its best strong points. With the latest version the engine has now features never dreamed. Like a recursive pattern matching. If you have never used a programming language with hashes or regexpes, you think you don't need them. After using it with perl you'll wonder how have you been programming without it.
The Win32::OLE module has to do quite a few syntax changes to make it work like the VBScrypt or JScrypt implementations of OLE (the significance of this is in ASP use). However with lvalue subs this is no longer the case. Irritating VBScript things like:
Object.Collection('Key') = Value
Can now be implemented in perl using the very similar syntax:
$Object->Collection('Key') = $Value;
So I think lvalue subs will have a lot of uses. They will also go a long way to allowing overriding of all core functions, although that's still a way away yet (something python does far more elegantly than perl).
Matt. Want XML + Apache + Stylesheets? Get AxKit.
How many of you still program in FORTH?
;-)?
I do.
And I disagree with every single thing you said there. I only had to read one book to understand Forth; furthermore, far from having a mess of inconsistent syntax, Forth has next to NO syntax.
Forth doesn't make solving hard problems impossible; it makes writing application-specific languages easy. You can then solve your problem in a language which is natural for solving it -- and one which may not look very much like Forth. That's not even remotely possible in Perlish or Pythonic languages (outside of going to ridiculous lengths, like building a parser and parsing a seperate file or comments).
Now, what does this have to do with Perl? I'm thinking that you're accusing Perl of being a fad, like Forth was in the early 80s. (And worse yet, a bad fad.) I don't think you have a leg to stand on here; not only did Perl manage to catch a MASSIVE growth spurt in the industry, but it has completely different characteristics from Forth in just about every way -- have you ever written a Forth compiler? How about a Perl compiler
Now, I'm sure that Perl will die out; it has nothing to offer that isn't done better in other places, and the sheer mass of its syntax is already causing it problems. Forth is still around, in OpenBoot and OTA (EuroPay), but only because it offered something really unique -- a simple VM which the programmer could understand and write to, without first having to master a byzantine language (I'm sorry, but even UCSD Pascal is byzantine compared to Forth).
Perl seems popular among web monkeys and CS geeks. Forth is popular among engineers (I've also met a few mathematicians who like Forth, oddly enough).
-Billy
Iconographic writing trades simplicity for portability. A system of writing wherein the rearrangements of the letters of the alphabet corresponds to the sounds (romantic languages for example) makes it impossible for a single word to make sense in different languages. Iconographic writing (chinese, japanese, etc) assigns a meaning to each character, but doesn't specify the sound. Thus the same writing can make sense to speakers of different chinese dialects (mandarin, cantonese, many others). Also the writing is accessible to Japanese & i believe korean, although each extends the icons with their own proprietary extensions. Makes sense if you were trying to make a unified script to manage your empire with if your empire extended over people with similar, but different languages.
ps - IANAL (i am not a linguist)
Scuttlemonkey is a troll
I agree. It's a feature that places more emphasis on the confusion between mutable objects and value types that seems to exist in most popular programming languages.
The problem is variables: sometimes when you write them, they get evaluated immediately (print a), and sometimes they only represent a reference. Perl is extending the range of situations where the latter occurs by allowing these lvalues to be returned from subroutines. I'm also not greatly happy with the way you specify that a routine returns an lvalue in the header of the routine rather than in the return statement it actually affects; I see this causing many bugs.
The solution in MOPL (My Own Pet Language) would be to make all variables objects, so that when you write their names it always means a reference to the object. And use constants instead of variables for holding immutable values to minimise use of variables.
Some functional languages already solve the value/object problem quite elegantly. ...by not having mutables at all. Hmm.
Anyway. I doubt this one'll tempt me to Perl; it's already got so many language features I haven't managed to learn yet, I don't need any more! Guess that's why I liked Python: I had picked it up, learned the language features, and starting writing production code in less than half an hour. But hey, I wouldn't want to start a Perl/Python flame war or anything. ;-) (After all, Python causes as much object-value confusion as any other language, when lists are mutables but tuples are not.)
--
This comment was brought to you by And Clover.
Am I the only one who thinks that the Perl team are trying too hard to make Perl all things to all programmers? I mean, Perl was designed to do simple scripting and text processing tasks, which it does well, but each new release sees some new "feature" tacked on to the end of the language without any real care over whether it is actually required or not.
Perl was never designed to handle classes, threading, lvalue subroutines and so on. I can understand the need for Unicode support - this is in keeping with the whole "Practical Exraction and Report Language" thing, but the rest seems unnecessary for what Perl should be. And unfortunately, Larry Wall et al., haven't never considered these issues in the first place, have added them to the language with little or no care or elegance.
What Perl needs is a bit of a rethink - go back to the core of what it is supposed to do and make sure that it does that as easily as possible. It doesn't need object orientation or threading - they are extraneous and bloated. Unfortunately, at the rate Perl's bloat is increasing, it'll soon be the Visual Basic of the *nix world, with plenty of "cool features" that nobody needs.
From the department of bizarre syntax, subroutines can now be legal lvalues; that means they can be assigned to. Of course, this only works if they return something assignable, and if they're marked as an lvalue subroutine.
Took me a few minutes, but I finally got my head around this one. Sure, it's interesting, but it's yet more bizarre syntax that is going to be hell to debug.
mysub(2) = 15;
Without looking at mysub(), how in the hell am I supposed to know this assigns to $a? So much for the "black box." This violates just about every precept of good programming practice I can think of. Not that it won't be useful; in perl, anything can be useful...
This is yet one more reason I am going to stay as far away from perl as I possibly can. I like to be able to maintain my code. And sometimes I have to maintain other people's code. Things like this will make maintenance a complete nightmare.
---
How am I supposed to fit a pithy, relevant quote into 120 characters?
I know I ought to leave this one alone.. I mean the clue is in the misspelling of the One True Religion...er....language name.
But it does allow one to re-iterate the point of the language:
Perl - The Swiss Army Chainsaw of Languages
If you want "clean", "pure" or "compact", move along there's nothing to see here. If, however you're a bit of a divv, programming wise (I'd certainly own up to this one), and/or you don't get the time you might like to code those C/C++ monster environments, and/or you have a job to do *now*, then the extreme feature-itis of Perl may well be for you...
Perl is *definitely* from the same stable of thought that brought you the UNIX environment - give 'em a toolkit and let 'em write their own apps... Except this time the toolkit is embedded within a language, which makes it usable on many platforms.. I've written scripts on AIX which I was able to successfully port to Linux, NT and even OS/2 using a simple "translation" tool - FTP. No source code editing for me, oh no.
And now if you excuse me I note that since I can now run Perl on my Psion, I feel the need for some serious mobile scripting coming on.
With apologies to the rest of the /. crowd for feeding the troll....
--
I'd rather have a bottle in front of me than a frontal lobotomy
I've been coding for about 15 years, but never bothered to learn Perl until a few weeks ago. I can tell you I'm sufficiently impressed with the language. Certainly, it has the power to be cryptic, but it's not as if "features" of other languages don't offer you an equivalent level of too much power (e.g. #define, the champion of obfuscated C/C++ contests).
/etc\n");
So why do I like perl? Because it has many of the most useful language constructs integrated into its general semantics in a way that other languages don't. In Java you can declare a stack object, in C++ w/ STL you can easily declare a stack object, but in perl, you just use push and pop and the stack is there. In perl if you want to treat something as a stack, and then as a queue, and then as an array, it's elementary.
Anyone who has ever looked at a unix configuration file can't dismiss the usefulness of perl's split function, and the simplicity it provides by splitting files into lines, lines into subsections, and sticking it all in arrays, stacks, or queues with arbitrary lengths, and all done with no effort, and a tiny section of code, in perl.
I shouldn't even need to mention the potential beauty and simplicity of regular expressions (in the hands of someone who knows how to comment!). In my most recent application I needed to split the unix mail spool file into separate emails, it was elementary using regular expressions in perl, since I could make one regular expression to detect the well-structured From line at the beginning of each email. The corresponding C/C++ code would have been quite large and complicated, and the corresponding Java code would have taken 14 packages, 32 regular methods, and 704 getter/setter methods.
The other great thing about Perl is that because of the way things like split, foreach, etc are so naturally integrated, you can usually avoid the most common programming errors. After 15 years, the things that still trip me up in a program are the stupid things. A null pointer error while traversing a data structure, or an off-by-one error while comparing something or interating something. You can't have an off-by-one with split or with regular expressions, since Perl handles the grunt work for you. You basically just tell it what you want it to do in condensed form, and it figures it out.
My biggest gripe with perl is that there seems to be no mode to require variables to be declared beforehand. I really despise when I'm coding and do something like:
my ($fileName) = "/etc/blah/blah.cfg";
if ( $filename =~ m~^/etc~ ) { print "This is in
In most languages, this would trigger a compile error since filename has never been declared, and you would say, "Oh, whoops, I meant to put fileName there", but since perl lets you declare filename in the middle of the if statement, it just makes a new variable. Fine, if you want to program in basic this is useful, but I want to turn it off because I prefer to maintain my sanity. If anyone knows a way to do this, please post it.
All in all, perl is a promissing language. I don't expect it to take any flying leaps in popularity or make any great paradigm shifts due to the level of detest some people have for it, but I know I'll continue to use it for the things it is well tuned for. It's the best tool for a great number of jobs.