Slashdot Mirror

The perl5-porters list has already been hit by this virus resulting in 200+ messages being posted over a period of two to three hours yesterday. Additionally, it was reported on this list by Elizabeth Mattijsen on this list here that the Gnome XML list has similarly been affected.

Nonsense. There's plenty of perl programming going on. Particularly if you are in NYC, Cali, or London. Hell, I make a pretty decent living hacking up perl. (Kind of like a hairball, but more spagetti-like ;)

From the Perl 6 development webpage:

Yes, but keep in mind that this page was written by the people who initiated the current incarnation of Perl 6 in mid-2000. At the time, they thought they would have a release within 18 to 24 months, an estimate which now seems to be off by a factor of at least 2x, probably more.

This is, IMHO, the big issue with "big bang" rewrites: even if you ultimately end up with a superior product (which, IMHO, Mozilla is compared to Netscape), you often kill the momentum of your product for several years, and once the new product is out, it may not be nearly as relevant as it was projected to be.

• Case 1: IPv4 vs IPv6 - IPv4 with NAT presents all sorts of complications and problems when trying to implement IPsec. Not least are the problems of NAT traversal which have only partial solutions available in the form of the NAT-T patches for linux-2.4 and are integrated into linux-2.6 and which can't do AH. Even if this is sorted out then there are still problems with MTU sizes leading to fragmentation as the result of protocol headers being layered within each other. IPv6 avoids these problems.
• Case 3: Perl 5.x vs Perl 6 - Perl6 development is tied to the fact that the interpreter was hard to maintain due to the structure of Perl5. So, in order to maintain the interpreter and continue to make incremental developments (as the author wishes) it's necessary to clean house. There is also the desire to keep developers (people that can make improvements) involved by allowing interesting new ideas to be incorporated (such as Parrot: a multi-language interpreter)
• Case 5: Netscape 4.x vs Mozilla - Well, I run mozilla on a 466MHz Celeron with 196Mb RAM and I don't see the speed difference that the author talks about.
• Case 6: HTML 4 vs XHTML + CSS + XML - There's no question that CSS and XHTML make webpage scripting easier and cleaner. Thank god for these developments. The author makes no substantive argument here

From the Perl 6 development webpage:

"The internals of the version 5 interpreter are so tangled that they hinder maintenance, thwart some new feature efforts, and scare off potential internals hackers. The language as of version 5 has some misfeatures that are a hassle to ongoing maintenance of the interpreter and of programs written in Perl."

For me, this is a necessary and sufficient condition for rewriting something.

Another one is: When changing the original will take longer than rewriting from scratch.

I advise keeping them all in /usr/local, then, which is its stated purpose in most distributions. I'm a Perl programmer and always do my own installation of perl in /usr/local so I can manage modules and upgrades myself.

I would hope that this new Debian installer tool respects /usr/local. I would think that even then you'd still probably have issues with package-managed library dependencies.

Was this written by MarkovBlogger?

I haven't used it yet but the next time I need to crunch a lot of data, that's the first thing I'm going to try. The expressivity of Perl along with strong matrices and decomposition? That could be quite choice.

We're in an exciting time when many of the scripting languages are being augmented to be able to handle Real Data (Numpy is another example).

