有“语言转换器”的经验吗？
我读过一些文章提到从一种语言到另一种语言的转换器。
我对使用此类工具持怀疑态度。有谁知道或有关于 Visual Basic 到 Java 或 vs 转换器的经验吗？仅举一个例子来选择
http://www.tvobjects.com/products/products.html，声称在这方面是“世界领导者”左右，但是如果阅读以下内容：
http://dev.mysql.com/tech-resources/articles/active-grid.html
其中作者指出：
“MySQL 用户的共识是 MS Access 的自动转换工具例如，将现有 Access 应用程序转换为 Java 的工具通常会产生 80% 完整的解决方案，而完成最后 20% 的工作比从头开始需要更长的时间。”
我们知道我们需要 80% 的时间来实现前 80% 的功能，另外 80% 的时间来实现另外 20% 的功能……
那么有人尝试过这样的工具并发现它们值得吗？
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
http://www.tvobjects.com/products/products.html, claims to be the "world leader" or so in that aspect, However if read this:
http://dev.mysql.com/tech-resources/articles/active-grid.html
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
尝试过吗？不，实际上构建了（多个）语言转换器。
这是我（和我的同事）为 B2 Spirit 隐形轰炸机 打造的一款将使用传统语言 JOVIAL 编码的任务软件转换为可维护的 C 代码，实现 100% 自动转换。要求之一是不允许我们查看实际的源代码。不是开玩笑。
你是对的：如果你只获得中等高的转化率（例如，70-80%），如果你确实能做到的话，完成转化的努力仍然是非常重要的。我们的目标是 95% 以上，并且当被告知要更加努力时会做得更好，就像 B2 的情况一样。人们接受中高速率转换器的唯一原因是因为他们找不到（或不会资助！）更好的转换器，坚持现在开始，并接受这样的事实：以这种方式转换可能会很痛苦（通常他们不知道有多痛苦），但实际上比从头开始重建更痛苦。 （我碰巧同意这个评估：一般来说，尝试从头开始重新编码大型系统的项目通常会失败，而使用中高转换率工具进行转换的失败率不会那么高。）
有很多糟糕的转换工具在那里，有一些东西与大量在文本字符串上执行正则表达式的 PERL 代码组合在一起，或者是一些基于 YACC 的解析器，其代码生成基本上是针对编译单元中的每个语句进行一对一的。前者是由那些从天而降的人建造的。后者通常是由没有良好编译器背景的善意工程师构建的。
对于一个非常糟糕的例子，请参阅我对有关 COBOL 迁移的 SO 问题的回答：将遗留的 Cobol/PL1 迁移到 Java，这正是一个直接语句翻译器......产生了“JOBOL”一词的产生。
为了获得如此高精度的转换率，您需要高质量的解析器，并需要构建高质量的翻译规则来保留语义，并针对目标语言属性和特殊情况进行优化。本质上，您需要可配置编译器技术。恕我直言，我们成功的原因是我们的 DMS 软件重组工具包，旨在完成这项工作。 （我是建筑师；查看我的 SO 图标/简介）。
大量仔细的测试也有帮助。
DMS“知道”编译器对代码的了解，因为它拥有一个类似编译器的感兴趣语言的前端，并且能够构建 AST、符号表、控制和数据流、调用图。它使用了编译器社区在过去半个世纪中发明的大部分编译器技术，因为这些东西已被证明在翻译中很有用！
DMS 比大多数人都了解更多编译器知道，因为它可以立即读取/分析/转换整个应用程序；大多数编译器坚持使用单个编译单元。因此，我们可以编写依赖于整个应用程序而不是仅依赖于当前语句的转换规则。我们经常添加特定问题或特定应用的知识来改进翻译。当转换一种语言的特殊功能或调用库时，通常会出现这种情况，其中必须将库调用识别为特殊习惯用法，并将它们转换为对目标库和语言结构的组合的调用。
此功能用于构建翻译器（例如，JOVIAL 翻译器）或特定于域的代码生成器。
更多时候，我们构建复杂的自动化软件工程工具来解决特定于客户的问题，例如程序分析工具（死代码、重复代码、风格破坏的代码、指标、架构提取……）和大规模变更工具（平台[不是语言]迁移、数据层插入、API 替换，...）
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: Experience migrating legacy Cobol/PL1 to Java, 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, ...)
在我看来，就像 MS-ACCESS 问题具有吸引更广泛的 StackOverflow 人群的标签的情况一样，回答的人错过了这里的关键问题，我将其解读为：
是否有任何工具可以成功地将将应用程序访问到任何其他平台？
答案是
绝对不是。
原因很简单，同一系列中的工具使用相似的 UI 对象模型（例如 VB6），缺少 Access 默认提供的许多功能（如何将 Access 连续子表单转换为VB6又不会失去功能？）。而其他平台甚至不共享与 VB6 和 Access 相同的核心模型，因此这些平台有更多的障碍需要清除。
引用的 MySQL 文章非常有趣，但它确实混淆了开发不合格的应用程序带来的问题与所使用的开发工具带来的问题。糟糕的数据模式并不是 Access 所固有的——它是[大多数]新手数据库用户所固有的。但文章似乎将这个问题归咎于Access。
并且完全忽略了修复架构、将其升级到 MySQL 并将前端保留在 Access 中的可能性，这是迄今为止解决该问题的最简单方法。
这正是我对那些没有使用 Access 的人的期望——他们甚至不认为 Access 作为安全的大容量服务器数据库引擎的前端可以成为解决问题的最佳方案。
该文章甚至没有真正考虑 Access 应用程序的转换，这是有充分理由的。我见过的所有声称可以转换 Access 应用程序（到任何平台）的工具要么只转换数据（在这种情况下它们根本不转换应用程序 - 白痴！），要么盲目地转换前端结构，Access 应用程序中的 UI 对象与目标应用程序中的 UI 对象之间具有 1:1 的对应关系。
这是行不通的。
Access 的应用程序设计是特定于其自身的，其他平台不支持同一组功能。因此，必须将 Access 功能转换为转换后的应用程序中原始功能的工作替代品。在我看来，这不是可以通过自动化方式完成的事情。
其次，当考虑将 Access 应用程序转换为在 Web 浏览器中部署时，整个应用程序模型是不同的，即从有状态到无状态，因此这不仅仅是一些不受支持的 Access 功能的问题，而是完全不同的问题。 UI 对象如何与数据交互的基本模型。也许 100% 未绑定的 Access 应用程序可以相对轻松地转换为基于浏览器的实现，但是这样的应用程序有多少呢？这意味着 Access 应用程序不使用任何子表单（因为它们无法解除绑定），并且应用程序仅使用丰富事件模型中的少数事件（其中大多数事件仅适用于绑定表单/控件）。简而言之，100% 未绑定的 Access 应用程序将与整个 Access 开发范例作斗争。任何认为自己想要在 Access 中构建未绑定应用程序的人确实不应该首先使用 Access，因为 Access 的全部要点就是绑定表单/控件！如果消除了这一点，您就失去了 Access 相对于其他开发平台的 RAD 优势，并且几乎没有获得任何回报（除了巨大的代码复杂性之外）。
要构建一个用于在 Web 浏览器中部署的应用程序来完成与 Access 应用程序相同的任务，需要从头开始重新设计应用程序 UI 和工作流程。没有有效的转换或翻译，因为成功的 Access 应用程序模型与成功的 Web 应用程序模型是对立的。
当然，随着 Access 2010 和带有 Access Services 的 Sharepoint Server 2010，所有这一切都发生了变化。在这种情况下，您可以在 Access 中构建应用程序（使用 Web 对象）并部署在 Sharepoint 上，以便用户在浏览器中运行它。结果在功能上 100% 等效（视觉上 90% 等效），并且可以在所有浏览器上运行（此处没有 IE 特定的依赖项）。
因此，从今年 6 月开始，将 Access 应用程序转换为在浏览器中部署的最便宜的方法很可能是升级到 A2010，将设计转换为使用所有 Web 对象，然后使用 Sharepoint 进行部署。这不是一个简单的项目，因为与客户端对象相比，Access Web 对象的功能有限（例如，没有 VBA，因此您必须学习新的宏，它们比旧的宏更强大、更安全，因此，对于那些熟悉 Access 遗留宏的人来说，这并不是可怕的困难），但它可能比在 Web 上部署的全面重新设计要少得多。
另一件事是，它不需要对最终用户进行任何重新培训（只要 Web 对象版本与原始客户端版本相同），因为 Access 客户端中的版本与 Web 浏览器中的版本相同。
因此，简而言之，我认为转变是一种幻想，而且几乎总是不值得付出努力。事实上，我同意所引用的观点（即使我对该来源的其他评论有很多问题）。但我也要提醒大家，转换的愿望常常被误导，并且错过了更便宜、更简单和更好的解决方案，而这些解决方案不需要从上到下大规模更换 Access 应用程序。通常，人们对 Jet/ACE 作为数据存储的不满使他们认为他们也必须更换 Access 应用程序。确实，许多用户开发的 Access 应用程序都充满了可怕的、无法维护的妥协，并且是用口香糖和保水线固定在一起的。但是，设计糟糕的 Access 应用程序可以结合后端数据模式的扩容和修订来进行改进——不必丢弃它。
这并不意味着它容易——通常情况并非如此。正如我一直告诉客户的那样，建造一栋新房子通常比改造旧房子更容易。但我们改造老房子的原因之一是因为它们具有我们不想失去的不可替代的特性。通常情况下，Access 应用程序隐含地包含许多业务规则和工作流建模，这些规则和工作流建模不应在新应用程序中丢失（旧的 Netscape 难题，Joel Spolsky）。对于试图移植到不同平台的外部开发人员来说，这些事情可能并不明显，但对于最终用户来说，如果应用程序产生的结果与旧应用程序相比相差一分钱，他们会不高兴（并且可能应该如此，因为这可能意味着应用程序的其他方面也不会产生可靠的结果）。
无论如何，我已经闲聊了太久，但我的观点是，除了最琐碎的应用程序（或那些旨在转换的应用程序，例如 100% 未绑定的 Access 应用程序）之外，转换永远不会起作用。我完全赞成修改而不是更换。
但是，当然，这就是我的谋生方式，即修复 Access 应用程序。
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
ABSOLUTELY NOT
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.
影响跨语言转换成败的几个问题是语言的相对语义丰富度及其语义模型。
从 C++ 到 C 的翻译应该相对容易，但是从 C 到惯用的 C++ 的翻译几乎是不可能的，因为这几乎不可能自动将过程程序转换为 OO 程序。
Java 到 C 的翻译相对简单，但处理存储管理会很混乱。如果 C 程序执行时髦的指针算术或在整数和不同类型的指针之间进行转换，则将 C 语言转换为 Java 几乎是不可能的。
将函数式语言转换为命令式语言会很容易，但结果可能效率低下、不符合习惯。将命令式语言翻译为函数式语言可能超出了现有技术水平......除非您在函数式语言中实现命令式语言的解释器。
这意味着某些翻译人员必然在以下方面比其他翻译人员更成功：
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:
你永远不应该做的事情，第一部分 作者：Joel Spolsky
“....他们做了这是因为他们犯了任何软件公司都可能犯的最严重的战略错误：
他们决定从头开始重写代码。”
我的网站上有MS Access 转换器列表。在我每天阅读的 Access 相关新闻组中的任何帖子中，我从未听说过任何关于它们的好消息。而且我每天都会阅读很多帖子。
另请注意，Access 中有大量功能，例如绑定连续表单或子表单，在其他系统中重现需要更多工作。不一定要做很多工作，但要做更多的工作。当分发和安装应用程序时，会遇到更多麻烦。
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.
我使用了从 C# 到 Visual Basic.NET 的自动转换器。除了添加一些不必要的
If True语句之外，它运行得非常好。我还尝试使用 Shed Skin 将 Python 转换为 C++，但没有成功无法工作，因为它缺乏对新型划分的支持。
I've used an automated converter from C# to Visual Basic.NET. It worked pretty well except for adding some unnecessary
If Truestatements.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.
我使用了将 VB6 项目转换为 VB.Net 的工具 - 您希望这可能是此类事情的更简单的示例之一。我的经验是，所有的东西都必须仔细检查，有一半的东西丢失/错误。
当然，我会建议手动迁移，或者根据您的目标语言，如果这使您有机会对代码库进行重大改进，我会考虑完全重写。
马丁
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
我只尝试过免费和基本付费转换器。但主要问题是很难确信转换完全成功。
通常它们最适合一次手动转换代码部分，您可以在其中查看每段代码。根据我的经验，重写而不是转换通常是更好的选择。
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.