Slashdot Mirror

Epic leaks? For the better part of a decade?

not sure, but that may be out of date: http://www.perl.org/about/whitepapers/perl-ipv6.html

Of course, that doesn't help me, because my now former ISP was Qwest and they had a "we will never support IPv6" policy, so until CenturyLink (the purchaser) replaces all of the old hardware, I am SOL for my website and browsers (no, I'm not setting up a tunnel - I have better things to do with my time than figure that out). Setting my web server up will be easy when they add it - just update the DNS server entry (since even my DNS provider supports it). If I didn't hate Comcast or XFinity or whatever they want to be called with a passion I may have switched back, but DISH has been way too nice. On a scale of 1 to 10 my customer experience rating with Comcast: 1, with Qwest 3, with DISH 10. Note to CenturyLink - learn something from DISH, fix the broken that was Qwest, and avoid being Comcast except from a network performance level.

First, we've known for many years that IP-level techniques can deal with a lot of spam. For example, using the Spamhaus "DROP" list in perimeter devices is so incredibly effective that anyone who isn't doing it may summarily be declared incompetent. As another example, perhaps more germane to this paper, see http://use.perl.org/~merlyn/journal/17094 -- which demonstrates how to use passive OS fingerprinting in the BSD pf firewall to throttle traffic from Windows systems. (I presume everyone is well aware that bots are nearly always hosted on Windows systems; my own research indicates that despite inroads by attackers into non-Windows hosts, the probability that any given bot will be found to be on a Windows system is still comfortably above 99.999%.) The technique shown by poster "merlyn" in that example from 2004 can readily be extended and combined with others.

Second, 95% true positive rate is impressive for a single measure, BUT we must also consider the false positive rate, and we have to consider the resource cost necessary to achieve this number. Frankly, doing this inside SpamAssassin is very inefficient -- this is a function that can be handled either in the firewall or in the MTA, or perhaps in a combination of the two. There's really no need to invoke something as heavyweight, slow and complex as SA. (Nor is this desirable: the more complex the anti-spam architecture, the more difficult it is to tune properly and the more susceptible it is to gaming.)

Here's the TL;DR version: if a host passive-OS-fingerprints as Windows then it's suspect. If it does that AND (lacks rDNS OR has generic rDNS) it's a bot.

I have to agree. Mono should have been a liberation path _outside_ of .NET. languages and run-times are plentiful in the OSS world, with almost all working the same in Windows, Mac OS, Linux, BSD, Solaris or whatever you what to use (barring iOS, that is). We have dynamic and static languages, compiled and interpreted, imperative and functional, new and well stablished. Hell, we even have executable line-noise and white space!

By the way, I have been told that Vala is very nice for people coming from C#, as it's based on it, but runs faster because it's compiled to native code.

Sorry I expected more than you prompted with the quote.

Running perl -Dx (perl must have been compiled with -DDEBUGGING ) dumps the Perl op code tree that perl compiles the script into. There is some discussion of the architecture, some discussion of the tree, a example walkthru and some documentation of the facility, as well as work using the system.

But it looks like (especially in the last several years) more "Perl call graph" work focuses on lexically parsing the Perl source. Which to me seems a great waste of this fascinating facility. Even though the graph is of a stack machine, not dataflow exactly, it seems like an interesting facility to target with a graph editor.

I just wish Perl 5 had a good OO system.

Try Moose.

I think one has to be programming Perl for 40+ hours a week, in order for their mind to stay fresh enough in Perl...

I think you have to understand the two underlying philosophical notions of Perl and know how to use the documentation to use it effectively. The book Modern Perl (I wrote it; electronic versions are free) explain those straightaway.

Note for the ignorant... that REALLY IS what it stands for!

Heh. Note to the ignorant who want to not be so and don't have a Camel book handy: No it isn't. At least, not exactly.

The "official" expansion is Practical Extraction and Report Language (the 'a' formerly being part of the acronym when it was briefly called 'Pearl'). "Official" is in quotes because there really isn't an official-official expansion, and Larry Wall wanted the name to inspire a variety of acronym expansions. But this is the one you'll see in the documentation.

