En tant que Développeur Full-Stack au sein d'Agaetis depuis plusieurs années, mes missions m'ont amené à développer autant en Python qu'en C#.  Que ce soit sur des projets Full python, full C#, ou en mixant les deux. Ce qui est plutôt intéressant, sachant qu'ils font partie des langages les plus appréciés des développeurs.  

Contexte

À l'époque, il existait deux solutions pour marier les deux technologies : IronPython et Docker . IronPython a vite été écarté : la version de Python disponible étant trop ancienne (2.x vs 3.x), elle obligeait à devoir réécrire une partie des algorithmes. Nous sommes donc partis sur Docker. Nous avons malgré tout dû réécrire une partie des algorithmes afin de pouvoir les lancer via une API Rest, mais ce fut juste du déplacement de code ou de la création de fonction.

Cette approche est simple et efficace, le seul bémol est que l'installation est complexifiée. Il faut installer/configurer Docker, builder l'image docker (accès à internet requis au moins pour cette phase) et définir des espaces d'échanges (certains algorithmes fournissent des fichiers de sortie). Même si ce n'était pas ce que nous avions en tête au départ, ça fonctionne, avec beaucoup de documentation pour l'installation.

Et aujourd'hui ?

Quand j'ai d u temps libre (temps de veille, baisse de régime d'un projet, inter-contrat), j'apprécie de me repencher sur d'anciens projets me permettant  de me poser la question : « Ferais-je différemment aujourd'hui ? ». Heureusement, la plupart du temps la réponse est oui, mais par moment la réponse est par la négative, souvent, du fait du contexte projet.

Ici, la réponse, à ce projet en particulier, est « peut-être ». Quand nous parlons algorithmes ou data science, nous pensons forcément que Python est incontournable, et ce à juste titre.  J’ai donc dû  regarder si du côté de Python il existait quelque chose de nouveau, permettant de me passer du C#, ou au contraire, de me passer de Python.

En ce qui concerne Python, rien n'a vraiment changé en termes d'interface utilisateur. Les bibliothèques graphiques leaders étant toujours Qt et Tkinter, cela implique de devoir installer une nouvelle fois des bibliothèques supplémentaires, et donc un risque de complexification de l’installation.

Et en ce qui concerne le C# ? Grâce à l'essor du moteur de jeu Unity , différentes librairies .Net ont émergé. Malheureusement, elles sont surtout orientées vers le Machine Learning et ne permettent pas de retranscrire la totalité des calculs de l'application. 

En continuant les recherches, je suis tombé sur la stack SciSharp , portage de différents outils Python en C# et F# (pour certains). Au programme : NumSharp (NumPy), TensorFlow.Net, Keras.Net, pour ne citer que les plus matures — d'autres comme Torch.Net (PyTorch), Gym.Net, Pandas.Net, SharpCV (portage d'OpenCV) sont encore en cours de développement.

La stack cible le .Net Standard Framework, et permet de faire tourner ces bibliothèques sur un projet WPF pointant le .Net framework 4.8, ce qui pourrait être notre cas, si nous gardions en tête le WPF (même si MAUI nous fait de l'œil). Cerise sur le gâteau, les bibliothèques gardent à l'identique le nom et les paramètres des fonctions.

Conclusion

Il existe bien évidemment d'autres possibilités, comme pythonnet , qui permet d'exécuter du code python sous .Net et inversement. Cette bibliothèque a l'avantage d'être à la base de plusieurs projets de portage entre Python et .Net ( liste des projets non exhaustive), dont Numpy.Net de SciSharp.

Dans le cas du projet étudié et pour les algorithmes que nous avions eu à retranscrire, NumSharp ou Pandas.Net suffiraient amplement (même si le portage n'est pas fini pour Pandas) pour livrer une application tout-en-un en minimisant le processus d'installation. 

Et vous, pensez-vous comme moi que de revenir de temps en temps sur d'anciens projets rentre dans le processus d'amélioration continue ? Que cela permet de se challenger et donc de se remettre en question, que ce soit tant au niveau pratique que théorique ?