The Perl Foundation Gets New Leadership

Andy Lester writes to tell us that the Perl foundation has named a new president and steering committee members. Bill Odom landed the seat of president, replacing Allison Randal who has occupied the seat since 2002. From the article: "Founded in 2000, The Perl Foundation (TPF) is a non-profit 501(c)(3) corporation based in Holland, Michigan, established to advance the use and development of the Perl programming language through open discussion, collaboration, design, and code."

Comments

What about Perl 6?

[bhirsch]

Hopefully this will help Perl 6 in being released at some point soon. My favorite programming language seems to be lagging behind quite a bit.

Re:What about Perl 6?

[bhirsch]

Not really. IIRC, he is stepping aside for the most part in Perl 6's development.

Re:What about Perl 6?

[rduke15]

Isn't it out already? I have seen the O'Reilly cover

Re:What about Perl 6?

[kcelery]

It's a 'NOT REALLY' cover, not O'Reilly cover.

Keep them both?

[neelm]

Why not keep both on as president? That way there would always be more than one way to get something done... I'm sure that never leads to problems. /who let this python guy in the room?

Re:Keep them both?

[truckaxle]

Ya and then if you want something done there will always be "more the one way to get do it".

I for One...

[MightyMait]

I, for one, welcome our new PERL overlords!

Re:I for One...

[some_canadian_hacker]

Ugh... there's at least one of these for every slashdot article posted. Just stop it - you're annoying people like myself and taking up one extra row in the /. DB servers.

Re:I for One...

[MightyMait]

Sorry to annoy you, but this is what's known in the world of comedy as a "running gag" (however, it's the first time *I've* participated in the perpetuation of this particular example). Perhaps I betray the level of sophistication of my sense of humor, but *I* find this particular "running gag" to be amusing. I thought my incantation was just a little bit clever given that the post to which I reply actually *does* refer to a change in leadership. Apologies again if your funny bone was rubbed the wrong way.

Re:I for One...

[some_canadian_hacker]

Hehe, it's good to know there's still some people with a _logical_ sense of humor... Thanks for pointing out my failure to see that - I guess I've just been a little too irritable lately :)

Re:I for One...

[MightyMait]

Tell me about it!! Between my own dental mess and my kids' health, I've been a bit humor-impaired recently. Anyways, to be fair, there comes a time when a running gag gets stale. I think the "overlords" gag has almost reached (or recently passed) that point. Here's to maintaining (sensible) humor! Er, and thanks for cutting me a bit of slack :)

Re:I for One...

[Zarf]

I for one welcome our new ...perpetuation of the running gag... overlords.

Re:Bring back Larry!

[CyricZ]

It's not an issue whether we all want Larry to take over Perl again. It's more a matter of whether or not he wishes to resume such leadership. And judging by his past statements, he is not interested in that. He wants Perl 6 to be a community effort, as it has been.

As it says on the Perl 6 home page:
"Perl 5 was my rewrite of Perl. I want Perl 6 to be the community's rewrite of Perl and of the community." - Larry Wall, State of the Onion speech, TPC4

Perl's place in todays world?

[rockinrobotix]

Other than for products (or news aggregating websites) that were originally coded in Perl is there any reason to start a project today in Perl instead of any of the more modern scripting languages?
This is not a rhetorical question (or in Slashdot: I am not trolling). I would actually like to know why developers would choose Perl over alternatives today on a new project.

Re:Perl's place in todays world?

[kurtu5]

A great reason to use perl is you can publish your code GPL and still keep your code secret!

Perl gives one the ability to write very very obsfucated code. In fact I love perl. Looking at someone else's perl code is even more fun/challenging than solving suduku puzzles!

Use perl if you don't want anyone, ever, maintaing your code.

Re:Perl's place in todays world?

[nothingbutcoupons]

Pardon my ignorance, but do a heckuva lot of people still use Perl? I used it a long time ago, but my Camel books are all collecting dust now as I move in different programming directions.

Re:Perl's place in todays world?

[Florian Weimer]

I would actually like to know why developers would choose Perl over alternatives today on a new project.

I use Perl if I can reuse existing code and cut down development time significantly (using some CPAN module, or an application framework such as RT).

Re:Perl's place in todays world?

[slavemowgli]

Let me rephrase that question: why would developers chose another language over Perl for a new project?

Re:Perl's place in todays world?

[Anonymous Coward]

CPAN.

CPAN is the silver bullet. While I prefer other scripting languages (heck, almost *any* scripting language) over Perl, no one comes close to having the sheer amount of instantly-useful code available as Perl boasts with the CPAN. Sure, there's some crap in there, but the wheat outshines the chaff by a wide margin.

Re:Perl's place in todays world?

[po_boy]

CPAN

You are correct, sir! When python sports a collection as good as CPAN, I'm trading in my camel for a snake. It's just not there, yet.

Re:Perl's place in todays world?

[photon317]

To you and your like minded responders: from the point of view of someone who stays current with perl, your question certainly seems like a troll.

Perl continues to be a one of the most advanced languages in existance (slashdot jokes about how horribly bad one can shoot oneself in the foot with it notwithstanding). There is every reason to start a new project in Perl today. I'm really not even going to try to run down a list of reasons why here, they're just too numerous. If you haven't given serious professional development in Perl a shot, you're missing out. Perl really doesn't have any equals. Python comes close to being an alternative to Perl where the rules are more strictly enforced (which removes a lot of interesting possibilities), whitespace matters syntactically (and that's just insane in a modern language), and the majority of CPAN is missing.

Take any paradigm, and method or way of developing, and unique and interesting feature of some other language, and it all can, will, and probably has been done in Perl. It is on some ways the ultimate metalanguage. You want OO? You have your choice of a wide array of completely different styles of OO (both in terms of internals and interfaces), whatever suits your needs. Are you a fan of functional programming ala Haskell? Try Language::Functional ( http://search.cpan.org/~lbrocard/Language-Function al-0.03/Functional.pm ). TheDamian even wrote a module that allows one to write perl code as correct sentences and paragraphs in proper Latin, even given Latin's lack of defined rules about word ordering. (see: http://search.cpan.org/~dconway/Lingua-Romana-Perl igata-0.50/lib/Lingua/Romana/Perligata.pm for the module, and http://www.csse.monash.edu.au/~damian/papers/HTML/ Perligata.html for the academic explanation)

Perl 6 + Parrot I suspect will be even stronger than Perl 5, but only time will tell. Perl 5 will of course be around virtually forever, even with what deficiencies it has.

BTW, there is recently a great new Perl book out called "Perl Best Practices", which goes about the business of telling you how to not write spaghetti unmaintainable broken perl code (of course, they way you do that isn't much different than how you do it in any other language, which just goes to show that the problem isn't neccesarily that Perl invites good programmers to program badly - the problem is that perl is so accessible and easy that it invites bad programmers to program at all).

Re:Perl's place in todays world?

[degraeve]

The CPAN modules available make writing a complex script possible on a short deadline. Try, in an afternoon, with PHP, to write a script to read from an email box to get an excel attachment whose contents you use to create a midi file.

(Perl is also useful for parsing posts like this.)

Re:Perl's place in todays world?

[moro_666]

don't get too excited now :)

sure perl can doo OO and functional programming (hey, i use it quite often, it's a realy swiss army knife and it runs on pretty much every linux box).

but if you need to mix OOP, streams and threading (yeah, software like that is really being written too) , then perl just can't cut it. because the current threading implementation attempts just literally **ck and dont provide anything that is fast enough and usable enough (the standard ithreads are not even close, liz's forks are good but has some pretty intensive overhead on new creation so ... no real stuff usable yet in 5.8.x).

i hope perl6 fixes this bigtime, but until it arrives, we'll just have to wait and see what finally comes out.

however, for the originator of this thread: if you can't "cut" perl, dont bash it. (i cant drive a plane but you dont see me shooting around the airport and flamebaiting, do you ?) (yeah i meant the guy that wanted to choose something over perl at every cost, check the url line of the slashdot page ... comments.pl for example ... )

learn perl, dont bash it.

Re:Perl's place in todays world?

[mpath]

Perl is a modern scripting language. Just because it's not "fresh" or has a fancy marketing scheme doesn't take away from its power & greatness. A lot of the newer/Web2.0 stuff is simply javascript on top of existing web services, which can be written in anything, including Perl. I guess the bottom line is that it's a great language and I enjoy writing my web applications in it because I know it so well and it's not limiting at all.

Re:Perl's place in todays world?

[Anonymous Coward]

Hi:

Just a comment on perl and threads - what (functionally) would a perl script need in terms of thread-like multitasking/parallel tasking that the astonishing POE doesn't provide ?

Actually, tangent to the comment - why doesn't POE get the props it deserves as an AFAIK perl-unique resource ? Most casual perl users don't seem to even know it exists and what it doesn/can do ?

http://poe.perl.org/?What_POE_Is

Thanks -

Re:Perl's place in todays world?

[publius_ovidius]

As one of the people who was elected to the steering committee, I don't mind taking a poke at this question.

Many of the complaints about Perl stem from the fact that Perl was a pioneer in getting "dynamically" typed languages before the public eye. It certainly wasn't the first (was LISP the first major one?), but it has been the largest. Unfortunately, because Perl has been blazing a trail it's had many years of going down promising paths only to find them dead ends (pseudo-hashes anyone?). Languages such as Python and Ruby have been happily running down this path and ignoring the trails they already know to lead to oblivion.

This suggests an obvious question: what's wrong with Perl? Well, there's plenty wrong with Perl that I can point out, but interestingly, I've discovered that the complaints which Perl experts have are radically different from the complaints that casual Perl users have (amusingly, many folks who criticize Perl couldn't tell simple Perl and PHP snippets apart).

