Hacker News Reader

Comment by paulhauggis | Hacker News Reader

The shittiest project I ever worked on was a php project that was converted from another language (I don't remember which one). This doesn't sound bad, except they used software to automatically convert it. The PHP code had no comments, minimal white space, and the variables were all hex. My job was to fix bugs.

I worked there for about a week before I quit in frustration.

View on HN

Well, I once worked on a Web App that was written in PL/SQL, that produced HTML. Every variable was named v1, v378, vT31 (yeah no order), and the whole app was in 3 procedures each 80,000 lines of code, AWFUL AWFUL CODE. Honestly the horrors. Stuff like:

   if condition
      do x
   else
      do x

I worked on it for a month and it felt like years.

That's nothing. I had to fix someone else's program once. It was written in PERL.

Damn, it reminds me of one of the projects I worked on, a .NET Winforms project with about 2 MLOC.

It was the result of automatically porting a codebase written with a RAD system called Gupta Team Developer / SQLWindows[1]. The original language supported multiple inheritance and the converted code was a huge mess of tangled interfaces trying to reproduce that. The tool generated lots of duplicated code and some monster constructs like a static class with 140.000 lines of code, with all public methods.

I still weep for my colleagues who were left to tame that mess.

[1] http://en.wikipedia.org/wiki/Gupta_Technologies

How can someone suggest auto convert into another language like that?

In the long run it would be cheaper rebuilding the entire thing.

Every developer would agree and every suit would disagree.

I once worked on a project that was auto converted from VB6 -> C#. Amazingly it compiled and parts of it actually ran.

We still rewrote the entire thing, line by line and then spent months refactoring it. It was our only choice really, so much of the original code was so unclear and all the original developers had left so it was our only hope of keeping the business logic intact.

Joel will have a word with you now

There are some (very few) cases where it makes business sense.

For example, the company I work for has software developed in a legacy language with no support (Forte 4GL).

There are companies that offer Forte to Java migration, it would have been worth it because of better tools and support (even if the code was the same crap as usual :) ).

I've actually been involved in at least three projects to do precisely that. And mostly they worked fine.

In two of the three cases I was converting between "the same language" but different incompatible versions of it and the original code bases had strict style guides. At the end of it everything worked brilliantly, and the code was just as maintainable as it was before the conversion.

In the third case was an full lexer/parser built out to compile VBScript down to JavaScript. The resulting code was not readable or maintainable but it did run and that satisfied the needs of the project.

In my experience is that language conversion projects are gnarly, and depend heavily on style guides and accurate specifications for the languages to produce good output. But these are not doomed enterprises from the start and in the end it's the quality of your convertering code that determines the success of the project.

I have done it for a few files here and there without too much hassle. An entire project sounds like a nightmare though. Also, which language you are converting from/to will have a big impact. VB.Net>C#; no big deal. FoxPro>Erlang; ouch.

Code generation isn't particularly hard as long as your source language or API is well specified. The problems come after.

One shot code generation is usually fine (make it, run it, throw it away).

Similarly, if the target language is never going to be read or edited by a human then you should avoid most issues.

Reply on news.ycombinator.com