What would be more productive? Converting VAX PASCAL into GNU PASCAL or port it to perl or some other language

Question

I have this legacy code base (Compaq PERL), about 1500 lines of code, that I need to port to Windows. I wanted to use gnu PASCAL (which I have installed and have working). I have already got our assembler (HP 64000 8051) off the VAX and on to Windows (KEIL 8051).

The director of Software engineering would like to get all products off the VAX. Here is the rub, I have tried to compile the PASCAL from the VAX on CYGWIN using gpc. There seems to be alot of things that would need to be done to get (IO and algorithmic ) equivalence from one PASCAL to the other.

I know PERL,FORTRAN,C and C++ fairly well( and JAVA but I would rather not). My question boils down to with 1500 lines of code would it be more productive to port the PASCAL code to the other PASCAL, or would it be more productive to port it to another language? VAX PASCAL was my first language in college but I haven't actively programed in it in 8 years. I work with PERL,C,C++, and FORTRAN all frequently and professionally .

I would say as far as my choice, PERL would be it if I was going to convert to another language.

What the code does is perform fills and a check sums for INTEL hex and TEX HEX image files. I am aware of the Srec 1.4 program that will work, but it is not an option,because I have to get my code qualified for DO-178B (And my company is leery of using open source code)(They have no problem with open source tools; just code).

Answer 1

Given that it is only 1500 lines of code, and that while Pascal had many virtues I/O was not one of them, I would port the whole thing to C, breaking it up into modules and writing some unit tests along the way. Porting to a new Pascal there's a big 'unknown factor' in just how compatible the different dialects are. If you port it to C you'll know by the end of the first day how long the job will take, and once you've done it you'll have it thoroughly nailed, because C will outlive us all. And I agree with Joel Neely; it will always be easy to find another C programmer to maintain it.

Because the program is so small and is mostly I/O and integer manipulation, I don't see a role for C++ here. Not worth the extra complexity.

Answer 2

I would try to port it to Free Pascal, but with a time limit. If it's too hard, then fall back to a more recently used (by you) language.

Is there any way to test if the new (ported or translated) version behaves the same as the old one?

Answer 3

I would first consider long-term maintainability (including by someone other than you). If, for example, you're the only one who knows PASCAL and you don't want to be the sole owner of maintenance and support for this program, then PASCAL might not be as good a choice as a language with a wider developer base in your shop.

If that is not a decision issue (e.g. multiple developers all equally familiar with the same range of languages), then I'd estimate time for the gnu PASCAL port to time for e.g. the Perl port and go with the target language that would take less time to use.

If that also is not a decision issue (i.e. equivalent level of effort), then I'd look at run-time economy (higher speed, smaller memory footprint).

Answer 4

I think porting 1500 lines of code to any language/platform should not be too hard given the fact that all you need to do is "perform fills" and compute checksums. Personally I would have preferred C# - it has a soothing effect on my mind :) but given your proficiency in C/C++ I would advise that you go with C++ for the simple reason that C++ is the world's best assembly language and will fulfill your requirements perfectly. I think pascal is some what antiquated and new projects should avoid it. Please feel free to correct me if I am wrong.

Programming in C is a chore and to leave some room for further enhancements to your program C++ seems to be the best option. Also do not forget unlike C, C++ has some very capable libraries backing it up (STL, Boost etc).

Answer 5

I always try to write programs as much as possible in the language the company mainly uses.

It makes no sense to resort to a scripting language (because it is a fragment easier) if there are six programmers sitting doing C++ in the company, increasing the language requirements on the next hire.

Personally I resent Perl because, well, the syntax is slightly cryptographic. Moreover it is not such a "corporate" language, specially not here, and outside of the Unix sysadmin corner it is hard to find people that are really versed in it (*)

Note that this is just a write-up from my current viewpoint, which is mostly that of a programmer in a small shop with big commercial clients that force their practices on us. YMMV.

(*) webdevels do mostly ASP.NET here.