Fog Creek Software
Discussion Board




Re-writes when tools or platforms change

I generally agree with Joel's essays about how code re-writes "to clean things up" are a bad idea.  However, there's another situation where I think a re-write is justified:  When the development tools or platform your code is running on are becoming an endangered species.  Sometimes you can get buy with emulation, a portability layer, or mechanical translation.  Other times, there's no choice but to roll up your sleaves and start over.

A famous example:  Adobe Photoshop was re-written in the early '90s to move the source code from Object Pascal into C++.  In retrospect, a wise move - I can't imagine trying to maintain a large commercial app in Pascal today.

J. Peterson
Friday, January 25, 2002

In such a situation I would start by translating the existing code line-for-line. There was even a command line unix utility p2c that translated Pascal to C. This is an easy, almost mechanical transformation that is easy to schedule and unlikely to fail.

One day, probably when 90% of my customers already have the .NET runtime, we'll port CityDesk from VB to C#. We'll start by keeping the main app in VB, and translating one form at a time to C#, creating COM objects that can still be called from VB. I really expect to be able to do this in a few developer months (whereas CityDesk has several developer years invested in it, and a ground-up rewrite could take decades given the massive scope creep these things usually entail).

Joel Spolsky
Friday, January 25, 2002

Umm translating pascal to C on anything non-trivial invariably fails.  The difference in scoping variables is a killer, pascal coders seem to have secret handshake global/local variable usages that stun those that convert the code.

And then there's the signed/unsigned problem.

Instead of translating line by line you translate functionality.  You use the existing code as a specification.  Bits of my soul are still singed from trying to fix translated code.

Simon Lucy
Sunday, January 27, 2002

I agree totally that a mechanical translation would not be that appropriate. Not only is there a language shift but also there would be a paradigm shift from pure procedural to OO which cannot be done automatically. I would use the PASCAL as a very well syntax checked pseudo-code.

I suppose p2c could be used for a quick hack job, but not for proper redevelopment with a view to long term maintenance and enhancement.

Jonathan Naylor
Sunday, January 27, 2002

Years ago I translated an application from Unix C++ to Windows Delphi.

It scared me a lot to get started and I tried several automated tools which promised to do most of the translation. The results of the automated translations I tested (years ago, don't ask me their names) were a total mess. Hopefully translation tools are better now. In my case I decided that I was better off doing the translation manually and use the Delphi editor with it's find and replace tools.

When started I was pleasantly surprised to find out how fast the translation went. It proves that most time is spend designing, thinking, sharing thoughts and not typing the that final line of code. The trick was not to get lured into changing anything in the design. Just translate line by line, get the compiler to eat it and nothing else. This way it was like Joey said a mechanical job. The only thing I did do, is take notes whenever I encountered pieces of code that I wanted to improve later. Not much fun, but efficient. Improving the code (don't know why, but I don't like the word refactoring) was done afterwards.

What I did throw away was the C++ GUI code. It was not a very big part and rewriting that in Delphi was about 100 times as efficient as writing the original Unix GUI code. Another important factor was that the application logic was already clearly separated from the GUI.

Jan Derk
Sunday, January 27, 2002

*  Recent Topics

*  Fog Creek Home