Pathologically Eclectic Rubbish Lister is just one of those other expansions the name inspired, and is often used by Perl aficionados (including Larry Wall, who I think coined it) as a term of endearment for the language and it's eccentricities.

So you could say "[Pathologically Eclectic Rubbish Lister] really is what it stands for", and be right, but it's in a metaphorical sense similar to how one might say "Ford really means Fix Or Repair Daily" (only in this case it's affectionate instead of insulting).

Yes it was Perl 4, which is one of the flaws in this study.

Perl has regexes. It also has a really twisted OO system -- elegant in its own way, but I don't know why you'd choose that if you have alternatives. It has ugly syntax, even when you know what you're doing. Anti-patterns are the default -- like, say, ignoring errors unless you explicitly handle them.

This criticism that used to apply 15 years ago, but is not really relevant anymore. The Perl community has gone to great lengths to address these things.

For OO, nowadays there is Moose, which is an excellent and extremely capable OO framework for Perl. Please check it out if you like.

For the anti-patterns, please note that strict mode is now the default on Perl 5.14 and I cannot think of a modern library ignoring errors by default. The error ignoring behavior is there for a bunch of built-in stuff that needs to maintain compatibility with old code, but you can, and are encouraged to, include the autodie pragma to change even that behavior.

About the syntax, it's probably a matter of personal taste, so I can't say anything about that. But I believe that personal taste doesn't have to do with whether you know what you're doing or not.

Lastly, writing Perl doesn't mean that your code has to be ugly and error-prone. May I suggest Damian Conway's Perl Best Practices, which IMHO is an excellent book with recommended coding practices.

Hope this helps!...

Perl has regexes. It also has a really twisted OO system -- elegant in its own way, but I don't know why you'd choose that if you have alternatives. It has ugly syntax, even when you know what you're doing. Anti-patterns are the default -- like, say, ignoring errors unless you explicitly handle them.

This criticism that used to apply 15 years ago, but is not really relevant anymore. The Perl community has gone to great lengths to address these things.

For OO, nowadays there is Moose, which is an excellent and extremely capable OO framework for Perl. Please check it out if you like.

For the anti-patterns, please note that strict mode is now the default on Perl 5.14 and I cannot think of a modern library ignoring errors by default. The error ignoring behavior is there for a bunch of built-in stuff that needs to maintain compatibility with old code, but you can, and are encouraged to, include the autodie pragma to change even that behavior.

About the syntax, it's probably a matter of personal taste, so I can't say anything about that. But I believe that personal taste doesn't have to do with whether you know what you're doing or not.

Lastly, writing Perl doesn't mean that your code has to be ugly and error-prone. May I suggest Damian Conway's Perl Best Practices, which IMHO is an excellent book with recommended coding practices.

Hope this helps!...

Anonymous Potty-mouth, it would be better to thank Larry Wall and Randall Schwartz, makers of Perl, for that. Larry even has his own interpretation of the GPL regarding code written in Perl or linked to it.

This is a clear example of folks not really knowing what they're talking about.
Perl6 is a language spec, not a language implementation. Check out Rakudo if you want to see an implementation.

Even so, Rakudo (and any other Perl6 implementation) is *not* the successor to Perl5. It's an unfortunate naming scheme that people don't understand, and although there are similar and borrowed elements between the two, they do not directly relate to each other.