Just as I have serious complaints with Perl, those who are experts in Ruby and Python probably have serious problems with those languages which do not mirror my own objections. Python, for example, is eliminating the badly implemented lambda function and getting rid of all hope for closures (feel free to correct me if I'm wrong). Ruby has mixins in lieue of multiple inheritance and traded one set of problems for another (trait composition seems to offer the best of both worlds but it hasn't caught on yet). However, those complaints probably reflect my imperfect understanding of those languages and I strongly suspect that those using these languages have other fish to fry.

A big problem with Perl is that it's being taught incorrectly. Few teaching materials really focus on the linguistic basis of the language. Once you really, really understand the linguistic basis, the difference my $foo = ... and my ($foo) = ... becomes second nature. The idea of "topics" and "topicalizers", though more explicitly stated in Perl 6, are also quite important but not taught well. It's quite natural, but it's such an unusual feature for programming languages that those who come to Perl who pick up the language in a haphazard manner get annoyed at the seeming fickleness of the language even though many of these behaviors are quite predictable if you understand the linguistic underpinnings. That's not to say there aren't quite a few quirks in the language whose behavior is not predictable, but many languages suffer strange quirks and are still widely used.

People complain about Perl's "line noise" characteristics and unmaintainable programs and ignore that much of this stems from heavy regular expression use (yell at regexes, not Perl) and people without a strong programming background finding the language easy to use (yell at those people, not at their tool). Professional programmers who use Perl often build large, robust systems in a fraction of of the time that developers in Java or C++ would. Of course, good programmers are implementing robust test suites, automatic builds and other tools to catch them when the fall.

When all is said and done, were it not for Perl 6, I'd probably start using Ruby. I have really enjoyed Ruby the few times I used it but it had such limited use (prior to Rails) that I didn't want to jump ship.

Re:Perl's place in todays world?

[bradkittenbrink]

whitespace matters syntactically (and that's just insane in a modern language)

When will people stop repeating this troll?? Syntactically significant whitespace is a well thought out choice by language designers and there are very good reasons for wanting it. If you don't like it, fine, don't use those languages, but don't start a witch hunt by calling those designers insane.

The fact of the matter is: whitespace is significant to human readers whether or not it's significant to machine readers, and there's no way around this. People's intution about what whitespace means is very strong and difficult to change. A huge proportion of the typographical errors in code I've read is due to the fact that the structure of the whitespace did not match the syntactical structure it was intended to describe. These types of errors are by definition impossible in languages where the syntactical structure is the whitespace structure. It makes a lot of sense to have the machine pay attention to the same features of the source code that people intuitively pay attention to, rather than force people to break their intuition and look for small features like semicolons and braces.

Re:Perl's place in todays world?

[consumer]

...is there any reason to start a project today in Perl instead of any of the more modern scripting languages?

Apparently Amazon thinks so. They started using Perl for their new web development a couple of years ago.

Re:Perl's place in todays world?

[dpuu]

And to add a bit of irony, Perl 6 will have its own syntactically significant whitespace. For example:

print (1+2)+3

will not be the same as:

print(1+2) + 3

(the first prints "6"; the second prints "3" and then adds three to the value returned from the print function)

Re:Perl's place in todays world?

[chromatic]

And to add a bit of irony, Perl 6 will have its own syntactically significant whitespace.

So does almost every phonetically written l an g u age, though it turns out that humans are still better at pattern matching than are computers.

Re:Perl's place in todays world?

[King Babar]

This suggests an obvious question: what's wrong with Perl? Well, there's plenty wrong with Perl that I can point out, but interestingly, I've discovered that the complaints which Perl experts have are radically different from the complaints that casual Perl users have (amusingly, many folks who criticize Perl couldn't tell simple Perl and PHP snippets apart).

What you say is true, but misses a major, major point. Perl right now has a pretty horrible reputation in some quarters, and even though it might be the result of kvetching from a lot of uninformed people, pointing this out is not a solution to the problem. More than a couple of political campaigns have gone down in flames when candidates made no useful response to baseless negative campaigning. Right now, I'm finally getting more excited by Perl6 now that there looks like there will be one, but we're still realistically looking at January 2007 for that, which is about seven years after the effort started.

Given the comment at the very end of your post about Ruby, you realize the kind of mortal peril that Perl finds itself in. If Matz had not been Japanese, and therefore more of the Ruby docs had been available in English maybe 3 years earlier, Perl could have ended up stone cold dead. What the new leadership has got to keep in mind is very simple: if we don't finish Perl6 *right now*, we're all going to die. This was not the only way to have done things, but so much has been invested in Perl6 for so long that there is really no way to make Perl5 better in ways that will convince people that it isn't last year's language. If only a bit more thought had gone into Perl5 these last five years or so, we'd be in better shape right now.

But I have one more point to make, while I'm on the soap box:

People complain about Perl's "line noise" characteristics and unmaintainable programs and ignore that much of this stems from heavy regular expression use (yell at regexes, not Perl) and people without a strong programming background finding the language easy to use (yell at those people, not at their tool).

That's not completely true. Like it or not, every Perl variable name has a piece of line noise attached to it that 90% of the time clarifies nothing. For that matter, there is the madness surrounding lexical variables in Perl. Using them is good programming practice, but every declaration of such a thing adds another "my" to the list. It would have been SO EASY to define a flag or a pragma noting that all of the declarations in a file were implicitly of "my" variables, but this never happened. And then there is the fiasco of function argument declarations. As in: Perl, unique among all other scripting languages doesn't yet have useful parameter lists in function definitions Every time I type somehing like my ($foo, bar, $baz) = @_; I think to myself "lame lame lame". Sure, Perl6 solves this one quite handily, and gives eleventy-seven different ways to call and declare function parameters, but Yeesh! Did we really have to wait for the One Great Perl to arrive to get something that sucks less than Javascript 1.0 in this respect?

I have been a Perl programmer for 14 years now, and I think the world of what it can do. But I am telling you this: if we don't fix Perl, we will die. The seven lean years will kill us unless we make it completely obvious to people how superior Perl6 is, and unless we make sure that it really is out there to hack with. If betas of Perl 6 don't arrive before the middle of 2006, I swear we are doomed. Please do everything in your power to make sure this doen't happen.

Thanks for listening. :-)

Re:Perl's place in todays world?

[halltk1983]

My best friend since grade school works for a company that does *hospital* software, in OO perl. It is very stable, very functional, and very quick to update / patch. That is actually where he learned perl could be programmed in OO fashion. He then taught me, and we are currently working on a modular universal perl back-end for developing custom web-pages and web-based applications. OOPerl is very functional, and very simple. Lots of documentation on it online, too.

Point of this post: perl can cut it, and does so efficiently in an environment where it is literally a life-and-death situation.

Re:Perl's place in todays world?

[kurtu5]

So I am a troll for being sarcastic. Well thanks very much. Someone pray tell me that what I said above is not true.

Re:Perl's place in todays world?

[chromatic]

It would have been SO EASY to define a flag or a pragma noting that all of the declarations in a file were implicitly of "my" variables, but this never happened.

How do you identify declarations without some sort of declaration identifier? Is it a typo or is it a new declaration? Other dynamic languages without a use strict 'vars'; equivalent suffer this problem.

But I am telling you this: if we don't fix Perl, we will die.

(Emphasis mine.) I look forward to your contributions of time, money, code, documentation, ideas, evangelism, testing, support, and praise.

Re:Perl's place in todays world?

[Anonymous Coward]

So I am a troll for being sarcastic. [..] Someone pray tell me that what I said above is not true.

You wrote:

Use perl if you don't want anyone, ever, maintaing your code.

You either don't know what you are talking about or you are a troll.

It isn't hard to write Perl like C. You do have a lot of freedom to express in Perl, but if you write larger projects you have to do coding standards anyway, no matter what language you use.

(I post Anon so not to feed the trolls. If you're just an idiot, I'm sorry for calling you a troll.)

Re:Perl's place in todays world?

[moro_666]

you missed my point totally.

perl (at least until 5.8.x) cant handle mixed oop, streams and threads at the same time. period.

i did imho very clearly express that perl can do OOP, can do streams, can do even some threading, but mixing all of them doesnt work. 2 ithreads cant mess around 1 i/o stream, which is a kick in the face (if you have ever done some real application programming, you should see where the problems start to raise). and threading without proper i/o support behind it is quite worthless in many many many applications.

Re:Perl's place in todays world?

[Anonymous Coward]

What you said above is not true.

