For the developer evaluating programming languages the question of which languages to learn rarely involves "can this language do what I want it to do?" This is because virtually all programming languages (except ANSI SQL, if you consider it a language) are Turing Complete. Instead, what I see, over and over, is discussions over two things:
So consider COBOL. Yes, I can get a job in that language, but do I like it? No. C is the same way for me. There are plenty of jobs out there, but I loathe how close it is to the metal because I like solving problems, not worrying about how to reallocate memory for a resized string. So if I were to assert that either COBOL or C is dead, that might be true ... for me. If I assert they're dead on the basis of job stats, I'd be sorely mistaken.
Naturally, when I hear the old "Perl is dead" saw, I know the job stats and I know they're not referring to them. However, what they invariably refer to is the "buzz" around Perl, measured by TIOBE, Google Trends and other tools. The buzz can be important, but at the end of the day, buzz won't matter if the tool is useful enough. Consider how much people complain about Perl's sigils. Now look at the following code:
$cssClass = "";
if ( $element->isOpen() ) {
$cssClass = ' class="selected"';
}
if ( !$element->isHiddenInNavigation() ) {
$filepath = $element->getId() . ".html";
if ( substr( $element->getFilePath(), 0, 4 ) == 'http' ) {
$filepath = $element->getFilePath();
}
$result .= ''
. $element->getLabel() . ''
. $this->generate( $element->getChildren() ) . '';
}
Assuming that has no errors, we know that it looks like Perl, but isn't (look closely if you don't see it). That's PHP code. So though people whine about sigils in Perl, you've got the same issue with PHP, but why has PHP crushed us in the Web space? Well, for one thing, people seem far happier with modphp than mod_perl. It's very easy to develop and deploy apps despite its inconsistencies and lacking many of the useful features that Perl 5 has.
A second issue, however, is the one which will continue to keep Perl 5 sneered at:
public function setHiddenInNavigation($hideInNavigation) {
return $this->hideInNavigation = $hideInNavigation;
}
That's PHP, too. Until we can make Perl 5 code that clean and simple and in the core[1], we'll continue to be sneered at. It's embarrassing to read through PHP code and, once again, sigh at basic, basic things Perl 5 is missing (yes, PHP is missing many things too, but I'll bet most 9 to 5 programmers would take method signatures over closures any day of the week).
So really, programmers are asking if a language can do what they want it to do; at least on a syntax level. That's because syntax is a large part of the aesthetic appeal of a language.
So in answer to the question "Why Should I Program in $Language?", what the language can do (functionally, not syntax!) isn't really the issue. Nor is the "are there jobs?" because we know there are plenty of Perl jobs out there (not in all areas, though). The real question is "will I like it?" and from the numerous Perl hate posts, this is very much an open question but Perl largely has itself to blame.
1. We have a better object system than you do! Just install Moose (but be aware that it might have backwards-incompatible changes in a few months). Oh, to install it, you just need to configure CPAN. What? You don't have root? Here's how to configure CPAN to install in a local directory. And be aware that Module::Build and ExtUtil::MakeMaker take different arguments, and don't forget that ...
Did I hear in my vague readings of p5p that this might be possible in 5.12?
If so, it'd be SO nice to have:
class Foo isa Bar {
method init(%options) {
$self->{some_key} = $options{some_key}// "default";
...
}
}
Re:Programmable keywords...
rafl on 2009-12-01T15:40:23
FYI, MooseX::Declare provides exactly that already (except you inherit with "extends", not "isa").Re:Programmable keywords...
Matts on 2009-12-02T17:42:25
Yeah I know, but it's very heavyweight (brings in Moose).
Re:Programmable keywords...
jrockway on 2009-12-08T17:48:53
Plain Perl OO is also very heavy, it brings in perl and entire OS. Are you sure that bringing in Moose is a legitimate concern, or are you just afraid to look at something popular out of fear that it might turn out to be better than complaining?Re:Programmable keywords...
Matts on 2009-12-10T10:05:40
I think you're assuming I *haven't* checked it out.
We have a better object system than you do! Just install Moose (but be aware that it might have backwards-incompatible changes in a few months)
What changes in a few months? I am not aware of such plans. We are generally highly responsible about our backwards incompat changes. Changes happen and sometimes they are hard and ugly, this is the real world after all and they need to happen. But
I suspect your just being sarcastic and playing the devils advocate here. Your right, having a decent object system that is not in core and needs to be installed via CPAN is ugly.
- Stevan
Re:Are you planning changes we don't know about?
Ovid on 2009-12-01T15:50:03
Yes, I am being a bit sarcastic, but more than once we've not been in a position to update Moose on our BBC project because of Class::MOP (and this has happened with Catalyst, too). The most important Perl projects and the ones we depend on are the ones we have difficulties keeping up with. Even if you rarely change Moose, or Class::MOP, or Catalyst, or [insert favorite module here] with backwards-incompatible changes, then you have to consider the chance of said changes happening in all of them, not just one of them.
That being said, I'm still quite happy with Moose and it's clear that the focus on backwards-compatibility has been helpful.
Re:Are you planning changes we don't know about?
Stevan on 2009-12-01T17:44:31
Yeah I know, I still have servers running Moose 0.24, so I am with you. We have been discussing trying to make these things smoother in various ways so that people can upgrade and say, get a performance improvement, but opt out of a feature/API change. Similar to the use feature in 5.10. It is still not perfect, but it might help ease those of us (me included) who have to deal with production environments all the time and for whom upgrading it usually not an option.Re:Are you planning changes we don't know about?
Mr. Muskrat on 2009-12-01T18:39:59
I'd be happy with a decent object system that is not in core if it didn't require half of CPAN as prerequisites.
Here at work, I have yet to be able to resolve all of the dependencies. As soon as I get a minute or two to spare (wishful thinking really), I might actually be able to track down the troublesome module(s).Re:Are you planning changes we don't know about?
Stevan on 2009-12-01T21:53:06
It shouldn't take too long since you only have 16 non-core dependencies to go through. FWIW, I am pretty sure there are more then 32 modules on CPAN now, it has grown a lot in the past few years
;) Sorry, couldn't resist. But in all seriousness we would be happy to help with this either on IRC or the Moose mailing list. The biggest problem I have seen when installing Moose on a bare bones system (and yes I have done it many MANY times so I am empathizing and not mocking) is that we require more up to date versions of the Test:: toolchain, which can get quite ugly sometimes.
- Stevan
Re:Are you planning changes we don't know about?
Mr. Muskrat on 2009-12-04T21:05:49
Stevan, I just don't have the bandwidth to deal with it right now. As soon as things slow down here to only a relatively hectic pace then I'll try it again.Re:Are you planning changes we don't know about?
Mr. Muskrat on 2010-01-04T18:53:17
I bit the bullet today and finally got Moose installed.
I installed the prereqs one by one starting from the bottom of the list. Once I thought I had them all installed, I tried to install Moose and it couldn't find about five of the prereqs so I bailed.
I tried to install each of them again only to be told that four of the five were already installed. Class::MOP just did not want to install... Or so it seemed.
I traced the problem to the order of my include paths. Once that was fixed, Class::MOP and Moose installed cleanly.
Re:It's so sad to say...
chorny on 2009-12-02T00:27:24
It is simple to configure to run
.pl as perl for Apache. But I prefer security of cgi-bin. It means that none will be able to download my non-executable files like templates or data files.
sub setHiddenInNavigation {
my ($this, $hideInNavigation) = @_;
$this->{hideInNavigation} = $hideInNavigation;
}
really isn't any worse than the PHP version. Sure, you gain an extra line, but you 'sub' is shorter than 'function', and you can lose the 'return' and 'public'. So, less typing overall.
Re:Perl setHiddenInNavigation is not really worse
Ovid on 2009-12-01T17:40:09
What happens if you call it with 17 arguments? A signature can guard against that. Second, what happens if you misspell the hash key? You may or may not get an error at that point, but have it happen later on (if at all). PHP's version will have a failure when calling a non-existent method. (I also hope that PHP's syntax allows validation rather than blanket assignment, but I don't know it well enough.)
Re:Perl setHiddenInNavigation is not really worse
derobert on 2009-12-01T18:16:45
What happens if you call it with 17 arguments? A signature can guard against that.
You'd expect that to be the case, but it isn't in PHP. PHP actually handles that exactly like my Perl version---it ignores the extra 16 arguments. That's how PHP implements variable numbers of arguments. So, PHP's method signature's have fooled you.
Second, what happens if you misspell the hash key? You may or may not get an error at that point, but have it happen later on (if at all).
This is indeed one drawback to the use of hash keys for object variable storage. But... PHP does the same thing. It'll happily create that variable for you on assignment.
(I also hope that PHP's syntax allows validation rather than blanket assignment, but I don't know it well enough.)
Not sure if its been added in PHP5, but 4 didn't.
Was that all pretty much just saying "we need an object system in core?"
+1 for sentiment, but we need more than sentiment. We need a plan that p5p supports. (And, probably, a long-term feature branch in the core to prototype, test and get buy-in around.)
As for the toolchain footnote, you're right, which is why I'm working on things like this and this. It can get better and it will get better.
-- dagolden
Re:To summarize your post...
chromatic on 2009-12-01T18:57:34
Was that all pretty much just saying "we need an object system in core?"
We need an object system and function/method signatures.
We need a plan that p5p supports.
I have no idea how to create this.
Re:To summarize your post...
Ovid on 2009-12-01T22:18:41
The function/method signature issue is very problematic because part of that deals with the philosophy of Perl. I, for example, sometimes find that static binding (compile time) of methods would make some problems magically go away, but I doubt that Perl 5 will ever be able to support that. Of course, signatures also might imply multimethods. That's another issue which would give people fits. Should all methods be multimethods or should we have to specify this directly?
Re:To summarize your post...
chromatic on 2009-12-02T08:02:47
Here's a secret, though: Perl 5.12 or 5.14 or whatever doesn't have to support all of those features to have useful function/method signatures. Even supporting only required positional parameters is useful for some 80% of extant code.
Re:To summarize your post...
jrockway on 2009-12-08T17:51:23
Considering all of this stuff already works in Perl 5 and is limited to a given lexical scope, I am having a really hard time seeing how this is 'impossible'.
The 1999 standard added common table expressions, and the 2003 standard added window functions. Those made it Turing complete.
See http://assets.en.oreilly.com/1/event/27/High%20Performance%20SQL%20with%20Postg
Re:ANSI SQL is Turing complete
runrig on 2009-12-03T17:56:18
That is cool. I was used to calling them analytic functions from Oracle, and googling for "analytic functions" and PostgreSQL only brought up posts from people wanting them in PostgreSQL. Now that I know that they're "window functions" they're easy to find:
Window Functions