3 ms·

My experience with Perl: We (a corporate shop) have a lot 'legacy' scripts in Perl. I am assigned to maintain such scripts as no one else wants that role. I

My experience with Perl: We (a corporate shop) have a lot 'legacy' scripts in Perl. I am assigned to maintain such scripts as no one else wants that role. I discover, Perl is powerful. Every 'legacy' script I find can be trivially regression tested (These scripts always have the same pattern, take some input, produce some output). Managers want to move away from Perl. I want to move closer to Perl.

protomyth 10y ago
The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do that well. Perl did that amazingly well[1]. Its really trivial to write easy to maintain code that does that in a very standard (across programs) way. 1) Data Munging with Perl was a pretty good book for it
- digi_owl 10y ago
  Work is receive input, mangle input, send output once you generalize it enough. but the devil will definitely be in the details.
  - protomyth 10y ago
    Oh yeah, the details are the problem. Worse, its a technical problem and a people issue for some kinds of output. Report Writing has all of the problems of graphic design and date munging with none of the rewards. Lord help you if the friggin DBA & Application Developers built the database or other data sources for transactional processing and didn't provide any help (e.g. summary tables, other data source) for batch (set) processing. I now follow a simple law when setting up a data source: If I need attribute X from an item then I better have a way to find all items with attribute X in a hurry.
- Bromskloss 10y ago
  > Cobol lives because it could do that well. Can't every language do that well?
  - protomyth 10y ago
    Amazingly enough, not really. Quite a few don't do it at all without some really good library support. Its not really that "sexy" of a problem and often ignored by people developing languages for interactive situations.
    - nickpsecurity 10y ago
      On top of that, I know actual companies that specialize in doing this for bigger companies. The companies want to move something from form, database, file, or whatever to another. Or merge several with some analysis into a new one. You'd think this would be automated or a simple job for one, on-site programmer. Instead, these firms get paid big money to do that on a regular basis for the same companies. Mind-blowing.
      - protomyth 10y ago
        You would think, but it does take some upfront thinking about how to get data cleanly out of one system and into another. Most developers don't really care about that part so you pay big bucks later. If your report writers are struggling getting collection-style reports (e.g. "give me all open contracts"), expect to pay through the nose.
- yeowMeng 10y ago
  And sometimes you find out data file Z is itself a Perl script :)
  - protomyth 10y ago
    Yep. It is often much easier (see UNIX pipes) to break a problem down into steps that can be paused / restarted, not to mention just making the logic of each piece much simpler. I've seen where one class of data (e.g. transactions on contracts) are broken down into subclasses (e.g. commercial, individual) then processed by a different perl program to be recombined into one set that is finished by another perl script. Its amazing how 5 very simple programs is easier to maintain code-wise and operations-wise than 1 big program sometimes.
    - unexistance 10y ago
      microservice :D
      - protomyth 10y ago
        I would so like to get a diary from a group that transitioned a overnight text batch system to a collection of microservices.
digi_owl 10y ago
Yep, powerful enough to power an online payment system. http://www.antipope.org/charlie/blog-static/2009/06/how_i_got_here_in_the_end_part_7.html http://www.antipope.org/charlie/blog-static/2009/06/how_i_go...
ianai 10y ago
Do they even have a replacement in mind already?
- 0xdeadbeefbabe 10y ago
  Wouldn't they need a mind to put something in mind?
PopsiclePete 10y ago
I can write Perl. Okay-ish. But I can almost never read Perl. I mean, I can read my Perl, 75% of the time, but other people's Perl? Very difficult. Managers (wisely) know that a large important project isn't (shouldn't be) built by one super-star programmer who then decides to leave for greener pastures, but that it's read, often times more than its written, by a team of people. Readability > Writability. And so Perl was destined to "fail" in the corporate world, at the expense of more boring languages like Java/C#. Of course there's exceptions and I'm sure there's 2-3 companies still out there that run Perl exclusively, but ultimately, it's a "bearded-loner-sitting-in-the-corner" language. Not that there's anything wrong with that.
- spraak 10y ago
  > And so Perl was destined to "fail" in the corporate world, at the expense of more boring languages like Java/C#. Can you explain how Perl was destined to fail in the corporate world?
  - aaronbrethorst 10y ago
    I'm up-voting you in the hope that this is an incredibly droll joke. And, in case it is: very well-played.
- Mithaldu 10y ago
  Without saying what your level of expertise is, and showing a sample of your Perl, drawing any conclusions from your statements is like reading tea leaves. Readability, of ANY code, is more often than not determined by how good the author is at naming things and avoiding senseless repetition (which are both skill honed with experience), and much less by any given feature of the language itself.
kamaal 10y ago
>>Managers want to move away from Perl. >>I want to move closer to Perl. I remember as a young programmer, our client once asked us to produce tool to migrate an entire legacy version control system with something like 20 years of history to a different version control system. It first went to up to some UML drawing Java architect, he came up with a estimate to have it done in 3 months with a team of 2-3 people working full time. The client was like "Never mind, forget about it". A few weeks passed by and client had dropped their mind to migrate the history and opted to just have the latest files checked in. In a random discussion with my manager it got a mention. My manager asked to check if I can do it quickly. I remember I wrote a script over the weekend and had every thing done. It was in Perl. The script then got passed around and lot of people migrated their repos. Finally it reached the Java architect. He had a hard time believing something like a few thousand lines of functioning feature rich code could even be written over the weekend. We had a good talk about it. Perl belongs to a very different culture of programming/programmers who care only about solving problems and getting things done. Its not exactly a language that blends well with corporate political goals.

protomyth 10y ago

The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do that well. Perl did that amazingly well[1]. Its really trivial to write easy to maintain code that does that in a very standard (across programs) way. 1) Data Munging with Perl was a pretty good book for it

