Las experiencias con “convertidores de lenguaje”?

Question

He leído un par de artículos que mencionan convertidores de un idioma a otro.

Estoy un poco más escépticos sobre el uso de este tipo de herramientas. ¿Alguien sabe o tiene experiencias digamos acerca de Visual Basic a Java o vs convertidores? Sólo un ejemplo para recoger

http://www.tvobjects.com/products/products.html , afirma ser el "líder mundial" más o menos en ese aspecto, sin embargo, si lee esto:

http://dev.mysql.com/tech-resources /articles/active-grid.html

el autor afirma:

"El consenso de los usuarios de MySQL es que las herramientas de conversión automatizados para MS Access no funcionan. Por ejemplo, las herramientas que se traducen Acceder a las aplicaciones existentes a Java a menudo resultan en un 80% de soluciones completas donde terminar el último 20% de la obra lleva más tiempo de empezar desde cero ".

Bien sabemos que tenemos el 80% del tiempo para implementar la primera funcionalidad del 80% y otro 80% del tiempo para el otro 20% ....

Así que alguien ha intentado este tipo de herramientas, y los halló que valga la pena?

Answer 1

Me parece, como es casi siempre el caso con preguntas MS-Access tener etiquetas que atraen a la población en general Stackoverflow, que las personas que responden faltan la cuestión clave aquí, que leí como:

¿Hay herramientas que pueden convertir con éxito una solicitud de acceso a cualquier otra plataforma?

Y la respuesta es

ABSOLUTAMENTE NO

La razón de esto es simplemente que las herramientas de la misma familia que utilizan modelos similares para los objetos de interfaz de usuario (por ejemplo, Visual Basic 6) carecen de muchas cosas que Access proporciona por defecto (¿cómo convertir un subformulario continuo acceso a VB6 y no funcionalidad perder?). Y otras plataformas ni siquiera comparten el mismo modelo básico como VB6 y el acceso, por lo que aquellos tienen aún más obstáculos para despejar.

El citado artículo MySQL es muy interesante, pero realmente confunde a los problemas que vienen con aplicaciones desarrolladas incompetente-vs los problemas que vienen con las herramientas de desarrollo están utilizando. Un esquema de datos mal no es inherente a Access - es inherente a la mayoría de [] novato usuarios de bases de datos. Sin embargo, los artículos parece atribuir este problema de acceso.

Y domina por completo la posibilidad de fijar el esquema, convertir a SQL Server a MySQL y manteniendo el extremo frontal de acceso, que es con mucho el método más fácil para el problema.

Esto es exactamente lo que espero de personas que simplemente no tienen acceso - que ni siquiera consideran que el acceso como interfaz para un motor de base de datos del servidor asegurable de gran capacidad puede ser una solución superior para el problema.

Este artículo no siquiera realmente en cuenta la conversión de una aplicación de acceso, y hay buenas razones para ello. Todas las herramientas que he visto que la pretensión de aplicaciones de acceso a convert (cualquier plataforma) sea convertido nada más que de datos (en cuyo caso no convierten la aplicación en todo - tarados), o convertir la estructura frontal servilmente , con un 1:. correspondencia 1 entre la interfaz de usuario objetos de la aplicación de acceso y en la aplicación de destino

Esto no funciona.

diseño de aplicaciones de acceso es específica a sí mismo, y otras plataformas no son compatibles con el mismo conjunto de características. Por lo tanto, tiene que haber traducción de acceso cuenta en un sustituto de trabajo para la función original en la aplicación convertida. Esto no es algo que se pueda hacer de forma automatizada, en mi opinión.

