Hacker News new | comments | show | ask | jobs | submit login
Perl as a career option (linuxcareer.com)
72 points by lmedinas 904 days ago | hide | past | web | 50 comments | favorite



I think it's a bit odd thinking of programming languages as a career option. I work at what's one of the biggest if not the biggest single employer of Perl programmers (Booking.com), and we don't specifically hire people with prior Perl experience. We hire people with relevant programming experience and bring them up to speed on Perl.

Anecdotally we've hired people who've had years of Perl experience who haven't done all that well, and people who've had no prior Perl experience who've just picked it up on the job and been very productive contributors within days or weeks.

The unstated assumption with articles like these is that you'd be losing out if you don't get experience with the "winning" platform, but in my opinion a much better way to become a good programmer is to get experience with a wide selection of toolsets and programming languages. Even if none of those toolsets are widely used commercially.

Having said that if you're interested in Perl as a career choice we're always hiring :)


I completely agree with this. In some cases focusing on a single language or set of languages can be a good idea - especially when it is a language in high demand and it means you know the ins and outs of a lot of different frameworks a la javascript. However, there is no downside to studying a lot of different languages because it gives you general experiences that you can apply to other languages, it helps you pick up new languages and toolsets, etc. The most basic example is that a programmer who only works with imperative languages should dabble in at least one functional language, because that can change the way you view algorithms, data structures, and overall program layout.


>I think it's a bit odd thinking of programming languages as a career option. Look at 99% of the jobs ads out there and they are looking for specific languages.


Agreed, but reading between the lines of these ads, there's a world of difference between an ad which is "we're looking for a great developer who will use <language X> to do [...]" and "we're looking for a <language X> Developer".

In my experience, the latter presentation tends to actively drive away the best candidates, and communicates a lack of understanding of the job to be done. This is not an absolute; sometimes you really do need a specific skillset. For example, one great company I worked at almost universally hired solid developers regardless of particular checkbox skills. We knew that the good ones would come up to speed, and we'd often benefit greatly from cross-pollination from differing backgrounds. However, there were definite instances where we needed a true specialist, e.g. in a specific, deep platform UI framework. Then we sought and found solid developers who were also top of their game in the needed skills.

In the latter ad copy above, a "<language X> Developer" often has the connotation not of a targeted specialist hire, e.g. "expert in <language X>". Instead it comes across as lazy recruiting: "warm body who checks off this box".


It seems to me that doing something as a career, you're expected to be really good at it. There's no way anyone can just pick up Perl and write good Perl code without a dozen best practice errors. Hiring someone who doesn't know Perl very well basically guarantees a high rate of bugs in your codebase.


Most of the traits that make good Perl code are the same traits that make good anything code: concise but readable, sensible naming conventions, useful comments, sensible logical structure that's not too complicated.

There are certainly a lot of things about Perl that are unique, but some time with the camel book and a few weeks of practice should sort that out for anybody with several years of production experience in another language.


There's nothing obvious about how to use persistent nested variables, or how to assign key/value pairs to a blessed file handle typeglob, or the difference between calling a package subroutine as either a method or a function. The more complicated your data structure gets, the more convoluted ways you can reference it. The subtle yet different ways to do the same thing (or almost do the same thing), like int@_ vs $#_ . Does the camel book explain the magic of $VERSION? Sure it's documented, but you'd have to read every perl doc to finally get to what it is and how it works, and then somehow remember its quirks amongst the pages and pages of docs you just read.

Evaluating true and false, or just simple comparisons, can be a mystery. Heck, just figuring out what's going to be a syntax error or not depending on if a variable was declared, defined, interpolated. Or referencing a nested data structure when one of the elements doesn't exist. Even just general conventions and best practices fills its own O'Reilly book. We haven't even begun talking about regular expressions.... Then there's the autoloader, and constants, namespaces, scalar/list context, signal handling, ....

