What's New in Perl 5.6.0 125
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
Brief note about Korean (Score:1)
P.S. IANALinguist Either, but I do know a Korean English teacher.
Re:A few reasons why pearl sucks. (Score:1)
Again, a nice attempt a trolling. I commend you. But you're wrong. ;)
Re:Regular Expressions improved (Score:1)
Would it maybe be possible to do symbolic integration with Perl regular expressions????
Scary thought, but it seems as though regexes and symbolic integration use roughly the same sort of processing technique. And now that they can be recursed it may well be possible... who knows...
binary? (Score:1)
Who am I?
Why am here?
Where is the chocolate?
Oh, I see... (Score:1)
Now that you point it out, I'm surprised I didn't think of that.
Who am I?
Why am here?
Where is the chocolate?
Even Better - Unicode support in source files! (Score:1)
You can use Unicode in your source files!
Which means you can now have Unicode characters as things like variable names, subroutines, and so on.
$ = &($);
and so on.
Whee! I bet ol' Starscreamer's head explodes after reading THAT for 10 hours.
Try CGI-Lite (Score:1)
use CGI-Lite;
$cgi = new CGI-Lite;
%FORM_HASH = $cgi->parse_form_data();
if (! %FORM_HASH) {
print_main_interface;
}
else {
process_form(%FORM_HASH);
}
Simple!
Re:Lvaluable Subroutines (Score:1)
No, it doesn't. It just means you have to understand the constructs.
Really?! You mean one must understand the Perl syntax in order to be able to maintain code written in it? Well, that certainly is a valid criticism of Perl...
"Here be dragons" (Score:1)
Bhah! =) Threads must be burned (through the computeresque threads do have their uses...)
Of course, every Perl hacker likes Klah [www.iki.fi]. It's a drink for true hackers [www.iki.fi]!
Psion support is cool and Unicode'll be handy. (Score:1)
Re:Feature bloat in Perl (Score:1)
Hey freak, that has nothing to do witht he fact that it is in Perl. It was a logic error. I know, because I made it. So blame me, not Perl.
Re:Bizarre behaviors-- Chechk this out! (Score:1)
Re:Lvaluable Subroutines (Score:1)
int x;
int &my_x() { return x; }
void foo() { my_x() = 42; }
It is very useful in some situations. Does it make C++ unmaintainable? Somewhat... a lot depends on having a good environment around the compiler to provide context information about the code you are reading.
Bizarre behaviors-- Chechk this out! (Score:1)
Comment: 'I surely do hope that's a syntax error.' - lwall
Example:
sub mysub : lvalue {
if ($_[0] > 0) { return $a } else { return $b }
}
mysub(2) = 15; # Set $a to 15
mysub(-1) = 9; # Set $b to 9
Wow! This is really bizar. With this, you really can start writing for the Obfuscated Perl Contest.
I conclude from this that the sub can't have a proper return value. So apperantly, you have to treat these subs really different-- or am I wrong here?
Some people in my department really distest perl for the post-modern language tricks... but this shell surely will explode! Camera ready...
Jeroen
Re:Feature bloat in Perl (Score:1)
print scalar(('a'..'z')[int(rand 25)]);
obfuscated at all?
Just remove scalar, and it nearly reads like text: print (('a'..'z')[int(rand 25)]); . Just read it like
Well, of course you have to know that you have 26 members, and that indici start at 0. For a coder, you could take that knowledge for granted.Just to prove the beauty of perl (american, that is).
Re:what's new in perl 5.6 (Score:1)
'0' should be fine (Score:1)
Re:Feature bloat in Perl (Score:1)
Sure, unless you need to maintain it. If there are five different ways to write something, then I as the writer only need to know one of them, but I as the maintainer need to know all five, since any of them might have been used. If there's only one way to do it, then as the writer, I don't have to waste mental power choosing between them, and as the maintainer, I only need to learn the one.
But the set of features you need to know is still not the whole language, its just the set of features which the author used.
Unless you're dealing with more than one author, or an author who's learning more about Perl the more they use it, or more than one program. While the set of features in Perl is large enough that you'll probably never see all of them used, as the number of programs you're responsible for increases the set that you'll have to know grows faster than many people are comfortable with. Especially people who look at other languages where the amount you have to remember at any given time is much smaller, and are jealous.
Anyways, I doubt anyone here will convince anyone else here to switch languages. Some people like Perl, some people don't. 5 Karma points to the first person who guesses which camp I'm in, and which camp I was in five years ago.
Later,
Blake.
Re:Lvaluable Subroutines (Score:1)
Is that the magical Perl comment construct that automatically updates itself when the code changes? I've been burned by erroneous comments more often than Obi-Wan errors.
Later,
Blake.
Re:Umm... (Score:1)
Re:Lvaluable Subroutines (Score:1)
Re:Feature bloat in Perl (Score:1)
Perl is not a panacea. However, instead of thinking "use the (one) right tool for the job" and learning C, C++, perl, python, java, scheme, eiffel etc, use "a good enough tool for the job" - which is often perl. Its easier to write in perl all the time and use a new feature than it is to learn a whole new language for every task.
Well, what is it then Mac? Is it or is it not a panacea? You sort of contradict yourself in the last sentences. But the important thing is: if you approach programming with this attitude (learn just one tool, use it all around) you're pretty likely to write software that sucks in one way or another. Which is not so bad for sysadmin stuff (which is still most of PERL's turf), and provides for a little job security on the side.
PS: Excuse me if the formatting comes out broken. I have posted twice to this article, previewed, but Slashdot keeps, uh, slashing at the formatting. What language was it written in again? Thought so.
Re:Feature bloat in Perl (Score:1)
But now you aroused my curiosity, would the construct work in a previous incarnation of PERL, by some magic? I'm not trying to be sly or anything here, just curious, not being a PERL guru myself.
Re:Feature bloat in Perl (Score:1)
Re:Feature bloat in Perl (Score:1)
Not that there's too many people running PERL on EBCDIC systems
Re:Another potential use of lvalue subs (Score:1)
my $handler = {
'this' => \&this_handler,
'that' => \&that_handler
}
# some other stuff
$handler->{$value}->($arg1, $arg2)
where $value can be 'this' or 'that' forgive me if the formatting's wrong...it's lovely how
Another potential use of lvalue subs (Score:1)
$rSub = \&mySub
Now I should be able to say: someSub(@someArgs) = \&mySub
This allows someSub to figure out some stuff and let me assign the appropriate sub reference.
Re:Well _I_ happen to like Perl. (Score:1)
use strict;
Always put that line in all your code. It will save you hours of headaches.
is 'use utf8' global? (Score:1)
--strick9 [yak.net]
Re:binary? (Score:1)
Nothing to do with Perl manipulating binary files...
(Although I guess there's nothing to stop you doing it, if that's the way your brain works
Cheers,
Tim
Conspiracy theory (Score:1)
Re:Graphical Perl? (Score:1)
Re:Graphical Perl? (Score:1)
Re:Well _I_ happen to like Perl. (Score:1)
Funny, I just spent the weekend tracking down an error in a java application and finding out that it was due to the fact that Sun decided to change the File class between 1.1 (our development environment) and 1.2 (our production environment). So what did I say to myself? "how unreasonable... why can't we be using perl on this project..."
Re:Lvaluable Subroutines (Score:1)
Why is "Your example (mysub(2) = 15) is unmaintainable"?
Never mind the coders, with which I think you're making a step in the right direction; but if you don't know Perl, including 5.6.0, what are you doing trying to maintain it?
Doesn't sound like a language misfeature to me, when you look at it like that.
Me, I'm looking to learn a bit of Scheme for those more orthogonal moments....
~Tim
--
use strict; (Score:1)
Beauty of Perl is in this, that... (Score:1)
The concept behind Perl is it is an 'orthogonal' language, or comparable to human language in that, that it evolves, accomodates new concepts and generally is not self-contained from the beginning (as most other programming languages), but rather represents a framework on which to build.
-!.
Re:Bizarre behaviors-- It doesn't work (Score:1)
I was very happy to see this feature added, as I had some obfuscated code/poetry to write using this. Problem is, on solaris, with this fresh perl 5.6.0 binary I just compiled, the example they provide doesn't even work.
whereas this works: my $var;sub mysub : lvalue {
$var;
}
mysub = "test";
print $var . "\n";
do work, but not with a return before $var! ( I guess return evaluate its argument somehow )
any clue?
Re:Feature bloat in Perl (Score:1)
print scalar(('a'..'z')[int(rand 25)]);
Mark
Re:Bizarre behaviors-- Chechk this out! (Score:1)
sub mysub
if ($_[0] > 0) { return $a } else { return $b }
}
mysub(2) = 15; # Set $a to 15
$myvar = mysub(2); # Set $myvar to 15
similar to declaring:
int& mysub(int foo)
{
return localvariable;
}
and calling
mysub() = 15;
will set localvariable to 15, but
myvar = mysub();
will set myvar to the value of mysub.
--
Re:Lvaluable Subroutines (Score:1)
such as
sub get_array_element : lvalue {
return $array[$_[0]];
} # get_array_element
&get_array_element(34) = 15;
I do this all the time in Java/C++ so this construct makes sense to me
Re:perl still has features to add... (Score:1)
That's all well and good, but I think the complaint was not that you couldn't write a little code to make %cgi=cgisplit(); work, but that you have to load the whole CGI module to do it, even if that's all you wanted the CGI module for.
I issue, with all the real Perl hackers (a set of which I am not a member) in posting on this story the standard ringing endorsement of the language.
Re:More confusion (Score:1)
If you're going to criticise a language, at least have the decency to spell it correctly. The language is Perl, not Pearl.
And a question: do you actually use Perl? Thousands of us do, some make a living out of it, others write incredibly useful software which underpins your day-to-day use of the internet. Perl doesn't deserve obscurity; it and its kin (Python, PHP et al.) deserve to be recognised.
Rob.
Re:Well _I_ happen to like Perl. (Score:1)
Dave Blau
Re:Well _I_ happen to like Perl. (Score:1)
my ($fileName) = "/etc/blah/blah.cfg"; if ( $filename =~ m~^/etc~ ) { print "This is in /etc\n");
"use strict" (or "use strict 'vars'") is your friend.
Darn straight it's for dinner. (Score:1)
I like the function as lvalue bit, which would probably let me do something like display the fact that I've forgotten basic syntax and functionality:
lookup(%table, $key) += $x;
barf(%table, $x) if ($key == -1);
Excuse me, I need to go hack.
Re:Feature bloat in Perl (Score:1)
Re:Feature bloat in Perl (Score:1)
Re:perl still has features to add... (Score:1)
Re:Feature bloat in Perl (Score:1)
By adding new features I mean things like adding object orientation to the language core, rather than new packages, which is quite straightfoward. Whew, my karma's taking a beating here - maybe I should stop saying what I think :)
Re:How do I say "Hello world!" in Perl? (Score:1)
#!/usr/bin/perl
print "Hello World!";
Re:Graphical Perl? (Score:1)
Re:More confusion (Score:1)
Re:More confusion (Score:1)
I learned c/c++ before I tried to learn perl, and I had a hell of a time with it. I tried for about two weeks and gave up. It is a messed up language.
As for PHP, well, does anyone use it? I've never seen any evidence for its use on the net.
I have seen it used in production enviroments. I worked at a web shop that used it. I dunno how many places run is exclusively, but it does forms and other nifty web stuff pretty well; plus it works with *sql pretty well.
Re:Feature bloat in Perl (Score:1)
Like English, Perl is easy to learn once you get started. Most foreign nationals will tell you that English is hard to learn at first, but they get it. It is the intimidation factor that scares many people, just like Perl. Perl was designed to operate and feel like a 'natural' language, like English (It was designed by a linguist!). So it may not have the neatness of Python, but the elegance of the code comes not from the language, but from the user. A New York cabbie may butcher the English language left and right, but in the hands of Shakespeare or Tennyson, English becomes a most beautiful, descriptive and powerful tool.
And as far as adding new features, perhaps I need clarification. I take features to mean packages such as "File::Find" or "Cwd". It seems that you mean something different. If you mean the packages, it is relatively easy to add them. You plan them, code them, save them as xxxxx.pm file and place them in Perl/Lib and use it in your code. No need to compile, etc. So I think that you mean something else by feature. Can you clarify that please?
Re:PERL FUTURE FORTH FUTURE = QUESTION (Score:2)
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
Re:Feature bloat in Perl (Score:2)
Re:Feature bloat in Perl (Score:2)
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.
Re:Well _I_ happen to like Perl. (Score:2)
#!/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,
Re:Feature bloat in Perl (Score:2)
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.
What about '0' in Unicode? (Score:2)
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
Re:The Camel Book (Score:2)
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.
Should be. (Score:2)
Re:Well _I_ happen to like Perl. (Score:2)
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
Re:Umm... (Score:2)
Eric
Re:Well _I_ happen to like Perl. (Score:2)
#!/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.
Re:Redundancy mistake (Score:2)
@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
Re:Feature bloat in Perl (Score:2)
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
Re:Lvaluable Subroutines (Score:2)
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
Re:Lvaluable Subroutines (Score:2)
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
Re:Feature bloat in Perl (Score:2)
@letters = ('a' .. 'z');
print $letters [rand @letters];
-- Abigail
Re:The Camel Book (Score:2)
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
Perlmonks.org? Site down due to Perl error. :-P (Score:2)
*cough*
Hemos, did you actually check the Perlmonks [perlmonks.org] 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!
Graphics Performance? (Score:2)
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...
perl still has features to add... (Score:2)
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.
Re:Try CGI-Lite (Score:2)
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?
Re:binary? (Score:2)
Re:Feature bloat in Perl (Score:2)
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.
Re:Well _I_ happen to like Perl. (Score:2)
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
Re:Lvaluable Subroutines (Score:2)
Bad HTML Formatting (Score:2)
What a perverse bug.
(I dare not preview this, but at least it will have some formatting.)
Re:Lvaluable Subroutines (Score:2)
Re:Feature bloat in Perl (Score:2)
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.
Re:Feature bloat in Perl (Score:2)
Re:Lvaluable Subroutines (Score:2)
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 [giant.net]), 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 [perl.com]. 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...
---
Regular Expressions improved (Score:2)
Re:Regular Expressions improved (Score:2)
$re = qr{
\(
(?:
(?> [^()]+ ) # Non-parens without backtracking
|
(?p{ $re }) # Group with matching parens
)*
\)
}x;
That will match things like:
abc(def(),ghi())If there are parens use the pattern recursed, if there aren't match !
One potential use of lvalue subs (Score:3)
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).
Re:PERL FUTURE FORTH FUTURE = QUESTION (Score:3)
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
what's new in perl 5.6 (Score:3)
Re:Unicode support (Score:3)
ps - IANAL (i am not a linguist)
lvalues considered pain in ass (Score:3)
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.
Feature bloat in Perl (Score:3)
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.
Re:Feature bloat in Perl (Score:3)
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.
And as far as threading is concerned, Perl is using threading in Win32 to allow ActivePerl emulate the fork command from *nix. That is something that should exist (free-threading is available in VC++ for all Win32 platforms), and I'm glad that I finally have it at my disposal.
Anyway, a rethink of Perl has been underway for a while. Look up the Topaz project [perl.com].
Lvaluable Subroutines (Score:3)
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.
---
Re:Feature bloat in Perl (Score:4)
But are you saying that a language designed to do one thing should forever remain just to do that one thing?
You think perl's OO features aren't elegant. I think the opposite - they so neatly fit into the language that it's hard to believe that they are so simple (bless $ref; # whoaa - it's an object now).
Perl does need a _bit_ of a rethink, but that rethink won't be to reduce perl back to just a reporting language - it will be to make perl more powerful. To provide threading or multiple interpreters from the ground up. To provide exceptions built into the core. To make compiled extensions a bit easier. To make classes have named attributes (not the monstrosity that is "use fields"). To make signal handling safe.
These things are being thought about, and are being dealt with, but don't expect miracles any time soon.
Re:More confusion (Score:4)
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....
Re:Feature bloat in Perl (Score:5)
What perl is today is the ultimate glue language. Via the modules available (both those shipped with perl and those available via CPAN) you can interface to practically anything (Most network protocols, data formats, APIs, etc etc)
To be honest, 'bloat' in the language is only important for two things:
1) Performance. This is fair enough, lighter interpreted languages will (probably) start up faster. Once the interpreter is running, though, I don't see why an (unused) language feature will impact execution speed.
Also, "premature optimisation is the root of all evil". Most perl scripts are 'fast enough'. Those that are performance sensitive (e.g. CGI under Apache) can generally be speeded up (apache mod_perl).
2) Language breadth. This issue seems to be alluded to by people elsewhere in this dicussion. The mindset appears to be "if a feature is in perl then I'll have to learn it to be able to maintain perl". I can understand why feature bloat is a worry if you think this.
Perl has a huge feature set. The key thing to understand is that you DON'T NEED TO KNOW THE WHOLE LANGUAGE (sorry for shouting, its my main point and this is a long comment - wanted to make it stand out
The point here is that you don't need to know that there is a language feature which will do your job in one line. If you know, you'll use it. If you don't know, you'll write 10 lines of perl instead. (or 50 or so in C to do the same job).
If you are maintaining someone else's code and they use a feature you don't recognise then you may need to look that up (the docs are good + install with perl). But the set of features you need to know is still not the whole language, its just the set of features which the author used.
Lastly, the number of features which can be abused to write unmaintainable code isn't really relevant. If a coder is sadistic enough to write unmaintainable code they only really need one or two language features (which all languages have).
Perl is not a panacea. However, instead of thinking "use the (one) right tool for the job" and learning C, C++, perl, python, java, scheme, eiffel etc, use "a good enough tool for the job" - which is often perl. Its easier to write in perl all the time and use a new feature than it is to learn a whole new language for every task.
Phew. Rant over.
Well _I_ happen to like Perl. (Score:5)
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.
Re:Lvaluable Subroutines (Score:5)
We often see the accusation that Perl is unmaintainable: I suspect that the blame lies with the coders, rather than the language itself.
Perl has a very handy construct that can render almost all code highly maintainable:
#
# it looks like this
#
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.
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.
Rob. (C++ and Perl coder, with an occasional dash of Python - Zope rules!)