If you want to see activity, check out web frameworks like Mojolicious (http://mojolicio.us), or installation tools like Perlbrew (http://perlbrew.pl). There's also plenty of activity going on @ sites like: http://blogs.perl.org/, http://ironman.enlightenedperl.org/, http://perlbuzz.com/.

Not to mention plenty of jobs always coming across the wire @ http://jobs.perl.org/. Which, interestingly enough, some rubyists copied - http://jobs.rubynow.com/

This is a clear example of folks not really knowing what they're talking about.
Perl6 is a language spec, not a language implementation. Check out Rakudo if you want to see an implementation.

Even so, Rakudo (and any other Perl6 implementation) is *not* the successor to Perl5. It's an unfortunate naming scheme that people don't understand, and although there are similar and borrowed elements between the two, they do not directly relate to each other.

If you want to see activity, check out web frameworks like Mojolicious (http://mojolicio.us), or installation tools like Perlbrew (http://perlbrew.pl). There's also plenty of activity going on @ sites like: http://blogs.perl.org/, http://ironman.enlightenedperl.org/, http://perlbuzz.com/.

Not to mention plenty of jobs always coming across the wire @ http://jobs.perl.org/. Which, interestingly enough, some rubyists copied - http://jobs.rubynow.com/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

I think Perl is a fantastic language--in fact it's my favorite language of all time. Heck, I just released a new tool at my work last week using Perl and CGI to help organize about 4 years worth of file changes from an active CVS archive into relevant categories.

Perl's not a language for the faint-hearted, however. It is not a language you sit down and instantly you have a webpage going--which is what most people want to do these days when it comes to casual programming. For that, PHP and Ruby seem to be a lot more accessible.

I've been using Perl for over ten years now, and I find that I'm still learning something new about how to use the language in fascinating ways--pretty much every day. Nothing compares to Perl's community. You can talk with experts daily if you like, on sites like http://www.perlmonks.org/ and the documentation is all accessible at http://perldoc.perl.org/ or with every install of perl by just typing perldoc... I love how easy it is to move data about. It really was the first language to fully incorporate hashing as a basic operator and though variable sigils confuse a lot of people used to simpler programming languages, such notation allows for some amazingly flexible operations without the need to create lengthy method calls for every basic operation on your data structures. In Perl every symbol has specific/distinct meaning and interoperates with all others, and those combinations make for some very powerful programs with few lines of code--like how you can load full hashes by acessing them with the array operator as hash slices... and who can compare to Perl's enhanced regular expressions, especially the latest from v. 5.12...

Anyhow there are languages for the pedantic, there are languages for your project managers and your CS grads, and for your code-generators--or for outsourcing to India, and then there's languages that really get your inner geek going... and Perl definitely reigns supreme for my inner geek. :)

In fact, Some people call it magic.

The biggest problem with making a mysql compatibility layer on top of postgres is dumbing down the whole interface to be compatible. It would involve removing so many items and breaking many standards. You might as well just keep using mysql in the meantime while you port your app to postgres.

And... the whole point of a compatibility layer is so that you can either 1) run your whole app as-is and keep developing as-is on the layer on top of the system. So now you have zero gain from moving to postgres, you're still using the same old cruft... or 2) you want to run some code in the compat layer and some code in the native layer. Now you open up a whole huge can of worms. Now you need to specify which tables/functions/etc are running in which platform, the screwy mysql one, or the real postgres one. Unforeseen interactions between the two would be full of fun surprises I can assure you.

Off the top of my head I can think of a few horrid problems with mysql that would have to be ported. Silent truncation for instance. Insert 30 characters into a 20 character field and mysql will gladly accept it, and not even throw you an error. Now there is a flag you can turn on that will give you errors on some of these issues, but not all of them.

There's several other silent behavior type problems in mysql that would need to be ported over. See: http://code.openark.org/blog/mysql/but-i-do-want-mysql-to-say-error

There's a bit of a history of silently doing nothing with bad data, or silently doing nothing when there's a problem in general. See: http://use.perl.org/~Smylers/journal/34246

This next writeup is a year old, and obviously some shortcomings of mysql have been fixed up... but many of these issues still remain. The issues listed that have not been fixed.... and then some, would have to be ported.

See:
http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009

In conclusion... why waste time in porting such an array of limitations and buggy behavior to such a great platform.

You might say 'but EnterpriseDB is an oracle layer on top of Postgres'. Yeah... Oracle... a real database, not mysql.

The internet isn't really a place to gain an informed opinion over things.

Yes, you are correct. Opinions should all be tossed out. Pure info is what the Internet is all about. Pick a language and a FOSS project, develop away, it's a great learning process that I've found much more "educational" than formal education.

Teach yourself C++: C++ Annotations, C++ Language Tutorial... ... or Perl: Perl programming documentation, or JavaScript,
or Java.

Just search the web, you'll find everything that any professor will ever be able to teach you online. Need guidance, clarification, or to ask a question? There are free online forums for that too... Yes, the Internet on average, much like the FM band, has more signal than noise, but similarly you can easily tune your into the signal you need.

Consider this: My Java "professor" gave an assignment where we read in rows of data from standard input, and output the table sorted by a certain column's value. He offered extra credit for proper alignment and justification of the table's cells... "WTF? Really?", I thought.

I used the Collections framework along with Swing to provide a GUI w/ sortable & justified JTable columns instead of doing character counting and sending extra spaces with the text to the standard output. He gave me a C. Another student used the Formatter to provide printf style formatting... also got a C, WTF! Go beyond the prof's teachings & expectations to meet a requirement, get a poor grade... That's dumb and counter productive.

In the real world, you try not to re-invent the wheel, this college course was not teaching practical programming; It was so far beneath what I learned already online, on Java's own website, I dropped the course (waste of time). Sure I can write a merge sort, or programatically align console text output, but that was not what the assignment said: "Provide a tabular output sorted by the 'Name' column." We learned merge sort 2 weeks prior, but the "professor" would not move on.

Not having a "degree" myself, I frequently answer questions that "Degree" holding graduates ask in online forums... Why? Because they didn't learn what they needed to know in their courses.

You would be hard pressed to find a programmer that doesn't have some form of documentation open in another window, screen, or context menu while coding. IMO, besides learning about algorithms and complexity, the language specs & online tutorials are all you really need. I find paper books pale in comparison to down-loadable, copy&paste-able free, online resources. Also note: As a programmer you will be expected to keep up to date with the ever changing languages you learn. All of these changes are easily accessible online too.

There's a lot of noise and very little quality signal to use and without having a degree to start with it's pretty much futile in terms of knowing what is and is not reliable information.

I call bullshit. See esp. the Java link above, your arguments are ill-informed, and reek of FUD. Search google for "java tutorial", or "$any_lang tutorial" and you get some pretty damn reliable, pure "signal" information about what you searched for.

Are you really arguing that Language specs & Tutorials from IBM, Microsoft, etc, and docs from a language's main website (such as http://perldoc.perl.org/

The internet isn't really a place to gain an informed opinion over things.

Yes, you are correct. Opinions should all be tossed out. Pure info is what the Internet is all about. Pick a language and a FOSS project, develop away, it's a great learning process that I've found much more "educational" than formal education.

Teach yourself C++: C++ Annotations, C++ Language Tutorial... ... or Perl: Perl programming documentation, or JavaScript,
or Java.

Just search the web, you'll find everything that any professor will ever be able to teach you online. Need guidance, clarification, or to ask a question? There are free online forums for that too... Yes, the Internet on average, much like the FM band, has more signal than noise, but similarly you can easily tune your into the signal you need.

Consider this: My Java "professor" gave an assignment where we read in rows of data from standard input, and output the table sorted by a certain column's value. He offered extra credit for proper alignment and justification of the table's cells... "WTF? Really?", I thought.

I used the Collections framework along with Swing to provide a GUI w/ sortable & justified JTable columns instead of doing character counting and sending extra spaces with the text to the standard output. He gave me a C. Another student used the Formatter to provide printf style formatting... also got a C, WTF! Go beyond the prof's teachings & expectations to meet a requirement, get a poor grade... That's dumb and counter productive.

In the real world, you try not to re-invent the wheel, this college course was not teaching practical programming; It was so far beneath what I learned already online, on Java's own website, I dropped the course (waste of time). Sure I can write a merge sort, or programatically align console text output, but that was not what the assignment said: "Provide a tabular output sorted by the 'Name' column." We learned merge sort 2 weeks prior, but the "professor" would not move on.

Not having a "degree" myself, I frequently answer questions that "Degree" holding graduates ask in online forums... Why? Because they didn't learn what they needed to know in their courses.

You would be hard pressed to find a programmer that doesn't have some form of documentation open in another window, screen, or context menu while coding. IMO, besides learning about algorithms and complexity, the language specs & online tutorials are all you really need. I find paper books pale in comparison to down-loadable, copy&paste-able free, online resources. Also note: As a programmer you will be expected to keep up to date with the ever changing languages you learn. All of these changes are easily accessible online too.

There's a lot of noise and very little quality signal to use and without having a degree to start with it's pretty much futile in terms of knowing what is and is not reliable information.

I call bullshit. See esp. the Java link above, your arguments are ill-informed, and reek of FUD. Search google for "java tutorial", or "$any_lang tutorial" and you get some pretty damn reliable, pure "signal" information about what you searched for.

Are you really arguing that Language specs & Tutorials from IBM, Microsoft, etc, and docs from a language's main website (such as http://perldoc.perl.org/

Perl 5.8 and above have native Unicode string and I/O support, per the first chapter of the most current rev of the Perl Cookbook, and you can use utf8 as well to write your scripts in Unicode.

Or POD.

you can much more easily inject natsy things into perl or php than into shell.

Erm... how so?

Have you ever seen a shell executing data?

Uhm... yes? That's what they do. Ever heard of a shell script?

I would need to call "sh" or "eval" to make this work.

So imagine a hypothetical script in which you do something like this stupid little example:

my $cmdline = "convert $x.svg $x.png";
system($cmdline);

And in this case, $x is user input. Well, now you're screwed if anyone enters spaces, so you do this:

my $cmdline = "convert '$x.svg' $x.png'";

Now you've got a classic SQL-injection-style vulnerability. What happens if a user sets $x to "'; rm -rf /; #"? That could be more devastating than a traditional SQL injection vulnerability.

So how, exactly, is Perl more vulnerable than that?

On the other side, is perl which calls without you knowing "sh" on simple things as opening a file.

Sorry, I have to call bullshit on this. Here's the perldoc on 'open'. It tells you exactly under which circumstances the filename will be interpreted as a command. If you don't want to sanitize a pipe character from the beginning and end of your string, there's always sysopen, which is mapped directly to fopen -- if this is vulnerable, then every single program on your system is vulnerable.

If you can't be bothered to RTFM, what business do you have programming?

And again, how is this more vulnerable than the point at which you call the shell from a perl script?

you can much more easily inject natsy things into perl or php than into shell.

Erm... how so?

Have you ever seen a shell executing data?

Uhm... yes? That's what they do. Ever heard of a shell script?

I would need to call "sh" or "eval" to make this work.

So imagine a hypothetical script in which you do something like this stupid little example:

my $cmdline = "convert $x.svg $x.png";
system($cmdline);

And in this case, $x is user input. Well, now you're screwed if anyone enters spaces, so you do this:

my $cmdline = "convert '$x.svg' $x.png'";

Now you've got a classic SQL-injection-style vulnerability. What happens if a user sets $x to "'; rm -rf /; #"? That could be more devastating than a traditional SQL injection vulnerability.

So how, exactly, is Perl more vulnerable than that?

On the other side, is perl which calls without you knowing "sh" on simple things as opening a file.

Sorry, I have to call bullshit on this. Here's the perldoc on 'open'. It tells you exactly under which circumstances the filename will be interpreted as a command. If you don't want to sanitize a pipe character from the beginning and end of your string, there's always sysopen, which is mapped directly to fopen -- if this is vulnerable, then every single program on your system is vulnerable.

If you can't be bothered to RTFM, what business do you have programming?

And again, how is this more vulnerable than the point at which you call the shell from a perl script?

Interesting that someone is talking about regular expressions and mentionning

> the absence of comparably useful alternatives, something that's no longer the case.

Other languages have indeed borrowed and extended the regular expression engine without questioning the initial design that is contemporary of the first Unix, with commands like sed. At some point, one has to sit down and redesign a feature set to clean it up and integrate it to the whole. That's the very point of Perl 6 and the grammar syntax is only a part. It may be debatable that the Perl 6 design is great or not. But the regular expression engine is now a full grammar engine. It is used to bootstrap the Perl language so it is the part that has been the most exercised.I don't ever hear someone that has used it saying that the design is unsound.

"But Perl has often been tagged as a language in which it's easy to write programs that are difficult to read, and it's no secret that regular expression syntax that has been the chief culprit. Funny that other languages have been borrowing Perl's regular expressions as fast as they can..." says Larry Wall in http://dev.perl.org/perl6/doc/design/apo/A05.html

The problem with all general purpose languages except Perl 6 is that regular expression is a side language or a library. The perl 5 interpreter has to resort to hand-lexing and yacc to parse Perl programs. And you had to use libraries if you wanted to do serious parsing, like Parse::Yapp, Parse::RecDescent or more recently Regex::Grammars.

Now, contrary to Perl 5, the parser engine is correctly integrated in the language and is used to parse Perl 6 programs which is a good clue to think it can handle very complex grammars.

Perl 6 is doing just what Perl had done in its time. Concentrating in a coherent whole what was scattered in many places. The price to pay is abandoning retrocompatibility and changing your habits for better ones.
I agree that the engine is slow, but that is an (early) implementation problem, not a design one.

... and replaced with? Look at the Perl 6 RFCs and make something coherent out of them. If you can pull it off in less time than it took the Perl 6 designers, you deserve a Fields medal.

Only Python comes close to having anything resembling Perl's level of testing. (Ruby's improved a lot thanks to Rubinius, but to my knowledge the latest stable releases don't include test suites.) PHP's testing was abysmal, last I checked.

None of those languages have anything like the CPAN, despite saying for years "We should build something like the CPAN."

None of those languages are as malleable as Perl 5; see MooseX::Declare for example, or even Moose.

PHP is still easier to deploy for web programs than Perl. Python has an advantage with GAE, and I understand Ruby has something called Heroku.

... when it languished under Larry Wall's negligent stewardship?

Healthy communities flourish from the healthy interactions between and cooperation of many individuals. If you thought Larry's job was to make sure that everyone is happy and doing exactly what he thinks they should do, you've never understood Larry or the Perl community.

It seems like the current way to be hip in developer circles is to make fun of Perl.

I really want to understand this phenomenon as I doubt most of these people bashing Perl have never even seen any Perl code written in the last 4 years. Hell, I could bet that a lot of people have never seen any *real* Perl code at all.

Perl 5 is a modern language which has the features of other currently more trendy dynamic languages and more. We have modern web frameworks. We have robust database bindings and state-of-the-art ORM libraries. We have have a well-tested modern object-system with optional declarative syntax. Perl is used by several high profile sites which, at this point, everyone already knows (BBC, DuckDuckGo, Slashdot, etc).

Perl 6 is a different language but shares a lot of the common minds behind all these awesome Perl 5 tools. However, even if you don't like Perl 5 for whatever reason keep in mind that Rakudo Star is a completely different thing (as a matter of fact, the name "Perl 6" should probably be dropped in favor of Rakudo - to avoid all this cargo-cult).

Perl's Taint Mode already supports this.

It generates runtime errors if you attempt to use a Tainted data. Data is never untainted, but untainted data can be generated by a regular expression match.

Perl takes special precautions called taint checks to prevent both obvious and subtle traps. Some of these checks are reasonably simple, such as verifying that path directories aren't writable by others; careful programmers have always used checks like these. Other checks, however, are best supported by the language itself, and it is these checks especially that contribute to making a set-id Perl program more secure than the corresponding C program.

You may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, locale information (see perllocale), results of certain system calls (readdir(), readlink(), the variable of shmread(), the messages returned by msgrcv(), the password, gcos and shell fields returned by the getpwxxx() calls), and all file input are marked as "tainted". Tainted data may not be used directly or indirectly in any command that invokes a sub-shell, nor in any command that modifies files, directories, or processes...

...

Because taintedness is associated with each scalar value, some elements of an array or hash can be tainted and others not. The keys of a hash are never tainted.

...

Sometimes you have just to clear your data's taintedness. Values may be untainted by using them as keys in a hash; otherwise the only way to bypass the tainting mechanism is by referencing subpatterns from a regular expression match. Perl presumes that if you reference a substring using $1, $2, etc., that you knew what you were doing when you wrote the pattern. That means using a bit of thought--don't just blindly untaint anything, or you defeat the entire mechanism.

There are plenty of examples behind the link.

You can do that with most regex systems. With Perl's you can do even so much more. If you have perl installed, try 'perldoc perlre', or you can readthe perldoc for perl regular expressions on perldoc.perl.org instead.

If you're intrigued by that, stop by Perl.org and PerlMonks. It's a much-maligned language, and for really superficial reasons. The modern best practices for the language answer most of the problems people ever had with it. The rest of the problems are personal preferences stated as fact, PR failures, and hyperbole.

You can do that with most regex systems. With Perl's you can do even so much more. If you have perl installed, try 'perldoc perlre', or you can readthe perldoc for perl regular expressions on perldoc.perl.org instead.

If you're intrigued by that, stop by Perl.org and PerlMonks. It's a much-maligned language, and for really superficial reasons. The modern best practices for the language answer most of the problems people ever had with it. The rest of the problems are personal preferences stated as fact, PR failures, and hyperbole.

The Perl 6 Design Team had a 6 in the middle, since 2000, and on and on it goes................

http://use.perl.org/~chromatic/journal/40296

Sometimes I wished `break` could take argument of how many levels it should break out of

It can in PHP. Java and Perl have a different solution: label the start of a loop and then use that label as the argument of break. In C, it's just a matter of discipline to use goto only to replace a throw or labeled break.

Perl is a tough market, it only has a few good job markets and relatively few positions available compared to Java or .NET or c# stuff. I looked for positions on http://jobs.perl.org/ and http://www.dice.com./ Dice has more Perl listings but I have gotten responses from both.

Like I said, Perl positions are spotty, I moved to Pittsburgh for 6 months, there was only one company advertising for one Perl position, that was it. Nothing else even close. Good job markets are in LA, San Fransico, NYC and after that, it becomes slim pickings with a position popping up every once in a while in a location.

Not necessary. A Bing Product Manager has already commented on the CPAN Testers blog entry upon which the article is based:

Hi,
I am a Program Manager on the Bing team at Microsoft, thanks for bringing this issue to our attention. I have sent an email to barbie@cpan.org as we need additional information to be able to track down the problem. If you have not received the email please contact us through the Bing webmaster center at bwmc@microsoft.com.

As said below, never ascribe to malice that which can be adequately explained by stupidity. (Insert lame joke about MSFT being full of stupidity here).

Random websites are being mysteriously slaughtered.

This guy has done some decent research into Facebook privacy in terms of their API and such.

http://use.perl.org/~pjf/journal/39998

good read.

perldoc perlsyn

'The other question is that there are no implementations of the standard yet...'

The Rakudo guys have now committed themselves to a useful/usable release (if not a complete implementation of everything in the standard) in Spring 2010 (the target is April):

http://use.perl.org/~pmichaud/journal/39411

They intend this to be a release which 'application writers will feel comfortable enough to start using in their projects'.

This probably helped:

http://news.perlfoundation.org/2008/05/tpf_receives_large_donation_in.html

Here's where they are now:

http://rakudo.org/status

http://github.com/rakudo/rakudo/blob/master/docs/ROADMAP

Well, the first line of the first Google hit for 'Perl 6':

http://dev.perl.org/perl6/

says:

"Perl 6 is a new language. Perl 5 and Perl 6 are two languages in the Perl family, but of different lineages. There is no current release schedule for Perl 6."

Some people, of course, may still find this confusing. These people should use Python :-)