Part of the difficulty of Perl is that you can write code that works perfectly until the clearly-obvious hole you left is triggered and a fatal error occurs, and then you get to learn about the debugger. It takes years to use all the parts of Perl that have weird magic or complex, non-obvious functionality tied to them. Saying you could use it all without problems after only a few weeks is really misleading.

The fact that there is a "strict" mode at all speaks to how difficult it can be to get the language right.


It has honestly been well over a decade since I last touched Perl (not that I'd mind going back to it), so I can't say much to most of your specific criticisms.

But, evaluating true and false in expressions is tricky in a lot of languages now. PHP is notorious for it. That's why you shouldn't mix data types. Regular expressions are no longer the sole domain of the Perl hacker, they're a regular staple of JavaScript and PHP and the commandline and other utilities.

Look, here's the thing: the response to avar has pretty much been, "you guys are doing it wrong", which is a seriously uncool armchair quarterback thing to say to someone else, especially someone that's a part of something as big as booking.com. If in fact their hiring process was as unutterably broken as you seem to believe it is, wouldn't you've expected their business to collapse in a pile of inscrutable bugs by now?

I'll readily agree that there's a vast difference between a coder in any particular language, and an expert in that language. That's why the experts get to define the language conventions used by a business, and the coders get to follow them. That's why there's testing and debugging and staging.

I try to assume least level of incompetence in other people on HN. Maybe instead of declaring things about their code base that you have no actual knowledge of ("There's no way anyone can just pick up Perl and write good Perl code without a dozen best practice errors. Hiring someone who doesn't know Perl very well basically guarantees a high rate of bugs in your codebase."), you could instead ask, "How do you guys handle training the guys that aren't very familiar with Perl quirks like int@_ vs $#_?"


I've worked at lots of places with really lame hiring and people just get stuff done. They also get stuff done with lots of bugs, which costs the company time and thus money. So inefficient hiring process does not mean your business folds, but it does mean your business may suffer.

And i'm not assuming any level of anything. If you learned spanish in Spain, you can't just go to Mexico or Venezuela or Argentina and pick up the local dialects, because there's different grammar and vocabulary and pronunciation you won't know until you run into it. Trying to write a paper in those countries after only using their dialect for a few weeks will land you with mistakes. I don't think this is a controversial thing to say. (And this is assuming you're picking up a very similar language; trying to go from Spanish to Portuguese would be nearly impossible in just a few weeks)


Grumble, don't talk about e.g. JavaScript regexps. :-(

>>which is a seriously uncool armchair quarterback thing to say

