I'm going to roll back to the perl to powershell rewrite. The right tool here was probably the one that already exists. There is a time and place for rewrite, but I don't suggest not knowing the language as being on.
I agree with you in general. I considered adding a point that when contributing to an existing project, the right tool for the job is the language the project is already written in. In the example I gave of the co-worker rewriting Perl scripts in PowerShell, these are all little scripts that were written by his predecessor to make certain tasks easier (what Perl excels at). They are only used by that position.
I'm known as the Perl guy around the office, so early on (the new co-worker has been here a little over a year now) the co-worker did ask for my help when he needed to make a few adjustments to one of the scripts. The script was only a few dozen lines (and definitely not what I'd consider Modern Perl--no use strict or use warnings). The script I helped with takes a spreadsheet provided by the payroll office (saved as a CSV) of retirement contributions, and sums up contributions per employee. The spreadsheet from payroll has multiple lines per employee: employer contribution, employee contribution, employer match, etc., but when the file is submitted to the company that manages our 403(b)s, they want a single line per employee. The script does have to be maintained. There are occasional changes to contribution codes and/or the format the third party expects.
It may have been best to leave them in Perl, but since the scripts are short, self-contained, perform simple tasks, only used by that position, and must be maintained by that position, I don't think rewriting them was a terrible decision.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm going to roll back to the perl to powershell rewrite. The right tool here was probably the one that already exists. There is a time and place for rewrite, but I don't suggest not knowing the language as being on.
I agree with you in general. I considered adding a point that when contributing to an existing project, the right tool for the job is the language the project is already written in. In the example I gave of the co-worker rewriting Perl scripts in PowerShell, these are all little scripts that were written by his predecessor to make certain tasks easier (what Perl excels at). They are only used by that position.
I'm known as the Perl guy around the office, so early on (the new co-worker has been here a little over a year now) the co-worker did ask for my help when he needed to make a few adjustments to one of the scripts. The script was only a few dozen lines (and definitely not what I'd consider Modern Perl--no
use strictoruse warnings). The script I helped with takes a spreadsheet provided by the payroll office (saved as a CSV) of retirement contributions, and sums up contributions per employee. The spreadsheet from payroll has multiple lines per employee: employer contribution, employee contribution, employer match, etc., but when the file is submitted to the company that manages our 403(b)s, they want a single line per employee. The script does have to be maintained. There are occasional changes to contribution codes and/or the format the third party expects.It may have been best to leave them in Perl, but since the scripts are short, self-contained, perform simple tasks, only used by that position, and must be maintained by that position, I don't think rewriting them was a terrible decision.