A longer answer (together with several chapters of new Perl 6 book written by some of the developers) is here:

http://cloud.github.com/downloads/perl6/book/book-2009-11.pdf

"Some might ask, 'Why call it Perl if it's a different language?' Perl is more than just the vagaries of syntax. Perl is philosophy (there's more than one way to do it; easy things easy, hard things possible); Perl is custom (unit testing); Perl is architectual edifice (Comprehensive Perl Archive Network); Perl is community (perl5porters, perl6-language). These are things that both Perl 5 and Perl 6 will share to varying degrees. Also, due to Perl's habit of stealing good ideas, Perl 5 and Perl 6 will converge in some areas as Perl 5 borrows ideas from Perl 6 and vice versa."

From Perl.org: Perl is a general-purpose programming language originally developed for text manipulation It evolved into a system admin language as time went on and modules were created/added....

There is basically zero quality control, anyone can put any module up they want and use any namespace. They don't have to offer ANY documentation

Sure, but since you can check the namespace and browse the docs before you choose to install the module, is that such a problem? I admit the quality control is limited, but there is a review facility which is reasonably well-used -see http://cpanratings.perl.org/.

if they go AWOL and stop maintaining the module, it just stays there, festering

Just like any other open-source project then.

One of the things I immediatly noticed is the lack of build-in libraries. The reason I've always preferred Delphi and C# over C/C++ and PHP over Perl is that they all come with a comprehensive build-in function library for wide area of things.