This is great news that Compiere finally went DB-independent. As a Perl DBI/DBD user I find DB-independence almost a prerequisite for any software I use, almost as important as its free software license. (Still, I'd like to see SQLite support, my favorite DB-apps prototyping DB.) Now, when it doesn't depand on Oracle any more, I will probably finally install it in my lab. How is PostgreSQL and MySQL comparing to each other speed-, flexibility- and security-wise? Which one would you suggest using with Compiere? Is that true that with MySQL Compiere is faster for the most simple tasks, but anything more than that requires PostgreSQL, which is slower in the short run but better choice in the long run? I'm asking because I want to have a flexible and long-term maintainable solution, where performance (via the hardware budget) is one of the most important factors, and the best security is a must. Thanks.

No, I know how to spell Randal. However, I can't say that I disagree with the sentiment of that poster. Only you could take an editorial gaffe or a simple request to remove pictures from your website and turn it into a "they're picking on me" kind of whinefest just to draw attention to yourself. Considering how rushed to press this hefty book was, I'm surprised there aren't far more glaring problems...at least Tom and Gnat know how to spell your name, unlike the reviewer. Changing your name to Dirtbag Q. Bosche might help that problem though.

You get what you give in this lifetime.

e.

Mono makes it easy to give access to all kinds of .net libraries from inside Parrot (the new high power VM for Perl and probably Python and Ruby.) And it makes it easy for Parrot to add the ability to turn perl code into .net code (I think. does anyone know how much mono code is being used in parrot?).

Mono makes it easy to give access to all kinds of .net libraries from inside Parrot (the new high power VM for Perl and probably Python and Ruby.) And it makes it easy for Parrot to add the ability to turn perl code into .net code (I think. does anyone know how much mono code is being used in parrot?).

Mono makes it easy to give access to all kinds of .net libraries from inside Parrot (the new high power VM for Perl and probably Python and Ruby.) And it makes it easy for Parrot to add the ability to turn perl code into .net code (I think. does anyone know how much mono code is being used in parrot?).

Mono makes it easy to give access to all kinds of .net libraries from inside Parrot (the new high power VM for Perl and probably Python and Ruby.) And it makes it easy for Parrot to add the ability to turn perl code into .net code (I think. does anyone know how much mono code is being used in parrot?).

SQLite is tiny, fast and ACID compliant. SQLite is a public domain embedded SQL database library. It is similar to BDB, but provides a complete SQL database.

Let us not forget about DBD::SQLite [cpan.org] — a DBI [cpan.org] (Perl [perl.org] Database Interface) driver which, not being a driver per se, includes a *full* SQLite distribution, so when one needs to use SQLite in a Perl program, one is only perl -W -MCPAN '-einstall"DBD::SQLite"' away from $dbh=DBI->connect(q(dbi:SQLite:dbname=dbfile)); which is truely amazing.

Perl significantly predates the web, so your hypothesis as to it's origins is incorrect. It did originate from Larry Wall's time at the NSA in the late 80s.

Java is just a knife. Perl is the Swiss Army Chainsaw.

See also:
- perl.org
- cpan.org

Actually, I've been waiting since this morning to see if this would be confirmed on slashdot or not.

Also, if you'll look around, the exploit is understood, and patches seem to be available, at least according to posts here.

Scientology is also doing something to make Earthlink (their ISP) come up high on many religious searches. Drives me nuts.

This is a common misconception by geeks who are smug because they didn't get infected with Sobig.

Sobig didn't use any exploits. It was just a plain old .EXE attached to an email. Outlook prompted the user when they tried to run it telling them that exes often contain viruses. But they still ran it.

This behaviour is the same in Thunderbird and other windows mail clients. It's even the same in Apple's Mail.app.

Don't be a bigot and assume you're immune because you don't run Outlook.

PDL ("Perl Data Language") gives standard Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing.

PDL turns perl in to a free, array-oriented, numerical language similar to such commerical packages as IDL and MatLab. One can write simple perl expressions to manipulate entire numerical arrays all at once. For example, using PDL the perl variable $a can hold a 1024x1024 floating point image, it only takes 4MB of memory to store it and expressions like $a=sqrt($a)+2 manipulate the whole image in a few seconds.

PDL ("Perl Data Language") gives standard Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing.

PDL turns perl in to a free, array-oriented, numerical language similar to such commerical packages as IDL and MatLab. One can write simple perl expressions to manipulate entire numerical arrays all at once. For example, using PDL the perl variable $a can hold a 1024x1024 floating point image, it only takes 4MB of memory to store it and expressions like $a=sqrt($a)+2 manipulate the whole image in a few seconds.

PDL ("Perl Data Language") gives standard Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing.

PDL turns perl in to a free, array-oriented, numerical language similar to such commerical packages as IDL and MatLab. One can write simple perl expressions to manipulate entire numerical arrays all at once. For example, using PDL the perl variable $a can hold a 1024x1024 floating point image, it only takes 4MB of memory to store it and expressions like $a=sqrt($a)+2 manipulate the whole image in a few seconds.

Unfortunately my spider program was going pretty slowly since I couldn't get asynchronous I/O to work properly, so I abandoned the idea.

In some ways, Apple sucks. If schools were to lose just one platform, it should be Microsoft. If schools were to switch to a monoculture, it should be a Linux distribution (for the felxibility that gives). However, I firmly believe that schools should teach as many systems as practical for the important lessons to be learned therein, including the Greatest PERL Lesson: TMTOWTDI. (-: Note that I say this as a near-non-PERL-programmer :-).

The Greatest PERL Lesson is a more important thing to know (not just hear occasionally) than most if not all of the entire high-school courses I can remember.

Schools really should be teaching principles, not single-obsolete-system recipes. That way when the systems they were taught on are obsolete, the students aren't left high and dry, a herd of one-trick ponies - and The Greatest PERL Lesson will continue to serve them well in area's they not yet faced, perhaps in areas that don't yet exist. The "How to produce greeting cards in MS-Publisher 101" course won't even make a dent in that.

Ten years of having a pickle up their ass about inane and retarded things!

For me, it came down to documentation. I have a moderately complicated GUI Perl app (Perl because it was the language I was most familiar with). I looked into various toolkits, like wxPerl, GTK/Perl, QT/Perl, but ended up using good ol' reliable Perl/Tk.

The big advantage with picking up Perl/Tk was that the O'Reilly books were extremely informative - good examples on each widget, how they interoperate, how to use them, and larger program examples. The documentation for the other toolkits I considered basically consisted of "look at the arguments this C++ function takes, and use it," which didn't make for an easy time picking things up (wxPerl was the worst in that regard). While an experienced C++ programmer might not have a hard time with that, it was way over my head.

As a result, though, I have a decent app that runs on X11 and Win32. With the great PAR archiver, I can even package the app up in a nice bundle.

Good times.

The book is far better than the relevant perldocs when it comes to _learning_. For reference, the perldocs are great, but for learning? No. Not even the tutorial ones.

On the other hand, there's this book (the alpaca) and the llama. Together, they get you from knowing nothing about perl, to being able to write your own modules/classes and releasing them on CPAN with tests.

If you need _more_ information than the books give you, or want to know precise details on the perl you're using, or you want a _reference_, then perldoc.

Anyway, I can only assume you haven't read most of the other Perl books out there (but with over 100 of them, not counting just ORA, that's probably not too surprising). Many of them either extend the perldocs, or they present friendlier text.

