I have read a few articles mentioning converters from one language to another.

I'm a bit more than skeptical about the use of such kind of tools. Does anyone know or have experiences let's say about Visual Basic to Java or vs converters? Just one example to pick, claims to be the "world leader" or so in that aspect, However if read this:

There the author states:

"The consensus of MySQL users is that automated conversion tools for MS Access do not work. For example, tools that translate existing Access applications to Java often result in 80% complete solutions where finishing the last 20% of the work takes longer than starting from scratch."

Well we know we need 80% of the time to implement the first 80% functionality and another 80% of the time for the other 20 %....

So has anyone tried such tools and found them to be worthwhile?

+7  A: 

Tried? No, actually built (more than one) language convertor.

Here's one I (and my coworkers) built for the B2 Spirit Stealth Bomber to convert the mission software, coded in a legacy language, JOVIAL, into maintainable C code, with 100% automated conversion. One of the requirements was that we were NOT allowed to see the actual source code. No joke.

You are right: if you get only a medium high conversion rate (e.g., 70-80%), the effort to finish the conversion is still very significant if indeed you can do it at all. We target 95%+ and do better when told to try harder as was the case for the B2. The only reason people accept medium high rate converters is because they can't find (or won't fund!) a better one, insist on starting now, and accept the fact that converting it this way may be painful (usually they don't know how much) but is in fact less painful than rebuilding it from scratch. (I happen to agree with this assessment: in general, projects that try to recode a large system from scratch usually fail and conversions using medium high conversion rate tools don't have as high a failure rate.)

There are lots of bad conversion tools out there, something slapped together with a mountain of PERL code doing regexes on text strings, or some YACC-based parser with code generation essentially one-to-one for each statement in the compilation unit. The former are built by people who had a conversion dropped on them out of the sky. The latter are often built by well-intentioned engineers that don't have decent compiler background.

For a singularly bad example, see my response to this SO question about COBOL migration:, which is exactly a direct statement translator... producing the stuff that gave rise to the term "JOBOL".

