The Perl Foundation Gets New Leadership 145
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."
What about Perl 6? (Score:3, Interesting)
Through "design"? (Score:4, Interesting)
I know this is a cheap shot but its an important one. On the site (excluding Perl 6)there are THREE [google.co.uk] 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.
There will always be a place for Perl. (Score:2, Interesting)
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. (Score:3, Interesting)
Re:Through "design"? (Score:3, Interesting)
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"? (Score:3, Interesting)
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:Perl's place in todays world? (Score:2, Interesting)
Re:There will always be a place for Perl. (Score:3, Interesting)
my ($foo, $bar) = $something =~ m#(.*)!(.*)#;
$foo gets the first one, $bar get's the second one.
Dear Perl letter (Score:4, Interesting)
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:Perl's place in todays world? (Score:5, Interesting)
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.
Funny thing ... (Score:1, Interesting)
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:Perl's place in todays world? (Score:4, Interesting)
Apparently Amazon thinks so. They started using Perl for their new web development a couple of years ago.
Ruby and Python "Power", and the Parrot joke (Score:2, Interesting)
Ian Bicking [ianbicking.org] weighs in on the relative relative power of Ruby and Python, and makes some interesting observations about "Parrot":
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:Perl's place in todays world? (Score:2, Interesting)
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? (Score:5, Interesting)
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.
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 [cpan.org] 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 [cpan.org] 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:Catch-up (Score:5, Interesting)
80% catch up? I think your math is off.
Catch up:
Revolutionary (items in parentheses explain why some "common" features are included here):
(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:Perl can't see the syntax for the trees (Score:2, Interesting)
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.