There are quite a few duds, but there are also quite a few excellent books.

There are certainly hashes in Perl 1. See hash.[ch], for example.

Did you file a bug report for your Makefile issue? Richard Clamp is maintaining this version.

Parrot's been around two years, not three. The oldest Perl 6 code I can find running on Parrot goes back one year.

Perl 6 isn't completely implemented on Parrot because Perl 6 isn't completely designed yet. Perl 5 isn't completely implemented on Parrot because no one's had the right combination of time, talent, and funding to implement it yet. The same goes for any combination of Perl and Parrot you care to mention. As of last month or so, there had been somewhere around five man years of Perl 6 and Parrot work funded.

Paying one developer to work on Parrot for a year and a half would double the amount of full-time contributions.

The parallels to Mono and DotGNU are inappropriate. Not only are they reimplementing something that's already been designed and implemented once by legions of funded developers at Microsoft, Ximian pays people to hack on Mono.

• Synopses, which are shorter and quicker to market.

The names are a running gag on church-latin, that interconnects Larry's linguisticism, Damian's eclecticism, and the monastic themery of the Perl Monks' alternate retroynm for .PM. Larry's Apocalypses are not apocalyptic in the common figurative sense (although the neo-Luddites who think the only improvement on Perl5 is PHP or Python may think so), but are the Revelations of the gur, which is the original sense of the word, before it came to be used to refer to the particularly apocalyptic content of St.John's Revelations also called Apocalypse in the latin. The churchly Exegeses are non-canonical explanations of the deeper meanings of the canonical texts. And of course, synopses are shorter summaries, like Cliff Notes (TM) or Master-Plots (TM), and were originally applied to religious writings of course.

require sig 1.3;

• Everyone in the world had a chance to submit RFCs
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
• Eventually, this will lead to the Design Documents

• Everyone in the world had a chance to submit RFCs
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
• Eventually, this will lead to the Design Documents

• Everyone in the world had a chance to submit RFCs
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
• Eventually, this will lead to the Design Documents

• Everyone in the world had a chance to submit RFCs
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
• Eventually, this will lead to the Design Documents

• Everyone in the world had a chance to submit RFCs
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
• Eventually, this will lead to the Design Documents

Turn my world upside down, hurt my brain, then expect me to shell out .... Oh. Only 18 bucks? Ok then. Never mind.

Turn my world upside down, hurt my brain, then expect me to shell out .... Oh. Only 18 bucks? Ok then. Never mind.

Hey, I ran into the same bug today, and it is being fixed.

Enjoyed reading your very informative explanation of copyright history (and I knew to hit reply to get the rest, too).

I dunno, the response to lini's question scares me.

So the best case scenario is that understanding Perl 6 programs written by gurus will require knowing the syntax of a bunch of other Parrot languages? Allowing you to write gluable libraries (like .Net) is one thing, but intermixing languages is just evil.

Try here or here.

Just trust that there are many talented people working on Perl 6.

