Why Perl isn't Going Away Soon (Or Ever)(ostatic.com)
ostatic.com
Why Perl isn't Going Away Soon (Or Ever)
http://ostatic.com/blog/guest-post-why-perl-isnt-going-away-soon-or-ever
10 comments
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.
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.
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.
Perl usage on the web began to fall off due in part to PHP, but you're neglecting the huge amount of Perl used in text processing, system administration, automation, even the sciences.
PHP is (very mildly) comparable to Perl's Mason template engine, if Mason were the only way to use Perl.
PHP is (very mildly) comparable to Perl's Mason template engine, if Mason were the only way to use Perl.
you're neglecting the huge amount of Perl used in text processing, system administration, automation, even the sciences
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.
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.
"Perl development is picking up and enthusiasm for Perl 5 is as strong as ever."
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?
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?
You might just not be in the right echo chamber. In the last few years I've been in several startups where perl is the primary development language. Most of the people we hired were in their mid twenties to mid thirties, which seems about what you'd expect for startups. HN seems to be a hangout for lots of python (and lisp, and ruby) people, but less so for perl and php people. Obviously I do hang out in the right echo chambers, which is probably why my experience differs.
As a counter-example, the previous startup I worked at was a medium-sized perl shop in SV. They had an incredibly hard time recruiting high-quality engineers. Finding good coders who were proficient in perl was a rarity and it seemed as though all of the various perl shops were fighting over these people when they hit the market; finding interns and recent college grads who either knew perl or were willing to spend the time to learn it was almost impossible. From what I saw the pool of perl talent was just not as broad as people claim.
I haven't ever had problems hiring good perl people for the startups I've founded. But that may just be the area (Vancouver has a bunch of really good perl people). Also I try to only do cool things and treat people well. ;-)
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).
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).
The company was doing some pretty cool stuff and the team/pay/benefits were on the high-end for the valley, so that was not really a problem, it was mostly a lot of competition for a small pool of people worth having.
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.
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.
If someone has interesting work, and wants to pay me to learn COBOL, then absolutely I will. Actually, I have another startup in the works that probably will require learning COBOL at some point anyway...
Older people use it is because they don't want to change or learn something new. Especially in a company already entrenched in Perl development, their is little benefit to switching to a better language compared to the cost of forcing people to learn a whole new technology stack when they are more than content with Perl. However, new companies are much more free to build on whatever technology stack is most appropriate.
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.
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.
I actually tend to find the opposite: I know lots of CS majors who love perl and C, and lots of web-design-focused non-cs-majors who love ruby, python, and php. Both groups are approx the same age (late-20s/early-30s).
I disagree with your implication that Perl is suitable for newbs but should be discarded for "better languages" by people who are interested in learning.
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.)
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.)
I never meant to imply that Perl is suitable for newbs, but rather most scripting languages are. I would much rather newbs learn another language, in fact. I changed my wording in my original post to reflect that.
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
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 am a young developer working primarily in Perl.
Reasons? Friendly, knowledgable community. CPAN and Catalyst.
Admittedly I don't know any other [under]graduates using Perl (outside of bio/geology).
Reasons? Friendly, knowledgable community. CPAN and Catalyst.
Admittedly I don't know any other [under]graduates using Perl (outside of bio/geology).
You have a good point that Perl doesn't have great adoption with young'uns. I think we'd see more Perl usage if Ruby didn't exist; Ruby borrowed some of Perl's most attractive features and is rightly popular for it.
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).
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).
Perhaps it's not as popular because it doesn't have One True Web Framework, which is what the young'uns use these days, right? I know Catalyst and Mason are both very nice frameworks, but they don't come rolled with a base Perl installation.
Rails is the main driver behind Ruby's success, true. And it really is a nice framework. However, Rails doesn't come rolled with a standard Ruby installation either, and 'gem install rails' is no easier or harder than 'cpan -i Catalyst::Devel'.
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.
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.
'gem install rails' is no easier or harder than 'cpan -i Catalyst::Devel'
...Perhaps from your perspective.
...Perhaps from your perspective.
enthusiasm for Perl 5 is as strong as ever
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.
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.
Bet you didn't know there was a [relatively] new COBOL-2002, either.
(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.)
(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.)
No technology ever goes away. Nobody is saying Perl won't be developed, just that people are less likely to use other languages for new projects in favor of newer technologies.
The article still makes an excellent point, which is that the difference between most of the 'newer technologies' and Perl is basically marketing, not any actual superiority of language design. You can write line noise in Perl, but you can also write Python in Perl. It may not be quite as pretty as Python, but as far as use in a production environment it will be equally useful.
Why not just write Python in Python instead ;)?
I like my braces ;}.
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.
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.
Since 2.x is just as feature stable and was just released in the last incarnation (2.7) before an "extended maintenance period", I do believe the limbo you speak of isn't an issue for anyone actually using Python.
I can imagine it looking worrisome from the outside, though.
I can imagine it looking worrisome from the outside, though.
That's a rather twisted reasoning, with Perl 6 on the doorstep ;)
Perl 6 is not meant to interoperate directly with Perl 5. It's not an incremental update in any way. IMO, it would be a lot clearer if Perl 6 weren't called Perl.
CPAN. CPAN is fricking awesome.
I consider Perl's data structures to be genuinely inferior. Lists that cannot contain other lists are not reasonable in a high level language. Pointers are not reasonable in a high level language. Explicit function signatures are a superior language design.
Lists that cannot contain other lists are not reasonable in a high level language.
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.
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.
If you put a list in a list in Perl, don't you have to specifically dereference the sublist when accessing it? Otherwise you get what looks to my eye like a pointer (a weird random number). The first google result I get is this: http://www.webreference.com/programming/perl/nested/ -- and to me "reference" == "pointer". And the fact that it is all weakly typed (that is, pointers are not a distinct type) makes it that much worse.
If you put a list in a list in Perl, don't you have to specifically dereference the sublist when accessing it?
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).
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).
Are there languages which don't require some special syntax for accessing nested data structures?
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.
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.
How to make an array of arrays in Perl 5:
@aoa = ( [ 1, 2, 3 ], [ 4, 5, 6 ] );
lol = [ [ 1, 2, 3 ], [ 4, 5, 6 ] ]
$aoa[1][1];
lol[1][1]
You've selected one option where Perl looks sane, while leaving out cases like "[ [1, 2, 3], [4, 5, 6] ]" or "( (1, 2, 3), (4, 5, 6) )". And of course there's other cases like lists containing hashes, and hashes containing lists. All of these are handled consistently in languages like Python and Ruby, and the programmer never needs to consider the interaction of the container and the objects it contains -- numbers and lists and strings and hashes are all objects and all act exactly the same with respect to containers.
I'm not going to defend Perl 5's dereferencing syntax for container operations. Perl 6 changed that for a very good reason.
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.
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.
CPAN is the killer app for Perl. Every time I flip across to another language I usually love the syntax and structures but the lack of a CPAN equivalent is always grating and I usually end up right back at Perl to get stuff done fast.
I used to think this way. After living without CPAN for 3 years using different languages, I appreciate the lack of dependency additions my projects get.
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.
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.
I blame your sysadmin for not making it easy. Even so, you probably don't rely on CPAN all that much if you lose more time to dependency problems than you save by re-using other people's code. That's not my experience at all. I save days and sometimes weeks at a time.
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.
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.
Agreed with the pain of admin with CPAN. I ended up creating a custom build and distribution tool to manage this as the existing solutions are weak.
Hah, what's funny is that Jeff Hobbs, the author of the article, is one of the main Tcl developers.
Except, that Jeff (who used to work for me at Scriptics) is a pragmatic kind of guy and is likely to not allow his allegiance to Tcl prevent him from seeing what else is going on out there.
I meant it in a "huh, that's funny" way, not that he's not perfectly capable of expressing intelligent opinions about Perl, Python or whatever else.
...because it's holding the entire internet together?
"because it's holding the entire internet together?"
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 ?
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 ?
I think you just answered your own question. I'd say just about every Unix box on the planet has Perl holding it together somewhere in there. What you've asked is essentially like asking "How does mortar hold buildings together any more than bricks, steel I-beams, or roofing?"
These things are equally important, and yes you could probably find a substitute, but why?
These things are equally important, and yes you could probably find a substitute, but why?
"What you've asked is essentially like asking "How does mortar hold buildings together any more than bricks, steel I-beams, or roofing?"
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).
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).
The phrase "Perl holds the internet together" was coined by analogy with Perl's widespread use as a glue language. You've interpreted it too literally. It doesn't mean that you can't set up a router or another piece of Internet infrastructure without using Perl.
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.
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.
"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.
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.
This whole thread is a joke that's gone over your head. "Perl is the glue that binds the web together" (or variants thereof) is an old pun on how Perl often gets used. Not so much to write large systems (as is the case with C/C++/..) but as a glue layer to stitch them together.
To answer your specific question, it isn't necessary. It's just another Turing-Complete language, right?
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.
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.
" 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."
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.
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.
Trends are funny, and don't only go in one direction. According to the admittedly flawed TIOBE index (see http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... for verification), in the last year PHP, Python, and Ruby have all fallen, while Perl has increased.
Yeah, not what I would expect either. But Perl isn't as dead as people claim.
Yeah, not what I would expect either. But Perl isn't as dead as people claim.
many of the "old school" also knew their way out of all kinds of bag and choose perl. Nobody needs to know (pick your language) but knowing perl has really helped me out in my long career in programming. You seem to be of the kind that does not like perl so are looking for the future where no one uses it .
If you think COBOL is only used in legacy code bases, every time you search for a hotel or Air tickets you are most probably interacting with a main frame system
Good question. I don't have a good answer, but my guess is that it refers to the cgi scripts that use to prevail before and also to all the scripts that every sys admins have written to make their job easier. At one point Perl was called "The duct tape of the internet", I guess referring to all the small scripts tying things together.
...because it is my duct tape
+1
...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.
...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.
Does any body remember when Larry Wall and others were rewriting all the Unix commands in Perl? I thought that was cool but I never heard of it again, and haven't been able to find references to it.
It was Tom Christiansen, originally. Looks like no updates since 2004: http://search.cpan.org/dist/ppt/
You're probably talking about the long dead one-man project to rewrite all the /bin/* utilities in Perl. That had nothing to do with Larry Wall.
The whole article fails to mention any advantage of Perl over the languages it's compared to (wonder why). The sooner Perl falls into obscurity, the better.
I currently code for my day job in a proprietary extension to a proprietary dialect of BASIC from the mid-80's. This language is legitimately broken, and has significant disadvantages at every turn. It has no real functions, no block-level scoping, lists are stored as delimited strings, there are no hashes, and nothing even resembling objects.
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.)
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.)
It's all fine until you have to work with bad legacy code ;)
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.
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.
Why can't you blame the original author since you know it was likely his first larger program?
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 ?
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 ?
Bad legacy code is certainly unpleasant. I'm currently working with a large code base that was mostly written about 10 years ago. It's not even particularly bad code, it's just big, and old, and crufty. But we can refactor that code a bit at a time into something clean and new, using modern perl. And we can do that without having to rewrite the entire thing in one shot. And that's one of the many advantages that being a good perl developer gives you. Another one is that that giant legacy code base still runs on a modern perl binary, because perl is (with a few well documented exceptions) a very very stable language. Most of the big modern perl changes are just modules. And they're backwards compatible with the old stuff too.
But that's because you already know perl. For new people... I don't see a reason to go there. Perl smells funny - there are better alternatives that don't require you to spend time learning (for example) what can be referenced, what cannot, when is \ not taking a reference, why I cannot have lists-inside-lists, and how is that different from arrays anyway, etc. And that's only one source of that funny smell... For beginners, there are loads of languages which offer consistent behaviour and once they learn that, perl will be the odd one you don't really want to touch.
So yes - some people will still write perl, but it will be an obscure language one day (hopefully).
So yes - some people will still write perl, but it will be an obscure language one day (hopefully).
There are better alternatives that don't require you to spend time learning ....
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.
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.
There's a difference between learning the difference where the language is consistent and when it handles everything differently. I see many problems, but staying with the list thing: \ creates references, () creates lists, \$a is a reference to $a, \($a, $b) is not a reference to an array, but it's (\$a, \$b), [$a, $b] creates a reference to an array without \. If I have a choice, I'll take a consistent solution instead.
Here's your problem: if you skip learning the basics of the language -- if you assume that the fundamental behavior of a new language is the same as other languages you know -- you will suffer constant friction and confusion.
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.
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.
Not really. I like learning languages and enjoy much weirder ones than Perl. Still - Perl is way more inconsistent than anything I've seen before and believe me I tried - went through the same Perl tutorials every time I had to fix some code. Every single time spending hours finding out some strange thing I wouldn't expect. Actually I learned Python at the same time I was learning Perl the first time. I spent two days fighting with Perl code, then rewrote everything in about 3h in Python with no previous experience.
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.
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.
I didn't skip the basics of the language.
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.
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.
"The answers are longevity, maturity, and a rich ecosystem of development tools and modules that developers can leverage for almost any programming task. Consider the Comprehensive Perl Archive Network (CPAN). CPAN is an enormous collection of software and documentation, largely unmatched outside of the Perl community. Yes, other languages have similar repositories patterned after CPAN -- but thus far none have matched CPAN for its size and scope. CPAN continues to grow at a rapid clip."
Did you perhaps mean perl 5.8?
No. It said Perl 5.12 because Perl 5.12 was released April 12 this year.
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.
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.
Thanks for the update. I stopped using perl around the same time 5.8 was slated to be the last version of perl 5, since perl 6 was coming Real Soon Now.
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.
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.
Did somebody really say "Perl 6 is coming real soon now?" I have only ever seen "by christmas" and they don't mention what year.
According to http://use.perl.org/~pmichaud/journal/39411 (written last summer) this Spring (likely April) is targeted for a production release of a usable subset of Perl 6. The same information is posted to http://www.perlfoundation.org/perl6/index.cgi?Rakudo_Star.
They obviously didn't make that. I don't know what the current state is or what the exact thinking is now.
They obviously didn't make that. I don't know what the current state is or what the exact thinking is now.
http://www.perlfoundation.org/perl6/index.cgi?rakudo_star
[..] original release plan was for late April 2010 [family crisis for lead developer]. The release date [..] sometime in the second quarter of 2010.
[..] original release plan was for late April 2010 [family crisis for lead developer]. The release date [..] sometime in the second quarter of 2010.
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.