Re:Perl's place in todays world?

[publius_ovidius]

I do agree that pointing out how invalid some criticisms of Perl are does not solve the perception problem. We're trying to figure out a good strategy to deal with this and suggestions are always welcome.

As in: Perl, unique among all other scripting languages doesn't yet have useful parameter lists in function definitions Every time I type somehing like my ($foo, bar, $baz) = @_; I think to myself "lame lame lame".

And later you wrote: I have been a Perl programmer for 14 years now ...

I sometimes hear the criticism about Perl's argument handling, but I don't hear that as much as the line noise issue. The fact that you've been a Perl programmer for 14 years means that you are probably more keenly aware of this than most. I've released a module named Sub::Signatures which helps to deal with this (and allows multi-(?:method|function) dispatching (MMD) based on the number of arguments) but because it's a source filter, people are afraid to try it. Frankly, given the reputation of source filters, I can't say I blame them.

In any event, this criticism is perfectly valid and it's one of my strongest complaints about the language. It's inherently tied to the MMD issue so the latter cannot be resolved easily without the former. Another major issue is lack of encapsulation in standard object creation. Class::Std helps to minimize the problem, but it has problems running under persistent environments such as mod_perl, thus limiting its usefulness in the sort of environment which is designed to scale and thus truly needs that encapsulation. These issues combined with a lack of proper introspection capabilities are my strongest complaints. Solving them would go a long way to making Perl a truly robust language.

These issues aside, I specialize in building huge systems in Perl. I have worked on systems that tell Hollywood how much money their movies make while collecting and collating data from thousands of movie theaters across the USA. I currently work on software used by little-known companies such as the Rand Corporation, the World Health Organization and the Congressionally funded Radio Free Asia (they use my employer's software to publish their Web site in 10 different languages). The major requirement for building large systems such as these is having a robust test suite. Given the latter requirement, you can achieve powerful scalability with just about any language capable of it. Fortunately, because I choose to use Perl, I can roll out solid, robust code much faster than Java or C++ programmers. I have some amusing stories about destroying competitors using those languages because they couldn't keep up with our speed of development but NDAs compel me to keep quite :(

As for Parrot and Perl 6, they solve these problems and many more. However, Parrot is revolutionary in its approach and given that that we are a volunteer organization, it is difficult to get qualified full-time developers to solve truly unique problems. Fortunately, we're finally getting there. Perl 6 is worth the wait but those who haven't been following it closely (and perhaps those who have been following it too closely :) are getting frustrated. I don't blame them, but we don't have a huge staff on hand to crank this stuff out the door.

Patches welcome :)

Re:Perl's place in todays world?

[kurtu5]

The problem is, Anon, that you don't have to follow coding standards. The number of ways one can write a single statement in perl is multitudinous.

Yes, I know you can do this for C, python, Java and etc. But the number of ways to do so in perl is mind boggling. I would say its an order of magnitude greater than the competition.

Apparently this code does something. I have no clue what it does and would rather just modify the assembly at this point.

Perl: "+87aZ{{skZixmZRJ+tbeatBY[:%?F&6&*;11))!!kccZRR {{kkscc1î{cRRasmMRMJCACD ?IE)W\7;.-4%&/,51($$(6

Re:Perl's place in todays world?

[kurtu5]

Oh and BTW, I am not an idiot

Get it right, I am a functional idiot. Thank you very much. :)

Re:Perl's place in todays world?

[CodeRx]

The cheeseshop is currently the closest thing python has to CPAN. Only ~900 modules compared to CPAN's 8,000+, so it still has a way to go. There is also the Vaults of Parnassus.

Also, the daily python url is a great way to keep up with the latest developments in the Python world.

Re:Perl's place in todays world?

[Anonymous Coward]

Ruby has mixins in lieue of multiple inheritance and traded one set of problems for another (trait composition seems to offer the best of both worlds but it hasn't caught on yet).

Haha, funny you mention traits. At RubyConf (which was this past weekend), matz showed off some new ideas for Ruby 2.0. http://www.rubyist.net/~matz/slides/rc2005/mgp0002 7.html

The full slides from matz's keynote: http://www.rubyist.net/~matz/slides/rc2005/

Re:Perl's place in todays world?

[strstrep]

At the very least, using brackets to group instead of whitespace allows you to move through code much more easily. I use % dozens of times a day in vi (it bounces between paired brackets). It's so much easier than scrolling up and down through pages of code. Also, making blocks of code more than about 24 lines in Python is a readability nightmare, because the whitespace that defines the block can't be seen in its context without scrolling... and you don't have a nice editor shortcut to help you out.

Re:Perl's place in todays world?

[King Babar]

(Emphasis mine.) I look forward to your contributions of time, money, code, documentation, ideas, evangelism, testing, support, and praise.

I already did contribute the money. Twice. Nothing much happened (this was 3-4 years ago), so I got discouraged. To be brutally honest, right now Perl needs fewer ideas (they should junk Parrot TODAY if it is slowing anything else down) and less praise. The thing that must be communicated is this: if we don't have a beta by summer 2006, we are _dead_. Pugs has done a world of good to help Perl6 already (we would surely be dead if that project hadn't started up), and if I had any time at all, I would try to write code for that. If the Perl Foundation were serious at all, they'd buy out Autrijus so he didn't have to worry about $work until next summer. Then we would probably have Perl6. If they don't, we won't. I'm thinking it's getting just about this simple, although I'd love to be wrong.

Re:Perl's place in todays world?

[chromatic]

If the Perl Foundation were serious at all, they'd buy out Autrijus so he didn't have to worry about $work until next summer.

Do you know Autrijus? I do not think he would ever agree to that.

...if we don't have a beta by summer 2006, we are _dead_.

You keep using that word. I do not think it means what you think it means.

As one of the people actually working on it, I feel confident in saying that Perl 6, Parrot, and Pugs are further along and healthier projects now than they've ever been. Maybe they're not moving as fast as the CLR or Mono or the JVM, but for the amount of funded man-months, the Perl 6 project is a tremendous bargain.

If you have ideas that would speed up the project -- and I admit a curiousity about how dropping Parrot could make it faster to achieve such goals as interoperability with Perl 5, continuations and coroutines, STM, full garbage collection, portable bytecode, JIT, efficient threads, Unicode support, and runtime grammar changes -- I'm sure any of the Perl 6 mailing lists or IRC channels would love to hear from you.

Re:Perl's place in todays world?

[Anonymous Coward]

The key phrase there being "a couple of years ago". The question is if there is any reason to start with Perl now. How can Perl compete against the publicity Ruby gets or the widespead usage of Java and .NET languages?

Re:Perl's place in todays world?

[eyeye]

it would have been SO EASY to define a flag or a pragma noting that all of the declarations in a file were implicitly of "my" variables

Erm.. thats the default, of course then you have effectively global variables which is a bad thing.

every Perl variable name has a piece of line noise attached to it that 90% of the time clarifies nothing.

Erm... $variable is a scalar @variable is an array and %variable is a hash. That clarifies nothing to you?
Are you really a perl programmer, you sound like a VB coder who never uses Option Explicit.

Re:Perl's place in todays world?

[Surt]

Ok, but you might assume at this point they are committed. The question is would they make the same bad decision today?

Re:Perl's place in todays world?

[jonadab]

> Perl gives one the ability to write very very obsfucated code.

Most of it only looks obfuscated to people who don't speak Perl. Once you become fluent, you read code that others would consider obfuscated and ask, "What's the big deal?"