Imho, you read too much into the discussion. Everyone knows that Booking.com must be doing a lot of things right for their particular problem set and situation. It is a high profile place that attract good talent. (I am hardly alone in assuming they aren't too stupid to listen to Ovid et al.) Their situation is unusual and the resulting specific differences in methods will be questioned, because of their high profile.


You're "always hiring", but your interviews are remarkably short on actually writing any code and if someone asks too much about your approach to maintaining software quality (in light of your cowboy-coder reputation) you'll question whether they're "pragmatic" enough to work there and lose interest. Which I guess was probably things working out for the best, but Amsterdam was a fun city. Perhaps I'll find another employer there someday. Looking at London and Berlin in the meantime. :P


I quizzed my interviewers for about an hour on how Booking did things and why when I had my interview, and I still got hired. Besides, like everyone if we don't hire someone we don't tell them why due to liability reasons.

So if you had an interview and got rejected maybe it was for some completely different reason, I've certainly never heard about someone getting rejected because they asked too many questions.

You might get rejected because you don't seem like a good fit though. I commented on this a bit more specifically in a Reddit discussion a while ago: http://www.reddit.com/r/perl/comments/1mkdl4/what_exactly_is...

Anyway, it's unclear from your post whether you tried and failed at an interview with Booking, or whether you used to work there. If it's the former I'd be happy to help you with another try.

Like any employer we'd rather not hire one right person than hire ten people we shouldn't have hired, so statistically we reject some candidates that would have been good fits.


I went through an interview process at booking two years ago. After the phone interview, they asked me to come to Amsterdam for a face to face interview. To arrange travel details, they asked me to send passport details (scan of passport info page).

Seven days after I sent them the passport scan I got an email explaining "While we impressed with your background and experience, we have concluded that other candidates' qualifications more closely match the requirements for this position.".

I guess my age wasn't a good fit.


> If it's the former I'd be happy to help you with another try.

thanks, 'sgood. have an offer in Berlin, will be weighing it against a potential offer from London over the next few days. :)


Booking.com is a big place where newbies will be sitting with lots of experienced people they can ask and discuss with over lunch/coffee.

I doubt that smaller places will see so fast ramp up that they don't bother to hire people that know the language environment. The language in itself is quite irrelevant, but building a taste and learning the standard libs (here -- CPAN) takes time. That goes for every environment.

Edit: It would be interesting to hear the experience on this at other big shops? Maybe material for an academic article, someone?

Edit 2: I might add -- the differences between the scripting languages seems a bit overblown in the article. The languages (Perl, Ruby et al) aren't that different. Here I argued about the environment and standard libraries, which takes many, many hours for at least Python and Perl. And for taste -- to not have anonymous functions in Python needs changes in how you code. And so on.


Almost all the libraries you deal with are in-house. Which is part of what I'm pointing out, most of getting up to speed in any company is learning about their domain-specific codebase, not the language they happen to be using.

You're certainly at an advantage if you know some of those things already, that goes without saying. I'm just pointing out that many people seem to overestimate the impact of the programming language on the overall stack. Knowing DB workflows, distributed programming etc. is much more important than knowing language trivia which you can mostly trivially look up.


I don't disagree.

My point was, to take a simple example, at places like Booking.com [new] people will typically find out about the used CPAN Date classes from the code or their table neighbour. Not by rolling their own or crawling all of the CPAN before finding DateTime.

But sure, the internal code will be a bigger issue.


There is mention at the very bottom of this article that a great way to improve your Perl skills is to participate in the Google Summer of Code (GSoC) or the Outreach Program for Women (OPfW). I've been involved in the selection process of both of these programs for The Perl Foundation this year and in the past. This year The Perl Foundation is participating in both programs.

I spend a lot of my open source time working on Perl and specifically https://metacpan.org We have both a GSoC and an OPfW participant currently working with us. They're learning a lot and contributing a lot of really great work back to the project.

If you do want to get involved in something like this, my advice would be to get to know the project you want to be involved with well before the deadline. Reach out to one of the project leaders. Find out how you can get involved. Start contributing patches as soon as you can. When the time for applications comes, ask for feedback on your proposal _before_ you submit it. Writing a strong proposal is a skill in its own right and something that will benefit you in your later professional life as well.

Conversely, if you lead an open source project, don't wait until the call for submissions to start trying to recruit students. Get the word out early so that you can better judge who would be a good applicant.

Having this kind of experience under your belt can help a lot when considering Perl (or other languages) as a career option. I'm happily coding Perl full time, but even if that's not the path you eventually take, it's still a great tool to have access to.


I went from working at Silverlight shop to a Perl shop two and a half years ago. The experience has been great. The article hits the nail on the head in terms of pros and cons.

The learning curve going from C# to Perl wasn't that bad. Both are expressive and share a number of idioms. Moose is easily one of the best parts of the toolkit and the one thing I miss most when doing Objective C and C# projects.


Back during my training, I used to do practically all of my coding in Perl. I loved it. Then I stumbled upon Python and Ruby, and I did not look back for a long time. When I did, I realized how much I disliked Perl's type system (or lack thereof). I sort of drifted around for a while between Python, Ruby, and Lua (although I do not really like Lua as a stand-alone scripting language, it totally rocks as an embedded scripting/extension language).

About 15 months ago, I started working as a sysadmin at a smallish (~100 people) engineering company, and I re-discovered Perl. I am not sure I would like to implement any largish piece of software in Perl, but as a scripting language for system administration, it still rules. Especially on Windows, which still feels like a downright hostile environment for programming.


I don't really get what is different with Perl and the other scripting languages for types, but check Moose.

E.g. http://search.cpan.org/~ether/Moose-2.1210/lib/Moose/Cookboo...

Quite OK for one of the scripting languages, imho.

  has 'employees' => (
      is      => 'rw',
      isa     => 'ArrayRef[Employee]'
      default => sub { [] },
   );


Yeah, learning Moose has been on my todo-list for a while now. Back when I still used Perl almost exclusively, I hardly did any object-oriented programming in it, and when I did, it felt awkward. Moose looks like a game changer, both for OOP in Perl and for typing. Right now, I have a lot on my plate, but once my schedule clears up a little, I will look into it. Thanks for the hint! (For sysadmin-scripting, non-OOP Perl is entirely sufficient, though.)


You should also check out Moo[2] and Mouse[1]. They both try to be simpler versions of Moose without the compile-time (and runtime) performance issues of Moose. They do that by dropping some things like metaobject protocols and other things that are great for introspection but may not be something you really care too much about. They both try hard to keep syntactically the same as Moose when possible so that you can most of the time use them all interchangeably.

[1]http://search.cpan.org/~gfuji/Mouse-2.3.0/lib/Mouse.pm [2]http://search.cpan.org/~haarg/Moo-1.005000/lib/Moo.pm


Additionally, Moops[1] may be useful to get some extra sugar going. It's a meta module that includes a few other modules to give you a sane (Moose/Moo) object model, plus function and method signatures through Method::Signatures.

For example:

    use Moops;

    role NamedThing {
       has name => (is => "ro", isa => Str);
    }

    class Person with NamedThing;

    class Company with NamedThing;

    class Employee extends Person {
       has job_title => (is => "rwp", isa => Str);
       has employer  => (is => "rwp", isa => InstanceOf["Company"]);

       method change_job ( Object $employer, Str $title ) {
          $self->_set_job_title($title);
          $self->_set_employer($employer);
       }

       method promote ( Str $title ) {
          $self->_set_job_title($title);
       }
    }

[1] https://metacpan.org/pod/Moops


Two common Perl problems:

People think Perl 6 is merely an incremental change of Perl 5

People thing pre-MOOSE pre-ModernPerl is the same as post MOOSE post ModernPerl because they're both Perl 5.

One problem with the article is thinking "a" language is your career. That's just weird.


I have been thinking about looking for a new job. I seem to be fairly well paid here as far Spain goes, so I was looking at the corporate option as they are the only ones that seem to pay more. Its all .Net or Java. And they ask for in the job ads. I agree there is a fault in turning down an experienced developer because he (or she) hasn't got experience with a specific language. But that doesn’t mean it doesn’t happen. All the time.


The idea that there is some under-appreciated, reliable technology that's already solved a lot of problems people are trying to address today is compelling to me. In fact, I've learned that I almost need to actively ignore short pieces of advocacy in order to keep them in perspective.

"Modern Perl" is an improvement on the coding styles that earned statements like "write once, read never". However, I think it is relevant to read "The Mid-Career of the Perl Programmer"[1] written by chromatic, who wrote the book on Modern Perl.

Realistically, the audience for this article will probably be people who are starting out with programming in addition to their primary job skills. Someone else further along probably isn't likely to choose one programming language for a career specialty.

While you can use Perl for automation, scripting, and data analysis as easily as you could in the past, there are additional tools available now. I feel that choosing Python, R, or Julia, depending on the task, maybe even VB.net is going to get people up and running faster, and also end up being a better starting point for doing more later if people get inspired.

[1] https://news.ycombinator.com/item?id=7373038


Coming from shops that were all about Java, Rails, and C# (but using Python myself), I was surprised at how much new (performant) Perl my current company generates. This is probably part of the reason for my new found love of Awk.

Perl is still a viable language, and a lot of the choice comes down to taste.


For anyone interested, DuckDuckGo is hiring Perl engineers... https://duck.co/help/company/hiring


An article about Perl invoking Slashdot discussion certainly feels anachronistic. I quit Perl relatively soon after Python's debut, though I still miss the feel of the whole Free/Open Source software movement during the Age of Perl. No doubt Perl and CPAN helped build the house we now live in.


Perl is an awesome tool to have under any developer's belt. It's likely that somewhere during the course of your development you'll need to hack together some one-off script to do something and Perl is likely the best tool for the job and will probably already be on your system. It's worth it to learn it for no other reason than it's probably the most productive tool for this kind of use-case available. It'll also give you some ideas for your main development languages in how things can work, and the "perl way" of doing things will bleed into that. You'll start to look at some of the overly complex line consuming ways of doing things like "reading in a text file to a string" as moronic and will start to write abstraction libraries to "fix" your other languages.

I know this is a limited view of Perl (and I'm a huge fan of Perl and using it in various key places has helped provide for a not-insignificant percent of my lifetime career earnings). But Perl 6 has effectively killed Perl.

It's a case of announcing too early and getting the entire community to back off from investment of resources into new Perl code when Perl 6 feels like it's been just around the corner for years.

Regardless of how you think of Perl 6 (an incremental upgrade or a major overhaul) the effect has been the same in almost every Perl shop I'm aware of. People backed off of new Perl 5 work, expecting it to stagnate (it didn't, but perceptions are hard to overcome) and waited and waited and waited for the version # in their perl -v to increment to 6.

Since they were going to switch to new code anyway, why not try out the half-dozen other languages that have soared in popularity since? And now you end up with the situation we have now.

Perl 6 also provided a long standing competition target for other languages to hit. It allowed other languages to figure out what Perl 6 was and wasn't going to bring to the table and hit the kinds of things that people really needed.

My ultimate opinion on 6 is that it's a huge effort/a major rewrite, for some rather incremental changes, without addressing long standing issues with Perl for large-scale development work. There's some really cool stuff in Perl 6, built in grammars are potentially amazing, but I'm not sure a 14 year wait (and counting) was worth it (and yes, I'm aware there are some implementations available, but until perl6 is a default command from the cli in any major *nix distro it doesn't matter).


> But Perl 6 has effectively killed Perl.

Oh fuck off, no one has been confused/concerned about the 5 vs 6 version numbering thing for at least 10 years. 5 is production, 6 is where the crazy geniuses experiment with language features, everyone knows that they're two separate things. Since 5.10 we've had major (sub)versions of 5 every year, consistently. And the better ideas from p6 creep their way back into p5 in the way of modules or features in new versions, so it's hardly for naught. The only real mistake was calling it "6" instead of "Dr. Wall and Conway's chimera language of onion and camel goodness" or something.


So let's say I decide to put 30 developers and QA guys into writing Perl 5 code for the next year. That's an investment on the order of $6-8 million dollars.

Why should I choose to do that? 5 is a moving target, and the island of stability (Perl 6) seems to be just around the corner forever. Except 6 will be an early, unoptimized version of whatever it will eventually become so I won't want to use it till it's well tested in real environments. Okay so I wait another year after 6 comes out, now I have even more legacy code to deal with.

So what are the metrics to port Perl 5 to 6? I have no idea, nobody really does. What does it cost to move 2 million lines of Perl 5 to Perl 6? The syntax is just different enough that I'll have to add another $1-2 million dollars or so into the long-term budget to port my Perl 5 code to Perl 6. I'm aware there are some conversion utilities, but now I have to QA all of the converted code and check for regressions and then fix them when they show up.

Sure I can just write for 5.xx and just stay there forever, but what if 6 does generally come out? Will the development community just shift over to 6 and now I don't get feature improvements and bug fixes? What's the long-term support case look like? I can't exactly contract the "Perl Company" to ensure I have long-term Perl 5 support for the next 5-10 years. So I'm just guessing and praying that what I'm building will have long-term support.

Or I can just tell my team to build in Python or Java or something else, not worry about all this and save $1-2 million in eventual porting and long-term maintenance costs.

There's actual business reasons for this. Every technical decision maker ruminating on Perl has gone through this, and they've decided to not go with Perl for these kinds of reasons. Which is why there are so few jobs requiring Perl, and why nobody bothers to learn it anymore.

Now, you may be swimming in hundreds of millions of dollars of personal wealth and can afford to make the decision to go with Perl, and that's cool. But unless you're willing to offset instability in the platform with personal investments in thousands of companies and development efforts, you can swear at me all you want, it won't change anything until Perl is again a stable platform and is solving people's problems.

To put the woes of Perl 6 in even more perspective. It's taken so long for Perl 6 to happen that Go, a language that didn't even exist when Perl 6 was announced, had a team formed, was announced, was developed with full-tooling and a robust standard library, went through betas, and is now in production use inside of hundreds of companies in less than half the time than it's taken for Perl 6 to get into some kind of alpha stage from announcement.


> 5 is a moving target, and the island of stability (Perl 6) seems to be just around the corner forever.

The idea of 6 as an island of stability and 5 as a moving target is exactly backwards.

And Perl 5 has had fewer breaking changes than any of its popular scripting siblings... Ruby (1.8 -> 1.9 anyone?), Python (oh, yes, let's talk about 2 vs 3, shall we?), or PHP (in which build flags introduce breaking changes, let alone stuff that's come with some 5.x dot release).

> So what are the metrics to port Perl 5 to 6? I have no idea, nobody really does. What does it cost to move 2 million lines of Perl 5 to Perl 6?

It doesn't matter what it'd cost at this point because there's no reason to do it, nor is there any visible time on the horizon at which you'd need to do it. Like the GP said, 5 is production, 6 is where people experiment with language features, and 5 has shown that it has plenty of future through regular stable releases and feature enhancements since 5.10 (released 7 years ago!).

> Every technical decision maker ruminating on Perl has gone through this, and they've decided to not go with Perl for these kinds of reasons.

Every technical decision maker worried about the Perl 5->6 transition over the last few years is someone who didn't actually do the kind of diligence a good technical decision maker should do, and hopefully that's a one-off mistake rather than indicative of the general quality of their judgment.


Every technical decision maker worried about the Perl 5->6 transition over the last few years is someone who didn't actually do the kind of diligence a good technical decision maker should do.

That's unfair. The current motto of the p6 faithful has become "It's a sister language not intended to replace Perl" over the years, but a lot of things have changed over the years. If and when a usable p6 is released, who knows what the motto will be then?

You brushed over the Python 2 to 3 migration, but at least that one had a coherent strategy. It's not an easy strategy, but there's an end of support date for Python 2. There's a widespread effort to port libraries and frameworks and projects to Python 3.

That hasn't happened yet for Perl. It's not clear if that's ever going to happen for Perl. No one is exactly sure how much of the CPAN p6 will support, if any.

Will people start writing more new code in p6 instead of Perl? Will people port code from one to the other? Will p6 be able to use existing libraries? Will those libraries be usable in the same process?

When will p6 be stable? When will it have documentation? When will it have support, from a community point of view or a vendor or bundling in a supported distribution? When will it have tool support? What is its deprecation policy? What is its support period? Who will use it? What will they use it for? How much training do they need? How much do they charge? How easy is it to hire them?

There are so many unknowns. It's unfair to sweep them under the rug and say "Everyone should know that Perl is Perl and 6 is something else and the latter doesn't matter."


> If and when a usable p6 is released, who knows what the motto will be then?

I guess I don't see why that's an important question when:

- there's no horizon on which a complete implementation (or stable target for a spec/test suite, for that matter) is promising to arrive

- 5.x has demonstrated it's a living/growing branch with as much a future as any open source project

- By comparison, for something like Python, the concrete reality of having a plan for changing horses midstream seems to be more painful than just keeping on with Perl 5

Or are those false assumptions?

I don't really expect everyone to keep up with everything about Perl. I'd certainly had no idea 5.10 was even a glimmer in someone's eye for over a year after it had come out because I was busy with front-end work and PHP projects. And I'm responding partly because maybe I've missed something again and this is a learning opportunity.

At the same time, when someone speaks up as the GP did and asserts that technical decision makers have done their homework and picked things like Python or Java by comparison to insulate themselves from the spectre of version shifts and associated porting costs, I think they may have earned themselves a challenge.


there's no horizon on which a complete implementation (or stable target for a spec/test suite, for that matter) is promising to arrive

That is the problem.

The future of Perl is very, very difficult to predict. 14 years ago, the next major version was announced. It was explained and designed and promoted in public by gathering the community's list of 361 technical flaws.

P6 is now older than Perl was when P6 was announced and no one can tell when or if P6 will replace Perl. That includes developers as well as users and technical decision makers. If you start a new project in Perl today, how long will it be supported? Will you be able to hire or train enough developers? Will you be able to retain them? Will P6 ever replace Perl?

Python has its difficulties with the gradual adoption of Python 3, but at least there's a consistent and coherent story about community expectations. Perl doesn't have that, and that, to me, as a technical decision maker, is a huge risk.


I have always wondered why more people don't point out the great reputation that perl has had with backward compatibility.


Python and Java are moving targets as well. Adoption of Python 3 in particular has been very slow. Who told you that any language is an 'island of stability'? Use C if you want something approaching that. :-)