To get such high-accuracy conversion rates, you need high-quality parsers, and means to build high-quality translation rules that preserve semantics, and optimize for target-language properties and special cases. In essence, you need what amounts to configurable compiler technology. The reason we succeed, IMHO, is our DMS Software Reengineering Toolkit, which was designed to do this job. (I'm the architect; check out my SO icon/bio).

Lots of careful testing helps, too.

DMS "knows" what the compiler knows about code, by virtue of having a compiler-like front end for the language of interest, and having the ability to build ASTs, symbol tables, control and data flows, call graphs. It uses much of the compiler technology that the compiler community spent the last half-century inventing, because that stuff has been proven to be useful in translation!

DMS knows more than most compilers know, because it can read/analyze/transform the entire application at once; most compilers stick to single compilation units. Thus one can code translation rules that depend on the entire application as opposed to just the current statement. We often add problem- or application-specific knowledge to improve the translation. This often shows up when converting special features of a language, or calls on libraries, where one must recognize the library calls as special idioms, and translate them to calls on compositions of target libraries and language constructs.

This capability is used to build translators (e.g., the JOVIAL translator), or domain-specific code generators.

More often we build complex automated software engineering tools that solve problems specific to customers, such as program analysis tools (dead code, duplicate code, style-broken code, metrics, architecture extraction, ...), and mass change tools (platform [not langauge] migrations, data layer insertion, API replacement, ...)

Ira Baxter
"Tried? No, actually built (more than one) langauge convertor." How did you build them without trying them? :)
While this is really a rhetorical question, it deserves a bit of an answer. 1) You need good system functionality tests; these are extremely hard to get as most customers don't have any kind of tests! So, *somebody* gets to code them. 2) You can heavily unit test the translators by enumerating the sets of language constructs/special cases as units, and running translation/checking on them. That pays off big time, because if you can reliably translate the language constructs/library calls and their compositions, you can translate entire programs reliably. This is how you test compilers.
Ira Baxter
"You need good system functionality tests; these are extremely hard to get as most customers don't have any kind of tests! So, somebody gets to code them. "Well you are to right about that, that is also the problem I'm facing but in my case it's Access and partly extremly poor paste+copy+error "code" ;-(
One of the things we do when considering a migration is to consider whether code clones play a significant part. To do that, we use our own (we think extremely good) clone detection tool based on DMS. This identifies where the copy-pasted code (reformatted/edited or not!) is and excactly how it has been edited. We have just released a VB6 version of this tool, and VB6 and VBA are nearly identical. Perhaps such a tool would be helpful in your migration?
Ira Baxter
+1  A: 

I've used an automated converter from C# to Visual Basic.NET. It worked pretty well except for adding some unnecessary If True statements.

I've also attempted to use Shed Skin to convert Python-to-C++, but it didn't work because of its lack of support for new-style division.

C# to VB.Net is almost always a trivial conversion. C# to Lisp or PHP or Perl however is much more tricky. Along with some syntax being completely incompatible, library functions must be mapped and possibly the static typing of C# has to somehow be converted over to a dynamic typing system... C# to VB should not count as an actual "translation"
Conversion tools with a deep understanding of the source and target languages won't produce things like "if true..."; they will recognize *generated* constructs that have simpler implementations (in this case, the empty implementation). To do this right, the translator cannot generate plain old text, because applying optimizations to generated code requires that it then be re-parsed and re-analyzed. I've discussed DMS in another answer here; it doesn't generate text directly, but rather ASTs for the target language, and then it can apply the rest of its compiler-like machinery to the result.
Ira Baxter
@Earlz: converting from a langauge with static typing to one with dynamic typing is *much* easier than going the other way. To convert to *dynamic* typing, you basically forget the type information. Forgetting is a skill all of us have. To convert to *static* typing, your conversion tool must infer (compiler-style static analysis!) the static type used for each variable at each point in the code, split the variable lifetimes into one for each used type, replicate the code and specialize where a variable may have multiple types, etc. Way harder.
Ira Baxter

I've used tools for converting a VB6 Project into VB.Net - which you would hope would be perhaps one of the simpler examples of this sort of thing. My experience was that everything had to be checked, in fine detail, and half the stuff was missing / wrong.

Certainly I would recommend a migration by hand, or depending on the language you're targetting, I would consider a complete rewrite if this gives you a chance to make major improvements to your codebase.


Martin Milan
Migration by hand is the most dangerous option. It took 10-20 years for all that application knowledge to crawl into the application (yes, the cruft, too). People that try to recode from scratch imagine they can re-invent all the functionality that is hiding in the application. They're almost always wrong, and they pay for that late in the conversion.
Ira Baxter
An automated conversion is little better though Ira - it still has to be checked by hand if you're serious - which means the same level of scrutiny - or maybe you're happy with just regression testing and prayer?
Martin Milan
You can check it by hand, but that's not a serious test, just as hand-testing isn't sensible for application development. You want heavy duty regression testing, which is hardly a prayer.
Ira Baxter
I wouldn't trust a simple regression test - there are too many wrong ways to get the right results in this case...
Martin Milan
I wouldn't trust "Joe" to do simple manual tests and get it right, and Joe won't run the tests more than 2 or 3 times before he gets disgusted with the whole process. Automation in (re)testing is what's needed.
Ira Baxter

I have only tried free and basic paid for converters. But the main problem is that it is very very hard to have confidence that the conversion is entirely successful.

Usually they are best used to hand convert code section at a time, where you review each piece of code. Often in my experience a rewrite instead of a conversion turns out to be a better option.

James Westgate
+2  A: 

A couple of issues that effect the success or failure of cross-language conversion are the relative semantic richness of the languages, and their semantic models.

  • Translation from C++ to C should be relatively easy, but translation of C to idiomatic C++ would be next to impossible because that would be next to impossible to automatically turn a procedural program into an OO program.

  • Translation of Java to C would be relatively simple, though handling storage management would be messy. Translation of C into Java would be next to impossible if the C program did funky pointer arithmetic or casting between integers and different kinds of pointer.

  • Translation of a functional language to an imperative language would be much easy though the result would probably be inefficient, an non-idiomatic. Translation of an imperative language to a functional language is probably beyond the state of the art .... unless you implement an interpreter for the imperative language in the functional language.

What this means is that some translators are necessarily going to be more successful than others in terms of:

  • completeness and accuracy of translation, and
  • readability and maintainability of the resulting code.
Stephen C
+3  A: 

It seems to me, as is almost always the case with MS-ACCESS questions having tags that attract the wider StackOverflow population, that the people answering are missing the key question here, which I read as:

Are there any tools that can successfully convert an Access application to any other platform?

And the answer is


The reason for that is simply that tools in the same family that use similar models for the UI objects (e.g., VB6) lack so many things that Access provides by default (how do you convert an Access continuous subform to VB6 and not lose functionality?). And other platforms don't even share the same core model as VB6 and Access, so those have even more hurdles to clear.

The cited MySQL article is quite interesting, but it really confuses the problems that come with incompetently-developed apps vs. the problems that come with the development tools being used. A bad data schema is not inherent to Access -- it's inherent to [most] novice database users. But the articles seems to attribute this problem to Access.

And entirely overlooks the possibility of fixing the schema, upsizing it to MySQL and keeping the front end in Access, which is by far the easiest approach to the problem.

This is exactly what I expect from people who just don't get Access -- they don't even consider that Access as front end to a securable, large-capacity server database engine can be a superior solution to the problem.

That article doesn't even really consider conversion of an Access app, and there's good reason for that. All the tools that I've seen that claim to convert Access applications (to whatever platform) either convert nothing but data (in which case they don't convert the app at all -- morons!), or convert the front end structure slavishly, with a 1:1 correspondence between UI objects in the Access application and in the target app.