(There are exceptions, of course; code that's used ACME::Eyedrops and whatnot really is too obfuscated to be clearly legible, and then there's Matt's Script Archive. But nobody plays those games in production code.)

Re:Perl's place in todays world?

[jonadab]

> and the majority of CPAN is missing.

The significance of this statement cannot be overstated. The CPAN with its wealth of modules is such an enormous benfit, this alone would make Perl five times better than any of the languages the other poster listed, even if it were otherwise nothing special (which it is).

Re:Perl's place in todays world?

[MadAhab]

Does Class::Std really have problems under mod_perl? Is that under Apache 2 or 1.3.x? That would be too bad. Class::Std really does address so much of what Perl 5 doesn't do for encapsulation. It looks, probably not coincidentally, that some of its thinking is reflected in Perl 6 design (like painless creation of accessor methods).

Are there other ways of accomplishing the same thing using inside-out objects without Class::Std? I'm not easily guessing exactly where the problem lies - though I suppose the overriding of some stuff in UNIVSERAL might do it?

Re:Perl's place in todays world?

[publius_ovidius]

You can read the bug report about Class::Std to get a handle on the problem. You could probably implement inside-out objects manually and save yourself the problems that Class::Std has. If you read through the Class::Std documentation, you can get enough of a handle on what's going to choose your own implementation.

Re:Perl's place in todays world?

[consumer]

They made this decision quite recently. Anyway, you clearly have already made up your mind and have no interest in actually talking about it.

Re:Perl's place in todays world?

[Surt]

The OP claimed the decision was made two years ago, an enormous amount of time when you consider what has been going on in ruby/python in that timespan.

But my post was mostly intended to be a +1 funny, I don't really hate perl or anything. I've used it for a few small projects, it's fine. I'm comfortable with enough languages that at this point I prefer to just work with whatever has the best dev environment. At the moment that's java with idea, but i'd be happy enough to switch to perl if it had a superior development environment. Maybe the next version of perl will make such a thing happen.

Re:Something would get in the way.

[GecKo213]

Why not keep both on as president?

Simple answer to your question...

Ego.

Through "design"?

[MosesJones]

I know this is a cheap shot but its an important one. On the site (excluding Perl 6)there are THREE references to design, none of these are about how you actually should go about designing in perl and what is good practice for design of Perl programmes.

For the Perl foundation to REALLY help its users out there it might want to promote more DESIGN and less CODE as a better way to approach Perl programming. I've wasted enough time debugging (and mainly binning) badly constructed Perl code, it would be great if the foundation addressed the issues of implementation (lack of design) rather than more bells and whistles for the inept to use.

Re:Through "design"?

[slavemowgli]

Perl just gives you enough rope to hang yourself with - the fact that you *do* choose to hang yourself is not the language's fault. :) In fact, given the fact that Perl is supposed to make easy things easy and hard things possible, forcing a certain programming style upon its users would run contrary to the language's goals - specifically, it would run contrary to the "make the easy things easy" part.

That being said, if you want to learn about how to design Perl programs, why not pick up a copy of Perl Best Practices, for example?

Re:Through "design"?

[photon317]

The primary purpose of The Perl Foundation, IMHO, is to pick up cash and give it out to appropriate people so they can eat and sleep in peace while they make Perl better. Some of the most insanely talented Perl developers (as in developers of perl itself and the core modules in it, rather than users of perl) get some cash through this foundation, and they're the ones making the design-related decisions.

Re:Through "design"?

[CromeDome]

I've wasted enough time debugging (and mainly binning) badly constructed Perl code, it would be great if the foundation addressed the issues of implementation (lack of design) rather than more bells and whistles for the inept to use.

The same can be said for any language. Don't blame the language or the foundation that supports its development - blame the dumbass programer.

Re:Through "design"?

[geminidomino]

Bah. Perl gives you enough rope to hang yourself, your dog, your parents, Bill Gates, and enough left over for some kinky japanese bondage with your girlfriend.

But when your perl-fu is strong, you can rope yourself an elephant without getting scratched.

2020 called....

[Anonymous Coward]

....it said Perl 6 isn't out yet.

There will always be a place for Perl.

[CyricZ]

Indeed, we may be seeing Perl's reign in certain areas coming to an end. Java, PHP and Ruby have taken over when it comes to developing web apps. The regular expression support of languages like Python, Ruby, and even C# trump that of Perl.

While Perl was once a great innovator, today it is increasingly becoming a thing of the past. What were once great benefits of Perl have become standard features in many other languages. And unfortunately, Perl has failed to stay a step ahead of the game. The Perl 6 delays have not helped it at all. Indeed, while Perl will surely be used for decades to come, it is quite rapidly losing its place as the glue of the open source world. Python and Ruby are quickly taking over, if they haven't already done so.

Re:There will always be a place for Perl.

[Anonymous Coward]

The regular expression support of languages like Python, Ruby, and even C# trump that of Perl.

... er, what? How do you possibly figure this?

Re:There will always be a place for Perl.

[A beautiful mind]

"The regular expression support of languages like Python, Ruby, and even C# trump that of Perl."

BWAHAHAHAHAHAHAHAHAHAhahahahahaha, oh, that's a good one, hahahah, haha. Oh boy.

*wipes tears off*

Re:There will always be a place for Perl.

[Florian Weimer]

I think Perl has mostly catched up again. There was a time when Python offered regular expressions as a first-class type, but Perl didn't. But the named captures which are offered by Python and others are only available as "highly experimental" extension in Perl.

Re:There will always be a place for Perl.

[Lost Found]

On the contrary, the absolutely huge market share Perl has, combined with the 8,000+ modules available freely on CPAN, combined with the fact that well made Perl applications can readily outperform those in any other comparable language, means it's going to be around for a long time. And on the Perl6 subject, when Perl6 is available, it's going to blow the doors off of everyone else for a long time.

Re:There will always be a place for Perl.

[EraserMouseMan]

when Perl6 is available, it's going to blow the doors off of everyone else for a long time

What features in Perl6 will make your prediction come true?

Re:There will always be a place for Perl.

[OverlordQ]

WHy do you ne4ed named captures you got $1 through $N sure you can't named them $foo through $bar, but there's still readily available. if you need them then do something like:


my ($foo, $bar) = $something =~ m#(.*)!(.*)#;


$foo gets the first one, $bar get's the second one.

Re:There will always be a place for Perl.

[Florian Weimer]

WHy do you ne4ed named captures you got $1 through $N

When N is somewhat large (7? 9?), counting becomes difficult, and the resulting code is hard to read. It's not needed for feature completeness (unlike regular expressions as first-class objects), but it makes the code more readable in some cases.

(Come to think of it, I don't use named captures in my Python code.)

Re:There will always be a place for Perl.

[chromatic]

Multi-dispatch, junctions, roles, rules and grammars, a much improved VM, asynchronous IO, working threads, an event system, continuations and coroutines, optional typing and type inferencing, an immensely improved FFI, interoperability with other languages including Perl 5, an improved object system, hyperoperators, unification of blocks and closures, properties, object-like built-ins, improved reflection and introspection, improved consistency, improved clarity, and improved distribution possibilities.

Re:There will always be a place for Perl.

[kb_badgett]

PERL is finding its way into many new places like silicon chip design. It is a standard practice to use PERL in verification, verilog build and timing scripts. These designs are real world, complex operation where you need a powerful language to get things done. It is a language that works well and one that you learn on the job and not hyped in school. Imagine how much more popular it would be if there were classes in PERL that could prepare students to learn what they will do on the job instead of learning it when you get here.

Re:There will always be a place for Perl.

[LLuthor]

The regular expression support of languages like Python, Ruby, and even C# trump that of Perl.

In what way can the regular expression capabilities of any of these languages even approach that of Perl?

Please put down your crack-pipe and have a look at the perlre man-page and the CPAN archives.

You can use it now.

[CyricZ]

While it's not production software by any means, you can begin testing and improving Pugs.

Re:Perl is Dead

[Vorondil28]

As long as Netcraft doens't confirm it, I'll keep coding.

Re:Bring back Larry!

[Anonymous Coward]

Unfortunately, that choice looks like it's leading to both design-by-committee and second-system effect at the same time.

The next wave of innovation.

[CyricZ]

No, really. Look into the support that C# offers for regular expressions. I'm not a fan nor a user of Microsoft's products, but I will admit that what they've done is top of the game stuff. Same with Python and Ruby. Like stated earlier, Perl was the innovator. And Perl even managed to popularize regular expressions. But these days others have taken over the task of innovation in that field.

That said, Perl could be preparing for the next wave of innovation. Strangely enough, such "innovation" may be in the form of functional programming. They are concepts that were pioneered decades ago, yet have not received widespread public use. Perl could change that, by bringing such academic ideas to industrial use.

The leading Perl 6 implementation, Pugs, is written in Haskell. Indeed, even if Perl 6 never takes off, there will at least be a number of developers who learned Haskell in order to work on Pugs. So that alone may be enough of a contribution to modern software development.

Re:The next wave of innovation.

[Anonymous Coward]

Have you sought help for your small penis?

Re:The next wave of innovation.

[Anonymous Coward]

Java's Regex-Support is modeled after Perl's, but lacks many features. It is also slower. Been there, done that.

I don't know much about C# Regex-Support, but I'm pretty sure that it is not included in the language, but is available through some Regex-Class. The same is true for Java and Python. That is really a serious disadvantage. In Perl using Regexes is really natural, and in most cases leads to code that is leaner and easier to understand. In Java you often have to do funky stuff with String-Tokenizer or String.split just to parse a simple string. That may take 10-20 lines of Java-code. In Perl you can do that in one regex. Also nothing prevents you from including a comment if you want to be verbose.

Java's Regexes are pretty much a rip-off from Perl, with the difficult features missing. If you think that C#-Regexes are better, then please tell me a single example where C# has something useful that Perl lacks. I'm really currious.

I personally think that Perl will not go away. Sure, lately Python and Ruby take away some of Perl's marketshare, but I don't think that's bad, because the languages pretty similar:

Ruby is pretty much the same language as Perl but with all the special characters stripped. Ruby-Code is nicer to look at than Perl, but not easier to read, because you really have to read everything. In Perl the special characters have a strong memnonic meaning, which enables programmers to quickly grasp what code does, once they remember the special characters. The object system is different.

Python, while less powerful as a language than Perl or Ruby, is the nicest looking language and is really easy and elegant. Python's object system is pretty much the same as Perl's.

PHP, I don't consider any competition. PHP is a nice toy-language, that is certainly good enough for some limited Web-Development tasks, but not for anything else. PHP even doesn't have Unicode support (there is some function that can translate 8-bit code pages to utf-8 and vice versa. But that is a joke).

I think that Perl 6 will be a killer language. It will merge all the good stuff from Perl 5, Ruby and Python together with some of the good stuff from Haskell. And it will be fast. The Perl 6 JIT compiler (Parrot) is really promising, especially at numerical tasks - Perl's traditional weakness. I think that even today Perl 5 outperforms C# and Java in pretty much every regard (Ruby and Python are on par with Perl):

- Code is shorter and easier to understand
- Development is faster and more dynamic
- The libraries are easier to use

Just take a look at CPAN. And compare the libraries there, to the stuff that is available to Java and C# developers. The only area where C# and Java are are ahead is the GUI-Libaries, but on *x even that is changing with tools like Glade that support Perl. In this area Perl is also miles ahead of Ruby and Python. But both catch up quickly. I heard Ruby on Rails is really nice, but I haven't looked at much yet.

And just imagine... In a year or two Perl, Ruby and Python might run on the same runtime (Parrot) and might very well outperform Java and C# speedwise...

Bye

Re:The next wave of innovation.

[A beautiful mind]

"Perl was the innovator. And Perl even managed to popularize regular expressions. But these days others have taken over the task of innovation in that field."

I thought that it's not necessary to make my point stronger, but it seems so.

Disclaimer: I've seen you posting a couple of times intelligent stuff, i believe this is one of the few mind barfs everyone has when you posted about Perl having worse regexp than the others listed.

You talk way too generalized, about languages and not in exact, specific things when you're talking about regular expression support in those languages. Mind you, Perl is practically built around regular expressions. 'perldoc perlre' and 'perldoc perlop' should give you a slight idea how it looks like. While maybe C# has regular expression support like for example, sed or even my favorite text editor, vim does, it's nowhere near Perl's support for regular expressions. In Perl, you can use regular expressions almost everywhere, taking full advantages of the Perl additions. Ever wondered why people actively using regular expressions talk about the sed style and Perl style regular expressions? Because Perl added a lot of new/good stuff, mostly which is not duplicated fully elsewhere. In C#, support for regular expressions is nowhere near to Perl. About Python - I've got marginal experience, so i'd rather not judge it, but Ruby isn't built around regular expressions either. Sorry, Perl still is the most regular expression capable language around.

If you have already taken a look at Perl 6, then you might have seen that the regular expressions are almost completely taken to a new level there, so I'd rather say that Perl will stay _the_ top regular expression language for a while...

Re:The next wave of innovation.

[CableModemSniper]

Um, have you seen where regexps are going with Perl6? I submit that C# is not the innovator here. I'm not quite sure about Python, but I know the only thing that Ruby has over perl that might be considered an innovation is much better locality of scope for the $n, $`, $', and $& special variables. True ruby matches return an object, but that not really an innovation just a consequence of the philosophy of ruby. IIRC in Python regexps are not first-class (in the sense of having literals as in perl and ruby) and I'm positive C# regexps don't have literals. There really is no innovation there, Perl6 brings almost a new philosophy to the regexp table, and its part of the reason that Perl6 can be self-hosting. OTOH Perl6 is really weird, and not a whole lot like perl in my opinion, but what do I know?

Why I use Perl..

[Anonymous Coward]

..for most of my homegrown projects is the extent and reliability of CPAN codebase.

Re:Something would get in the way.

[Senzei]

Simple answer to your question...

Ego.

Which, I believe, is also why seemingly 90% of perl code is unreadable. In other words: yeah, well, I can do it in two fewer lines.

Allison Randal

[krani1lesi]

I actually had the privilege of meeting Allison, she is just a wonderfull person :) ... and I've got a nice "Programming Perl" signed by her too ;) miss you Allison

what perl's features are now standard?

[SolitaryMan]

What were once great benefits of Perl have become standard features in many other languages.

If you were talking about Python or Ruby, I could've agreed. But Java, C#, PHP are *DAMN FAR BEHIND* in this respect. I mean, metadata manipulation, built in hash and list data types with appropriate manipulation functions (grep, map etc.) are still "too advanced" features for modern programming languages like C# and Java.

Dear Perl letter

[Colonel Panic]

Dear Perl,

Look, I know that we were an item for quite a few years.

You were my one and only. My true love.
But I've gotta admit, when I saw your younger sister Ruby a few years back... well, I thought she was hot. But of course, she was too young then so I stayed away from her.

Now, more recently I have to confess that I went out with Ruby for a few dates and believe me, she is plenty mature now!
Not only that but her library seems somehow more complete than yours and certainly better organized. And her object oriented features - OO la la! Look, you're a great gal, but you're certainly not anywhere near as well endowed in THAT department.

And now that Ruby's got transportation (ok, so she likes to ride the rails) we're really getting around.

So, dear Perl, I have to tell you that it's over between you and me. From now on it's me and Ruby.
Please don't take it too hard. Maybe you'll find someone else after you're makeover.

John

Re:Dear Perl letter

[Anonymous Coward]

Laugh my @SS off that is a very clever and funny letter, good job!

I am a hardcore perl programmer and I will go to my grave using perl but if you can't laugh at yourself first than you truly never know humour.

Re:Dear Perl letter

[Anonymous Coward]

Dear John,

I hear you're dating my younger sister Ruby. She's quite a looker for her age, and I'm sure you'll have some good times.

I'm moving on as well, I'm happy to say, and I have been hanging out with a new crowd. In a lot of ways, I think I've learned from my sister, but she can be small-town just like I was in her own way, and most of the best ... techniques that she picked up are from Smalltalk: a mutual acquaintence.

I'm just holding on for my sweet 6th birthday, and when that comes I'll be back to the download sites... maybe we'll see each other there. I'm also playing with the idea of threesomes, so maybe the three of us... well let's just say a little bird gave me some great ideas.

Re:Dear Perl letter

[Colonel Panic]

Dear Perl,

I don't know how to say this gently, so I'll just say it: you need to seek professional help.
You've been talking about your '6th birthday' or '6th makeover' or similar such for about 5 years now. For 5 years now all I've heard from you is how great things will be after you reach this milestone. The years have come and gone and nothing ever seems to change. At first I believed you and I was excited about the future. But how can I believe you anymore? You've lost all credibility.

Please, you've got to quit looking toward some pie-in-the-sky-in-the-sweet-by-and-by and learn to face reality.

John

Re:Dear Perl letter

[ndogg]

That was disturbing on a number of levels...

Re:Something would get in the way.

[andy@petdance.com]

Not ego at all. As noted in the article, Allison stepped aside so that she could concentrate on Perl 6 and Parrot development.

In other words...

[rduke15]

Other than for products (or news aggregating websites) that were originally coded by smart people having fun, is there any reason to start a project today in a fun and powerful language instead of any of the more boring scripting languages?
This is not a rhetorical question (or in Slashdot: I am not trolling). I would actually like to know why developers would choose having fun over alternatives today on a new project. :-)

