Introduccion
Desde los a帽os 70, se ha desarrollado el ingl茅s simplificado , cuyo prop贸sito es determinar un subconjunto del idioma que sea comprensible para una amplia gama de hablantes no nativos del idioma. Recomendado, por ejemplo, para documentaci贸n t茅cnica. Los traductores autom谩ticos en un subconjunto de este tipo funcionar谩n obviamente de manera m谩s correcta, idealmente generando texto que no requiere revisi贸n manual.
Si aplica este enfoque a C # para la tarea de convertir autom谩ticamente el c贸digo a otros lenguajes de programaci贸n, puede seleccionar un subconjunto de construcciones de lenguaje, bibliotecas del sistema y tecnolog铆as que podr铆an traducirse a una amplia gama de otros lenguajes. Adem谩s, la conversi贸n no es una sola vez (migraci贸n), sino constante para expandir las capacidades de integraci贸n del proyecto en C #, para que en cualquier momento pueda obtener un c贸digo de trabajo en otro idioma sin la necesidad de ninguna edici贸n.
D茅jame presentarte: UniSharping
La restricci贸n de C # .NET para resolver este problema se llam贸 U # (Universal Sharp), y el proceso de conversi贸n y su herramienta se llamaron UniSharping . Los m贸dulos ejecutables, la configuraci贸n y la documentaci贸n est谩n disponibles en GitHub , el sistema es gratuito para uso no comercial (Freeware no comercial).
Para multiplataforma, Microsoft ya ha hecho una limitaci贸n de .NET Framework en t茅rminos de bibliotecas y tecnolog铆as: .NET Core. Es como el primer paso en la direcci贸n correcta, U # da el segundo paso hacia la "capacidad de programaci贸n cruzada".
Hubo pocas limitaciones de U # en las construcciones del lenguaje: estos son atavismos goto y case goto, as铆 como el rendimiento, que no se modela adecuadamente en modo autom谩tico. No se recomienda (aunque es posible) usar struct, hay matices con nombres; todo esto se describe en detalle en un documento separado. El analizador U # proporciona errores y advertencias, y para garantizar la generaci贸n correcta, debe ajustar el c贸digo fuente de C # para que, idealmente, desaparezcan por completo. Si a煤n necesita conservar la versi贸n original, puede usar las directivas de preprocesador #if JAVA || PHP ... #else ... #endif. Estas restricciones se aplican a nivel del motor U # y no est谩n sujetas a correcci贸n externa, as铆 como a la lista de idiomas admitidos.
Pero las restricciones a nivel de las bibliotecas del sistema no se establecen r铆gidamente y se configuran externamente a trav茅s de archivos de texto especiales que determinan c贸mo traducir una clase particular y sus miembros al idioma correspondiente. Si hay un an谩logo directo, entonces se indica, si la situaci贸n es m谩s complicada, entonces se escribe un c贸digo del lenguaje final o, en general, una clase especial (de servicio) que resuelve el problema deseado. En casos muy dif铆ciles, debe "codificar" en el nivel del motor, pero tales situaciones son bastante raras (alrededor de una docena). El procedimiento para configurar las clases del sistema y sus miembros se describe en un documento separado. Aqu铆 hay una lista de clases de C # compatibles y sus miembros con an谩logos en Java y Python en la versi贸n actual del sitio, tambi茅n hay una demostraci贸n en l铆nea .
En cuanto a la tecnolog铆a, ahora la lista se limita a la aplicaci贸n de consola y las pruebas unitarias (UnitTest). Bueno, los proyectos individuales de Lib, como un caso especial, se traducen en las construcciones correspondientes del idioma deseado.
Para una traducci贸n exitosa, el proyecto de C # de origen (soluci贸n) debe tener una parte de inicio que verifique la funcionalidad dentro del C # de origen. Es bueno si se trata de un extenso sistema de pruebas autom谩ticas (UnitTest est谩ndar en diferentes implementaciones o autoescrito), pero al menos debe haber al menos una aplicaci贸n de consola que funcione correctamente cuando se inicia sin intervenci贸n del usuario. La necesidad de esto es obvia: despu茅s de la generaci贸n en el lenguaje final, puede verificar inmediatamente el rendimiento. Idealmente, todas las pruebas deber铆an funcionar de manera similar a C #.
Historia del proyecto
La idea de tal convertidor ha existido durante mucho tiempo. Mi principal proyecto de procesamiento de lenguaje natural SDK Pullenti es un candidato ideal para la conversi贸n: una gran cantidad de c贸digo complejo y en constante mejora. Para integrarme con Java, tuve que envolverlo en servicios web, servidores tcp, etc.
El verano pasado, encontr茅 el tiempo y la energ铆a para crear la primera opci贸n. Tradujo el proyecto Pullenti a Java, as铆 como a s铆 mismo en Java.
Durante los siguientes seis meses, el convertidor se desarroll贸 en varios proyectos internos que estaban en la compa帽铆a, principalmente a trav茅s de la expansi贸n de las clases de sistemas.
En la primavera de 2018, la idea surgi贸 para apoyar Python, que se implement贸 en el verano. Pero la inclusi贸n de un segundo idioma no se proporcion贸 en la versi贸n inicial y result贸 torpemente. En el verano tuve que rehacer completamente el motor por el potencial de varios idiomas finales. Adem谩s, la configuraci贸n de las clases del sistema del c贸digo r铆gido se movi贸 a archivos de texto externos. Espero que este conjunto no se expanda sin su ayuda.
Otros planes son los siguientes:
- tire de Python al nivel de Java. Python ahora es compatible con el nivel Pullenti, pero Java ha avanzado mucho en otros proyectos en comparaci贸n con 茅l.
- admite PHP al menos en el nivel de proyecto Pullenti.
- Soporta C ++. S铆, me doy cuenta de que esto es muy dif铆cil, ya que no est谩 claro al liberar memoria qu茅 puntero es un enlace y para qu茅 eliminaci贸n debe hacerse. Pero hay ideas ...
驴Qui茅n puede ser 煤til?
Principalmente aquellos que desarrollan SDK potencialmente multiplataforma en C #. Gracias al convertidor UniSharping, su SDK tambi茅n puede convertirse en "software cruzado", lo que ampliar谩 el c铆rculo de usuarios potenciales.
Recientemente, las posiciones de STR se han fortalecido en Rusia, que se han convertido en obligatorias en la mayor铆a de las agencias gubernamentales y algunas grandes empresas. Explique que .NET Core tampoco siempre funciona, porque es "Microsoft". Deje que alguna compa帽铆a desarrolle su sistema de informaci贸n en C #. Para introducir el producto en la "empresa de c贸digo abierto", puede seleccionar la parte l贸gica del proyecto (back-end), convertirlo autom谩ticamente a versiones seg煤n sea necesario y convertir la parte visual (front-end) en software de c贸digo abierto. Es decir, para continuar el desarrollo en C #, y en Java solo front-end.
No excluyo que, en principio, la conversi贸n de proyectos web sea posible (con limitaciones, por supuesto), pero no tengo las habilidades e informaci贸n necesarias para esto. Si alguien ve esa oportunidad, es muy posible implementarla en UniSharping.
Observo que para un proyecto de C # realmente complejo, admitir Java u otro lenguaje requerir谩 cierto esfuerzo para modificar el c贸digo, resaltar la parte port谩til en el proyecto y "rodearlo" con pruebas unitarias. Adem谩s, configurar clases y m茅todos de sistema a煤n no compatibles y corregir errores de UniSharping en s铆 (con mi ayuda) sigue siendo el trabajo. Pero el proceso es convergente, al final del cual el proyecto espera una bonificaci贸n entre programadores.