Ask HN: Is Perl dead?
139 comments
(Second try at this)
First, anyone who says that Python or Ruby is not even comparable to Perl is full of it or very mistaken. They are close enough that we quickly run into the narcissism of small differences [1].
Second, in my experience HN ranges from uninterested to hostile when it comes to Perl. I read lots about Perl, but many of the blogs or forums I frequent are Perl-centric. My point is simply that you shouldn't judge by "what you read" if what you read is a function of what you choose or who you follow.
Third, and most importantly, the Perl5 community doesn't seem anywhere near dead. Off the top of my head, I'm particularly happy with a slew of new tools for working with Perl and CPAN: cpanm[2], perlbrew[3], cpan-outdated[4], pmuninstall[5], cpansearch [6] (written in C, but obviously made for the Perl community). There's also Plack[7] for modern Perl webapps. Finally, consider the whole Modern Perl[8] movement.
[1] http://en.wikipedia.org/wiki/Narcissism_of_small_differences
[2] http://github.com/miyagawa/cpanminus
[3] http://github.com/gugod/App-perlbrew
[4] http://github.com/tokuhirom/cpan-outdated
[5] http://github.com/xaicron/pm-uninstall
[6] http://github.com/c9s/cpansearch
[7] http://plackperl.org/
[8] http://github.com/chromatic/modern_perl_book
First, anyone who says that Python or Ruby is not even comparable to Perl is full of it or very mistaken. They are close enough that we quickly run into the narcissism of small differences [1].
Second, in my experience HN ranges from uninterested to hostile when it comes to Perl. I read lots about Perl, but many of the blogs or forums I frequent are Perl-centric. My point is simply that you shouldn't judge by "what you read" if what you read is a function of what you choose or who you follow.
Third, and most importantly, the Perl5 community doesn't seem anywhere near dead. Off the top of my head, I'm particularly happy with a slew of new tools for working with Perl and CPAN: cpanm[2], perlbrew[3], cpan-outdated[4], pmuninstall[5], cpansearch [6] (written in C, but obviously made for the Perl community). There's also Plack[7] for modern Perl webapps. Finally, consider the whole Modern Perl[8] movement.
[1] http://en.wikipedia.org/wiki/Narcissism_of_small_differences
[2] http://github.com/miyagawa/cpanminus
[3] http://github.com/gugod/App-perlbrew
[4] http://github.com/tokuhirom/cpan-outdated
[5] http://github.com/xaicron/pm-uninstall
[6] http://github.com/c9s/cpansearch
[7] http://plackperl.org/
[8] http://github.com/chromatic/modern_perl_book
For a while, maybe 5+ years ago (7? I can't remember clearly) it seemed like Perl was stagnating a little. This was about the time Ruby really seemed to take off, and some neat Python projects appeared (e.g. Gentoo Linux).
Now, even though the core language hasn't changed, there seem to be all sorts of clever Perl modules appearing which take advantage of a lot of Perl's highly flexible nature.
I really like Ruby myself, and really hate Python (even though I have to use it at work) but when the other languages fail me, I can almost always turn to Perl in a pinch and get it to do what I want. I also have to admit that the potential power of Perl6's syntax is a little astonishing; I think I would pick Perl6 over Ruby, for example.
Now, even though the core language hasn't changed, there seem to be all sorts of clever Perl modules appearing which take advantage of a lot of Perl's highly flexible nature.
I really like Ruby myself, and really hate Python (even though I have to use it at work) but when the other languages fail me, I can almost always turn to Perl in a pinch and get it to do what I want. I also have to admit that the potential power of Perl6's syntax is a little astonishing; I think I would pick Perl6 over Ruby, for example.
> really hate Python
Why?
Why?
I can't speak for him, but it looks a lot like my pre-code scribbles. As someone who takes pride in being a fleshware translator of pseudo-code to real-code, I feel indignant at the sight of executable, Englishy specification.
High praise or a heavy put-down?
Also, I seem to hold the Guy Steele languages in highest regard, and consider the rest passable toys. C, Common Lisp, Scheme, Java, Fortran .. somehow they feel real. You crack open the spec and you're quickly welcomed into an intelligent dialog with the best minds in systems programming. I read several chapters of the Java spec last night and learned more about the language in one night than weeks of "googling" Ruby. The GSL-school of specification is precise, uses a well established vocabulary, and explains the syntactic and semantic rules of the language, along with their required execution environment. Not a word is said about add-on packages, installation crap, compiler internals or how to fork the language on github.
Compare these two and see what I mean:
http://docs.python.org/reference/index.html
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC....
See how much more detailed the Java specification is; although the language has more features, the spec manages to be much more succinct and precise. The Python spec is littered with references to "CPython" and the internals of an specific compiler.
High praise or a heavy put-down?
Also, I seem to hold the Guy Steele languages in highest regard, and consider the rest passable toys. C, Common Lisp, Scheme, Java, Fortran .. somehow they feel real. You crack open the spec and you're quickly welcomed into an intelligent dialog with the best minds in systems programming. I read several chapters of the Java spec last night and learned more about the language in one night than weeks of "googling" Ruby. The GSL-school of specification is precise, uses a well established vocabulary, and explains the syntactic and semantic rules of the language, along with their required execution environment. Not a word is said about add-on packages, installation crap, compiler internals or how to fork the language on github.
Compare these two and see what I mean:
http://docs.python.org/reference/index.html
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC....
See how much more detailed the Java specification is; although the language has more features, the spec manages to be much more succinct and precise. The Python spec is littered with references to "CPython" and the internals of an specific compiler.
You are the first person I've encountered that thinks ill of the fact that Python reads like pseudo code.
In my mind, it does it in a way that remains succinct and strict, thus avoiding the abomination of "enlishy" code (AppleScript, SQL to some extent, etc.)
In my mind, it does it in a way that remains succinct and strict, thus avoiding the abomination of "enlishy" code (AppleScript, SQL to some extent, etc.)
It was an earned compliment, given in reluctance.
> it looks a lot like my pre-code scribbles
Absolutely, and I mostly write ruby. I actually love that about python. But it feels optimized for writing code with a pen, not with a keyboard. Come to think of it, I don't prefer either for the reading of other's code. But ruby and perl seem to flow from my keys much more naturally than python.
Maybe if I switch from vi to emacs I'll change my tune? ;)
Absolutely, and I mostly write ruby. I actually love that about python. But it feels optimized for writing code with a pen, not with a keyboard. Come to think of it, I don't prefer either for the reading of other's code. But ruby and perl seem to flow from my keys much more naturally than python.
Maybe if I switch from vi to emacs I'll change my tune? ;)
I don't _hate_ Python, I just dislike it. I religiously indent my code in every language, but the significant whitespace bothers me. You can't have multiline lambdas. "There should be only one way to do it" bothers me. I always miss blocks. Reddit's blatant, blind hatred of Ruby and intense love of Python really turns me off. Guido's lack of understanding of TCO is embarassing. (though I've seen worse...)
All of these things are not dealbreakers, and I'd rather code in Python than several other languages. But I never actively want to develop in it.
All of these things are not dealbreakers, and I'd rather code in Python than several other languages. But I never actively want to develop in it.
No, it isn't dead by a long shot. We're just busy doing stuff. Core development (including the release frequency) has been more active than it has been in years. Most of the new developments happen around things like Catalyst and Mojo (Web Frameworks), Moose (OO and Meta-OO), Plack (Web Application Deployments), KiokuDB (Object-Graph storage), syntax extensions, Dist-Zilla (release management) and others. The testing and documentation "movements" are still strong and getting stronger. The toolchain is still being improved (telemachos named a few good examples). If you want to take a look at what the community is doing, I'd suggest reading the IronMan planet at http://ironman.enlightenedperl.org/
There aren't many people using Perl for web applications, but there's lot of other (and in my opinion, more rewarding) work being done in it: email security, bio-informatics, "devops" (infrastructure as code) tooling. In addition, from what I know, Amazon still uses it extensively. Generally, however, these jobs (e.g., my last one in an email security company) usually combine Perl and C/C++ rather than being purely in Perl.
That being said, Ruby is close enough to Perl to where it would not be difficult for you to pick it up and in all likelihood you'll actually enjoy it (especially if you're been writing clean, object oriented Perl). If there's a Ruby-based job that interests you, go for it.
I personally, "moved on" (for non-trivial personal projects) onto Scala and OCaml: I actually like static typing (when there's type inference to reduce verbosity) and the mixed paradigms and "terse syntax" in these languages appeal to my Perl hacker DNA. The fact they're also blazingly fast means I don't have to "go down" to C++ (really, not all that hard in Perl with XS): the scalability of these languages (being suitable to whole variety of tasks, from simple scripts, to full systems) also appeals to me.
That being said, Ruby is close enough to Perl to where it would not be difficult for you to pick it up and in all likelihood you'll actually enjoy it (especially if you're been writing clean, object oriented Perl). If there's a Ruby-based job that interests you, go for it.
I personally, "moved on" (for non-trivial personal projects) onto Scala and OCaml: I actually like static typing (when there's type inference to reduce verbosity) and the mixed paradigms and "terse syntax" in these languages appeal to my Perl hacker DNA. The fact they're also blazingly fast means I don't have to "go down" to C++ (really, not all that hard in Perl with XS): the scalability of these languages (being suitable to whole variety of tasks, from simple scripts, to full systems) also appeals to me.
I'm headed this way myself. For anything more complicated than a toss-off script I start with Scala now.
My experience is nearly the opposite, Modern Perl for me is a wonderful language to write web applications in. Nearly everybody I speak with regularly is developing some web based application in Perl. Then again thats what I do for a living so my glasses are definitely rose tinted.
Sites like the BBC iPlayer system, and Omni Hotel's booking application are large public examples of Perl applications, Magazines.com is another. At the smaller end of the fence I worked on ParkingMobility.com, a REST system written in Perl with multi-platform clients (including iPhone), was written using Catalyst and the KiokuDB Object Persistence engine.
You have moved on, but so has Perl. Moose for example has had heavy influences from OCaml, Scala, CLOS, Smalltalk, and others. It provides anywhere from "some" (Moose has Type Constraints but not inferencing for example) to much if not more (Moose's implementation of Traits can provide state unlike Scala's from what I know) of the features of other languages.
The rivalry between Perl5 and Perl6 means that more and more of these features will be expressed. For example, I've seen some proof of concept code for implementing Moose's type system at the core language level (my Int $i = 'One'; # boom!). With a properly motivated hacker and the right direction this could turn into an excellent dynamic type system, or even a semi-static system similar to the one Perl6 is implementing. Having this kind of a type system makes lot of Web programming tasks much simpler to implement (and eliminates a whole range of security holes).
The current momentum in the community has me very excited for the future of Perl.
Sites like the BBC iPlayer system, and Omni Hotel's booking application are large public examples of Perl applications, Magazines.com is another. At the smaller end of the fence I worked on ParkingMobility.com, a REST system written in Perl with multi-platform clients (including iPhone), was written using Catalyst and the KiokuDB Object Persistence engine.
You have moved on, but so has Perl. Moose for example has had heavy influences from OCaml, Scala, CLOS, Smalltalk, and others. It provides anywhere from "some" (Moose has Type Constraints but not inferencing for example) to much if not more (Moose's implementation of Traits can provide state unlike Scala's from what I know) of the features of other languages.
The rivalry between Perl5 and Perl6 means that more and more of these features will be expressed. For example, I've seen some proof of concept code for implementing Moose's type system at the core language level (my Int $i = 'One'; # boom!). With a properly motivated hacker and the right direction this could turn into an excellent dynamic type system, or even a semi-static system similar to the one Perl6 is implementing. Having this kind of a type system makes lot of Web programming tasks much simpler to implement (and eliminates a whole range of security holes).
The current momentum in the community has me very excited for the future of Perl.
FYI, I use Perl extensively for text file parsing and processing
Yeah, me too, but that's the issue. It's great at that. Great at quick and dirty command line hacks. Hell, most of my PhD code was written in Perl. (Something I take a perverse satisfaction in.)
But it's not great for rapid webapp development, it's probably harder to hire people, there are fewer libraries and interfaces and open source toolkits, etc - so people like me moved from Perl to Python (it's a really easy jump).
I still use my old perl scripts now and again, but even for quick and dirty stuff I tend to use Python - just in case I want to come back to it later and have a chance of understanding what the hell I wrote. :)
(Aside: One of my summer internships was on the web backend team at my university's Engineering lab. We wrote an object oriented student class administration system, in Perl. It was quite probably the most hideous piece of software engineering I've ever seen...)
Yeah, me too, but that's the issue. It's great at that. Great at quick and dirty command line hacks. Hell, most of my PhD code was written in Perl. (Something I take a perverse satisfaction in.)
But it's not great for rapid webapp development, it's probably harder to hire people, there are fewer libraries and interfaces and open source toolkits, etc - so people like me moved from Perl to Python (it's a really easy jump).
I still use my old perl scripts now and again, but even for quick and dirty stuff I tend to use Python - just in case I want to come back to it later and have a chance of understanding what the hell I wrote. :)
(Aside: One of my summer internships was on the web backend team at my university's Engineering lab. We wrote an object oriented student class administration system, in Perl. It was quite probably the most hideous piece of software engineering I've ever seen...)
> there are fewer libraries and interfaces and open source toolkits, etc
Um... What? According to http://search.cpan.org/, there are 85193 community-contributed modules. Okay, some of that is stupid stuff (http://search.cpan.org/perldoc?Acme::Meow) but they don't make up a large percentage. Compare that to PyPI's 11199 packages and RubyGems' 15674 gems.
Um... What? According to http://search.cpan.org/, there are 85193 community-contributed modules. Okay, some of that is stupid stuff (http://search.cpan.org/perldoc?Acme::Meow) but they don't make up a large percentage. Compare that to PyPI's 11199 packages and RubyGems' 15674 gems.
Yes, but do they _work_? That's why I became disillusioned with Perl, even though it was heavily used at my last company. I got the "oh, yeah, just go to CPAN and grab the module." I usually ended up using Java (how perverse is that?). I now prefer Python and C# because I find more stuff that works (but still plenty of broken old stuff).
The CPAN ecosystem provides some basic guarantees that I haven't seen mentioned for other language's repositories. For example every distribution uploaded to the CPAN is tested on some subset of (using last month's statistics[1]) 15 different operating systems, across 81 platforms, and 26 different versions of Perl. Not every package is tested on every perl and every platform because this is a volunteer effort, but the major platforms (Linux, Windows, BSD, Solaris) are generally covered. These test results are aggregated and reported on search.cpan.org.
Every package uploaded is given a Bug Queue (rt.cpan.org) so bugs and patches can be reported to the author. Additionally distributions can now specify in their metadata (META.yaml/META.json) the source code repository for the code so you can see from search.cpan.org the place to get the latest code to patch against. Additionally there is a process that if a maintainer goes rogue and stops responding, packages can be taken over. This doesn't happen often but has been used when other options fail. Many modern projects have several co-maintainers who can all make releases lowering the "bus factor".
Right now the biggest problem is finding the wheat for all the chaff. Sturgeon's Law applies, 90% of everything is crap. With 21038 (as of this writing) unique distributions, finding the ones that are well written, useful, and generally "best" is actually a difficult problem. You're not alone in finding that hard, but there are projects like Task::Kensho[2] to curate CPAN. This process is hard and would require a full time team of experts to perform properly.
It is big problem but one I think I'd rather have than when I was (for example) working in Java in 2005 and not only had to go through the effort of assessing the module in question (will this work? is it good? will I have problems later) but also had to hunt around the web for where all the different projects were located.
[1]: http://stats.cpantesters.org/
[2]: Full disclosure, Task::Kensho is a project I started in 2007 based upon the feedback of several people in the Perl community.
Every package uploaded is given a Bug Queue (rt.cpan.org) so bugs and patches can be reported to the author. Additionally distributions can now specify in their metadata (META.yaml/META.json) the source code repository for the code so you can see from search.cpan.org the place to get the latest code to patch against. Additionally there is a process that if a maintainer goes rogue and stops responding, packages can be taken over. This doesn't happen often but has been used when other options fail. Many modern projects have several co-maintainers who can all make releases lowering the "bus factor".
Right now the biggest problem is finding the wheat for all the chaff. Sturgeon's Law applies, 90% of everything is crap. With 21038 (as of this writing) unique distributions, finding the ones that are well written, useful, and generally "best" is actually a difficult problem. You're not alone in finding that hard, but there are projects like Task::Kensho[2] to curate CPAN. This process is hard and would require a full time team of experts to perform properly.
It is big problem but one I think I'd rather have than when I was (for example) working in Java in 2005 and not only had to go through the effort of assessing the module in question (will this work? is it good? will I have problems later) but also had to hunt around the web for where all the different projects were located.
[1]: http://stats.cpantesters.org/
[2]: Full disclosure, Task::Kensho is a project I started in 2007 based upon the feedback of several people in the Perl community.
> from Perl to Python (it's a really easy jump)
I disagree. Python is incredibly restrictive when you're used to perl. I would be so frustrated if I went that direction.
I disagree. Python is incredibly restrictive when you're used to perl. I would be so frustrated if I went that direction.
Just curious, what ways you found python restrictive?
The whole language is all One Way To Do It-ified. It's fine, there's nothing wrong with it, I just always feel a lot more like I'm part of a creative process when I'm working with perl, like it's this magic goop I can mush around and throw at anything and it'll do everything I can think of. With python, it feels more like I'm trying to fit my program into the python world, which is very nice and square and proper and everything works perfectly fine, except if I happen to want to do it the other way just for kicks, I can't. Or, worse, I can and the performance is crap for no obvious reason (or a very good obvious reason that should've been fixed ages ago by relaxing things just a little bit).
I used to be a real big python fan, now it just seems like too much training wheels. I like perl's weirdness: its global variables, implicit returns, gotos and loop labels, weird calling conventions that, while unexpected, are perfectly well documented and reliable, and _boy_ do I love its string support.
I used to be a real big python fan, now it just seems like too much training wheels. I like perl's weirdness: its global variables, implicit returns, gotos and loop labels, weird calling conventions that, while unexpected, are perfectly well documented and reliable, and _boy_ do I love its string support.
Ok, I was sort of hoping for a more concrete example. Do you mean like not being able to use 'unless' constructs? Not having regular expression operators? Not being able to reference default variables like $_? What is an example of doing it "the other way"?
I can usually find several different ways to do anything in Python, too. In fact I find this is true even for trivial things. For example, here are 4 ways to parse /etc/passwd and return a list of objects such that you can reference each value by the field name, for example:
I can usually find several different ways to do anything in Python, too. In fact I find this is true even for trivial things. For example, here are 4 ways to parse /etc/passwd and return a list of objects such that you can reference each value by the field name, for example:
>>> passwd_data('/etc/passwd')[5]['shell']
'/bin/bash'
Odd. Around 2004, I switched from Perl to Python for all the same tasks, and I barely noticed: it was a matter of weeks before I was just as fluent in Python as I had been in Perl. What's your experience been like?
I went from python to perl, I'm just imagining based on what I know of each.
Yeah, there are times when it's easy to be frustrated at the roundabout way you have to do certain things in Python compared to Perl; I also found the latter to be true on other occasions so it's swings and roundabouts.
My side point was really just that if you know Perl, you don't have to do much to learn Python. Another commenter in this thread says Ruby's easy to a Perl-head, but I didn't find that to be the case personally.
My side point was really just that if you know Perl, you don't have to do much to learn Python. Another commenter in this thread says Ruby's easy to a Perl-head, but I didn't find that to be the case personally.
Well in general, if you're a polyglot programmer (which all Perl programmers should be because honestly, nobody in their right mind is going to let you program only in Perl all day), you don't have to do much to learn either one.
These three though, have more in common. They all have roughly C-like syntax, passable functions, simple I/O, and good vector and dictionary support by default. To me, they're all the same language in different suits (well, pant-suits in ruby's case ;-).
These three though, have more in common. They all have roughly C-like syntax, passable functions, simple I/O, and good vector and dictionary support by default. To me, they're all the same language in different suits (well, pant-suits in ruby's case ;-).
>>But it's not great for rapid webapp development
Interesting, do you know what you talk about and have references?
AFAIK, there are some quite neat libraries and a better OO system than the usual competition (Ruby, Python, Java et al). Etc.
Interesting, do you know what you talk about and have references?
AFAIK, there are some quite neat libraries and a better OO system than the usual competition (Ruby, Python, Java et al). Etc.
Observe the vague handwavy terms I used: I'm about 18 months out of date as I made the switch to Python around the start of 09.
At the time, Catalyst was very unfriendly (a quick google - it still is) and nowhere near as rapid-accessible as Django, just because of the amount of head-twisting you have to do to get things up and running. It may have changed, but frankly I have little interest in investigating it, and I expect most other people who drifted away from Perl are in a similar boat.
Also, having developed an OO backend for a site running in Perl, I never wish to do so again. Your definition of 'better OO system' clearly differs from mine.
At the time, Catalyst was very unfriendly (a quick google - it still is) and nowhere near as rapid-accessible as Django, just because of the amount of head-twisting you have to do to get things up and running. It may have changed, but frankly I have little interest in investigating it, and I expect most other people who drifted away from Perl are in a similar boat.
Also, having developed an OO backend for a site running in Perl, I never wish to do so again. Your definition of 'better OO system' clearly differs from mine.
He's referring to Moose, which is an insanely good object system, which wasn't prevalent at all 18 months ago but is nearly de rigueur in all but a handful of cases today. It's a mashup of CLOS, Perl 6, Smalltalk and a few other things that remains consistent, Perlish and intuitive. It's also crazy extensible - just look at the MooseX namespace on CPAN to see what I mean.
How much of CPAN has been migrated to Moose, as opposed to directly calling "bless" as the docs[1] advocate even now? As I understand it, the story on interop between the two styles is "don't go there".
[1]http://perldoc.perl.org/perlobj.html
[1]http://perldoc.perl.org/perlobj.html
I use Moose combined with non Moose OO libraries all the time and only run into troubles when they are doing some really funky stuff on the inside (The Glib wrappers were hard to tackle, but they have to be funky, since they're a C OO to Perl interface). Most of this is thanks to MooseX-NonMoose which takes care of most common things.
> As I understand it, the story on interop between the two styles is "don't go there".
Interop between Moose and legacy Perl 5 OO works just fine.
Interop between Moose and legacy Perl 5 OO works just fine.
The perlobj perldoc is about the old style OO -- and discusses the old style OO... :-) It doesn't discuss any CPAN modules at all (there are quite a lot about OO). Are you trolling?
What problems do you mean with Moose and the blessed OO?
What problems do you mean with Moose and the blessed OO?
Not at all. I learned Perl from the manpages, and I'm mystified how noobs are to discover and convince themselves that "man perlobj" is now bad advice yet remains official.
As for bless/Moose interop, I read somewhere there were big problems mixing the two but don't remember the specifics (I mostly dropped Perl a long time ago over its dogged attempts to guess what I probably wanted when I made a mistake). Others in this thread now say that's not true if it ever was, which is good news for users of pre-Moose CPAN modules.
As for bless/Moose interop, I read somewhere there were big problems mixing the two but don't remember the specifics (I mostly dropped Perl a long time ago over its dogged attempts to guess what I probably wanted when I made a mistake). Others in this thread now say that's not true if it ever was, which is good news for users of pre-Moose CPAN modules.
I'm mystified how noobs are to discover and convince themselves that "man perlobj" is now bad advice yet remains official.
Me too, which is one reason I'd like to remove it, or at least fix it.
Me too, which is one reason I'd like to remove it, or at least fix it.
The Perl 5 world seems to change quite a lot every few years. If people have an old install, perldoc might be out of date. Wouldn't it be better to just add an URL at the top of the page to a page at perl.org and put the best practices for CPAN there?
The question is should the documentation shipped with perl document the features available with that distribution, or should it document the features available in the wider Perl culture?
For example, Moose has always made an effort to cooperate with the native Perl object system. The documentation in the perldoc's for object oriented programming isn't wrong. The skills you learn from perltoot and companions will transfer to Moose, you'll know how the underlying implementation works. Is this the right way to learn Perl's Object Oriented programming? That is an argument the Perl community itself is having[1]. As that argument is resolved the documentation is updated.
If you think about this in startup terms. Moose as a project is 4 years old. Would you invest in a startup that had an exit strategy that was targeted for than than 5 years? Moose has just recently (in the last year or two) reached a dominant market position when compared to the existing competition (Class::MethodMaker, Class::STD, etc) but still is adopted by only 5% of the total market (that is we have ~1K direct downstream dependencies out of about 20K distribution on CPAN). It would be premature to expect the industry to recognize let alone promote Moose as the de-facto standard. However it would be an excellent bet that sometime in the next few years that will happen.
Of the "Modern Perl" distributions out there Moose is one of the most consolidated in it's scope. Things like Catalyst have been gaining new competition (Dancer, Mojolicious) in their respective markets. It's interesting to watch things that appear to my untrained eye like market forces play out across the adoption of various CPAN modules.
To circle back around, perl documentation needs to strike a careful balance between what they can guarantee exists (bless $ref, __PACKAGE__) and what the community accepts as best practice (use Moose;). The documentation needs to intentionally be less dynamic than the fashions of the community. It must be conservative enough to provide continuity so that someone who happens to be on a perl-5.8.8 box (released 3 months before Moose, and still the standard on RHEL if I recall) doesn't learn a whole different set of "best practice" modules than someone on a 5.10.1 box. It does however need to be updated as things like Moose take over the mind share and prove themselves out. When only 1 in 20 modules you run into will likely involve Moose, you'll still need to understand the native solutions. When that ratio changes, the balance will need to change too.
[1]: http://stackoverflow.com/questions/980751/should-i-learn-per...
For example, Moose has always made an effort to cooperate with the native Perl object system. The documentation in the perldoc's for object oriented programming isn't wrong. The skills you learn from perltoot and companions will transfer to Moose, you'll know how the underlying implementation works. Is this the right way to learn Perl's Object Oriented programming? That is an argument the Perl community itself is having[1]. As that argument is resolved the documentation is updated.
If you think about this in startup terms. Moose as a project is 4 years old. Would you invest in a startup that had an exit strategy that was targeted for than than 5 years? Moose has just recently (in the last year or two) reached a dominant market position when compared to the existing competition (Class::MethodMaker, Class::STD, etc) but still is adopted by only 5% of the total market (that is we have ~1K direct downstream dependencies out of about 20K distribution on CPAN). It would be premature to expect the industry to recognize let alone promote Moose as the de-facto standard. However it would be an excellent bet that sometime in the next few years that will happen.
Of the "Modern Perl" distributions out there Moose is one of the most consolidated in it's scope. Things like Catalyst have been gaining new competition (Dancer, Mojolicious) in their respective markets. It's interesting to watch things that appear to my untrained eye like market forces play out across the adoption of various CPAN modules.
To circle back around, perl documentation needs to strike a careful balance between what they can guarantee exists (bless $ref, __PACKAGE__) and what the community accepts as best practice (use Moose;). The documentation needs to intentionally be less dynamic than the fashions of the community. It must be conservative enough to provide continuity so that someone who happens to be on a perl-5.8.8 box (released 3 months before Moose, and still the standard on RHEL if I recall) doesn't learn a whole different set of "best practice" modules than someone on a 5.10.1 box. It does however need to be updated as things like Moose take over the mind share and prove themselves out. When only 1 in 20 modules you run into will likely involve Moose, you'll still need to understand the native solutions. When that ratio changes, the balance will need to change too.
[1]: http://stackoverflow.com/questions/980751/should-i-learn-per...
Wow... what I take from that is:
A really well argued way of agreeing with my point that perldoc pages should start with a reference to e.g. a page on perl.org with the present best practices for that perldoc page? :-)
Or maybe as close as possible to get of a formal proof? :-)
>>[Moose] still is adopted by only 5% [of CPAN] [..] It would be premature to expect the industry to recognize let alone promote Moose as the de-facto standard.
The counter argument is that new work generally seems to use Moose. But, of course, new work use the CPAN modules.
A really well argued way of agreeing with my point that perldoc pages should start with a reference to e.g. a page on perl.org with the present best practices for that perldoc page? :-)
Or maybe as close as possible to get of a formal proof? :-)
>>[Moose] still is adopted by only 5% [of CPAN] [..] It would be premature to expect the industry to recognize let alone promote Moose as the de-facto standard.
The counter argument is that new work generally seems to use Moose. But, of course, new work use the CPAN modules.
>>I learned Perl from the manpages
Well, that was impressive. Stupid, but impressive... :-)
>>discover and convince themselves that "man perlobj" is now bad advice yet remains official.
AGAIN: Those man pages doesn't discuss CPAN modules. But afaik, they recommend books and the web...
Well, that was impressive. Stupid, but impressive... :-)
>>discover and convince themselves that "man perlobj" is now bad advice yet remains official.
AGAIN: Those man pages doesn't discuss CPAN modules. But afaik, they recommend books and the web...
Meh, I don't care for being spoonfed. I also read RFCs. I'm actually embarrassed to have paid for Real World Haskell, because if I were as smart as I want to be I wouldn't need it.
In this case, neither perlobj, perlboot, nor perlbot mention any CPAN modules at all, and perltoot cites a couple but Moose isn't among them.
In this case, neither perlobj, perlboot, nor perlbot mention any CPAN modules at all, and perltoot cites a couple but Moose isn't among them.
Good to know. Should I ever feel masochistic enough to look back at Perl, I'll undoubtedly check it out.
And this reply alone is proof Perl isn't dead.
And this reply alone is proof Perl isn't dead.
[deleted]
Post: "I've done a bit of X and my overall impression of Y in was..."
Reply: "References, sources, double blind studies please! Prove you know what you're talking about..."
Feel free to vote me down, if you're all about karma... :-)
I asked because his claim went against what I've read on the subject. I don't really know, since I haven't really been working with web development for a couple of years (which is why I started with "Interesting").
I asked because his claim went against what I've read on the subject. I don't really know, since I haven't really been working with web development for a couple of years (which is why I started with "Interesting").
For what it's worth, a quick search on dice.com gives the following:
- perl: 4448 results
- python: 1988
- ruby: 1087
Here's a graph with postings for jobs.perl.org from jan/2002 to aug/2010:
http://bit.ly/bFuh7x
(source http://jobs.perl.org/about/stats)
http://bit.ly/bFuh7x
(source http://jobs.perl.org/about/stats)
Look like Rails took a big bite out of Perl jobs?
In 2008? I can think of other explanations for a drop in hiring around then.
Hey, wasn't that the year the economy started to go south? ....
Obviously, people stopped employing people in Perl, and the economy took a steep dive because of it!. Use Perl! Save the economy!.
( nb. for people with no sense of humour, this was a stab at people who don't understand that correlation != causation )
( nb. for people with no sense of humour, this was a stab at people who don't understand that correlation != causation )
Calm down guys, I counted the years wrong - I thought the drop was taking place in 2006-7, when Rails was growing quickly. Also, it was a guess, which was why I used a "?"
"Dead perl" reminds me of when Bill Clinton said "you just don't get it" to Bush 41. Essentially meaningless, yet devastatingly true.
So, some interesting tidbits to add to this "conversation":
1. Perl developers are older (on average) than those of other trendier languages. They were there at the dawn of the web. They are more experienced. They are also less expensive. But who wants to be an old-timer who gets paid less?
2. There is a negative feedback situ between developers choosing what technology to learn based on what companies are running on, and companies choosing a technology to run on based on what developers are learning. This sort of tragic loop is a social cancer which takes leadership and risk to overcome.
3. CPAN completely kills the competition. It might have something to do with perl, but it doesn't matter. This thing is outstanding, one of the 5 best things in software engineering... period. If you don't get this, you are deluding yourself and need to take a closer look at it.
4. Perl6 is going to blow the doors off the hinges because it is even more hacker-friendly than perl5 (which is ludicrously hackable).
5. Perl is dead to you.
So, some interesting tidbits to add to this "conversation":
1. Perl developers are older (on average) than those of other trendier languages. They were there at the dawn of the web. They are more experienced. They are also less expensive. But who wants to be an old-timer who gets paid less?
2. There is a negative feedback situ between developers choosing what technology to learn based on what companies are running on, and companies choosing a technology to run on based on what developers are learning. This sort of tragic loop is a social cancer which takes leadership and risk to overcome.
3. CPAN completely kills the competition. It might have something to do with perl, but it doesn't matter. This thing is outstanding, one of the 5 best things in software engineering... period. If you don't get this, you are deluding yourself and need to take a closer look at it.
4. Perl6 is going to blow the doors off the hinges because it is even more hacker-friendly than perl5 (which is ludicrously hackable).
5. Perl is dead to you.
Perl 5 is mature, and Perl 6 is pre-release, but they're different languages with the same name for branding purposes.
Perl 6 is a really promising language with tons of cool features, and some similarities to Perl 5. It will pick up hype when it's 100% finalized, even though you can use it now.
Perl 5 (popularly known as "Perl") is old enough to be on the other side of "cool", but it's a perfectly good language, especially if you use CPAN.
Perl 6 is a really promising language with tons of cool features, and some similarities to Perl 5. It will pick up hype when it's 100% finalized, even though you can use it now.
Perl 5 (popularly known as "Perl") is old enough to be on the other side of "cool", but it's a perfectly good language, especially if you use CPAN.
Perl 5 came out in 1994, Ruby came out in 1995, Python came out in 1991.
(Sources: Wikipedia)
Perls 1-4 are even older (Perl 1 was 1987). Perl 5 really is just another version number of Perl, not a new language entirely like Perl 6.
Oftentimes what matters is exposure more than when something was invented. Erlang and Haskell came out in 1986 and 1990, respectively, but they're newer to most people than Perl is. Ruby and Python didn't have the exposure in 1995 and 1991 that Perl had.
(Interesting thought experiment--are there any obscure programming langauges today that will be all the rage in 2020, or has the internet accelerated that process?)
Oftentimes what matters is exposure more than when something was invented. Erlang and Haskell came out in 1986 and 1990, respectively, but they're newer to most people than Perl is. Ruby and Python didn't have the exposure in 1995 and 1991 that Perl had.
(Interesting thought experiment--are there any obscure programming langauges today that will be all the rage in 2020, or has the internet accelerated that process?)
Actually, having worked with Perl during the Perl 4 to Perl 5 transition, I'd argue that it was almost as large as the C to C++ transition, though not as big as the Perl 5 to Perl 6 transition. Perl 5 dramatically expanded the options for expressing ideas in the language, while remaining largely syntactically upwards compatible (the Perl transition retained more compatibility with the previous version than did the C/C++ transition).
Perl 5 added lexically scoped variables ("my"), in addition to Perl 4's dynamicly scoped variables ("local"). Perl 5 added references, which is what made OO Perl possible (either "traditional" blessed hash references, or Moose, or any of the less popular alternatives, like "inside-out" objects).
I suspect the programming language rage of 2020 is currently some highschool kid's pet project (or some elementary school kid's daydream?) which no one else has seen yet.
Perl 5 added lexically scoped variables ("my"), in addition to Perl 4's dynamicly scoped variables ("local"). Perl 5 added references, which is what made OO Perl possible (either "traditional" blessed hash references, or Moose, or any of the less popular alternatives, like "inside-out" objects).
I suspect the programming language rage of 2020 is currently some highschool kid's pet project (or some elementary school kid's daydream?) which no one else has seen yet.
> Perl 6 is pre-release...
Rakudo Perl 6 has had 34 releases.
> It will pick up hype when it's 100% finalized....
That must be Perl 5's marketing problem then, because it's not finalized either.
Rakudo Perl 6 has had 34 releases.
> It will pick up hype when it's 100% finalized....
That must be Perl 5's marketing problem then, because it's not finalized either.
Wikipedia: As of 2009, multiple Perl 6 implementations are under development, but none are considered "complete". As noted in the history section the language design itself is still subject to change. No implementation will be designated as the official Perl 6 implementation; rather, "Perl 6 is anything that passes the official test suite."[12]
If that's changed, you should probably go update that. "Pre-release" is generally understood as a synonym for "not complete", right? There's no complete, finished implementation of the Perl 6 spec, right? Is the spec itself finished?
It's like you can't say anything about Perl (either one) on Hacker News, not even mildly complimentary things, without someone jumping on perceived slights.
If that's changed, you should probably go update that. "Pre-release" is generally understood as a synonym for "not complete", right? There's no complete, finished implementation of the Perl 6 spec, right? Is the spec itself finished?
It's like you can't say anything about Perl (either one) on Hacker News, not even mildly complimentary things, without someone jumping on perceived slights.
> If that's changed, you should probably go update that.
If that weren't against Wikipedia policies, I would. Then again, I don't consider Perl 5 "complete" either, whatever "complete" means.
> There's no complete, finished implementation of the Perl 6 spec, right? Is the spec itself finished?
No to both, but why does that matter? There'll be a Perl 6.1 spec and a Perl 6.2 spec and so on. Meanwhile, people who find a Perl 6 implementation usable for their purposes will use it and people who don't won't. Fortunately, every release is more usable to more people.
As for "pre-release", I don't believe in playing linguistic existential games. Software exists or it doesn't. You've released it or you haven't. It does something or it doesn't. Perpetual betas and alphas and pre-releases and unstable versions and (even) release candidates are for people who lack the courage to release good software.
As for "perceived slights", insinuating that Perl 6 doesn't exist or isn't useful because the spec isn't "complete" (whatever that means) or no single implementation is "finished" (whatever that means) or no one has said "This particular release of this particular implementation is stable for every domain and every purpose and everyone who might ever want to use it" is awfully silly and (in my mind) deserves a challenge.
If that weren't against Wikipedia policies, I would. Then again, I don't consider Perl 5 "complete" either, whatever "complete" means.
> There's no complete, finished implementation of the Perl 6 spec, right? Is the spec itself finished?
No to both, but why does that matter? There'll be a Perl 6.1 spec and a Perl 6.2 spec and so on. Meanwhile, people who find a Perl 6 implementation usable for their purposes will use it and people who don't won't. Fortunately, every release is more usable to more people.
As for "pre-release", I don't believe in playing linguistic existential games. Software exists or it doesn't. You've released it or you haven't. It does something or it doesn't. Perpetual betas and alphas and pre-releases and unstable versions and (even) release candidates are for people who lack the courage to release good software.
As for "perceived slights", insinuating that Perl 6 doesn't exist or isn't useful because the spec isn't "complete" (whatever that means) or no single implementation is "finished" (whatever that means) or no one has said "This particular release of this particular implementation is stable for every domain and every purpose and everyone who might ever want to use it" is awfully silly and (in my mind) deserves a challenge.
You're being evasive, which is equal parts amusing and irritating. Maybe Perl 6 is an exercise in deconstructing the concept of a software product ever being done?
As long as the official language specification refers to Perl 6 in the future tense, I will as well. Take it up with Larry Wall.
For those of us who don't play linguistic existential games, BTW, Perl 5 has been "done" since 1994. I think most of us recognize that you can continue maintaining and updating software after it's done/finished/released. It appears the Perl 6 community has been innovative in the discovery that you can release software before it's done or finished and go Derrida on someone's ass for implying that an incomplete implementation of a draft specification is, in fact, incomplete.
As long as the official language specification refers to Perl 6 in the future tense, I will as well. Take it up with Larry Wall.
For those of us who don't play linguistic existential games, BTW, Perl 5 has been "done" since 1994. I think most of us recognize that you can continue maintaining and updating software after it's done/finished/released. It appears the Perl 6 community has been innovative in the discovery that you can release software before it's done or finished and go Derrida on someone's ass for implying that an incomplete implementation of a draft specification is, in fact, incomplete.
And yet, the fine people on p5p keep making changes to something you're trying to claim is "done". You suggest elsewhere that "done"ness is a 100% thing. If Perl5 keeps changing, and it was 100% done in 1994 ... something is really inconsistent with the universe.
chromatic's pedantry is a symptom of people like us ignoring the fact that even a language like TeX will only be done when the author decides it's done (Knuth's death for example). That and he's a grumpy-butt sometimes. Perl6 is a fully-functional language in that you can write useful (for some value of useful) scripts in it. The specification is undergoing radical changes, but then as I've pointed out the Perl5 specification is undergoing changes that some consider "radical" (if you doubt this, read threads on perl5-porters sometime ... look up the debate(s) about the "feature" pragma).
Valid complaints about Rakudo being an unfinished implementation of Perl6 are better centered around things like it doesn't pass 100% of the Spec tests yet. The Rakudo developers will (I'm pretty sure) own up to this, and point to the fact that they're working hard on it and that patches are welcome. That doesn't mean that Rakudo * was in some way "Pre Release". I don't recall anybody using the term "Pre" when talking about the Rakudo * release. The terms I remember are "early", "useful", "useable","for developers". If we as non-members of the Perl6 community go about continuing to imply that Perl6 is somehow less than released in a way for developers to generate useful and usable applications, we're gonna have the grumpier members of the Perl6 community call us on it.
It looks to me like you have a unique opportunity to contribute most effectively to Perl6 moving from being what you consider pre-Released to Released. You can submit a doc patch to change the tense in the Perl6 documentation.
chromatic's pedantry is a symptom of people like us ignoring the fact that even a language like TeX will only be done when the author decides it's done (Knuth's death for example). That and he's a grumpy-butt sometimes. Perl6 is a fully-functional language in that you can write useful (for some value of useful) scripts in it. The specification is undergoing radical changes, but then as I've pointed out the Perl5 specification is undergoing changes that some consider "radical" (if you doubt this, read threads on perl5-porters sometime ... look up the debate(s) about the "feature" pragma).
Valid complaints about Rakudo being an unfinished implementation of Perl6 are better centered around things like it doesn't pass 100% of the Spec tests yet. The Rakudo developers will (I'm pretty sure) own up to this, and point to the fact that they're working hard on it and that patches are welcome. That doesn't mean that Rakudo * was in some way "Pre Release". I don't recall anybody using the term "Pre" when talking about the Rakudo * release. The terms I remember are "early", "useful", "useable","for developers". If we as non-members of the Perl6 community go about continuing to imply that Perl6 is somehow less than released in a way for developers to generate useful and usable applications, we're gonna have the grumpier members of the Perl6 community call us on it.
It looks to me like you have a unique opportunity to contribute most effectively to Perl6 moving from being what you consider pre-Released to Released. You can submit a doc patch to change the tense in the Perl6 documentation.
I did say, "I think most of us recognize that you can continue maintaining and updating software after it's done/finished/released."
Whether a software project is release-quality or not is a rather basic concept to everyone else. It can be intellectually tempting to try and deconstruct these basic concepts, but more often than not it's an exercise in evasion rather than illumination. Perl 6 (or Perl 6.0.0 for the pedantic) is a work in progress--at some point in the near future, the spec and implementations will be "done" to a point where everyone will agree that this is Perl 6.0.0, every implementation that matches the spec and passes the tests is Perl 6.0.0, and work will begin on Perl 6.1. Perl 5.0.0 reached that state in the past--16 years or so in the past to be precise. There's a distinction here that's dishonest to evade.
If the Perl 6 community is more interested in using linguistic evasion and deconstructing the concept of the finished release more than they're interested in actually making a finished release though, I'd best leave it to them. Maybe this is what Larry Wall meant about the postmodernism. Who knows? My mind is still blown by the observation that you have to doubletalk your way around the idea that Perl 6 hasn't reached 6.0.0 final yet.
Whether a software project is release-quality or not is a rather basic concept to everyone else. It can be intellectually tempting to try and deconstruct these basic concepts, but more often than not it's an exercise in evasion rather than illumination. Perl 6 (or Perl 6.0.0 for the pedantic) is a work in progress--at some point in the near future, the spec and implementations will be "done" to a point where everyone will agree that this is Perl 6.0.0, every implementation that matches the spec and passes the tests is Perl 6.0.0, and work will begin on Perl 6.1. Perl 5.0.0 reached that state in the past--16 years or so in the past to be precise. There's a distinction here that's dishonest to evade.
If the Perl 6 community is more interested in using linguistic evasion and deconstructing the concept of the finished release more than they're interested in actually making a finished release though, I'd best leave it to them. Maybe this is what Larry Wall meant about the postmodernism. Who knows? My mind is still blown by the observation that you have to doubletalk your way around the idea that Perl 6 hasn't reached 6.0.0 final yet.
It can be intellectually tempting to try and deconstruct these basic concepts....
I'd like to see a unified theory of version numbers while you're at it. It'd be nice to account for Ubuntu, OpenBSD, Mplayer, Microsoft Windows, Mac OS X, the Linux kernel, and TeX at minimum. After that, care to decipher what "beta" or "alpha" or "pre-release" means?
If the Perl 6 community is more interested in using linguistic evasion....
I'd take your argument at all seriously if it were more honest, say either "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" or "It shouldn't have taken ten years to release Rakudo Star." Those are debatable positions.
Arguing "But it doesn't really exist because you didn't releeeeeeease-release a fiiiiiinished-finished version!" is precisely the epistemological-linguistic ticky tackery you claim to decry. Even so, it matters not at all in the real world because there will be a new release next month and the month after that and the month after that ad utilitarian, and you're welcome to use it at any point when it's useful to you.
I'd like to see a unified theory of version numbers while you're at it. It'd be nice to account for Ubuntu, OpenBSD, Mplayer, Microsoft Windows, Mac OS X, the Linux kernel, and TeX at minimum. After that, care to decipher what "beta" or "alpha" or "pre-release" means?
If the Perl 6 community is more interested in using linguistic evasion....
I'd take your argument at all seriously if it were more honest, say either "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" or "It shouldn't have taken ten years to release Rakudo Star." Those are debatable positions.
Arguing "But it doesn't really exist because you didn't releeeeeeease-release a fiiiiiinished-finished version!" is precisely the epistemological-linguistic ticky tackery you claim to decry. Even so, it matters not at all in the real world because there will be a new release next month and the month after that and the month after that ad utilitarian, and you're welcome to use it at any point when it's useful to you.
I'd take your argument at all seriously if it were more honest, say either "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" or "It shouldn't have taken ten years to release Rakudo Star." Those are debatable positions.
Actually, I clarified what I meant in a previous post, when I characterized Perl 6 implementations as "incomplete implementation[s] of a draft specification". I didn't say it didn't exist, just that it exists in a non-final, pre-released state. Some people call them betas, some people call them release candidates, some people call them pre-release, and you try to cleverly evade the fact that every Perl 6 implementation is an incomplete implementation of a draft spec, but a rose by any other name and so forth.
I actually expect that some Perl 6 implementation will meet a finished 6.0.0 spec within the next 5 years. But none does currently. Which is a roundabout way of saying "it's not done yet", which is apparently doubleplusungood to state so directly.
I got into this trying to say good things about Perl. I guess you've shown me the error of my ways. If I'm going to have everything I say about Perl on Hacker News trolled by defensive Perl fanbois, I might as well trot out the old "explosion in an ASCII factory" joke again.
Edit: The problem is, you're seeing criticism where there was really none there. All I made was a statement of fact--Perl 6 isn't done yet. I've even clarified what I meant by "not done yet"--the spec is draft and the implementations are incomplete even against that spec. I think that's a reasonable definition of "not done yet", don't you? I never said anything about how long it's taking or whether implementation and spec will ever meet, you just projected those criticisms onto me because you're defensive about the issue. That's bad faith. Fuck, man, I even said Perl 6 would be done in the near future! How the hell do you get from that to projecting "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" onto me? Are you even reading my comments or am I talking to myself here?
Actually, I clarified what I meant in a previous post, when I characterized Perl 6 implementations as "incomplete implementation[s] of a draft specification". I didn't say it didn't exist, just that it exists in a non-final, pre-released state. Some people call them betas, some people call them release candidates, some people call them pre-release, and you try to cleverly evade the fact that every Perl 6 implementation is an incomplete implementation of a draft spec, but a rose by any other name and so forth.
I actually expect that some Perl 6 implementation will meet a finished 6.0.0 spec within the next 5 years. But none does currently. Which is a roundabout way of saying "it's not done yet", which is apparently doubleplusungood to state so directly.
I got into this trying to say good things about Perl. I guess you've shown me the error of my ways. If I'm going to have everything I say about Perl on Hacker News trolled by defensive Perl fanbois, I might as well trot out the old "explosion in an ASCII factory" joke again.
Edit: The problem is, you're seeing criticism where there was really none there. All I made was a statement of fact--Perl 6 isn't done yet. I've even clarified what I meant by "not done yet"--the spec is draft and the implementations are incomplete even against that spec. I think that's a reasonable definition of "not done yet", don't you? I never said anything about how long it's taking or whether implementation and spec will ever meet, you just projected those criticisms onto me because you're defensive about the issue. That's bad faith. Fuck, man, I even said Perl 6 would be done in the near future! How the hell do you get from that to projecting "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" onto me? Are you even reading my comments or am I talking to myself here?
Hi Phil, don't feel bad, amigo. The problem is that the good Perl 6 people are putting in long hours making something really awesome, and they are doing it only for fun, the challenge, the love of programming, and because it's great to build something beautiful and useful for oneself, and for the world.
Meanwhile, over in non-Perl-world, other people are (sometimes innocently, sometimes idly, sometimes maliciously) perpetuating these idiotic toxic "perl is X" memes which just poison the ecosystem for rational argument (in my opinion).
So you stepped into a minefield with good intentions, my thoughtful friend. But if I were on the Perl 6 team, I would be so frustrated by others out there who have this perverse obsession with what other people are doing, what other people are using, what other people are building.
It's not healthy, but regretably, it's also often very mean-spirited and has all the social utility of gambling on a cock fight.
I love what Perl has become, what the Perl community is, what the Perl 6 people are building, the UNIX-y culture, the spirit of adventure. It's really cool, and for those who don't get it, and don't want to, just move on (not you Phil).
Meanwhile, over in non-Perl-world, other people are (sometimes innocently, sometimes idly, sometimes maliciously) perpetuating these idiotic toxic "perl is X" memes which just poison the ecosystem for rational argument (in my opinion).
So you stepped into a minefield with good intentions, my thoughtful friend. But if I were on the Perl 6 team, I would be so frustrated by others out there who have this perverse obsession with what other people are doing, what other people are using, what other people are building.
It's not healthy, but regretably, it's also often very mean-spirited and has all the social utility of gambling on a cock fight.
I love what Perl has become, what the Perl community is, what the Perl 6 people are building, the UNIX-y culture, the spirit of adventure. It's really cool, and for those who don't get it, and don't want to, just move on (not you Phil).
... you try to cleverly evade the fact that every Perl 6 implementation is an incomplete implementation of a draft spec.
Nonsense; even the release announcements say that directly.
All I made was a statement of fact--Perl 6 isn't done yet.
I wouldn't have objected if you'd written that. Characterizing software we've released on schedule for almost three years running as something thrown out in the world incomplete, ahead of an "official" release (whatever "official" means) is, I believe, incorrect and unhelpful.
Nonsense; even the release announcements say that directly.
All I made was a statement of fact--Perl 6 isn't done yet.
I wouldn't have objected if you'd written that. Characterizing software we've released on schedule for almost three years running as something thrown out in the world incomplete, ahead of an "official" release (whatever "official" means) is, I believe, incorrect and unhelpful.
I think we got 2 posts in before I clarified that's what I meant by "pre-release", and here you are still objecting a day later.
I'm surprised nobody has provided this link yet.
Perl is Dead. Long Live Perl. http://www.oreillynet.com/onlamp/blog/2007/08/perl_is_dead_l...
It's an essay from 2007, but I think it's still relevant today.
Perl is Dead. Long Live Perl. http://www.oreillynet.com/onlamp/blog/2007/08/perl_is_dead_l...
It's an essay from 2007, but I think it's still relevant today.
Hmm... define dead? I see a lot of cool programming concepts and computer science coming together in Perl 6- too much for me to know how to use it effectively or rationally. To me Perl is going from terse parsing and glue language to something more like Haskell- I don't think of Haskell as dead just because it's not used as a quick scripting language- I assume Haskell will keep creating cutting edge stuff that eventually filters down into "lesser" languages.
Now, on the other hand, if I had actually taken the time to become a Perl monk, and good grasp enough of the awesome stuff coming down the line and know exactly how it would fit into real-world problems- Perl wouldn't even be close to dead to me. I'm sure there are a lot of people out there that are in that group. I'm jealous but not quite enough to actually try to get up to speed on it.
If it's not dead to you then I would recommend having no hesitations using it. It'll certainly be supported, and libraries... I mean, I don't know of anything that comes close to touching CPAN yet (dunno how Perl 6 fits in there). For me, though, it's dead as an alternative unless I see something amazingly compelling that I can't get elsewhere without similar learning investment.
Now, on the other hand, if I had actually taken the time to become a Perl monk, and good grasp enough of the awesome stuff coming down the line and know exactly how it would fit into real-world problems- Perl wouldn't even be close to dead to me. I'm sure there are a lot of people out there that are in that group. I'm jealous but not quite enough to actually try to get up to speed on it.
If it's not dead to you then I would recommend having no hesitations using it. It'll certainly be supported, and libraries... I mean, I don't know of anything that comes close to touching CPAN yet (dunno how Perl 6 fits in there). For me, though, it's dead as an alternative unless I see something amazingly compelling that I can't get elsewhere without similar learning investment.
I blogged about this on my use.perl.org/~scrottie blog. Perl's supply lines have been cut: grade school language courses don't teach it; those teach Flash, Squeak, and other things. High-school age hackers go for things like PyGame. College classes teach Java or Microsoft technologies, depending on who they're getting money from (sadly). Only a couple of Universities still teach Scheme as part of SICP. Self-taught Web programmers go the low road of PHP or Ruby for the high road. There are companies that use Perl but the work tends to be maintenance (which no one wants to do) or else they hire small, crack teams of experienced Perl programmers, not bothering with trying to invest in novice or intermediate programmers.
Perl launched to fame by being able to talk to a bunch of databases and being easily (for the time) bindable to binary libraries, as well as having great low level access to the OS, as well as being a direct upgrade path for sed, awk, bash, csh and so on. Now people don't care about upgrading old shell scripts and don't understand awk's idioms, sadly -- everyone wants yet another C, and every other language talks to the various databases and binds to C libraries just as well plus have better toolkits for creating games.
Perl 5 is dead in the sense that COBOL is dead: all of the work is maintenance work; there are no entry level or intermediate positions; experts can still find work and will be able to for a long time.
Perl 6 does lots of great stuff but that alone isn't enough. Without a PyGame, Rack, and lots of other pieces, it's just a neat language design. Whether Perl 6 kicks ass very much still depends on where people take it. In a very real sense, Perl 6's success depends on me. I need to port Continuity to it (and its native coroutines!). I need to take more features from Seaside and show them off. I need to play with SDL stuff and make good abstractions. Busy, busy, busy!
-scott
Perl launched to fame by being able to talk to a bunch of databases and being easily (for the time) bindable to binary libraries, as well as having great low level access to the OS, as well as being a direct upgrade path for sed, awk, bash, csh and so on. Now people don't care about upgrading old shell scripts and don't understand awk's idioms, sadly -- everyone wants yet another C, and every other language talks to the various databases and binds to C libraries just as well plus have better toolkits for creating games.
Perl 5 is dead in the sense that COBOL is dead: all of the work is maintenance work; there are no entry level or intermediate positions; experts can still find work and will be able to for a long time.
Perl 6 does lots of great stuff but that alone isn't enough. Without a PyGame, Rack, and lots of other pieces, it's just a neat language design. Whether Perl 6 kicks ass very much still depends on where people take it. In a very real sense, Perl 6's success depends on me. I need to port Continuity to it (and its native coroutines!). I need to take more features from Seaside and show them off. I need to play with SDL stuff and make good abstractions. Busy, busy, busy!
-scott
The bad news is that Perl isn't dead for sure. Languages tend to stick around for a while.
For myself, I regret all the time I've spent learning and using it. Perl and C++ are languages for those who don't know better. I know because I've used both extensively. Powerful text handling facilities? Perl? You are kidding: Emacs Lisp burns it with a blow.
Now down-vote me like ants gone mad. If you have less than ten years of experience "struggling" with code, and you haven't learned a bunch of languages beyond mainstream ones, then you just can't understand.
> A current example is the "Who's hiring" thread which is now on HN: Most of the requirements are C/C++/Java/PHP/Python/Ruby, and almost none are for Perl.
C/C++/Java/PHP/Python/Ruby? Really? I was expecting HNers to be a little more innovative.
For myself, I regret all the time I've spent learning and using it. Perl and C++ are languages for those who don't know better. I know because I've used both extensively. Powerful text handling facilities? Perl? You are kidding: Emacs Lisp burns it with a blow.
Now down-vote me like ants gone mad. If you have less than ten years of experience "struggling" with code, and you haven't learned a bunch of languages beyond mainstream ones, then you just can't understand.
> A current example is the "Who's hiring" thread which is now on HN: Most of the requirements are C/C++/Java/PHP/Python/Ruby, and almost none are for Perl.
C/C++/Java/PHP/Python/Ruby? Really? I was expecting HNers to be a little more innovative.
> I was expecting HNers to be a little more innovative.
I was expecting them to be less insulting, but you still get upvoted.
I was expecting them to be less insulting, but you still get upvoted.
I agree with you about Perl, but what language do you use to replace C++, as someone who knows better? I haven't quite found anything that can replace it.
I'm sorry to say I should have written: "Perl and C++ are good languages to those who don't know better ones" instead. I've been able to dump Perl, but I'm currently stuck with C++ too (as an employee). Why do you think you can't replace it? What are you using C++ for?
> C/C++/Java/PHP/Python/Ruby? Really? I was expecting HNers to be a little more innovative
Care to explain?
Care to explain?
Sorry. I should have deleted Python, Ruby - and maybe PHP for close to the metal web programming - after having copied the line. Regarding C/C++/Java, I was expecting HNers to prefer more agile languages and/or exploiting some other language's features to gain a competitive advantage.
> Will Perl 6 be able to turn things around, or is it too late?
Community plays a large role here, I think.
The Perl community (both 5 and 6) overall has a practical can-do attitude. This attracts users.
Perl 5 seems to have more grumpy (though still helpful) users.
Perl 6 has Larry and lots of courteous, friendly, and helpful users. It's a community you want to be a part of.
The Python community has a "no, you're wrong -- that's not Pythonic" feel to it which I think turns a lot of users off to Python.
So, I think Perl 6 does have a chance. Personally, I'd probably be more on-board with Perl 6 if it didn't look so darn complex.
Community plays a large role here, I think.
The Perl community (both 5 and 6) overall has a practical can-do attitude. This attracts users.
Perl 5 seems to have more grumpy (though still helpful) users.
Perl 6 has Larry and lots of courteous, friendly, and helpful users. It's a community you want to be a part of.
The Python community has a "no, you're wrong -- that's not Pythonic" feel to it which I think turns a lot of users off to Python.
So, I think Perl 6 does have a chance. Personally, I'd probably be more on-board with Perl 6 if it didn't look so darn complex.
It is a very useful tool that serves many needs.
It isn't "dead" anymore than the Norwegian language is "dead".
It might just not be your first choice for your next project.
It isn't "dead" anymore than the Norwegian language is "dead".
It might just not be your first choice for your next project.
> It isn't "dead" anymore than the Norwegian language is "dead".
It's just pining for the fjords?
Kidding aside, it still does well here:
http://www.langpop.com/
Although if you put Ohloh and Freshmeat at 0, it does significantly worse.
It's just pining for the fjords?
Kidding aside, it still does well here:
http://www.langpop.com/
Although if you put Ohloh and Freshmeat at 0, it does significantly worse.
Duck Duck Go has a lot of perl in it, and it's a somewhat trendy discussion topic on HN.
I think most of the reason we don't care is because DDG's strengths have nothing to do with Perl -- except for maybe how easy it is to deploy/keep running and regular expressions.
I think most of the reason we don't care is because DDG's strengths have nothing to do with Perl -- except for maybe how easy it is to deploy/keep running and regular expressions.
Most of my friends in bioinformatics still use Perl extensively, and it's the primary language in a couple of QA groups I know people in. I don't know that it'll ever be "hot" again, but it's certainly still a production language.
Language is a tool. Certainly, some people will create literature and others are merely hacks. Some languages will be conceptually cleaner, some more pure, and some an amalgam of expressions "borrowed" from other languages.
No, Virginia, Perl is not dead. Not as long as there is more than one way to do it, or a hacker trying to finish something that was due yesterday.
Perl, as we know it, might pass from this earth. But the spirit it embodied, that first we should use duct tape to build on the work of others then write glue to make it stick, that getting-things-done was the primary goal --- this is too close to the core of our restless selves. A thousand years from now, there will be some startup somewhere with an urgent need and a hacker that strokes his chin and says, "I think I could write that in Perl[1]..."
[1] replace "perl" with your favorite language. Pick the right tool for the job. Sometimes means "the tool you are most familiar with", but that says more about you than about the language.
No, Virginia, Perl is not dead. Not as long as there is more than one way to do it, or a hacker trying to finish something that was due yesterday.
Perl, as we know it, might pass from this earth. But the spirit it embodied, that first we should use duct tape to build on the work of others then write glue to make it stick, that getting-things-done was the primary goal --- this is too close to the core of our restless selves. A thousand years from now, there will be some startup somewhere with an urgent need and a hacker that strokes his chin and says, "I think I could write that in Perl[1]..."
[1] replace "perl" with your favorite language. Pick the right tool for the job. Sometimes means "the tool you are most familiar with", but that says more about you than about the language.
If perl is dead, could you please stop having threads about whether it's dead every month? TIA.
amongst webapp developers, yeah. But amongst SysAdmins? Python still has a long ways to go before it reaches the stability of perl, though it's gaining. Also, CPAN is awesome. I don't know of another language that has a cpan-like tool that measures up to CPAN.
SysAdmins are slow to discard a good tool; hell, some of us still use bash. Perl 5 has been dominant for most of my career in this arena, and things will be quite slow to change.
I do see that Python is beginning to replace perl in the places where perl5 replaced bash in the earliest parts of my career... I remember back in the late '90s it was common to maintain two versions of perl on a system. Now, perl5 is stable... you almost never need more than one version of it, but I see systems (especially RHEL systems) with more than one version of python (sometimes more than two. Gah!)
SysAdmins are slow to discard a good tool; hell, some of us still use bash. Perl 5 has been dominant for most of my career in this arena, and things will be quite slow to change.
I do see that Python is beginning to replace perl in the places where perl5 replaced bash in the earliest parts of my career... I remember back in the late '90s it was common to maintain two versions of perl on a system. Now, perl5 is stable... you almost never need more than one version of it, but I see systems (especially RHEL systems) with more than one version of python (sometimes more than two. Gah!)
hell, some of us still use bash
As opposed to what? (Do all the cool kids now use zsh? That's my best guess.) Bash just had a major release, as well as a point-upgrade to that. How is Bash now a poster child for out-of-date good tools that people won't let go of?
As opposed to what? (Do all the cool kids now use zsh? That's my best guess.) Bash just had a major release, as well as a point-upgrade to that. How is Bash now a poster child for out-of-date good tools that people won't let go of?
As opposed to Perl for tasks that would be much easier with Perl scripts than with shell scripts. I know SysAdmins who do this. Perl won't be replaced as A SysAmin language of choice for while now, I don't think.
I suspect that the grandparent meant "write shell scripts".
Duh (aimed at myself). Right, sorry. Whew. I got scared there for a minute that I was so terribly behind the times (insofar as I still use Bash as my primary shell).
Funny, I find Python to be more stable than Perl, the one that needs multiple versions on the same system, and the one with modules that fail to compile without tweaking compiler flags.
My thoughts... coming from someone who has been working with Perl for basically a decade at various companies, and have had the pleasure of working with Perl experts like Tim Bunce (author of DBI) and Randall Schwartz (author of various Perl books, including the camel book).
a) Perl was used for EVERYTHING web-related in the early 2000s, but other languages and tools have come around to supplant it.
Several commenters have already said, "oh man I had to deal with this legacy perl code and it was awful," and yeah, that's a common experience and makes them think, "Perl is a terrible legacy language, I can't wait to trash it on my Ruby mailing list tonight." The negativity propagates and then people like you wonder, "is Perl dead?"
b) Web frameworks are one of those tools where frameworks like Rails and Django have all the hype. If you want to whip up your startup idea into a minimum viable web application, the trendy choice is Rails or Django. I've used Perl web frameworks like Catalyst and I'll be the first to admit banging out your "It's like Facebook... But For Cats!" startup idea is a lot faster in Rails or Django.
c) As Steve Yegge said in one of his blog posts:
'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'
In my experience (which of course is just as anecdotal at Steve's), this is very true. Zed Shaw writes yet another blog post blasting whatever technology crawled up his ass and died, and we just smirk and update our modules on CPAN. But while that means we're not getting caught up in the "narcissism of small differences" (to refer to an earlier commenter), it also means we're not part of the noise on the web. There will probably never be a "Perl is a Ghetto" blog post written, and while that's obviously a good thing, it can also lead to the perception that, "man, nobody's talking about Perl, nobody's even bashing Perl, is it dead?"
d) That said, in my opinion these languages don't hold a candle to Perl when it comes to back-end engineering. We love talking about startups here at HN and thus, we talk a lot about startup problems and their solutions. But if your startup actually grows into a real company, you're going to encounter problems like, "we need a system to allow our analysts to manage our SEM campaigns and reconcile our cost and revenue" or "this partner doesn't have an API so we need to spider their interface to get the daily data and import it into our data warehouse." And any company that dismisses Perl as an option for those problems just because of (a) (b) and (c) is doing their company a disservice.
TL;DR -- Perl's strengths don't match the trendy topics on communities like HN, but it still has real value for real business problems.
a) Perl was used for EVERYTHING web-related in the early 2000s, but other languages and tools have come around to supplant it.
Several commenters have already said, "oh man I had to deal with this legacy perl code and it was awful," and yeah, that's a common experience and makes them think, "Perl is a terrible legacy language, I can't wait to trash it on my Ruby mailing list tonight." The negativity propagates and then people like you wonder, "is Perl dead?"
b) Web frameworks are one of those tools where frameworks like Rails and Django have all the hype. If you want to whip up your startup idea into a minimum viable web application, the trendy choice is Rails or Django. I've used Perl web frameworks like Catalyst and I'll be the first to admit banging out your "It's like Facebook... But For Cats!" startup idea is a lot faster in Rails or Django.
c) As Steve Yegge said in one of his blog posts:
'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'
In my experience (which of course is just as anecdotal at Steve's), this is very true. Zed Shaw writes yet another blog post blasting whatever technology crawled up his ass and died, and we just smirk and update our modules on CPAN. But while that means we're not getting caught up in the "narcissism of small differences" (to refer to an earlier commenter), it also means we're not part of the noise on the web. There will probably never be a "Perl is a Ghetto" blog post written, and while that's obviously a good thing, it can also lead to the perception that, "man, nobody's talking about Perl, nobody's even bashing Perl, is it dead?"
d) That said, in my opinion these languages don't hold a candle to Perl when it comes to back-end engineering. We love talking about startups here at HN and thus, we talk a lot about startup problems and their solutions. But if your startup actually grows into a real company, you're going to encounter problems like, "we need a system to allow our analysts to manage our SEM campaigns and reconcile our cost and revenue" or "this partner doesn't have an API so we need to spider their interface to get the daily data and import it into our data warehouse." And any company that dismisses Perl as an option for those problems just because of (a) (b) and (c) is doing their company a disservice.
TL;DR -- Perl's strengths don't match the trendy topics on communities like HN, but it still has real value for real business problems.
I would say that it is absolutely not, at least in my experience. In my lab, which is a bioinformatics lab, perl is still being used heavily. Perl is a great tool for dealing with text files, and little pieces of code that you need to do something quick.
Read the following and stop asking:
http://www.modernperlbooks.com/mt/index.html
http://www.modernperlbooks.com/mt/index.html
There are some big and new projects in Perl out there (BBC iPlayer for one – which is an enormously high-traffic site).
The real issue is that a language dies when new people stop learning it. Python's the language-du-jour of programming education (and has a strong position in science as a Matlab replacement, thanks to Numpy), Ruby's got Rails to give it momentum, PHP has Wordpress and Drupal as gateway drugs, Clojure and Scala are the JVM's great hopes, F# is the CLR's, and C#, Java and C++ will give you access to a lot of jobs.
Where are the new Perl programmers – in bulk – going to come from?
The real issue is that a language dies when new people stop learning it. Python's the language-du-jour of programming education (and has a strong position in science as a Matlab replacement, thanks to Numpy), Ruby's got Rails to give it momentum, PHP has Wordpress and Drupal as gateway drugs, Clojure and Scala are the JVM's great hopes, F# is the CLR's, and C#, Java and C++ will give you access to a lot of jobs.
Where are the new Perl programmers – in bulk – going to come from?
> Where are the new Perl programmers – in bulk – going to come from?
The world of non-programmers, same as always.
The world of non-programmers, same as always.
Perl was the first programming language that I really liked using. Before perl i had programmed in basic and pascal and that wasn't very fun.
One of the best aspects of perl is the rock solid runtime, they have really gotten that right. Many of the newer languages like java, python & ruby have VMs that turn belly up after a varying amount of time, but perl just keeps running.
I prefer coding in ruby or clojure and I don't really like the object orientation syntax in perl. I'm looking forward to try out perl6.
One of the best aspects of perl is the rock solid runtime, they have really gotten that right. Many of the newer languages like java, python & ruby have VMs that turn belly up after a varying amount of time, but perl just keeps running.
I prefer coding in ruby or clojure and I don't really like the object orientation syntax in perl. I'm looking forward to try out perl6.
You might like Moose (http://search.cpan.org/dist/Moose/lib/Moose.pm). It's built on top of--and is compatible with--plain Perl OO, but provides a whole lot more and has grown a nice, big community. There's more information (presentations, articles and stuff) on http://moose.perl.org/
The Perl jobs mailing list frequently has a dozen or more jobs internationally a week. I'd say no, Perl is far from dead, despite it not having the sexy factor it once did.
I also use Perl (5 of course) for text processing but also for some binary file modifications. Just for playing with algorithms I use Python. I still wouldn't like to have to use the "wrong" of them for the given purpose.
Personally I don't expect Perl 6 to have a noticeable impact soon, I've read about it and I've never thought "that's what I've been missing all the time."
Let me tell you what I'm really missing -- something even simpler than Python which would allow me to draw the random graphical things with basic interactive possibilities but with the ease of old Basic languages. I've used tkinter a few times but every time I have to make something new I just discover I've forgot all the illogical things I had to do the last time, and the old source is not of much help, I know I'll have to spend trying a lot just to make something simple, so I lose the will to even start again...
Personally I don't expect Perl 6 to have a noticeable impact soon, I've read about it and I've never thought "that's what I've been missing all the time."
Let me tell you what I'm really missing -- something even simpler than Python which would allow me to draw the random graphical things with basic interactive possibilities but with the ease of old Basic languages. I've used tkinter a few times but every time I have to make something new I just discover I've forgot all the illogical things I had to do the last time, and the old source is not of much help, I know I'll have to spend trying a lot just to make something simple, so I lose the will to even start again...
I love perl, and I don't want to see it be dead, but there aren't enough libraries relating to my interests (games).
You should really check out the SDL bindings for Perl. It's getting to the point where the dev versions are almost comparable to PyGame. There's some really cool stuff going on.
I had checked them out about a year ago and they couldn't even draw a line on the screen :\
Weird, considering that the very well-known free game Frozen Bubble is written in SDL/Perl...
It didn't have to draw any lines. Everything was bitmaps.
It's now also on CPAN by the way at http://search.cpan.org/dist/Games-FrozenBubble/
I'm not really a game developer or have any idea about SDL, but from the Perl feeds I read (I think this instance was from Planet Iron Man) I gather that the SDL development was recently revitalized. They have their website at http://sdl.perl.org/ and since the Latest News entry at this time is from the end of August, it seems up-to-date.
I'm not really a game developer or have any idea about SDL, but from the Perl feeds I read (I think this instance was from Planet Iron Man) I gather that the SDL development was recently revitalized. They have their website at http://sdl.perl.org/ and since the Latest News entry at this time is from the end of August, it seems up-to-date.
YouTube is full of Frozen Bubble movies. See for example http://www.youtube.com/watch?v=5nUkly7AkFs , someone completing level 70.
There's the Ogre bindings, but they are unfortunately incomplete. I think the problem here is that of critical mass. For real nice game development, you don't simply want OpenGL or even an engine like Ogre. You want to extend the engine to include physics and collision detection.
So, there would need to be either a large enough crowd able to maintain the bindings for the engines and their extensions, or we need a more generic approach to C++ foreign library access. Since there are people working on better C and C++ FFI's,
I'm hoping for the latter. But that's probably mostly because I'm no good at C++, and such a layer would be my only way to use external libraries without available bindings.
So, there would need to be either a large enough crowd able to maintain the bindings for the engines and their extensions, or we need a more generic approach to C++ foreign library access. Since there are people working on better C and C++ FFI's,
I'm hoping for the latter. But that's probably mostly because I'm no good at C++, and such a layer would be my only way to use external libraries without available bindings.
No. I wrote the bulk of my intern project this summer in perl.
I'm currently writing a web application with perl catalyst...
This is a question, but isn't it used fairly often in the finance industry?
Are you suggesting that this could explain certain events in the past?
As others stated for me, to parse large text files of data.
I think there's still a vibrant perl community out there, but I wouldn't say the perl community is growing. I don't know that I'd use dead or alive but maybe "plateaued".
Not if you include Asia. It's huge there, especially in Japan.
[deleted]
[deleted]
As strlen already mentioned perl is big in the e-mail and infrastructure world. I write perl code for our e-mail filter and/or infrastructure frequently. But our webui is developed is developed in rails and qooxdoo. So I guess, it boils down to right tool for the job and trends of the day.
I don't think Perl is dead, as computer languages are significantly harder to kill than zombies. I would not at all be surprised if some critical infrastructure that must run lets a bunch of people gets killed is written in PDP 9 assembler. Just seams to be the nature of the beast.
Isn't duckduckgo written in Perl? Thats one huge application right there.
[deleted]
I'd much rather search/replace a huge string in Perl than in C++. Perl's hugely optimised.
In summary: not dead yet because of all the legacy code and because of the "Modern Perl" movement.
However: many of us believe that Perl's day has come and gone and that truly modern languages like Ruby and Python have supplanted it. Absolutely true for me; I never use Perl when I can use Ruby -- not because of political reasons, but because Ruby is more elegant, readable, and concise.
As always, YMMV.
However: many of us believe that Perl's day has come and gone and that truly modern languages like Ruby and Python have supplanted it. Absolutely true for me; I never use Perl when I can use Ruby -- not because of political reasons, but because Ruby is more elegant, readable, and concise.
As always, YMMV.
> ... truly modern languages like Ruby and Python have supplanted it.
In what ways?
Certainly not in testing culture, nor available libraries, nor the power of features such as language extensions or object systems, nor in flexibility.
Screencasts, perhaps?
In what ways?
Certainly not in testing culture, nor available libraries, nor the power of features such as language extensions or object systems, nor in flexibility.
Screencasts, perhaps?
If this really isn't trolling, check jobs.perl.org instead.
As others have written, Python and Ruby fill the same niches and have about the same features.
As others have written, Python and Ruby fill the same niches and have about the same features.
The most widely used spam filter was written in Perl - http://spamassassin.apache.org/
Spend a couple of minutes thinking about why on in Java or C++ (the answer is - tons of modules it uses).
Now try harder question - why not in Ruby or Python? ^_^
The world is the way it is, because it got that way. ^_^
Spend a couple of minutes thinking about why on in Java or C++ (the answer is - tons of modules it uses).
Now try harder question - why not in Ruby or Python? ^_^
The world is the way it is, because it got that way. ^_^
Short answer: Yes.
Learn Python and you'll notice why perl doesn't make sense.
Perl makes sense. It's a matter of degree of sense, and personal opinion. Python's use of semantic white space doesn't make any sense to me. But I know plenty of sane people who disagree with me.
Python's "semantic whitespace" is syntax that gives meaning to a common pattern in code. Most code that way by convention anyway. If that pattern has meaning then curly braces can be used for something else (in python's case: dictionary literals).
Hope it makes more sense now, even if you don't prefer that style.
Hope it makes more sense now, even if you don't prefer that style.
It makes logical sense (i.e. I understood the meaning of the whitespace-delineated blocks). I'm really just saying I don't prefer the style.
...its total lack of movement is due to it bein' tired and shagged out following a prolonged squawk.
...actually, it's probably pining for the fjords.
...actually, it's probably pining for the fjords.
http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htmI guess: yes.
The only place i see it is in some old scripts running at customers and they ALWAYS are a nightmare, unmaintainable, horrific, spaghetti code that oftern enough makes me want to poke my eyeballs out. Mostly, the customer agrees with me, but usually those scripts are too big to be replaced quickly... :/
The only place i see it is in some old scripts running at customers and they ALWAYS are a nightmare, unmaintainable, horrific, spaghetti code that oftern enough makes me want to poke my eyeballs out. Mostly, the customer agrees with me, but usually those scripts are too big to be replaced quickly... :/
A current example is the "Who's hiring" thread which is now on HN: Most of the requirements are C/C++/Java/PHP/Python/Ruby, and almost none are for Perl.
However, this is not just about hiring. In almost anything I read, there is barely a mention of Perl anymore.
FYI, I use Perl extensively for text file parsing and processing, and I'm not familiar with Python or Ruby, but it seems that these two languages are "winning the war" against Perl (although I assume some of you may dispute that these two languages are even comparable to Perl, for a variety of reasons)
Is my general observation correct?
Will Perl 6 be able to turn things around, or is it too late?