Nice mixed metaphor :o)

[Dystopian Rebel]

the wheat outshines the chaff by a wide margin

Any Perl user can appreciate the loosely-typed metaphors in that sentence.

Catch-up

[EraserMouseMan]

I'd say that 80% of those features are catch up. The other 20% are not necessary in other languages because, by their very nature, lend themselves to abuse/misuse. From that list I doubt that Perl 6 will be adopted by anybody but the people who already program in Perl.

Java, and C# (especially C#), however are truely on the cutting edge and are converting Perl users.

I mean, seriously, Threading, Events, Reflection, this stuff has been around for over a decade (probably two).

Re:Catch-up

[chromatic]

Java, and C# (especially C#), however are truely on the cutting edge...

The cutting edge of what, the best technologies the '70s had to offer?

It's not clear that you understand CPS, continuations, coroutines, properties, language-supported roles, optional type inferencing and strictness, junctions, hyperoperators, rules, grammars, or closure-based control structures. I don't expect to see Java add any of those features in the next ten years. The CLR might add a few in the next five years.

Have you ever programmed in a language outside of the Algol family tree?

Re:Catch-up

[Lost Found]

You know, flexibility in the freedoms of society leads to abuse/misuse too. Are you ready for your iron chains?

Re:Catch-up

[Lost Found]

D'oh. Attached my reply to the wrong place.

Re:Catch-up

[EraserMouseMan]

No iron chains. But I'll have to admit guard rails on cliffs are nice. Automatic Traction Control is nice. Database row locking is nice. Strongly typed languages are nice. Sure, there are very rare situations when these become a pain. But very very rare.

Re:Catch-up

[publius_ovidius]

80% catch up? I think your math is off.

Catch up:

• multi-dispatch
• asynchronous IO
• working threads
• an event system
• immensely improved FFI
• properties
• object-like built-ins
• improved reflection and introspection
• improved consistency
• improved clarity
• improved distribution possibilities.

Revolutionary (items in parentheses explain why some "common" features are included here):