En segundo lugar, cuando se contempla la conversión de una aplicación de acceso para el despliegue en el navegador web, todo el modelo de aplicación es diferente, es decir, de estado para sin estado, y así que no es sólo una cuestión de unas pocas características de acceso que no son compatibles, sino de un modelo fundamental completamente diferente de cómo los objetos de interfaz de usuario interactuar con los datos. Tal vez una aplicación de acceso no unido 100% podría ser relativamente fácil convertir en una aplicación basada en navegador, pero ¿cuántos de los que hay? Esto significaría una aplicación de acceso que no utiliza ningún tipo subformularios (ya que no pueden estar sin unir), y una aplicación que utiliza sólo un puñado de eventos del modelo de eventos ricos (la mayoría de los cuales trabajan únicamente con formas inseparables / controles). En resumen, una aplicación de acceso sin consolidar el 100% sería uno que lucha contra todo el paradigma de desarrollo acceso. Cualquiera que piense que quieren construir una aplicación no unido en el acceso realmente no debería ser usar el acceso, en primer lugar, como todo el punto de acceso es el límite formularios / controles! Si se elimina eso, usted ha tirado por la mayoría de las ventajas del RAD de Access a través de otras plataformas de desarrollo, y ha ganado casi nada a cambio (que no sea enorme complejidad de código).

Para construir una aplicación para el despliegue en el navegador web que realiza las mismas tareas que un Acceder a las aplicaciones requiere de-la-tierra-para arriba el rediseño de la interfaz de usuario de la aplicación y flujo de trabajo. No hay conversión o traducción que funciona porque el modelo de solicitud de acceso con éxito es la antítesis del modelo de aplicación web con éxito.

Por supuesto, todo esto cambia con Access 2010 y Sharepoint Server 2010 con servicios de acceso. En ese caso, usted puede construir su aplicación en Access (utilizando los objetos web) y desplegar en Sharepoint para los usuarios ejecutar en el navegador. Los resultados son funcionalmente equivalentes al 100% (y el 90% visualmente), y se ejecutan en todos los navegadores (IE sin dependencias específicas aquí).

Por lo tanto, a partir de este mes de junio, la forma más barata para convertir una aplicación de acceso para el despliegue en el navegador puede ser muy bien para actualizar a A2010, convertir el diseño de utilizar todos los objetos web, y luego desplegar con Sharepoint. Eso no es un proyecto trivial, como objetos Web Access tienen un conjunto limitado de funciones en comparación con objetos de cliente (y sin VBA, por ejemplo, por lo que tiene que aprender las nuevas macros, que son mucho más potente y segura que las anteriores, de manera que no es la terrible dificultad que pueda parecer a aquellos que están familiarizados con las macros heredadas de acceso), pero probablemente sería mucho menos trabajo que un rediseño a gran escala para el despliegue en la web.

La otra cosa es que no se requiere ningún tipo de readaptación profesional para los usuarios finales (en la medida en la versión web a objetos es la misma que la versión original del cliente), ya que será el mismo en el cliente de acceso como en la web navegador.

Así que, en resumen, yo diría que la conversión es una quimera, y casi siempre no vale la pena el esfuerzo. Estoy de acuerdo con el sentimiento citado, de hecho (aunque tenga una gran cantidad de problemas con los otros comentarios de esa fuente). Pero también me advierten que el deseo de conversión es a menudo equivocada y se pierde en soluciones más baratas, más fáciles y mejores que no requieren reemplazo sistemático de la aplicación Acceso de arriba a abajo. Muy a menudo la insatisfacción con Jet / ACE como datos almacenar confunde a la gente haciéndoles creer que tienen que reemplazar el uso de acceso también. Y es cierto que muchas de las aplicaciones de acceso desarrolladas por el usuario están llenos de compromisos terribles, imposible de mantener y se llevan a cabo junto con la goma de mascar y el rescate de alambre. Sin embargo, una aplicación de Access malo-diseñado se puede mejorar en conjunto con el aumento de tamaño andrevision de fondo del esquema de datos -. No tiene que ser descartado

Esto no quiere decir que sea fácil - No es muy a menudo. Como les digo a los clientes todo el tiempo, por lo general es más fácil construir una nueva casa de remodelar una vieja. Pero una de las razones por las que remodelar casas antiguas es porque tienen características insustituibles que no queremos perder. Es muy a menudo el caso de que una aplicación de acceso incluye implícitamente una gran cantidad de reglas de negocio y la modelización de flujos de trabajo que no deben perderse en una nueva aplicación (el antiguo enigma Netscape, ritmo Joel Spolsky). Estas cosas pueden no ser obvio para el desarrollador externo tratando de puerto a una plataforma diferente, pero para el usuario final, si la aplicación produce resultados que están fuera por un centavo en comparación con la aplicación de edad, van a ser infeliz (y probablemente debe ser, ya que puede significar que otros aspectos de la aplicación no están produciendo resultados fiables, tampoco).