No. (yes i know it's an old joke)

Mr. Shoe-Bomb also failed

There was a Perl programmer on that flight.

I hope you haven't seen this yet. It'll really boil your blood.

Can I just say that I really like Larry Wall? I mean, reading that document, I realize that he is sooo good for Perl culture. You won't hear "that's how it has always been done" from him. His focus is on how to build a better system, not politics, not grandstanding. I would be very happy to see this kind of openness and disarmingly reasonable attitude influence certain other people in the Perl community.

Of course, I could be extrapolating too much, and it could be he's a PITA, but I've read his comments/posts/articles a few times over the years, and he's been this way each time.

Even though the perl regexp's tend to be the de-facto standard, the perl people are frequently adding stuff to their regexps.

Damn those Perl people and their innovations. Why can't they just be happy doing everything the familiar, crappy way? Why must they push the envelope to make things easier and better? I hate that.

PS. I hope you haven't seen this yet. It'll really boil your blood.

I'm currently debugging some Ada code at work that was written by a primarily-C programmer. And believe me, this sticks out like a sore thumb in his code and makes it hard to read even though I am "fluent" in both Ada and C.

Perl doesn't teach bad programming habits. Perl just allows bad programming habits to a somewhat higher degree than other languages. There is a big difference. C allows more bad programming habits than Ada, but you don't see people shunning C, do you?

Perl was designed to read almost like english if you write it properly, which I (having english as my first language) think makes it very easy to read. Especially look at some of the powerful constructs in Perl 6. Stuff like regexps are even easy to read when accompanied by appropriate commenting.

Perl written by a good perl programmer is the most maintainable out of any language I have worked in professionally. On the other hand, perl written by a bad perl programmer is the least maintainable out of any language I have worked in professionally.

Same goes for english or any natural language. A five year old may speak English very poorly, but you don't see people blaming that on the language itself.

Perl fast facts

Perl stansds for "Practical Extraction and Reporting Language". Invented in 1987 by Larry Wall, it was originally used for in system maintenance tools for UNIX, mostly parsing logs and foramatting the results for display on the screen.

Ideally, one would never want 100 PCs to deal with. I've worked in such environments before, and there are constantly parts breaking, etc, - its just a major headache. Thin clients with no moving parts are a much better solution. Check out this article on Largo, Florida, and the link to the original article:

http://newsforge.com/article.pl?sid=02/12/04/234 62 15

However, suppose you already made the mistake of buying a big pile of PCs, so you want to make use of them until you migrate to something that makes more sense. Rolling out Linux on them all would be relatively painless, and there are numerous ways of doing this. One method would be to go with the Linux Terminal Server project:

http://www.ltsp.org/

Supposing you want to keep the "PC" model, because, say, you don't have the network or server resources for a central login server setup, then there are many ways of rolling out a group of linux PC installs as well. Here's an article that discusses some of them:


http://www.linux-mag.com/2002-12/cloning_01.html


In UNIX/Linux, by default, normal users do not have the ability to modify the system. They have authority only over their own home directories. There is a great deal of security measures that one could take to "lock down" the system to a far greater degree than the average defaults, but the default configuration for most distributions likely offers more protection to the systems integrity than a professionally locked down Windows box.

You can set up Linux in several ways for centralized system accounts and authentication, to achieve, in effect, the type of "domain-like" logins that you are used to in Windows. LDAP servers are a great mechanism to do this (LDAP is actually the protocol on which MS DS is based).

There are numerous ways to centrally manage all of the software installs, configuration files (which determine all system settings), etc., on a network of Linux machines. Linux/UNIX philosophy is that tools are made to be simple and flexible, and to work easily with other tools. This gives the administrator the freedom to set things up the way s/he sees fit for his/her specific environment. Rsync is a good example of a tool with remarkable flexibility for keeping files in sync: http://rsync.samba.org/index.html

Perl has infinite potential and flexibility in systems management. http://www.perl.org

Cfengine is a powerful distributed configuration system: http://www.cfengine.org/

So basically you can patch together a system that works best for you. There are hundreds, maybe thousands of tools that you can use. Many of them are built in, others you might have to download and install.

If you want a commercial "out-of-the-box" management solution, those are available too. Ximian's Red Carpet product is an example of centralized package management. I think I read that Novell was working on some type of management software... I've never looked into commercial solutions, since the free & roll-your-own ones are more than sufficient for me.

As for your quip about no support and problems with drivers - that just shows your lack of experience with the platform. Support is generally a lot better with open source software than it is for commercial software, and its usually free. As for drivers, wouldn't you check to make sure they exist before buying the hardware? Chances are extremely high that any hardware you have in the enterprise today is fully supported in Linux. Its the bleeding edge, just released this month gaming hardware that isn't.