The release of Strawberry Perl Professional in January should resolve your issues then, as we're going to be rolling a ton of stuff into a single install, so it will come with comprehensive built-in function library for a wide area of things.

Or at least, it will fix it on Windows...

Perl developers know about this thing called CPAN. PHP doesn't even come close in this regard, and you really can't get a better language reference than perldoc. Honestly, if you can't write an app using Perl's built-in functions and the thousands of modules from CPAN, you probably shouldn't be programming. While choice in languages can vary widely according to the individual coder's personal preferences and particular suitability for a given task, the weakness you've cited is imaginary.

You don't even get a Perl or Python interpreter preinstalled in Windows; how backward can you get?

What place does Perl and Python have in the default install of an OS?

Python comes pre-installed on Mac OS X, but due to Apple's release cycle, it's often one or even two years old. The overwhelming recommendation of the "MacPython" community is to upgrade your Python by downloading and installing a newer version from the Python standard release page. Python on the Mac

If you are running a Linux system (or most UNIX systems, including Mac OS X), you probably already have an installation of perl. Type perl -v at the command line to find out which version. Get Perl

A 100% Open Source Perl for Windows that is exactly the same
as Perl everywhere else. And now it's rebuilt from scratch! We've partnered with Microsoft to improve CPAN on Win32. Our new WiX-based MSI installer enables Active Directory Group Policy installation across your entire organisation. New bundled support for the world's most popular Open Source database MySQL, plus SQLite and ODBC clients. And some little things, like installer clash detection logic, a cleaner uninstall, and Perl upgrade support. Strawberry Perl For Windows

