Python vs C#/. NET-quelles sont les principales différences à considérer pour en utiliser un pour développer une grande application web?

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

Permettez-moi de commencer par dire que je me rends compte que l'une ou l'autre technologie fonctionnera très bien, et je suis à la recherche des différentiateurs clés (et associés avantages et inconvénients) ces langues ont beaucoup en commun, et beaucoup pas-je cherche votre point de vue sur leurs différences clés.

Exemple de compromis / différenciateur 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 l'équipe d'ingénierie est d'environ 20 grands et nous travaillons dans de petites équipes de 5-7 dont nous faisons tourner les gens dans et Hors fréquemment. Nous travaillons sur le code que quelqu'un d'autre a écrit autant que nous écrivons un nouveau code.

Avec python, nous irions sur la route Django, et avec. net, nous irions avec MVC2. Nos serveurs sont des serveurs windows exécutant IIS.

Certaines choses que nous aimons à propos de ColdFusion incluent 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 à le faire redémarrez-Les ou interrompez quelqu'un sur eux.


J'ai lu quelques-uns des autres threads X vs y impliquant ces deux langages et les ai trouvés très utiles, mais je voudrais mettre Python en tête-à-tête contre.net directement. Merci d'avance de me laisser exploiter vos expériences pour cette question difficile!

54
demandé sur Zugwalt 2010-08-06 06:18:54

4 réponses

". net " n'est pas une langue. Peut-être que C'est Python vs. C# ou Python/Django vs C#/ASP.NET (ou choisissez n'importe quel "webwork" que vous voulez; il y a beaucoup, beaucoup de solutions différentes pour Python et". NET" et choisir Django ou MVC2 de la chauve-souris pourrait sévèrement limiter les meilleures options viables). En tant que compteur du Python vs.". net": il y a IronPython (Python "in. net")