This doesn't work.

Access's application design is specific to itself, and other platforms don't support the same set of features. Thus, there has to be translation of Access features into a working substitute for the original feature in the converted application. This is not something that can be done in an automated fashion, in my opinion.

Secondly, when contemplating converting an Access app for deployment in the web browser, the whole application model is different, i.e., from stateful to stateless, and so it's not just a matter of a few Access features that are unsupported, but of a completely different fundamental model of how the UI objects interact with the data. Perhaps a 100% unbound Access app could be relatively easily be converted to a browser-based implementation, but how many of those are there? It would mean an Access app that uses no subforms whatsoever (since they can't be unbound), and an app that uses only a handful of events from the rich event model (most of which work only with bound forms/controls). In short, a 100% unbound Access app would be one that fights against the whole Access development paradigm. Anyone who thinks they want to build an unbound app in Access really shouldn't be using Access in the first place, as the whole point of Access is the bound forms/controls! If you eliminate that, you've thrown out the majority of Access's RAD advantage over other development platforms, and gained almost nothing in return (other than enormous code complexity).

To build an app for deployment in the web browser that accomplishes the same tasks as an Access applications requires from-the-ground-up redesign of the application UI and workflow. There is no conversion or translation that will work because the successful Access application model is antithetical to the successful web application model.

Of course, all of this changes with Access 2010 and Sharepoint Server 2010 with Access Services. In that case, you can build your app in Access (using web objects) and deploy on Sharepoint for users to run it in the browser. The results are functionally 100% equivalent (and 90% visually), and run on all browsers (no IE-specific dependencies here).

So, starting this June, the cheapest way to convert an Access app for deployment in the browser may very well be to upgrade to A2010, convert the design to use all web objects, and then deploy with Sharepoint. That's not a trivial project, as Access web objects have a limited set of features in comparison to client objects (and no VBA, for instance, so you have to learn the new macros, which are much more powerful and safe than the old ones, so that's not the terrible hardship it may seem for those familiar with Access's legacy macros), but it would likely be much less work than a full-scale redesign for deployment on the web.

The other thing is that it won't require any retraining for end users (insofar as the web-object version is the same as the original client version), as it will be the same in the Access client as in the web browser.

So, in short, I'd say conversion is a chimera, and almost always not worth the effort. I'm agreeing with the cited sentiment, in fact (even if I have a lot of problems with the other comments from that source). But I'd also caution that the desire for conversion is often misguided and misses out on cheaper, easier and better solutions that don't require wholesale replacement of the Access app from top to bottom. Very often the dissatisfaction with Jet/ACE as data store confuses people into thinking they have to replace the Access application as well. And it's true that many user-developed Access apps are filled with terrible, unmaintainable compromises and are held together with chewing gum and bailing wire. But a badly-designed Access application can be improved in conjunction with the back-end upsizing andrevision of the data schema -- it doesn't have to be discarded.

That doesn't mean it's easy -- it's very often not. As I tell clients all the time, it's usually easier to build a new house than to remodel an old one. But one of the reasons we remodel old houses is because they have irreplaceable characteristics that we don't want to lose. It's very often the case that an Access app implicitly includes a lot of business rules and modelling of workflows that should not be lost in a new app (the old Netscape conundrum, pace Joel Spolsky). These things may not be obvious to the outside developer trying to port to a different platform, but for the end user, if the app produces results that are off by a penny in comparison to the old app, they'll be unhappy (and probably should be, since it may mean that other aspects of the app are not producing reliable results, either).

Anyway, I've rambled on for too long, but my opinion is that conversion never works except for the most trivial apps (or for ones that were designed to be converted, e.g., a 100% unbound Access app). I'm all for revision in place of replacment.

But, of course, that's how I make my living, i.e., fixing Access apps.

+2  A: 

Things You Should Never Do, Part I by Joel Spolsky

"....They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch."

I have a list of MS Access converters on my website. I've never heard anything good about any of them in any postings in the Access related newsgroups I read on a daily basis. And I read a lot of postings on a daily basis.

Also note that there is a significant amount of functionality in Access, such as bound continuous forms or subforms, that is more work to reproduce in other systems. Not necessarily a lot of work but more work. And more troubles when it comes time to distribute and install the app.

Tony Toews