Perl can do this, too, using source filters. ;)

Not sure about PHP, but when you make such comparisons between RoR and Perl solutions you should at least be aware of recent developments such as the Catalyst framework.

Not to mention things such as perl5i which tries to aggregate most of what is known as modern Perl.

Perl is an evolving language and Perl code from 8 years is very different from modern Perl code.

And when you say Perl supports random access of Unicode strings, are you sure it's not just giving you random access to an array of Unicode code points --- which is also wrong? Remember that a single Unicode glyph can be made up of an arbitrary number of code points.

Interesting point. Some documentation: man perlunicode, man perluniintro, Unicode::Normalize. I spent some time studying these, and concluded that I didn't understand enough to answer your question :-)

And when you say Perl supports random access of Unicode strings, are you sure it's not just giving you random access to an array of Unicode code points --- which is also wrong? Remember that a single Unicode glyph can be made up of an arbitrary number of code points.

Interesting point. Some documentation: man perlunicode, man perluniintro, Unicode::Normalize. I spent some time studying these, and concluded that I didn't understand enough to answer your question :-)

And when you say Perl supports random access of Unicode strings, are you sure it's not just giving you random access to an array of Unicode code points --- which is also wrong? Remember that a single Unicode glyph can be made up of an arbitrary number of code points.

Interesting point. Some documentation: man perlunicode, man perluniintro, Unicode::Normalize. I spent some time studying these, and concluded that I didn't understand enough to answer your question :-)

Perl is glue.

The GP was apparently talking about PERL, which is a joke programming language in which it's impossible to write maintainable code. You're thinking of the Perl programming language, which allows untrained novices to do useful things while not preventing diligent and careful programmers from writing effective and maintainable code.

You can safely ignore the opinion of anyone who spells the latter PERL.