I think 'bane' is perfectly aware of your point, that Perl 5/6 are very different languages and even Perl 5's incredibly backwards compatibility.

Iirc, he has trolled in Perl discussions before.


Code is the least part of the problem. Build a loosely connected system in the languages specialising in that segment. Perl for text processing, Java for message passing, Python to glue it together, Prolog for some AI, whatever floats your goat.

For a multi-million dollar development with more than 6 developers, code is the least of your worries.


Perl is on the sure way to become the COBOL of the scripting world. I'm saying this as one who invested years into learning and applying Perl everywhere I could. But seriously, it's a done deal now. Move on.

Yes, there are still companies with large Perl code-bases. Large Perl code-bases need a lot of maintenance (sigh). So Perl programmers will be in some demand for a few years at the least. Hence the analogy to COBOL.


Wouldn't COBOL be classic scripting - one funny thing at BT we had a lifer COBOL guy (20 years plus on mainframes) join our perl team - he found the transition hard "where are the Divisions" was one quote from him


When was the last time a COBOL project has generated as much buzz as Perl's Mojolicious has just yesterday? https://news.ycombinator.com/item?id=8095574


That's a little unfair. COBOL just isn't well suited to problems solved by a new web framework. Batch processing of financial data is important, but it ain't likely to generate buzz.


As opposed to Perl, which was designed as a web framework language?


Point taken, but Perl has a (very) long history of being the glue the holds websites (and everything else) together. I think perl files in cgi-bin is the first time I ever connected a database to a web page.


COBOL has an even longer history processing business and financial data. Perhaps COBOL is the secret sauce that hedge funds use for high frequency trading?


Maybe you just weren't a good enough programmer for Perl?


That's entirely possible. Perl's trajectory in the past 7-8 years is, after all, consistent with all the stars staying and all the bad programmers leaving.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: