Why Perl isn't Going Away Soon (Or Ever)
ostatic.com
ostatic.com
I would agree. A little over a decade ago, Perl suffered from the same problems which plagued JavaScript in its early days: ease of writing shitty code, mountains of shitty sample code, and a community which did not vehemently encourage the writing of unshitty code.
This caused a backlash which lasted several years, during which the programming public panned the languages almost universally.
But a funny thing happened; rather than shriveling up and going away, the languages and their practitioners matured. Community focus became less centered on glue code and scrolling effects, and attention was shifted to writing clean, maintainable code which uses the language's best features (metaprogramming, easy hash/object manipulation, etc) in manageable, modular ways.
Now both ecosystems are flourishing, and though Perl doesn't have quite the install base of JavaScript, it's still a viable contender to Ruby and Python in their areas of expertise, and it can be called the best tool for some of those jobs.
I will take your word for it, but I do have to say (speaking as someone with a lot of grey in his hair) that I haven't seen a young developer choose to work primarily in perl (over ruby or Python or Java or C#) in ages. Most new projects/startups don't seem to choose perl as their primary language.
I readily concede that this is probably an artifact of my limited experience with perl. Just noting what I see, not looking for a flame war.
How many of YC companies use perl do you think?
By the numbers, though, I still agree with the quoted statement. Perl development is picking up compared to the past few years, and enthusiasm for Perl 5 is the strongest it's been (at least since 5.0).
Interestingly, I notice many of the new Rails 3.0 features -- most notably composable set algebra and increased modularity -- are features which drew me to Catalyst+DBIx::Class. I haven't worked with Rails 3 in detail yet, but I have some Rails work coming up in the next few months and I am excited to compare and contrast.
...Perhaps from your perspective.
I've also noticed over time that lots of non-CS majors can and do program in scripting languages because they are relatively easy to pick up and get things done with. These people are usually more aligned with an IT career in that scripting constitutes only a fraction of their job. If they happen to learn Perl and PHP first, then that is what they stick with.
These people may like to program, but it is not the favorite part of their job and they have other work activities they enjoy more. More importantly, they know little to nothing about software design principles and are not interested in improving their software development skills. They would rather spend their time learning about something else that interests them more. Therefore, they don't even know how to appreciate the advantages more modern scripting languages offer. To these people, languages like Perl are more than sufficient to get their job done, and they are probably right.
However, as people who know better, I believe we should be encouraging better languages in a friendly way whenever possible. When my IT friends ask me about any questions related to programming, I usually try to point them to Python or Ruby for a solution. If they are asking questions they are probably interested in learning something new!
edit: changed wording based on reply from gamache.
In fact I would invert your statement: I think Perl is not a good choice for people without good programming habits, but for those who know how to use it, it offers more power of expression than most of its peers.
(Also, datum: count me in as an "older person" preferring Perl for most tasks despite knowing Ruby, Python, JS and half a dozen other languages.)
Also, for my background, I learned Perl as my first scripting language and after writing a ~1k line code project in it, decided that for anything over 200 lines I would rather use Java. Later when I learned Python I was vindicated in that almost everything I instinctively disliked about Perl was absent in Python. Since then I have learned many other languages as well, and I also know Perl the language better than most of my co-workers
I see your point about talent though. There are quite a few really good perl programmers, and a lot of "I once wrote a script in that" types, but not many in the middle. In some ways this is a strength - if you're programming in perl these days, odds are you've stuck with it because you actually like the language, so you're probably pretty good at it. On the other hand, it's not taught in school, so unless folks learn it on their own or on the job, there might be a real lack of new talent coming up the ranks.
As a programmer for hire, I can't complain about the wages. As an entrepreneur, I know where to find the good people, so it's not really a problem for me.
(I would also point out that any good programmer or intern/recent college grad who wishes to become a good programmer should always be willing to learn a new language on the company's tab. If they aren't, that probably says more about them than the language).
any good programmer or intern/recent college grad who wishes to become a good programmer should always be willing to learn a new language on the company's tab. If they aren't, that probably says more about them than the language
Would you learn COBOL on the company's tab? I wouldn't waste my time. Right or wrong, the impression that most people under 30 have of perl is that it is crufty write-once-read-never-again code used back when cgi scripts ruled the world; a dead-end skill that won't improve their long-term prospects.
Reasons? Friendly, knowledgable community. CPAN and Catalyst.
Admittedly I don't know any other [under]graduates using Perl (outside of bio/geology).
That's not how I remember it. Perl usage started to really fall off when PHP became popular and replaced modperl/ cgi scripts as the common way of throwing together a dynamic webpage. PHP is a language famous for letting people write shitty code and having a "community" that doesn't discourage it.
PHP is (very mildly) comparable to Perl's Mason template engine, if Mason were the only way to use Perl.
Are you saying that perl usage had started to fall off in these areas before it lost its crown as the lingua franca of the web? Possible, but again that is not how I remember it rolling out.
That's probably something of an overstatement, but I've written Perl in the past months for gigs, even though I have long abandoned it for Ruby. I don't know that I'd call the general interest in Perl5 "enthusiasm" -- that's a word I'd save for Ruby/RoR and maybe Python and DJ Ango. ;-p :-)
Perl5 is mature. There are modules for anything you can imagine, and most seem to be well-maintained. It's still useful, if someone antiquated in feel.
Perl6: that's another story. It's DOA. People will point to this implementation and that one, but the lack of a reference implementation, along with the long development time, makes Perl6 the Duke Nukem Forever of scripting.
(If I were snarky, I would note that the next COBOL spec after that -- yes, there is one -- might well be released before perl 6.)
Also, Perl 5 is feature-stable, and probably always will be. Python is in this 2.x-3.x limbo right now where it's difficult to find libraries that are going to work as-is for much longer. If you write a Perl application well, maintenance will as easy as reasonably possible, which I think is the only real measure of a good language. Most of the 'ease of use' problems disappear once you know what you're doing, and the language learning curve is a relatively small part of a programmer's life-cycle.
Indeed it is.
I can imagine it looking worrisome from the outside, though.
Perl has supported arrays of arrays since 1994.
Pointers are not reasonable in a high level language.
Perl has never supported pointers.
Explicit function signatures are a superior language design.
I agree with this. Perl 5 should have had them years ago.
You mean "array" instead of "list", but yes. Are there languages which don't require some special syntax for accessing nested data structures?
Otherwise you get what looks to my eye like a pointer (a weird random number).
When you stringify a reference, you get either the default stringification or an overloaded stringification, if you've overloaded stringification for a particular class. When you numify a reference, you get a unique number. Think of it as a cheap object identifier, because that's effectively what it is. It's not a great interface to expose to users, but that's its intent.
I argue that it's not a pointer, because you can't do pointer arithmetic with it.
...pointers are not a distinct type...
You mean "reference", and indeed they are distinct. They're RVs. That's a scalar type (SV).
Isn't that true for... most languages? Python, Ruby, Java, PHP, Smalltalk. And any language created in modern times. Perl in this respect is like a transitional animal in the evolution of languages -- what seemed somewhat modern given its peers (like shell or Tcl) now seems horribly outdated, the programming language world moved on having considered nested data structures a solved problem. It's like goto or dynamically scoped variables in other eras.
@aoa = ( [ 1, 2, 3 ], [ 4, 5, 6 ] );
lol = [ [ 1, 2, 3 ], [ 4, 5, 6 ] ]
$aoa[1][1];
lol[1][1]
I could give you examples of Ruby's and Python's inconsistency in their use of parentheses, as sometimes they group expressions to influence parsing precedence and sometimes they denote first-class data structures, but as you persist in asserting that parentheses create lists in Perl and that lists are first-class data structures, I suspect this discussion will continue to go nowhere.
The problem with CPAN is the same things as RPM hell or DLL hell, only worse and more fragile. On a large project, you really don't want to randomly upgrade your DBI module, or some other small perl package that may bring your whole project down. But then one day you need to use Net::SSH and it wants to upgrade DBI::Search for some bizarre reason, which requires you to compile a beta version of the GZIP library because it's using some new interface that's not included with your CentOS 5 install. Then you find out DBI::Search requires DBI 1.41 and you're only using 1.40. There's a backwards incompatible behavior that affects your code in 1.41, which is why you haven't upgraded yet. You go through all 100k lines of your project and make sure all the DBI code handles this new case.
Then you have to try and install the changes on all 75 of your servers. You may have some sort of capistrano script to make this simpler, or you may have used RPM versions of your CPAN packages. Neither solution is less painful than the other. CPAN wasn't really designed to work with your sysadmin's workflow, so neither solution is particularly useful.
At the end of the day, you would have spent less time just writing the damn code yourself to call out to the ssh binary.
If you're running through 100K lines of code to test a DBI upgrade you're clearly not testing properly. Not that most CPAN modules break compatibility. It's very rare that something like a DBI upgrade will break anything. All the good module authors are very careful.
Could someone explain what this means in some detail? I hear this all the time but I could never make any sense out of it. Sure once upon a time perl was the best way to get cgi scripts running and do some web programming. Other than this piece of history, any specific examples of the "holding the internet together" property perl is supposed to have? What part of critical internet infrastructure depends on perl?
I am no networking expert but it seems to me that a lot of the infrastructure (apache, tcp/ip stacks etc) is written in C. How (specifically) does perl hold the internet together any more than any other scripting language? Or is this jusr something perl aficionados tell each other ?
These things are equally important, and yes you could probably find a substitute, but why?
Argument by metaphor is a lazy device. I don't see any specific "mortar like" virtues that perl has but other common scripting languages don't. In this metaphor I guess C Code would be the "bricks and steel beams".
Why can't I put a unix box together without perl on it? Is there any specific piece of perl code that has to be on a unix box to enable it to work as an internet server or router? Is there a piece of code that has to be present on a Unix box for me to deploy say Apache or for dns to work? Honest question. Looking for concrete answers.
What specifically does perl do to "hold the internet together" today?
As an aside, I remember some COBOL programmers saying COBOL (running on mainframes) underlies all business on the internet and so COBOL was the real "internet commerce " language. Sure, you can say it and it can be justified by a lot of convolutions and narrowing of vision, but the truth seems to be that if it ever was so critical it is (a) an accident of history and (b) getting less true with every passing day.
I suspect (but am willing to be corrected) that perl is not indispensable to the internet any more (if it ever was).
Perl was one of the first popular scripting languages out there to have well-integrated regex handling and was useful for programming purposes. Most old-school systems and network people not only know how to code their way out of a paper bag, but typically grew up with C and Perl as their two go-to languages. C when you needed speed above all else, and Perl when you needed the regex functionality.
While specific functions vary for any given environment, I can safely say that I've written all of these in Perl at one point or another:
- Crunching netflow data to make life easier for those who do capacity planning.
- Running glue scripts against a device database to generate the configs that go to open-source monitoring systems.
- Lexing SNMP data in order to generate a device-independent network configuration, and then turning around and "compiling" it to another target network device.
All of these could be re-written in python. I've done it. Yet, they're all written in Perl because that's what the people who "Run The Internet" historically have used.
In another generation, maybe Python will be the regex-heavy scripting language of choice. For right now though, I suppose the best answer is that that Perl holds the Internet together for historical reasons, because that's what got the job done.
Which is probably why the "new school" systems programmers (many of whom also know how to program their way out of all kinds of bags) choose other scripting languages to go with C. They don't need to know perl any longer for all the tasks you laid out. Which is probably a good thing. The less dependence internet infrastructure has on specific languages the better.
As you correctly said "Perl holds the Internet together for http://redstate.com/historical reasons, " just as COBOL was the primary "business systems" language for a long time for historical reasons.
As someone pointed out above, when people talk about languages "going away" they don't mean that no one works on the language anymore, just that there are better alternatives these days.
Every time someone uses another language for what someone 10 years ago would have needed COBOL for, it fades a little, till there is only legacy codebases and its caretakers keeping the language alive.
I don't think it is that bad for Perl yet, but the trend seems to be in that direction, with more and more people using Python, Ruby (and even PHP) for the tasks Perl would have been the default choice historically.
Yeah, not what I would expect either. But Perl isn't as dead as people claim.
It means that Perl is used in a lot of unexpected places, and that a lot of critical things are "held together" by Perl. Even if you think your website is running on Java, some systems administrator probably has a cronjob written in Perl critical to its operation.
In the above sentence replace Perl with C/C++/awk/lua/Python/Ruby/almost-any-language and it makes as much sense. Which is probably another indicator that there is nothing particularly perl specific about "holding together the internet". If anything "holds together the internet" it is the (language independent) protocols that do it.
...and it is my glue. So many things in my environment wouldn't happen to be able to talk to each other if it weren't for Perl.
Perl has all of these things. If you're coding in Perl and you write bad code, it's your fault. If Perl has a fault, it's that it's easy to write code that you think is done, when you have more work to do if you want to develop a full-scale application. However, you can write incomplete but good-enough code in any language. (And I will always use Perl to write once-off scripts. It's perfect for that task.)
My last project at work was rewriting a 4k line monstrosity in Perl into 500 lines of Python which do exactly the same. I can't even blame the original authors (it was likely their first larger program), it's just that Perl makes it so easy to write horrible code.
I know that Perl's defaults (mainly lack of strict and warnings) can make it easy to write code that easily breaks or has bugs or is harder to maintain, but it is the first time I hear the argument that it make it any easier or encourage someone to write 4k lines when he could have written 500 lines.
I would guess that guy would have created a 4k monstrosity in Python if that's what he had to use without having enough experience.
Or maybe I am not being imaginative enough? Can you give examples from the program you rewrote where Perl encourage beginners to write "huge monstrosities" while Python would have encouraged them to write succinct code ?
So yes - some people will still write perl, but it will be an obscure language one day (hopefully).
That's a silly argument. Do you know of any language where beginners don't have to learn between language primitives to create complex data structures, for example? Assuming (for example) that parentheses create lists and that lists are first-class data types in Perl (and neither is true) is a fine example of Blub programming false cognates.
Lists and arrays are not the same thing in Perl. Parentheses do not create lists in Perl. Parentheses group terms.
You'd have the same sort of problem conflating tuples and lists in Python, especially if you don't know about the special comma syntax and zero-or-one element tuples.
I didn't skip the basics of the language. Still - basics keep biting me every single time. I don't think it's my problem after all... I mean - it may have its strange rules - but if it's less easy to handle than other languages, it won't draw new people in.
perlfaq4 explains the difference between arrays and lists in Perl in plain language. One is a variable. The other is a value.
The rest is operator precedence, grouping, and context. If you don't understand those, you don't understand Perl. Granted, most tutorials do a terrible job of explaining those, but these are fundamental concepts.
* ... but if it's less easy to handle than other languages, it won't draw new people in.*
That sounds like a tempting explanation for language popularity, but I doubt it's true -- it's too close to the "Obviously the technically best solution deserves to win!" fallacy. I suspect that practicality, availability, and the ease of which you can just get something done trumps quality. Certainly PHP's ease of deployment has contributed to its popularity more than consistency and correctness of design.
However that said, Perl cuts releases of old branches from time to time. So 5.8.9 was released a year after 5.10. See http://search.cpan.org/~jesse/perl-5.12.0/pod/perlhist.pod for a full release history.
I learned perl in 1996 in order to cobble together a system that collected reports from all sorts of weird text files and formats (anyone remember Framemaker?) and merge them into one nice big postscript file with custom watermarks and page numbers. This program ran for at least 8 years after that. I had to learn perl in the dead of night because I had been instructed to find a "technology solution" and perl was "unsupportable".
Another totally different program was developed to prototype a large orchestration of securities valuation and hedging. It even had numerical optimization in it. It was taken wholesale into production.
Many other programs, some fairly long, were written in order to run successfully only once, and then they were retired.
I loved perl.
Then I learned python and could read the code that I wrote a few months ago and more importantly, read other peoples' code more easily. Consistent white space helps a lot. It had many of the same advantages of perl, with slightly clunkier regexes, plus a nice system for introspection. It could almost replace matlab--almost.
I built a complicated optimization system that orchestrated multiple processors and called C++ library code so I didn't have to learn C++.
I forgot about perl. I loved python now.
Then I learned haskell and forgot about python but that's enough for today.
They obviously didn't make that. I don't know what the current state is or what the exact thinking is now.
[..] original release plan was for late April 2010 [family crisis for lead developer]. The release date [..] sometime in the second quarter of 2010.