digi_owl 10y ago
Work is receive input, mangle input, send output once you generalize it enough. but the devil will definitely be in the details.
- protomyth 10y ago
  Oh yeah, the details are the problem. Worse, its a technical problem and a people issue for some kinds of output. Report Writing has all of the problems of graphic design and date munging with none of the rewards. Lord help you if the friggin DBA & Application Developers built the database or other data sources for transactional processing and didn't provide any help (e.g. summary tables, other data source) for batch (set) processing. I now follow a simple law when setting up a data source: If I need attribute X from an item then I better have a way to find all items with attribute X in a hurry.
Bromskloss 10y ago
> Cobol lives because it could do that well. Can't every language do that well?
- protomyth 10y ago
  Amazingly enough, not really. Quite a few don't do it at all without some really good library support. Its not really that "sexy" of a problem and often ignored by people developing languages for interactive situations.
  - nickpsecurity 10y ago
    On top of that, I know actual companies that specialize in doing this for bigger companies. The companies want to move something from form, database, file, or whatever to another. Or merge several with some analysis into a new one. You'd think this would be automated or a simple job for one, on-site programmer. Instead, these firms get paid big money to do that on a regular basis for the same companies. Mind-blowing.
    - protomyth 10y ago
      You would think, but it does take some upfront thinking about how to get data cleanly out of one system and into another. Most developers don't really care about that part so you pay big bucks later. If your report writers are struggling getting collection-style reports (e.g. "give me all open contracts"), expect to pay through the nose.
yeowMeng 10y ago
And sometimes you find out data file Z is itself a Perl script :)
- protomyth 10y ago
  Yep. It is often much easier (see UNIX pipes) to break a problem down into steps that can be paused / restarted, not to mention just making the logic of each piece much simpler. I've seen where one class of data (e.g. transactions on contracts) are broken down into subclasses (e.g. commercial, individual) then processed by a different perl program to be recombined into one set that is finished by another perl script. Its amazing how 5 very simple programs is easier to maintain code-wise and operations-wise than 1 big program sometimes.
  - unexistance 10y ago
    microservice :D
    - protomyth 10y ago
      I would so like to get a diary from a group that transitioned a overnight text batch system to a collection of microservices.

digi_owl 10y ago

Yep, powerful enough to power an online payment system. http://www.antipope.org/charlie/blog-static/2009/06/how_i_got_here_in_the_end_part_7.html http://www.antipope.org/charlie/blog-static/2009/06/how_i_go...

ianai 10y ago

Do they even have a replacement in mind already?

0xdeadbeefbabe 10y ago
Wouldn't they need a mind to put something in mind?

PopsiclePete 10y ago

I can write Perl. Okay-ish. But I can almost never read Perl. I mean, I can read my Perl, 75% of the time, but other people's Perl? Very difficult. Managers (wisely) know that a large important project isn't (shouldn't be) built by one super-star programmer who then decides to leave for greener pastures, but that it's read, often times more than its written, by a team of people. Readability > Writability. And so Perl was destined to "fail" in the corporate world, at the expense of more boring languages like Java/C#. Of course there's exceptions and I'm sure there's 2-3 companies still out there that run Perl exclusively, but ultimately, it's a "bearded-loner-sitting-in-the-corner" language. Not that there's anything wrong with that.

spraak 10y ago
> And so Perl was destined to "fail" in the corporate world, at the expense of more boring languages like Java/C#. Can you explain how Perl was destined to fail in the corporate world?
- aaronbrethorst 10y ago
  I'm up-voting you in the hope that this is an incredibly droll joke. And, in case it is: very well-played.
Mithaldu 10y ago
Without saying what your level of expertise is, and showing a sample of your Perl, drawing any conclusions from your statements is like reading tea leaves. Readability, of ANY code, is more often than not determined by how good the author is at naming things and avoiding senseless repetition (which are both skill honed with experience), and much less by any given feature of the language itself.

kamaal 10y ago

>>Managers want to move away from Perl. >>I want to move closer to Perl. I remember as a young programmer, our client once asked us to produce tool to migrate an entire legacy version control system with something like 20 years of history to a different version control system. It first went to up to some UML drawing Java architect, he came up with a estimate to have it done in 3 months with a team of 2-3 people working full time. The client was like "Never mind, forget about it". A few weeks passed by and client had dropped their mind to migrate the history and opted to just have the latest files checked in. In a random discussion with my manager it got a mention. My manager asked to check if I can do it quickly. I remember I wrote a script over the weekend and had every thing done. It was in Perl. The script then got passed around and lot of people migrated their repos. Finally it reached the Java architect. He had a hard time believing something like a few thousand lines of functioning feature rich code could even be written over the weekend. We had a good talk about it. Perl belongs to a very different culture of programming/programmers who care only about solving problems and getting things done. Its not exactly a language that blends well with corporate political goals.