in reply to XBASIC to Perl translator: semantical equity

Don't use automated translators for mission-critical code. Hire someone to translate it for you. If it's mission-critical, it's worth something to someone, right? Well, make them prove it.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

  • Comment on Re: Mission critial code required: I have some code in BASIC and require it to be translated to perl

Replies are listed 'Best First'.
Re: Mission critial code required: I have some code in BASIC and require it to be translated to perl
by Abigail-II (Bishop) on Apr 16, 2004 at 12:05 UTC
    Why even bother translating it? It's mission critical and it works to such satisfaction that it's considered a reference implementation - translated code should work identical to the original, instead of adhering to some specification.

    Why take the risk of breaking it?

    Abigail

      BTW I thought about Inline'ing, but XBASIC isn't supported yet.

      There is no specification - just code. The author did some comments within the scientific paper, but no mathematical formula or whatever were used to introduce the idea behind it. So i have the bare bone xbasic code which i want to play with. But i am reluctant to use xbasic, but prefer to have perl code (which the original author doesnt supply). I am looking forward to enhance it (DBI, XML, etc).

      I especially fear that perl will suffer "numerical instabilities" when floating points were used.

      20040417 Edit by Corion: Exchanged PRE tags for P tags

      Edit2 by Chady: fixed link.

Re^2: Mission critial code required: I have some code in BASIC and require it to be translated to perl
by adrianh (Chancellor) on Apr 24, 2004 at 00:00 UTC
    Don't use automated translators for mission-critical code. Hire someone to translate it for you. If it's mission-critical, it's worth something to someone, right? Well, make them prove it.

    I don't know. If you have a lot of source code in Foo then it can be more time efficient and less error prone to re-implement a Foo compiler that targets something else than it is to translate all the code by hand.

    I once had to help shift a fair sized app (about 20KLOC) from some old PDP-11 hardware that was implemented in a home grown bastard offspring of Lisp and Prolog. Rather that translate the code we just re-implemented the language in Common Lisp. I guarantee that doing a manual translation of the code would have taken a heck of a lot longer, and probably introduced a bunch of errors into working code.

      That is one option. I tend to prefer, after a few times doing this, to rewrite the app. The number of improvements and bugs fixed tend to outweigh the number of errors. Granted, I have only worked with relatively young apps and rewriting them after they were implemented by junior developers. *shrugs* YMMV, as with everything.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        That is one option. I tend to prefer, after a few times doing this, to rewrite the app. The number of improvements and bugs fixed tend to outweigh the number of errors.

        If you have buggy code that nobody understands then translation may be a better option.

        In my case my clients were perfectly happy with their little language and the quality of their codebase. They were not happy with their PDP-11s - which were getting more expensive to maintain every year. So building a new compiler for a new box was the obvious decision. For all I know they're still tweaking their little expert system now.

        If we'd gone the translation route then not only would the development time have been longer, the client would have also had to retrain their internal people to use a new language.

        Also 20KLOC isn't really that much. When you have organisations with hundreds of programmer years invested in their code you know why they prefer to take compiler development in-house rather than manually convert everything to whatever the current language-of-choice is :-)

        The number of improvements and bugs fixed tend to outweigh the number of errors. Granted, I have only worked with relatively young apps and rewriting them after they were implemented by junior developers. *shrugs* YMMV, as with everything

        Indeed. Sometimes moving to another language is exactly the right thing to do. Context is everything.