Je considérerais: Developer comfort avec un langage et, s'ils sont égaux en Python et ". NET", alors je envisagerait les délais d'exécution pour le développement et choisirait le langage / "webwork" qui minimise cela (encore une fois, il n'est pas nécessaire que ce soit des contraintes antérieures).

Alors que le test d'unité / intégration est un must pour tout projet [important], je trouve qu'un langage typé statiquement (C#/F#) peutréduire considérablement le nombre de "bugs stupides" relatifs aux types.

Ouvrez le terrain de jeu: -)

Modifier le commentaire:

Alors vous comparez juste langue.

Auquel cas, C# est un langage impératif statiquement typé très ennuyeux avec un seul héritage / Interface basé sur une classe OO (mais quelques astuces plus soignées que Java, qui est juste carrément l'âge de Pierre). C'est le même type de base de OO que Python a {[6] } et à l'exclusion du bit statique / dynamique, les deux langages sont fortement typés (la mécanique est différente, mais le résultat final est assez similaire dans le spectre du langage). En fait, python a MI, mais cela semble moins accepté en python comme l'utilisation du mot-clé 'lambda' et puisque python est typé dynamiquement, il n'y a pas de support à la compilation pour déterminer les contrats d'interface / type(il y a cependant quelques modules qui essaient de le fournir).

Si vous pouvez apprendre/savoir Python, alors vous pouvez apprendre/connu C#., Il n'est pas un changement de paradigme. Certains mots-clés ici, accolades là, besoin de dire quel type vous voulez dire là, une bibliothèque de base différente... environnement différent (vous devez vous battre pour arriver à un REPL, mais c'est faisable dans VS.) comment les développeurs aiment/apprennent/utilisent c'est une autre histoire. Bien que J'aie appelé c# imperative auparavant, il est agréable de voir l'ajout de certaines fonctionnalités "fonctionnelles" telles que LINQ/IEnumerable extensions et closures-without-delegates, même si la syntaxe C# de base est très procédurale-encore une fois, à peu près comme python (for-expressions, fonctions imbriquées, Division d'instruction/expression).

Alors que la nouvelle 'dynamique' floue la ligne (il y a très rarement une bonne utilisation pour cela -- dans à peu près tous les mêmes endroits, on aurait pu devoir se replier sur la réflexion dans les versions C# antérieures-ce n'est pas vrai, mais le fait est que c'est généralement "le mauvais sens", sauf dans les rares cas où c'est "le meilleur/le seul moyen"), 'var' ne le fait pas. C'est le type d'un 'var' variable est connu au moment de la compilation et n'a rien à voir avec typage dynamique, c'est tout l'inférence de type. Certains langages comme F# / SML et Haskell ont une inférence de type beaucoup plus puissante supprimer le besoin de "toutes ces déclarations de type laid "(Bien que l'Annotation explicite des types autorisés ou un ensemble de types puisse rendre l'intention plus claire) tout en préservant le typage statique.

Personnellement, tout le reste mis à part , j'utiliserais un langage typé statiquement. Je ne dis pas C# (et je ne dis certainement pas Java!), mais les langages statiquement typés peuvent pousser les erreurs de type vers le haut et nécessiter des contrats explicites initiaux (c'est une grande, grande victoire pour moi). Pendant que vous manquez sur quelques astuces dynamiques soignées, il y a presque toujours une meilleure façon d'effectuer la même action dans la langue cible - il suffit de penser en termes de cette langue et d'utiliser un tournevis pour une vis et un marteau pour un clou. Par exemple, ne vous attendez pas à apporter du code Python reposant sur l'utilisation (ab)de local() ou global() en C# tel quel.

Sur le "down-side" , la plupart des langages typés statiquement (C # ici) nécessitent une compilation explicite d'abord (mais ce n'est pas si mal car cela fait 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 langue), cela peut être un facteur décisif pour savoir pourquoi choisir une langue plutôt que l'autre.

38
répondu 2010-08-06 05:26:32

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é sur C#/. NET pendant près de 10 ans, donc je le sais très bien. Et je programme sur Python à Quora depuis ~ 7 mois maintenant, donc j'espère que je le sais assez bien.

  • Python est gagnant dans: facilité d'apprentissage, développement multi-plateforme, disponibilité de l'open source les bibliothèques

  • C # est gagnant dans: bibliothèque standard, fonctionnalités linguistiques, processus et outils de développement, performance, vitesse d'évolution du langage
  • à peu près même: syntaxe (Python est meilleur en lisibilité, C# a une syntaxe plus cohérente), adoption.
28
répondu Alex Yakunin 2015-10-19 12:14:50

Je suggère également que nous devons comparer les runtimes et ne pas nous limiter aux fonctionnalités de la langue avant de faire de tels mouvements. Python s'exécute via l'interpréteur CPython où 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 des threads... et aussi il peut prendre des avantages des processus de travail dans IIS (ASP.NET). CPython n'offre pas de vraies capacités de threading à cause de GIL...un verrou que chaque thread doit acquérir avant d'exécuter n'importe quel code, pour de vrai multitâche, vous devez utiliser plusieurs processus.

Quand nous hébergeons ASP.NET application sur IIS sur un processus de travail unique, ASP.NET peut encore profiter du threading pour servir plusieurs requêtes web simultanément sur différents cœurs où CPython dépend de plusieurs processus de travail pour réaliser un calcul parallèle sur différents cœurs.

Tout cela conduit à une grande question, comment nous allons héberger l'application Python/Django sur windows. Nous savons tous fourche le processus sous windows est beaucoup plus coûteux que 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 serait Linux...et si vous êtes comme moi, venant de windows, le choix de Python introduirait une nouvelle courbe d'apprentissage de Linux...bien que n'est pas très difficile ces jours-ci...

6
répondu Faraz M. Khan 2014-12-02 16:58:04

Le principal problème dans 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. Donc, vous avez presque la même sécurité en python maintenant.

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

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

Python fonctionne presque n'importe où et vous avez le choix entre différents runtimes, principalement compatibles (12 sur Wikipedia) liste d'interpréteurs Wikipedia python

2
répondu bjoern 2015-03-10 18:18:32