Présentation

Depuis les années 70, l' anglais simplifié se développe, dont le but est de déterminer un sous-ensemble de la langue qui est compréhensible pour un large éventail de locuteurs non natifs de la langue. Recommandé, par exemple, pour la documentation technique. Les traducteurs automatiques sur un tel sous-ensemble fonctionneront évidemment plus correctement, générant idéalement du texte qui ne nécessite pas de relecture manuelle.
Si vous appliquez cette approche à C # pour la tâche de conversion automatique du code vers d'autres langages de programmation, vous pouvez sélectionner un sous-ensemble des constructions de langage, des bibliothèques système et des technologies qui pourraient potentiellement être traduites dans un large éventail d'autres langages. De plus, la conversion n'est pas unique (migration), mais constante pour étendre les capacités d'intégration du projet en C # - de sorte qu'à tout moment, vous pouvez obtenir un code de travail dans une autre langue sans avoir besoin d'aucune modification.

Permettez-moi de vous présenter: UniSharping

La restriction de C # .NET pour résoudre ce problème a été appelée U # (Universal Sharp), et le processus de conversion et son outil ont été appelés UniSharping . Les modules exécutables, les paramètres et la documentation sont disponibles sur GitHub , le système est gratuit pour une utilisation non commerciale (Freeware non commercial).

Afin de multiplier les plateformes, Microsoft a déjà fait une limitation du .NET Framework en termes de bibliothèques et de technologies: .NET Core. C’est comme le premier pas dans la bonne direction, U # fait le deuxième pas vers la «programmabilité croisée».

Il y avait peu de limitations U # dans les constructions de langage - ce sont les atavismes goto et goto de cas, ainsi que le rendement, qui n'est pas modélisé correctement en mode automatique. Il n'est pas recommandé (bien que cela soit possible) d'utiliser struct, il y a des nuances avec les noms - tout cela est décrit en détail dans un document séparé. L'analyseur U # donne des erreurs et des avertissements, et pour garantir une génération correcte, vous devez ajuster le code source C # afin qu'ils disparaissent idéalement complètement. Si vous devez toujours conserver la version d'origine, vous pouvez utiliser les directives du préprocesseur # si JAVA || PHP ... #else ... #endif. Ces restrictions s'appliquent au niveau du moteur U # et ne sont pas soumises à une correction externe, ainsi qu'à la liste des langues prises en charge.

Mais les restrictions au niveau des bibliothèques système ne sont pas définies de manière rigide et sont configurées en externe via des fichiers texte spéciaux qui déterminent comment traduire une classe particulière et ses membres dans la langue correspondante. S'il y a un analogue direct, alors il est indiqué, si la situation est plus compliquée, alors soit un morceau de code de la langue finale est écrit, soit en général une classe spéciale (service) qui résout le problème souhaité. Dans les cas très difficiles, vous devez «coder en dur» au niveau du moteur, mais de telles situations sont assez rares (une douzaine environ). La procédure de configuration des classes système et de leurs membres est décrite dans un document séparé. Voici une liste des classes C # prises en charge et de leurs membres avec des analogues en Java et Python dans la version actuelle sur le site, il y a aussi une démo en ligne .

Quant à la technologie, la liste se limite désormais à l'application console et aux tests unitaires (UnitTest). Eh bien, les projets Lib individuels, comme un cas spécial, sont traduits dans les constructions correspondantes de la langue souhaitée.

Pour une traduction réussie, le projet C # source (solution) doit avoir une partie de démarrage qui vérifie la fonctionnalité au sein du C # source. C'est bien s'il s'agit d'un système étendu d'autotests (UnitTest standard dans différentes implémentations ou auto-écrit), mais au moins il devrait y avoir au moins une application console qui fonctionne correctement lorsqu'elle est lancée sans aucune intervention de l'utilisateur. Le besoin est évident - après la génération dans la langue finale, vous pouvez immédiatement vérifier les performances. Idéalement, tous les tests devraient fonctionner de manière similaire à C #.

Historique du projet

L'idée d'un tel convertisseur existe depuis longtemps. Mon principal projet de traitement du langage naturel SDK Pullenti est un candidat idéal pour la conversion: une grande quantité de code complexe et en constante amélioration. Pour m'intégrer à Java, je devais l'envelopper dans des services Web, des serveurs TCP, etc.
L'été dernier, j'ai trouvé le temps et l'énergie pour créer la première option. Il a traduit le projet Pullenti en Java, ainsi que lui-même en Java.
Au cours des six mois suivants, le convertisseur s'est développé sur plusieurs projets internes à l'entreprise, principalement grâce à l'expansion des classes système.
Au printemps 2018, l'idée est venue de soutenir Python, qui a été mis en œuvre d'ici l'été. Mais l'inclusion d'une deuxième langue n'était pas prévue dans la version initiale et elle s'est avérée maladroite. En été, j'ai dû refaire complètement le moteur pour le potentiel de plusieurs langues finales. De plus, les paramètres des classes système du code dur ont été déplacés vers des fichiers texte externes. J'espère que cet ensemble ne se développera pas sans votre aide.

D'autres plans sont les suivants:

• tirer Python au niveau Java. Python est désormais pris en charge au niveau Pullenti, mais Java est allé de l'avant sur d'autres projets par rapport à lui.
• supporte PHP au moins au niveau du projet Pullenti.
• supporte C ++. Oui, je me rends compte que c'est très difficile, car il n'est pas clair lors de la libération de la mémoire quel pointeur est un lien et pour lequel la suppression doit être effectuée. Mais il y a des idées ...

Qui peut être utile

Surtout ceux qui développent des SDK potentiellement multiplateformes en C #. Grâce au convertisseur UniSharping, leur SDK peut également devenir «cross-software», ce qui élargira le cercle des utilisateurs potentiels.
Récemment, les positions STR ont été renforcées en Russie, qui sont devenues obligatoires dans la plupart des agences gouvernementales et dans certaines grandes entreprises. Expliquez que .NET Core ne fonctionne pas toujours non plus, car il s'agit de «Microsoft». Laissez une entreprise développer son système d'information en C #. Afin d'introduire le produit dans la "société open source", vous pouvez sélectionner la partie logique du projet (back-end), le convertir automatiquement en versions si nécessaire et faire de la partie visuelle (front-end) un logiciel open source. Autrement dit, pour continuer le développement en C #, et en Java uniquement front-end.

Je n'exclue pas qu'en principe la conversion de projets Web soit possible (avec des limitations, bien sûr), mais je n'ai pas les compétences et les informations nécessaires pour cela. Si quelqu'un voit une telle opportunité, il est tout à fait possible de l'implémenter dans UniSharping.

Je note que pour un projet C # vraiment complexe, la prise en charge de Java ou d'un autre langage nécessitera un certain effort pour modifier le code, mettre en surbrillance la partie portable dans le projet et «l'encercler» avec des tests unitaires. En outre, la mise en place de classes et de méthodes système encore non prises en charge et la correction des erreurs d'UniSharping lui-même (avec mon aide) est toujours le travail. Mais le processus converge, au terme duquel le projet attend un bonus multi-programmeur.