• an improved object system (revolutionary in its approach)
• Register-based VM
• junctions
• roles
• rules and grammars
• continuations and coroutines (not widespread)
• optional typing and type inferencing (other languages typically don't make this optional)
• interoperability with other languages including Perl 5 (because of how easy it is)
• hyperoperators
• unification of blocks and closures

(Before you criticize those things I put in the revolutionary list, you'd have to take the time to read up on them and realize why I put them there rather than just assume that I don't know what I'm talking about. I've programmed in many languages and I have a very good idea of what's common and what's not -- though perhaps I'm just smoking crack.)

Of course, I could make similar comments as yours about Java (I don't know C++ well). Java languished for a long time without regular expressions. Autoboxing in Tiger was an attempt to get around some of the difficulties inherent in typing the container. The latest Dr. Dobb's has an interesting article about functional programming in Java -- something many other programs have allowed for years. Of course, Java still doesn't have closures (that's sooooo 1980's and interfaces were a neat idea which introduced a different set of problems for the ones they solved). Further, Java's decision to type the containers instead of the data means they must focus more on class types than class capabilities, thereby eliminating many of the benefits of allomorphism. And not even get into how ridiculously verbose the language is. I don't play "Perl golf". I take the time to write out clear code. It's still far shorter than equivalent code in Java.

Mind you, just because I list these issues with Java does not mean that I think it's a bad language. On the contrary: I happen to like Java. I sometimes program in it and just as Perl has some benefits over Java, the reverse is often true. Java and Perl are both crazy but Perl is my type of crazy.

Re:Catch-up

[ajs]

Most people won't understand why you put these items under "revolutionary", and in some cases, I don't either, but given as how I'm finally getting back in the saddle and working on S29 again, I suppose I should at least be able to clarify these:

• an improved object system (revolutionary in its approach)

  Well, this one is pretty much accurate. The combination of Java-style interfaces, C++-style MI, and Smalltalk/Ruby-style mix-ins in unified and elegant "Role" system is certainly nothing like what I've come across before.

• Register-based VM

  Foul. This is a Parrot feature, and has no real preference for Perl 6 in theory, and very little preference in practice.

• junctions

  Junctions are rarely used, but I'm not sure I'd call them revolutionary. For those who don't know, junctions are unresolved expressions which can have many values at once. The english equivalent would be "any one of Mary, Tom, or Fred," or, "all of the colors; red, blue, and green." In Perl 6, you would say "$Mary | $Tom | $Fred" or "$red & $blue & $green". These are first-class values which can be passed around to functions, added to lists and hashes and evaluated in logical conditions.

• roles

  Roles fall under the object system, and are most of what makes it revolutionary (though the delegation management is pretty interesting stuff too).

• rules and grammars

  Let's be clear: Rules and Grammars aren't terribly interesting on their own. The fact that they are even more deeply integrated into the language than regexps were in Perl 5 is radical to say the least. There will be a build-in Grammar called something like Perl6::Parser, and yes, you can alter it at compile-time or run-time. This is not a unique feature, but it's certainly rare outside of the LISP world.

• continuations and coroutines (not widespread)

  Not widespread outside of the LISP world, but LISP dialects as often have such features as not.

• optional typing and type inferencing (other languages typically don't make this optional)

  I'd take that one off the list. First off, Perl 6 typing isn't optional, you just get a default type (Scalar). Such typing games are not unheard of, especially in the LISP world.

• interoperability with other languages including Perl 5 (because of how easy it is)

  This is no more a Perl 6 feature than it is a Perl 5 feature. In fact, right now Perl 5 (Ponie) is much further along on this front. In reality, this is a Parrot feature, and all languages benefit.

• hyperoperators

  Many lisp variants have similar constructs, but I'm not aware of any procedural equivalents. To those unaware, this is where a single operator applies to a list. For example, "$sum = [+] @list;" That generalizes to any binary operator.

• unification of blocks and closures

  This is, of course, a baby-step on the way to S-expressions. Perl can hardly claim to be revolutionary here. Again, for those unaware, a closure is a code construct that captures its lexical scope and freezes it in time. In Perl 6, various grammatical hooks allow you to treat any block as a closure object, which is tremendously powerful.

Overall, Perl 6 is probably the closest that any procedural language will come for a long time to the power of S-expression-based functional languages. It also retains and enhances the power of the current state of the art in dynamic procedural languages such as Perl 5, Python, Ruby, etc. Perl 6 will certainly be a force to contend with.

Funny thing ...

[Anonymous Coward]

...to post on a site that itself runs on Perl.
Anyway I am not a developer, but I am using Perl to automate management task both on Windows and Linux servers. I can't talk about features of programming languages, I just use and like Perl.
And there comes a time in everyone's life when one feels a need to create some kind of web interface for something like database access, and I thought why not Perl. For a beginner it is not a easy way to know wich way to start. There are dozen different web frameworks. Tired of typing print "something;? OK, there are (many) templating systems, most of them produce many types of output, HTML is just one of them. "There's more than one way..." is what I like about Perl, but sometimes it's nice when one of those ways is easily recognizable example of the rest. My coleague went for PHP ("There's one way to do it, and we'll show you how it's done") because it is easier to start: all PHP books write about the same thing.
It reminds me about Debian-Ubuntu relation (I use both). Debian is everything for everybody, (usable desktop is just one of them), supposibly hard to install. Someone takes Debian, streamlines it into one easy recognizible and comprehensible thing and look what happens. Thousands are happy using their apt-gets and synaptic like it has been just invented. But I believe it's a good thing for Debian too.
So I believe Perl should be "ubuntufied", one of those perl many ways to write web apps should be made "more equal" than the others from perpective of the beginners so ju can have easy jumpstart, and from there you can find your own way.
(I'm reluctant to brag about Perl since I'm not a developer and I can't develop this thing I'm talking about, but here I said it)

Re:Holland, MI?

[Anonymous Coward]

Isn't that where cmdrtaco lives?

OTOH...

[quarkscat]

More code readily available LOCALLY (not via D/L) would be nice. With the exception of old RedHat "Power Tools" kit, I have not seen any ISO images of Perl code or a way to CVS anapshot all the latest code.

It would be very nice to have a local repository of perl code available, without having to get out on the internet to D/L it a chunk at a time. Not everyone who uses perl has a full-time broadband connection.

Re:OTOH...

[chromatic]

Perhaps CPAN::Mini could help you.

Ruby and Python "Power", and the Parrot joke

[SimHacker]

Ian Bicking weighs in on the relative relative power of Ruby and Python, and makes some interesting observations about "Parrot":

I think Ruby on the Parrot VM works better than Python. But, AFAIK, no real language runs on Parrot at this point (even Perl, for which Parrot was written), it's all experiments. I honestly want Parrot to succede; it's currently the only real effort at a community-driven VM, and the only VM written specifically for dynamic languages. But for some reason they can't get their act together.

I would love if Parrot created an environment where Python, Ruby, Perl, PHP, and other open source languages happily coexisted and shared a basic infrastructure. It doesn't have to mean 100% transparency between languages for it to be useful and successful. But at this point it's hard for me to believe Parrot will catch up to other competing runtime environments.

Parrot was a joke, and still is. If the Parrot developers really understood what they were doing, then they wouldn't be trying to do it that way. It's just a sophmoric exercise in mental masturbation. So it's no wonder that the Parrot project is dead in the water, pushing up daisies!

-Don

Re:Ruby and Python "Power", and the Parrot joke

[publius_ovidius]

Dead in the water? Parrot is being actively developed, has part of its development being funded by NLNet, and has made great strides in showing the power of a register-based virtual machine vis-a-vis a stack-based virtual machine. Further, instead of just being a "Perl only" sort of thing, tons of developers in many languages have become excited about what Parrot can do for them and we have active developers coming in from other languages to help out given how excited they are about this. Of course, as the Parrot grant manager (er, this is a new role for me and one that most don't know about), I perhaps see this more than most but you're welcome to sign up on the development lists and see for yourself rather than just take my word for it.

Of course, if you have any substance to back up your "mental masturbation" comments, feel free to share it. I'm sure there are many developers who would be curious to know why they're wasting their time.

Turd Wrapped in Foil != Silver Bullet

[SimHacker]

CPAN is a turd wrapped in aluminum foil, not a silver bullet.

-Don

Mods 5 Interesting?

[truckaxle]

The regular expression support of languages like Python, Ruby, and even C# trump that of Perl. And what do you base this comment on - which is stated as fact with no supporting reference or valid points.

Language post! Bring on the FUD!

[Kirby]

Of course, any time a slashdot article talks about a programming language, there's a concerted effort by the language's detractors to say things like, "Does any one still use Perl?" "C++, isn't that a dead language with C# and Java taking its place?" "Java's just marketing hype, and C# doubly so, nothing beats C." and so on forever.

But of course we do this. As programmers, winning the language evangelism wars is one of the few things that really matters. And by matters, I mean it affects how much money I make.

I'm a good Perl programmer. I'm a novice at several other languages. I could pick them up, but it'll take years before I'm as proficient in anything else as I am in Perl. The same is true for most programmers after they pass the five year mark or so.

So, if the VP of an up and coming company chooses Java, I'm very unlikely to work there. If they choose Perl, I might. And it increases demand for Perl programmers. It's nothing but good for me if there's more options available when the day comes for me to change employers. And so, I have a vested interest in people believing Perl is faster to develop in and easier to maintain than Java or C#.

And so, don't believe me. And don't believe anyone else either who is detracting. It's in their interest to see people start projects in their language of choice. There's very little impartiality here.

Instead, ask yourself: does this language do the job? Is the development time acceptable? Is the performance acceptable?

I think Perl is very hard to beat on development time, and very few people need the performance of C or assembly - but I've just told you that I have invested a lot of time in becoming an experienced Perl programmer, so I want you to believe Perl is the tool to use. I don't think I've attached myself to a bad language, and I think it'll really win a fair fight quite often, but the court of public opinion (especially Slashdot Comments) is just such a terrible place to form technical opinions.

Re:Language post! Bring on the FUD!

[Drathus]

Nothing beats C.

(Sorry... Had to do it. Honest.)

Re:Language post! Bring on the FUD!

[BerntB]

any time a slashdot article talks about a programming language, there's a concerted effort by the language's detractors to say things like, [...] But of course we do this.

I like Perl and I agree with you -- it is one of the best tools around, for quite a lot of problems.

I do language evangelism, but I really won't sink so low that I go around trolling discussions of other languages. I am not that much of a pathetic asshole that I sell my intellectual integrity for the possibility of money.

(-: I had allergy/stomach problems this last winter and lost 15 kg. I can tell you from firsthand experience that starving is no fun, but I'd rather do that than documentation. Money isn't everything. :-)

Compare Perl to Python, not PHP

[SimHacker]

Of course it's easy to compare Perl to a lame language like PHP, but how is Perl any better than real languages like Python, Ruby or Lisp, which make it much easier to learn, maintain, read and reuse code written by other people?

It's easy to do all that you require in Python by integrating existing modules: imaplib IMAP4 protocol client module, Integrating Python and MS Excel, pyExcelerator library for generating and importing Excel files, Python Midi Package for handling MIDI input and output.

-Don

Re:Something would get in the way.

[Anonymous Coward]

Unreadable to you perhaps.

I have spent the last week-end reading and editing perl modules from CPAN to extend some functionality. I am a Java programmer professionally, and rarely have I seen such beautiful and well-written code in my 22-year programming life.

Perl is only unreadable to those who have not spent time learning it, expecting it to be as easy as other languages. These are usually the same people who say C++ templates are unnecessary obfusaction of code - they have never seen them used properly or even learned their full potential.

Perl is designed for primarily usability - not ease of use. It also helps that CPAN is full of amazing code, most of which is so well written that its a joy to read and work with.

Generalized Overloading in C++ blows away Perl

[SimHacker]

With an attitude like that, I'll bet C++ would really appeal to you, too -- you should definitely check it out! Why wait for Perl 6 when you can start learning C++ today!!! C++ has just as many cool buzzwords as Perl, and it tries to go down even more dead-end paths at once! You'll just love operator overloading and templates, and you'll want to use all its advanced features at once in every program you write! But if you don't have time to learn C++, then why not adapt its best ideas to Perl?

You'll really be amazed by Bjarne Stroustrup's brilliant extension to C++: "Generalized Overloading for C++2000", and I'm sure you'll want to delay the release of Perl 6 some more until all these cool features can be appropriated and hacked into the Parrot VM.

Here are some of the most amazing features of Generalized Overloading in C++2000, that you will never be able to live without, once you've tried them:

With the acceptance of the ISO C++ standard, the time has come to consider new directions for the C++ language and to revise the facilities already provided to make them more complete and consistent. A good example of a current facility that can be generalized into something much more powerful and useful is overloading. The aim of overloading is to accurately reflect the notations used in application areas. For example, overloading of + and * allows us to use the conventional notation for arithmetic operations for a variety of data types such as integers, floating point numbers (for built-in types), complex numbers, and infinite precision numbers (user-defined types). This existing C++ facility can be generalized to handle user-defined operators and overloaded whitespace.

[...] Here, I describe the more innovative and powerful mechanism for overloading whitespace. Consider x*y. In programming languages (e.g. Fortran, Pascal, and C++), this is the conventional notation for multiplying two values. However, mathematicians and physicists traditionally do not use the operator *. Instead they use simple juxtaposition to indicate multiplication. That is, for variables x and y of suitable types,

x y

means multiply x by y.

[...] Overloading Separate Forms of Whitespace

There are of course several forms of whitespace, such as space, tab, // comments, and /* */ comments. A comment is considered a single whitespace character. For example,

/* this comment is considered a single character
for overloading purposes
*/

It was soon discovered that it was essential to be able to overload the different forms of whitespace differently. For example, several heavy users of whitespace overloading found overloading of newline ('\n'), tab ('\t'), and comments as the same arithmetic operator is counterintuitive and error prone. Consider:

double z1 = x y; // obvious
double z2 = x
y; // obscure
double z3 = x /* asking for trouble */ y;

In addition, different overloading of different whitespace characters can be used to mirror conventional two-dimensional layout of computations (see below).

Stavtrup claimed that it was important to distinguish between different number of adjacent whitespace characters, but we did not find that mechanism useful. In fact, we determined it to be error-prone and omitted for Standard C++.

Overloading Missing Whitespace

After some experimentation, it was discovered that the overloading mechanism described so far did not go far enough. When using the mechanism, the physicists tended to omit the space character and write

xy

rather than

x y

This problem persisted even after the overloading rules had been clearly and repeatedly explained. What was needed wasn't just the ability to overload explicit use of whitespace, but also implicit application. This is easily ach

Perl can't see the syntax for the trees

[SimHacker]

The meaning of a program should be clear and unambiguous to the reader, and not require you to do a lot of pattern matching and apply a bunch of rules and heuristics to understand what it means. Most copies of the K&R C manual fall open to the same page: the table of operator precedence. That shows that the skyscraper of precedence rules was a mistake in the design of the language, but Perl takes that idea and runs with it, in many different directions!

That example of how Perl 6 is fucked is that "print (1+2)+3" will not be the same as "print(1+2) + 3". That's MUCH more confusing and unexpected than Python or almost any other language! The white space that Python requires simply makes the program clearer and easier to read, but Perl's astonishingly arbitrary parsing heuristics make it extremely difficult to understand, and horribly easy to make dreadful mistakes.

Yet you leap to defend Perl 6's bizarre and unexpected interpretation of white space as if it were a benefit??! With a spin like that, you should apply for Scott McClellan's job. Are you just one of those slackers who loves Perl because of its deep flaws, due to the job security it gives you? That's a BAD long term plan.

PS: In case you're like one of the people working on Parrot who take jokes much too seriously and can't detect sarcasm, my previous message about C++ Generalized White Space Overloading was a joke, and the publication date of that Generalized Overloading for C++2000 proposal (which was really written by Bjarne Stroustrup), was April 1.

-Don

Re:Perl can't see the syntax for the trees

[chromatic]

The meaning of a program should be clear and unambiguous to the reader...

Perhaps the reader should bother to learn the language (or at least consult the error messages) before complaining that it's too difficult to read.

I can't read Asian pictograms or any Sanskrit-derived languages, but somehow a couple of billion people in the world manage to get by with them.

Re:Perl can't see the syntax for the trees

[SimHacker]

I bothered to learn Perl in 1989, and have been watching it decay ever since. But I've also bothered to learn other languages that are much better than Perl, and I choose to use those instead.

So let me get you right: do you actually think it's a good thing that Perl 6 treats "print (1+2)+3" differently than "print(1+2) + 3"? How is that "easier to read"?

-Don

Re:Perl can't see the syntax for the trees

[chromatic]

I don't think it's a good thing, but I know why it's there and I think it's a difficult-to-avoid syntactic trap. All languages have them; consider the ambiguous pronoun antecedent problem in English.

There are certainly ways around it too. On the compiler side, it's possible for the parser or tree transformer to detect an ambiguous expression of this sort and emit a warning or error message. On the programmer side, add parentheses to ambiguous expressions.

I consider separating a function parameter list from the function name akin to splitting a word in English, so I don't worry too much about this problem in general. I've also encountered it only twice in years and years of programming Perl 5. Maybe it makes me an awful person to believe that no designed language can completely eliminate ambiguous constructs. I can only imagine how tedious such a language would be.

Re:Perl can't see the syntax for the trees

[jdavidb]

That example of how Perl 6 is fucked is that "print (1+2)+3" will not be the same as "print(1+2) + 3".

I'm surprised nobody pointed out to you that this is incorrect.

Re:Perl can't see the syntax for the trees

[jdavidb]

Oh, wait. You were talking about Perl 6. I may be completely wrong, then.

But it doesn't change how great Perl 5 is. :)

Re:Perl can't see the syntax for the trees

[SimHacker]

It just means your Perl 5 programs will break in many horrible and unexpected ways, if you ever try to port them to Perl 6. But that's absolutely wonderful, if you enjoy Perl's flaws because you want to lock your employer into depending on you and paying you to keep the code running for many years.

Using Perl is simply foolish, irresponsible, short sighted, and self serving. But if you want to really "stick it to the man" who's paying you to design their web site, then it's the perfect weapon of mass destruction and corporate sabotage.

-Don

Re:Perl can't see the syntax for the trees

[photon317]

Part of the plan is the ability to mechanically translate Perl5 to equivalent Perl6 without any human intervention.

I take great offense at your insinuation that by using Perl I'm foolish, irresponsible, short sighted, and self serving, or that I would try to lock my employer into anything. I think you've brainwashed yourself into hating perl after seeing too many examples of bad perl. There is good perl, and there are good perl programmers. I'm nearing completion right now on an enterprise-grade perl application. It will probably finish at ~12,000 lines of code, god knows how many multiples of that the same task would take in many other languages or environments.

It's all written to a clear, consistent style. It's got correct OO where appropriate, and code re-use in the form of non-OO libraries where appropriate. It runs on several distinct *nix environments, some of which were installed a decade ago and have never been patched. It was developed in about 1.5 man years (1 real year). It's wide open, with a public (within the company) Subversion server tracking all changes, and a public Bugzilla server for defect tracking. Plans are in the works to bring other capable people in the group up to speed on the architecture so that they can extend and support it, and to make sure the company can reliably do so long after I or anyone else is gone.

I'll say it one more time, for people who are too fucking foolish, irresponsible, short-sighted, and self-serving to see past their own prejudices:

Perl is a badass language, don't blame the language for the code you've seen some crappy programmers generate with it. And definitely don't accuse me of personal and/or corporate irresponsibility, dipshit.

Guile

[SimHacker]

The Gnu kernel is being actively developed, and has bla bla bla...

Why aren't you just extending Guile, which has been declared the official GNU scripting langauge by none other than RMS himself.

Tom Lord discusses the history of Guile, in the context of the great TCL war, which happened just before Java came onto the scene.

Ian Bicking discusses some of the reasons why Guile failed to gain any traction.

-Don

Re:Guile

[publius_ovidius]

Nice job changing the subject. I see you really don't have much to say. My apologies for wasting your time.

Re:Guile

[SimHacker]

Bad job avoiding the point. Read the post by Ian Bicking discussing how Guile relates to Parrot.

Those who ignore history are bla bla bla...

-Don

Re:Guile

[publius_ovidius]

If you read through your post, you see that you talked about Guile a few times and gave no indication that in clicking a link apparently about Guile that I might, just might, have gleaned a bit of insight about why you object to Parrot. If you have bothered to say up front "hey, this has info relevant to my Parrot objections", I would have clicked the link.

Of course, the main points of that link were lack of developer effort (Parrot has tons of devopers compared to Guile though I confess we don't have enough) and the issue of string handling in different languages (a problem that Parrot addressed a long time ago). There's a claim that a CLR will force languages to adopt a common set of semantics. That claim is false. If you pay attention to current Parrot development, you'd know that. Or if you just asked instead of assumed, you'd know that.

If you have anything current to say, we're all ears. Post it to the development lists, though. I really don't want to bother arguing with someone who is attacking a project they clearly have little knowledge of.

Re:Guile

[SimHacker]

You wouldn't think I was changing the subject if you bothered to read the articles I pointed to. There's some really important stuff in there that I think you should know, otherwise you're going to re-discover it all the hard way, when you're up the creek without a paddle. Don't think Parrot is the first time somebody's tried something like that. Guile started with a much more coherent language (Scheme) than Parrot is saddled with (Perl), and Guile didn't succeed for many of the same reasons that Parrot will fail.

From Ian Bicking's remarks in the discussion titled "A vision for Parrot":

[...] I don't think this is really correct -- I think it was mostly because Tcl was a lame language, and was being pushed as an application scripting language. Of course, Lisp is close to RMS's heart, which is why the FSF proposed Scheme as an alternative over other languages. Simplicity was always essential for an application scripting language, which is probably why Perl wasn't a serious contender. It was also a long time ago, when Python was young. And the translation dream.

[...] But you're right, it is a really hard problem anyway. And there's lots of details.

You have to deal with competing naming conventions -- Scheme allows almost all characters in its functions, for instance. Lots of languages have different namespaces for functions and variables. Something like Smalltalk has an entirely different notion of method naming, even though its semantics are close to these other languages. It seems small, but it's a pain.

There's also issues with errors -- if you want a usable language, a traceback like Python's should be a bare minimum in this day. But what does that look like with mixed languages? What does that even look like with one language, ontop of a VM that's meant to be generic? This is often dealt with very poorly as VM developers mostly test with trivial and correct programs.

And of course there's a huge number of problems with objects. Mutable vs. immutable strings being a good example -- it's not just a n x m problems, it's a straight-up no-good-solution problem. There's no *right* way to deal with this. Each language means something different by "string", and yet it's so important to each language that if you expect them to interoperate *at all* you need to deal with that. Do you annotate functions and methods so that some automatic interoperation layer can be used? Do you force users to use awkward constructions, exposing the fact that they're accessing another language? Do you create wrappers? Do you just punt, and assume some simplistic behavior will be good enough, even though it's not predictable to the programmer?

C#/CLR I believe has resolved these issues by forcing the languages to adapt to a common set of semantics. I just can't imagine a common set of semantics that would bring Perl and Python together -- Python and Ruby, sure, but there's not enough common ground with Perl to do that.

Re:Guile

[SimHacker]

<understatement degree="gross">Having tons of developers isn't necessarily an advantage when designing the core of a runtime system.</understatement>

Thanks for your open invitation join the big party going on in the kitchen, and throw my own ingredients into the delicious rock soup you all are cooking. Please seriously consider my proposal to add generalized overloading of white space to Parrot, based on Bjarne Stroustrup's brilliant and well thought out paper: Generalized Overloading for C++2000.

What good is Parrot, if it can't support all the wonderful features of C++?

-Don

my $foo vs my ($foo)

[Anonymous Coward]

Ok, I'll bite - what is the difference?
I've been programming in Perl for 2 years and I honestly do not know why I would ever want to use the my ($foo) form for a single scalar value.

Re:my $foo vs my ($foo)

[chromatic]

The parentheses put the right-hand side of the expression in list context.

Not to mention...

[ESqVIP]

...you don't have to rearrange everything when you include a new capture. This can be quite useful if your regular expression is somewhat complex and keeps changing, or if you'd like to use more than one regular expression (which match the captures in a different order) with the same piece of code.

I don't normally use named captures, but sometimes I fall into the situation I just described.

I'm glad Allison is gone

[Anonymous Coward]

she didn't know shit about computers, I mean what woman does?

Re:Perl's place in todays world?y

[ACORN_USER]

Hmm. Why do I do perl? Because Perl is my B!tch!

I just succeeded in making governance people realise that Perl is in fact a language used for development and has long grown out of its early scripting days. I fight for advocacy wherever I work and always insist on there being an element of perl.

Why use Perl over other languages? Why not use both?

o Perl is a super/fast language for prototyping
o Perl is accessible to both lame-brains and software engineers.
o The language provides self-governed constructs for object orientation - yet in the fashion of all things perl - this can be violated to your hearts content.
o The idea of a large repository of re-usable components, all having to adhere to (moderately) high standards, is unique to Perl. CPAN, together with CPAN+, make reuse and dependency management a breeze.
o XS, Inline::* give perl developers the flexibility to easily integrate legacy/vendor libraries into perl applications.
o Perl's reg-exp engine is father of many modern day implementations and combined with the ease of the language makes an excellent tool for text processing
o SOAP::Lite makes for quick integration and prototyping of applications consuming data from web services

There is bad also (although point 2 above is not exactly al. that great). I have never worked in a place where a wannabe perl developer hadn't left a legacy of poorly written, bloated and suffocating code. I think that Larry Wall once compared Perl to English. He stated that in English an infant can communicate in the same language as a Professor of Linguistics. The only difference being the elegance with which they communicate their message. The same goes for Perl, but more so than other languages. To draw another similarity with linguistics, Perl has the danger of allowing newbies to code in in-coherent slang. As an emergent property of the language, they usually manage to get their message out - some of the time.

Use the right tool for the right job. It's not bad to be honest and admit that sometimes, or in many cases, perl, python, ruby, lisp or some other unfashionable language are suited to your solution. Or than once started the language will open itself up to us. In industry people argue that they have to focus on some industry saturated skill and utilise this for 'everything' - all for the sake of utilising their skills pool. I'm sure that a 'good' developer can utilise whatever technology she considers suited to the problem at hand. Especially with languages like Perl and Python. 10 minutes with a man page and she'll be building you your very own HAL.

It's the fastest tool I know for knocking 'just about anything' out 'very' quickly.

Why do you troll?

[BerntB]

Why aren't you just extending Guile, which has been declared the official GNU scripting langauge by none other than RMS himself.

Why don't you go discuss Guile with the large development community around it instead of trolling discussions about other languages?

Oh, sorry, there are no other people. (-: Everyone left the Guile community after you started advocating it? :-)

When you look at the previous posts by you, you look quite serious. Here you seem to do trolls about language design choices (spaces as part of syntax) and dead scripting languages. Have you started doing drugs? Found a nice bridge to live beneath?

I believe so

[JimTheta]

It's where Slashdot started, I believe. The guys went to Hope College, I think it was.