De todos modos, he divagó durante demasiado tiempo, pero mi opinión es que la conversión nunca funciona a excepción de las aplicaciones más triviales (o para los que fueron diseñados para ser convertido, por ejemplo, una aplicación de acceso no unido 100%). Estoy a favor de la revisión en el lugar de replacment.

Pero, por supuesto, que es como me gano la vida, es decir, la fijación de aplicaciones de acceso.

Answer 2

intentado? No, en realidad construida (más de uno) convertidor idioma.

Aquí hay una que (y mis compañeros de trabajo) construido para la B2 Spirit bombardero de la cautela para convertir el software de misión, codificado en un lenguaje heredado, agradable, en código C mantenible, con la conversión de 100% automatizado. Uno de los requisitos es que no se nos permitió ver el código fuente real. No es broma.

Tiene usted razón: si se obtiene sólo un alto índice de conversión medio (por ejemplo, 70-80%), el esfuerzo para terminar la conversión sigue siendo muy significativa si las puedes hacerlo en absoluto. Nos dirigimos a 95% + y hacemos mejor cuando se le dijo que esforzarse más como fue el caso para el B2. La única razón por la gente acepta convertidores de alta tasa de transmisión media se debe a que no pueden encontrar (o no financiará!) Uno mejor, insisten en iniciar ahora , y aceptar el hecho de que la conversión de esta manera puede ser doloroso (por lo general no saben cuánto) pero en realidad es menos dolorosa que la reconstrucción desde cero. (Da la casualidad que estar de acuerdo con esta evaluación: en general, los proyectos que intentan volver a codificar un gran sistema desde cero por lo general fallan y conversiones utilizando herramientas de tasa media-alta conversión no tenga la mayor tasa de fracaso.)

Hay un montón de malas herramientas de conversión por ahí, algo palmada junto con una montaña de código Perl haciendo expresiones regulares en cadenas de texto, o algún analizador basado en YACC con la generación de código en esencia uno-a-uno para cada sentencia de la unidad de compilación . Los primeros se construyeron por personas que tenían una conversión cayó sobre ellos desde el cielo. Estos últimos son a menudo construidos por ingenieros bien intencionados que no tienen compilador de fondo decente.

Para un mal ejemplo singularmente, ver mi respuesta a esta pregunta acerca de la migración SO COBOL: Experiencia legado migrar Cobol / PL1 a Java , que es exactamente un traductor directo declaración ... la producción de la materia que dio origen al término 'JOBOL'.

Para obtener este tipo de tasas de conversión de alta precisión, es necesario analizadores de alta calidad, y los medios para construir reglas de traducción de alta calidad que conservan la semántica, y optimizar las propiedades para el idioma de destino y casos especiales. En esencia, lo que necesita lo que equivale a tecnología de compilación configurable. La razón tenemos éxito, en mi humilde opinión, es nuestra software DMS Reingeniería Toolkit, que era diseñado para hacer este trabajo. (Soy el arquitecto, echa un vistazo a mi icono de SO / bio)

.

Las porciones de cuidadosas pruebas también ayuda.

DMS "sabe" lo que el compilador sabe sobre el código, en virtud de que tiene un extremo frontal del compilador como para el lenguaje de interés, y tener la capacidad de AST construcción, tablas de símbolos, los flujos de control y de datos, gráficos de llamadas. Se utiliza gran parte de la tecnología de compilación que la comunidad compilador pasó el inventar último medio siglo, porque esas cosas se ha demostrado ser útil en la traducción!

DMS sabe más que la mayoría de los compiladores saben, ya que puede leer / analizar / transformar toda la aplicación a la vez; la mayoría de los compiladores se adhieren a las unidades de compilación individuales. Por lo tanto, las reglas de conversión de código uno puede que dependen de la aplicación completa en lugar de sólo la instrucción actual. A menudo añadimos el conocimiento de problemas o aplicación específica para mejorar la traducción. Esto a menudo se manifiesta al convertir las características especiales de un idioma o llamadas en las bibliotecas, en los que uno debe reconocer las llamadas a las bibliotecas como expresiones especiales, y traducirlos a las llamadas en composiciones de bibliotecas objetivo y construcciones del lenguaje.

