Python vs C#/.NET - quelles sont les principales différences à prendre en compte pour l'utilisation de l'un ou l'autre pour développer une grande application web ?

Question

Mon organisation fournit actuellement une application web basée principalement sur un back-end SQL Server 2005/2008, un cadre de modèles/contrôleurs Java et des vues ColdFusion. Nous avons décidé de passer à un cadre plus récent et, après des explorations internes et des mini-projets, nous avons réduit le choix entre Python et C#/.NET.

Permettez-moi de commencer en disant que Je suis conscient que l'une ou l'autre de ces technologies peut très bien fonctionner, et je cherche à connaître les principaux facteurs de différenciation (et les avantages et inconvénients associés). Ces langues ont beaucoup de points communs, et beaucoup d'autres non. J'aimerais connaître votre avis sur leurs principales différences.

Exemple de compromis/différentiateur que je recherche :

Bien qu'il semble que vous puissiez accomplir plus avec moins de code et être plus créatif avec Python, puisque .NET est plus structuré, il peut être plus facile de prendre en charge la compréhension et la modification du code que quelqu'un d'autre a écrit.

Quelques informations supplémentaires qui peuvent être utiles :

Notre équipe d'ingénieurs est composée d'une vingtaine de personnes et nous travaillons en petites équipes de 5 à 7 personnes, avec des rotations fréquentes. Nous travaillons sur le code que quelqu'un d'autre a écrit autant que nous écrivons du nouveau code.

Avec Python, nous suivrions la voie de Django, et avec .NET, nous opterions pour MVC2. Nos serveurs sont des serveurs Windows exécutant IIS.

Ce que nous apprécions dans ColdFusion, c'est qu'il est très facile de travailler avec des requêtes et que nous pouvons "déployer à chaud" des correctifs sur nos serveurs web sans avoir à les redémarrer ou à interrompre quiconque s'y trouve.

---

J'ai lu certains des autres fils de discussion X contre Y impliquant ces deux langages et je les ai trouvés très utiles, mais j'aimerais mettre Python en concurrence directe avec .Net. Merci d'avance de me faire profiter de votre expérience pour cette question difficile !

Answer 1

".NET" n'est pas un langage. Peut-être s'agit-il de Python contre C# ou de Python/Django contre C#/ASP.NET (ou choisissez le "réseau web" que vous voulez ; il existe de très nombreuses solutions différentes pour Python et ".NET" et choisir Django ou MVC2 d'emblée pourrait limiter considérablement les meilleures options viables). Pour contrer l'opposition entre Python et ".NET" : Il y a IronPython (Python "en .NET")

