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)
FYI - The Korean alphabet is based on arrangements of letters (Arranged as triplets of letters in a sqaure formation) rather than Chinese style Iconographs. This is however a recent (By Korean standards) innovation, and previously they used Chinese as a written language. The syntax and grammer of both these languages is pretty much the same, so Korean can be translated directly to Chinese and vice versa. As far as accesability goes, you are quite correct since most educated Koreans can read and write in both their native alphabet and the Chinese alphabet.
P.S. IANALinguist Either, but I do know a Korean English teacher.
Again, a nice attempt a trolling. I commend you. But you're wrong. ;)
WWJD? JWRTFM!!!
I heard about this improvement a while ago and was thinking....
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...
OK...the binary looks....interesting.....but what would you want perl handling binary for?
Who am I?
Why am here?
Where is the chocolate?
What is your Slash Rating?
This makes passing a whole bunch of flags easier too....almost like setting flags into a register in assembler....
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?
What is your Slash Rating?
Aside from the purely practical purpose of processing plural-byte datasets using perl programs, there exists a powerful punishment for the producers of the Obfusacated Perl Contest with this latest Perl permutation:
:)
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.
Want to learn about race cars? Read my Book
This isn't exactly what you want, but if the all-singing, all-dancing CGI module is too heavy for your purposes, then the CGI-Lite module may be better for you.
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!
Want to learn about race cars? Read my Book
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...
"Hot lesbian witches! It's fucking genius!"
Bhah! =) Threads must be burned (through the computeresque threads do have their uses...)
Of course, every Perl hacker likes Klah. It's a drink for true hackers!
but threading, compiling, lvalue subroutines sound like feature bloat to me. However I suppose *someone* must ned them.
Deleted
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.
Someone's got to explain me how this is supposed to be any better than passing references to scalars. I really really don't see the point.
C++ has had this for a very long time. A function can return a reference to a variable, therefore making its return value a lvalue:
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.
Subject: valuable Subroutines
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
Writing about music is like dancing about words - FZ
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).
Writing about music is like dancing about words - FZ
there has to be a first to everything, and here's my first whine about moderation. I go through the list of new 5.6 features, giving my opinion on each of them, and it gets moderated "redundant"? whatever.
Unicode (ISO-10646?) is, I believe, a superset of ISO-8859-1 (Latin1, which is itself a superset of ASCII); so all characters <0x100 (256:)) should be identical to their Latin1 counterparts, and, furthermore, those <128 function the same as they do in ASCII (ISO-646).
-rozzin.
Perl has a huge feature set. The key thing to understand is that you DON'T NEED TO KNOW THE WHOLE LANGUAGE
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.
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.
Of course there's more than one way to spell it... Why not Practical Extraction And Reporting Language? Why not Pathetic Excuse for a Real Language? It sure makes more sense to me...
Information wants to be beer, or something like that.
Perl has a very handy construct that can render almost all code highly maintainable: # # it looks like this # The same construct can be used to optimize and make the pearl code more useful. Just include the '#' at the beginning of each line in your script^H^H^H^H^H^Hprogram. Thank you.
Information wants to be beer, or something like that.
You claim (or rather, Larry Wall's) that PERL's learning curve is not steep simply doesn't stand ground. PERL is not only huge, it's syntax is complicated and full of bogosities that make it hard to understand. What you are apparently forgetting is that there is more to programming than just learning a "language". You have to learn APIs to interact with the underlying system, and programming models. C, and LISP especially, lay ou an easy path for you to do so. No so with Perl.
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.
Information wants to be beer, or something like that.
Well then, being pedantic, there is nothing specific to Perl 5.6 in this thread, and as I'm sure you must have noticed from reading them far and wide, most of the other threads in this comments section.
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.
Information wants to be beer, or something like that.
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. Well, with that kind of mindset I can actually agree, and I commend you for not being as single-minded as I presumed at first. Learning new things (languages, tools, APIs, things outside the realm of computer wizardry) is a great skill, useful not only in the practice of the craft but in everyday life as well. And the great thing about it is that it is generally a self-rewarding effort. Now, I wouldn't compare PERL to Leathermen, but rather to a weighty hammer with a handle full of knobs and sharp edges that hurt your hands every time you try to use it, but that is just a question of personal taste,I guess...
Information wants to be beer, or something like that.
Not to be pedantic, but that would only hold true for ASCII(ANSI, ISO-* etc) character systems. ;-)
Not that there's too many people running PERL on EBCDIC systems
Information wants to be beer, or something like that.
Dude, we've been able to do callbacks for a lot longer than the release of 5.6. I use them all the time. They're great when writing parsers:
/. removes formatting with preview...
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
$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.
use strict;
Always put that line in all your code. It will save you hours of headaches.
--strick9
Doesn't lwall work for O'Reilly? New features drive customer demand for edition++
Yep, Perl/TK
Oops, I meant to post the URL of the FAQ. http://www.lns.cornell.edu/~pvhp/ptk/ptkFAQ.html
Unfortuantely if you have not used perl long you have not been able to learn some of its pains. Such as new versions breaking code
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..."
Here's a simple question, feel free to respond sensibly amidst the flames...
:)
.|` Clouds cross the black moonlight,
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
--
~Tim
--
Rushing on down to the circle of the turn
will require your variables to be declared before use
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.
-!.
God did not appoint us to suffer wrath but to receive salvation through our Lord Jesus Christ --1Thes5:9
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?
. . . . . . .
may u!sh 2 sm!le at dz!z bad nn.!m!tat!ion
print scalar(('a'..'z')[int(rand 25)]);
Mark
actually the whole mysub thing is *very* useful and you'll see it in almost any object oriented language...
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
This space for sale
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.
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
At the grave risk of joining a religious war, may I make the following suggestion:
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.
Dave Blau
This post expresses my opinion, not that of my employer. And yes, IAAL.
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.
And lunch. Occasionaly, for breakfast.
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.
Obfuscated? No. Well documented language features used as expected. I find your condensation clearer than the 1st.
"Remember, any tool can be the right tool." -- Red Green
So I hope your not saying that your C++ example is so much easier than perl. I could just as easily write: $letter = chr( rand( 25 ) + ord('a') ); looks remarkably like your C++ example of: char letter = rand() % 26 + 'a';
-- Freedom means letting other people do things you don't like.
-- Freedom means letting other people do things you don't like.
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 :)
#!/usr/bin/perl
print "Hello World!";
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
There's also PerlQt
As for PHP, well, does anyone use it? I've never seen any evidence for its use on the net. Are you crazy? Try http://sourceforge.net for a start - one of the nicest appsites going. Go check http://www.php.net as well - I think they have usage stats from netcraft.
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.
No replies made to AC posts. Please log in.
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?
How do I get random lowercase letters like I would random numbers? @alphabet = ('a'..'z'); $letter = scalar($alphabet[int(rand 25)]); print "$letter"; Well, in C++ that could be: char letter = rand() % 26 + 'a';
Except you forgot to mention that my snippet is the whole program, and would run just fine, whereas, your code needs to be such:
/* whichever header(s) you want */
;) And I don't really think the C Code is any more readable or easier to understand...
#include
void main(void) {
char letter = rand() % 26 + 'a';
print "%s\n", letter;
}
and then gcc -Wall -o foo foo.c (click on Build in the menu, whatever you need to do...) and while you're doing that, I'm on the next project.
I stand corrected. (sheepish grin) Thank you for pointing out my error. Though embarassing, I have learned something. :) Kudos to you.
Gotcha. I still think that Perl is the ultimate glue language, that let's me do anything in ten lines or less. ;) There are still things that I don't understand about Perl, but I like it more every day that I use it. Take an example from PerlMonks:
How do I get random lowercase letters like I would random numbers?
@alphabet = ('a'..'z');
$letter = scalar($alphabet[int(rand 25)]);
print "$letter";
Now that is obfuscated, but I code clear that up and do it differently so it was easier to understand, comment it, etc. But to do that in C/C++ would take more code and Maalox. I don't expect Perl to be for everyone, but I certainly don't think that it loses anything by adding the new features.
Good one! I still have much learn. :)
Quite true Abigail, my mistake on the redundancy. I used 25 instead of 26 though because Perl arrays are 0 based, and when starting with 0, the highest subscript is 25.
:) I appreciate you taking the time to show me the error of my ways. Take care.
@letters = ('a'..'z');
print $letters[26];
produces nothing. but that is neither here nor there.
Of course, all the magic would have to be programmed in Perl. ;-)
Unfortuantely if you have not used perl long you have not been able to learn some of its pains. Such as new versions breaking code (yes it happens argue that it dont all you want but its happened to me in a VERY big way and I refuse to use Perl from now on.. Hava nice day) Love the language but larry wall is a psychopath and I think perl is an o-neat language yeah I know it drives most of the dynamic content on the web, but thats changing.. rather quickly.
Jeremy
Ok, I just bought the second edition a couple of weeks back. Does this mean I'm going to have to buy edition 3? I'm a newbie at Perl or at least compared to a lot of guys on Slashdot but its definetly worth learning... I guess my question is whether or not the new perl is radically different from version 5.
Nathaniel P. Wilkerson
NPS Internet Solutions, LLC
www.npsis.com
Nathaniel P. Wilkerson
www.haidacarver.com
sub cgisplit
{
use CGI;
my $q = new CGI;
my %param;
foreach my $key ($q->param())
{
$param{$key} = $q->param($key);
}
return %param;
}
Je t'aime Stéphanie
Threads which probably will be thrown away (the original one are no good either) A questionable compiler (for quite a while) I'm not impressed. Perl is no longer a 'glue language' it claims to be (TCL is). It is quickly becoming a BLOBware.
You have a lot of nerve saying that Larry Wall extends Perl without care or elegance. Are you the standard of elegance now? Just because it isn't the way you would do it, it must be wrong?
In case you haven't noticed, many large and complex systems are written in Perl. They use these features you find so worthless to write robust code that is easily shared among a large group of developers.
The beauty of Perl is that you can use it for your little throw-away scripts, and others can use it for powerful object-oriented server applications. That's flexibility, and practicality, and elegance. Keep up the good work, Larry!
The problem isn't perl's OO framework itself. The *real* problem is at a level below: references. Syntax for references in Perl was chosen to match the syntax for pointers in C/C++, with explicit referencing/dereferencing, which is too low level, for most of the stuff you want to do with Perl. Contrast this with the much cleaner syntax in Python/Java/almost all modern languages. Even "Perl luvers" admit that! Check the relevant section in Sins of Perl revisited> mentioning: "Doom and gloom" !
I think this is part of the reason few people (AFAIK) write classes in Perl, for normal, everyday code (I'm not talking about reusable modules going to CPAN). Creating a (usable) new class is such a hassle...
Though your opinion on the feature additions themselves is not unreasonable, your assumptions about the process by which they came to be is entirely mistaken. As a rule, new ideas for Perl undergo scrupulous examination regarding their impact on usability, learnability, maintainability, backwards-compatibility, aesthetics, Perl-ish-ness, and performance. There is a strong anti-change sentiment among Perl hackers. The ordeal that would-be enhancements much survive is daunting indeed.
And on top of that, there remains the Larry test, which has proven spookily discerning.
Your claim that Larry "never considered these issues" is ignorant and frankly offensive. Similarly for the other Perl developers. Read what Larry has written about Perl, or look up the history of Perl 5 development. To see the process in action, read perl5-porters for a bit. (But arm thyself against flames!)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Perl has a very handy construct that can render almost all code highly maintainable:
#
# it looks like this
#
I think the problem is that we should try as much as practical to say things clearly in code rather than in comments. From the little Perl code I have seen so far (I don't do Perl) it is not easy to infer what the code does. The comment you answered to seems to address this problem and the fact that some enhancement in the language has rendered it even more cryptic, at least potentially.
This may not be an issue for those fluent in the language, but this cryptic character certainly demotivates those who consider learning it.
Before some oyster-minded zealot flames me, I want to point out that this comment comes from someone who is trying to get rid of a nasty habit, namely using one single tool to do just about anything. That happens to be C++ in my case (besides HTML obviously). The wide acceptance of Perl was an indicator that it could be an excelent complementary tool to C++, but this syntax issue is really an obstacle.
By the way, I guess the answer to the subject question must be something like:
# This outputs "Hello world!" to the console :)
&^%$[]"Hello world!"\\!@
#
I'm afraid this will be lost in the noise or will be too far down the list for anyone to care, but I remember hearing something a while back about a version of Perl or an add-on library for it that allows one to build GUI applications. Does anyone know anything about this?
Also, I'd like to thank Slashdot for advocating the use of Perl. It's truly a kick-ass language! I love how full-featured it is. When I'm programming an ASP website in VBScript, there's so much I can't do. Simple stuff, like writing a binary file to the server's hard drive. In ASP, you need to buy a damned third-party component to do it. In Perl, the functionality for that, and so many other tasks, like ripping content from other websites, is built right into the language.
I can even write a little auto-downloader for MP3s that will log onto a FTP server and keep trying until it finally gets in and downloads. And, I can extend its functionality easily, like adding support for a list of URLs to download from. In C, that would take forever to write. In Perl, it's a snap. I once wrote a small web server in C. It worked well, but handling and parsing all those strings was tricky. Now, if I port it to Perl... When I get back to work on Tuesday, every computer I use regularly will get Perl installed on it.
Anyway, that's enough gushing over how great Perl is. How about this graphical Perl? I'd love GUI Perl programs!!
"All the sounds that human beings make," you ask? And what would we do with this Mythical Phonetic Language Complete? We'd still have to convert it into something usable by human users. The issue is not that we need that many characters, but that we (as a world) use that many characters. Besides, Unicode's a lot easier to implement that your MPLC.
The point is, there are problems which existed before computers, and problems that arrived after the invention of computers. In my view the human voice is incredibly diverse and complex, and judging by the sound of the voices of great singers, without hard limits.
Unicode is a compromise. It's use implies, "we're not gonna bother with an uberlanguage, we just want our string handling algorithms to still work." It is impressively unambitious, a logical evolution of character-handling.
You don't have a decent gripe. You can't get a linguist to do a coder's work.
Maybe the reason the Japanese and Koreans are familiar with Chinese pictograms is because the Chinese civilization is about 5000 years old and they've been given plenty of time to assert their memes in that part of the world? I mean, why do you think the Canadians speak American? ;)
Seriously though, your idea that the design of a written language has something to do with its application is interesting, but I don't think it's applicable here, because most people were illiterate in antiquity. In ancient China the ability to read and write was a pursuit of the scholarly and noble, so it's use as a tool for managing an empire was limited.
I suppose it was useful for maintaining a bureaucracy over distance, but there the time needed to transmit such written messages would also limit the written word's effectiveness. There, the autonomy feudalism afforded, the unifying force of a deified emperor and the might of the sword would probably be most useful.
Your asserion that:
is just plain wrong. It doesn't make sense to define "word" so narrowly. A word is more than a sequence of particular characters. A word doesn't have to be exactly the same to be understood by speakers of different languages.oral style defeats pictogram style.
I have to disagree with this (and IIRC, so does Mr Wall). Unix's philosophy is "the whole is greater than the sum of the parts" -- use pipes and simple utilities that work better than one monstrous and utility to handle weird cases. If it's a trivial job, I can use sed, awk, grep, sh, cut, etc. and a couple pipes to do the job in one line. If it's not so trivial, I'll use C. Perl has its place & lots of people use it, but it's anti-unix.
According to an old book I saw in a library once, there is/was a programming language from the 60s/70s called "Pearl", which I assume predates perl :-)
Apache is much better featured web sever thant any other , even for application development is better than domino and IIS.
The thread stuff will allow people run it inside WinNT, in places where linux is banned by policy.
For answers to this and all of your other Perl questions that have been answered a quadrillion times before, see the Perl FAQ here, look in your distribution, or man perlfaq.
Adios
Does AOL really allow Hyphens now?
"spare the lachrymosity when the fulminations have inveighed"
-madd
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
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.
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
*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.
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.