Esta capacidad se utiliza para traductores de construcción (por ejemplo, el traductor JOVIAL), o generadores de código de dominio específico.

A menudo construimos herramientas de ingeniería de software automatizado de complejo que resuelven problemas SPECIFic a los clientes, tales como herramientas de análisis de programa (código muerto, código duplicado, código de estilo-roto, la métrica, la extracción de la arquitectura, ...), y herramientas de cambio de masa (plataforma [no langauge] migraciones, la inserción capa de datos, la sustitución de la API, ...)

Answer 3

Un par de cuestiones que afectan al éxito o fracaso de la conversión entre lenguajes son la riqueza semántica relativa de las lenguas, y sus modelos semánticos.

• La traducción del C ++ a C debería ser relativamente fácil, pero la traducción de C a idiomática C ++ sería casi imposible porque eso sería casi imposible convertir automáticamente un programa procedimental en una OO programa.

• Traducción de Java a C sería relativamente simple, aunque el manejo de la gestión de almacenamiento sería desordenado. Traducción de C en Java sería casi imposible si el programa de C hizo aritmética de punteros funky o la conversión entre números enteros y diferentes tipos de puntero.

• La traducción de un lenguaje funcional a un lenguaje imperativo sería mucho más fácil, sin embargo el resultado probablemente sería ineficaz, un no-idiomática. La traducción de un lenguaje imperativo de un lenguaje funcional es probablemente más allá del estado del arte .... a menos que implemente un intérprete para el lenguaje imperativo en el lenguaje funcional.

Lo que esto significa es que algunos traductores son necesariamente va a tener más éxito que otros en términos de:

• integridad y exactitud de la traducción, y
• legibilidad y mantenibilidad del código resultante.

Answer 4

cosas que usted debe nunca lo hacen, Parte I por Joel Spolsky

" .... Lo hicieron al hacer el peor error estratégico que cualquier compañía de software puede hacer:

Se decidió volver a escribir el código desde cero. "

Tengo una de los convertidores de MS Access en mi sitio web . Nunca he oído nada bueno acerca de cualquiera de ellos en cualquier publicación en los grupos de noticias relacionados con el acceso que leí sobre una base diaria. Y leí una gran cantidad de publicaciones sobre una base diaria.

Tenga en cuenta también que hay una cantidad significativa de funcionalidad en Access, como formularios o subformularios continuos unidos, es más trabajo para reproducirse en otros sistemas. No necesariamente una gran cantidad de trabajo, pero más trabajo. Y más problemas a la hora de distribuir e instalar la aplicación.

Answer 5

He utilizado un convertidor automático de C # para Visual Basic.NET. Funcionó bastante bien excepto por la adición de algunas declaraciones If True innecesaria.

También he intentado utilizar mudar la piel Python para convertir a C ++, pero no funcionó debido a su falta de apoyo para la división de nuevo cuño.

Answer 6

He utilizado las herramientas para convertir un proyecto de VB6 a VB.Net - lo cual es de esperar que sería tal vez uno de los ejemplos más simples de este tipo de cosas. Mi experiencia fue que todo tenía que ser revisado en detalle fino, y la mitad de las cosas que le faltaba / incorrecto.

Desde luego que recomendaría una migración a mano, o en función de la lengua que está selección de objetivo, lo consideraría una reescritura completa si esto le da la oportunidad de hacer grandes mejoras en su base de código.

Martin

Answer 7

Sólo he tratado de libre y básica pagado por los convertidores. Pero el principal problema es que es muy, muy difícil tener confianza en que la conversión es del todo satisfactoria.

Por lo general, lo mejor es utilizarlos a la sección de códigos mano convertido en un momento, en el que revise cada pieza de código. A menudo, en mi experiencia una reescritura en lugar de una conversión resulta ser una mejor opción.