J'y réfléchirais : Confort du développeur avec un langage et, s'ils sont égaux en Python et ".NET", alors je considérerais les délais de développement et choisirais le langage/le "webwork" qui minimise cela (encore une fois, il ne doit pas s'agir de contraintes antérieures).

Bien que le test d'unité/intégration soit indispensable pour tout projet [important], je trouve qu'un test d'unité et d'intégration est plus facile à réaliser. langage statiquement typé (C#/F#) peut réduire considérablement le nombre de "bugs stupides" relatifs aux types.

Ouvrez le terrain de jeu :-)

Modifier pour le commentaire :

Alors vous ne faites que comparer les langues.

Dans ce cas, le C# est un langage impératif statiquement typé très ennuyeux, avec un système d'exploitation basé sur les classes à héritage unique/interface (mais avec un peu plus d'astuces que Java, qui est carrément de l'âge de pierre). Ceci est le même type d'OO de base que celui de Python et en excluant le bit statique/dynamique, les deux langages sont fortement typés (les mécanismes sont différents, mais le résultat final est assez similaire dans le spectre des langues). En fait, python dispose de MI, mais cela semble moins accepté en python que l'utilisation du mot-clé "lambda" et, comme python est typée dynamiquement, il n'y a pas de support de compilation pour déterminer les contrats d'interface/type (il y a cependant quelques modules qui essaient de le faire).

Si vous pouvez apprendre/connaître Python, alors vous pouvez apprendre/connaître C#. Ce n'est pas un changement de paradigme. Quelques mots-clés par-ci, des accolades par-là, la nécessité de dire de quel type on parle par-là, une bibliothèque de base différente... un environnement différent (il faut se battre pour accéder à un REPL, mais c'est faisable dans VS.) La façon dont les développeurs l'apprécient, l'apprennent et l'utilisent est une autre histoire. Alors que je qualifiais auparavant le C# d'impératif, il est agréable de voir l'ajout de certaines fonctionnalités "de type fonctionnel" telles que les extensions LINQ/IEnumerable et les closures-without-delegates, même si la syntaxe de base du C# est très procédurale -- une fois de plus, assez proche de celle de Python (for-expressions, fonctions imbriquées, division des déclarations/expressions).

Alors que le nouveau "dynamic" brouille les pistes (il n'est que très rarement utilisé à bon escient - dans à peu près tous les endroits où l'on aurait pu se rabattre sur la réflexion dans les versions antérieures de C# - ce n'est pas vrai, mais le fait est que c'est généralement "la mauvaise méthode", sauf dans les rares cas où c'est "la meilleure/la seule méthode"), "var" ne le fait pas. C'est-à-dire que le type d'une variable 'var' est connu au moment de la compilation y n'a rien à voir avec le typage dynamique Il s'agit d'une inférence de type. Certains langages comme F#/SML et Haskell ont une inférence de type beaucoup, beaucoup plus puissante, supprimant le besoin de "toutes ces affreuses déclarations de type" (bien que l'annotation explicite des types ou des ensembles de types autorisés puisse rendre l'intention plus claire) tout en préservant le typage statique.

Personnellement, tout le reste mis à part je choisirais un langage à typage statique. Je ne dis pas C# (et je ne dis certainement pas Java !), mais les langages à typage statique peuvent faire passer les erreurs de type au premier plan et exiger des contrats explicites dès le départ (c'est une grande, grande victoire pour moi). Bien que vous ne puissiez pas profiter de certaines astuces dynamiques, il existe presque toujours une meilleure façon d'effectuer la même action dans le langage cible - vous devez simplement penser en termes de ce langage et utiliser un tournevis pour une vis et un marteau pour un clou. Par exemple, n'espérez pas transposer tel quel en C# du code Python reposant sur l'utilisation (ou l'absence d'utilisation) de local() ou global().

Du côté négatif, la plupart des langages typés statiquement (ici C#) nécessitent une compilation explicite en premier (mais ce n'est pas si mal car cela permet de faire de jolis assemblages) et des outils comme le "REPL" ne sont pas considérés comme des citoyens de première classe (c'est un citoyen de première classe dans F#/VS2010). De plus, si vous avez une bibliothèque essentielle pour Python/C# (et qu'elle n'est pas disponible dans l'autre langage), cela peut être un facteur décisif pour choisir un langage plutôt que l'autre.

Answer 2

J'ai écrit une réponse très complète sur Quora à ce sujet : Comment Python se compare-t-il à C# ?

TL;DR

• La réponse est énorme, mais (espérons-le) assez complète. J'ai programmé en C# / .NET pendant près de 10 ans, je le connais donc très bien. Et je programme en Python chez Quora depuis environ 7 mois maintenant, donc j'espère que je le connais assez bien.

• Python est le vainqueur dans les domaines suivants : facilité d'apprentissage, développement multiplateforme, disponibilité de bibliothèques open source.

• Le C# est gagnant dans les domaines suivants : bibliothèque standard, caractéristiques du langage, processus et outils de développement, performances, vitesse d'évolution du langage.

• À peu près à égalité : syntaxe (Python est plus facile à lire, C# a une syntaxe plus cohérente), adoption.

Answer 3

J'aimerais également suggérer que nous devons comparer les temps d'exécution et ne pas nous limiter aux caractéristiques du langage avant de faire de tels choix. Python s'exécute via l'interpréteur CPython alors que C# s'exécute sur CLR dans leurs implémentations par défaut.

Le multitâche est très important dans tout projet à grande échelle ; .NET peut facilement gérer cela via les threads... et il peut également tirer parti des processus de travail dans IIS (ASP.NET). CPython n'offre pas de véritables capacités de threading à cause du GIL... un verrou que chaque thread doit acquérir avant d'exécuter tout code, pour un véritable multitâche, vous devez utiliser plusieurs processus.

Lorsque nous hébergeons une application ASP.NET sur IIS sur un seul processus de travail, ASP.NET peut toujours tirer parti du threading pour servir plusieurs requêtes web simultanément sur différents cœurs, alors que CPython dépend de plusieurs processus de travail pour réaliser un calcul parallèle sur différents cœurs.

Tout ceci nous amène à une grande question : comment allons-nous héberger une application Python/Django sur Windows ? Nous savons tous que le processus de fork sous Windows est beaucoup plus coûteux que sous Linux. Donc, idéalement, pour héberger l'application Python/Django, le meilleur environnement serait Linux plutôt que Windows.

Si vous choisissez Python, le bon environnement pour développer et héberger Python sera Linux... et si vous êtes comme moi, venant de Windows, choisir Python introduira une nouvelle courbe d'apprentissage de Linux également... bien que ce ne soit pas très difficile de nos jours...

Answer 4

Le principal problème dans l'industrie est la nature dynamique de python. Parce que vous avez une sorte de sécurité avec un langage typé statique.

Mais maintenant nous avons des IDE modernes comme PyCharm. Ils intègrent pylint et pep8 "code-checking" et "styleguide-check" lorsque vous tapez votre code. Cela élimine les erreurs les plus stupides. Vous avez donc presque la même sécurité en python maintenant.

L'autre chose est que, si vous avez besoin de "vérification de type statique", faites-le vous-même quand vous en avez besoin. C'est la nature pragmatique de Python.

La GIL est un problème, mais vous pouvez utiliser gevent ou ZMQ pour faire une sorte de threading. Mais travail en cours sur PyPy STM.

Python s'exécute presque partout et vous avez le choix entre différents moteurs d'exécution, généralement compatibles (12 sur Wikipedia). Liste des interpréteurs python de Wikipédia