Quelles sont les raisons de choisir un langage de script non DSL sur un langage compilé statiquement tel que C#?Quelles sont les raisons de choisir un langage de script sur C#?
-edit- Bonne réponse jusqu'à maintenant. Je pense que je devrais expliquer plus loin. Je suis sûr que les gens utilisent Python sur C# pour plus de raisons que le goût et C# sur Python pour d'autres situations.
Duck typing: s'il marche comme un canard et parle comme un canard, c'est un canard.
Sauf quand c'est un dragon déguisé en canard, mais c'est complètement différent. – JAB
L'anglais est ambigu, c'est pourquoi il n'est pas utilisé comme langage de programmation. C'est aussi la raison pour laquelle le typage de Duck n'est pas à l'échelle. – clemahieu
@clemahieu: Plutôt que d'attaquer la réponse de tout le monde ici, pourquoi ne créez-vous pas votre propre réponse sur les raisons de ne PAS choisir un langage dynamique. Ce sera plus utile à SO et à tous ceux qui ont réexaminé cette question à l'avenir. Je ne dis pas que le typage du canard est bon ou mauvais, mais que c'est l'une des raisons pour lesquelles les gens utilisent un langage dynamique (comme c'est la question). –
Vitesse de développement généralement, un langage de script supprime tout besoin de compiler quelque chose - il suffit de taper et de l'exécuter. Généralement, vous pouvez taper comme s'il s'exécutait si vous l'éditiez pendant que vous l'avez arrêté dans un débogueur - pas de recompilation, pas besoin de 'éditer et continuer', pas de rien. Beaucoup de langages de script ont aussi une portée moins restrictive pour des choses comme les types statiques, vous pouvez juste coder sans se soucier si votre chaîne doit être convertie en un entier ou vice versa, vous l'utilisez tel quel et cela fonctionne. On peut se demander si c'est une bonne ou une mauvaise chose, mais je pense que c'est une de ces choses où c'est bon quand il est utilisé pour certaines tâches et mauvais pour d'autres. Les modules complémentaires et les bibliothèques sont généralement beaucoup plus faciles à utiliser - vous n'avez pas besoin d'enregistrer ou d'installer quoi que ce soit, ou de vous soucier des assemblages ou du GAC ou des documents signés, vous n'avez qu'à inclure les fichiers sources et vous avez terminé .
Donc, le script est la chose la plus facile à faire en général, c'est pourquoi les gens l'utilisent.
Une très bonne réponse. –
Juste une petite note sur ce bit add-ons: avec certaines langues, telles que Python, qui peut utiliser des extensions écrites en C, vous devez compiler/installer des choses dans certaines situations. – JAB
Le temps de développement initial est l'un des plus petits puits de temps dans le processus de développement. La maintenance et la gestion de la complexité dans les grands systèmes représentent un puits de temps beaucoup plus important. – clemahieu
Les langages de script excel principalement dans 2 domaines:
projets de petite à moyenne taille où les performances ne sont pas une priorité absolue et la flexibilité dans l'environnement d'exécution est.
La construction de langages spécifiques au domaine. Les fonctionnalités de typage de canard et d'invocation dynamique de méthode d'un langage de script le rendent idéal pour la conception de langages spécifiques à un domaine. Ruby on Rails, bien sûr, est le porte-affiche de cette capacité, mais de nombreux autres exemples existent en particulier dans les logiciels développés en interne.
Le principal inconvénient est que ces caractéristiques sont souvent trop puissants, et sans une discipline stricte, il est très facile d'écrire du code qui est difficile à maintenir.
C# peut redéfinir le code en temps réel à la volée. – clemahieu
"écrire du code et le tester plus vite" Pourquoi le besoin de tester si vite? Peut-être parce que vous n'êtes pas sûr que le code fonctionnera comme prévu, car il n'y a pas d'analyse statique. Avec un langage typé statiquement, vous pouvez écrire un programme entier sans aucun test. –
@Max Toro oui, vous pouvez écrire tout un programme du début à la fin sans test, et ce sera faux avec une probabilité de 99% ... Et l'analyse statique ne vous aidera pas plus qu'un correcteur orthographique ne le fera en écrivant un livre. Peut-être que vous êtes un génie, mais la plupart des gens dans ce monde ne comprennent pas bien la première fois. – fortran
Portabilité vers d'autres plateformes, et environnement de développement plus simple (généralement un éditeur de texte, pas Visual Studio).
Vous n'avez pas besoin de Visual Studio pour écrire C#, vous pouvez utiliser Notepad si vous voulez - mais un IDE aide! – ChrisF
Les programmeurs qui ont seulement utilisé une langue statiquement typée peuvent simplement accepter que c'est une manière nécessaire de faire les choses. Une fois que vous avez expérimenté le typage du canard, vous réalisez que le polymorphisme peut vraiment être aussi simple - sans toutes les lignes de code supplémentaires pour spécifier les types. Tout ce type de déclaration de type n'est pas requis pour que le programme fonctionne - et c'est libérateur à l'expérience - c'est simplement pour que le compilateur puisse vérifier certains types d'erreurs. Si vous ne faites pas de test dans une langue dynamique, vous pouvez être touché par des erreurs d'exécution que le compilateur attraperait dans une langue statiquement typée - mais il s'avère que ce n'est pas autant une victoire pour statiquement les langues dactylographiées que vous pourriez penser, parce que vous devriez faire des essais dans les deux types de langues de toute façon. Vous devez tester dans des langages statiquement typés pour attraper les autres erreurs logiques que la vérification de type n'attrapera pas - et dans de nombreux cas, les types de tests qui passent excluront les erreurs liées au type - vous n'avez donc pas besoin de suffisamment tester dans des langages dynamiques pour compenser le codage de déclaration de type que vous n'avez pas à faire. Le résultat est non seulement une productivité accrue, mais le plaisir de se concentrer uniquement sur ce que vous voulez faire, le cœur du problème, plutôt que de vous embourber pour dire au compilateur un tas de choses afin qu'il puisse vous protéger de les erreurs que vous allez (au moins) tester contre toute façon. La performance est le compromis, car un langage dynamique ne peut pas assumer autant de choses au moment de l'exécution - mais la performance n'est souvent pas le problème. Et quand c'est le cas, vous pouvez réécrire les modules critiques de performance dans un langage de niveau inférieur. Des langages comme Python rendent cela facile.
Les langues avec des capacités d'inférence de type sont un moyen terme à considérer.
J'ai beaucoup utilisé les langages typés statiquement et dynamiquement, et les caractères typés statiques rattrapent tellement d'erreurs au moment de la compilation que cela vaut facilement le coup de frappe. Vous compensez les annotations de type en n'ayant pas à écrire autant de tests unitaires. En fait, dans des langages tels que Haskell avec des systèmes de type avancé, assez souvent, si votre programme compile, cela fonctionne correctement. (Et vous n'avez même pas besoin de faire des annotations de type!) – Zifre
Je vois généralement que les adeptes du typage de canards viennent d'un contexte de travail sur de petits systèmes. La gestion de la complexité des grands systèmes devient l'une des étapes les plus fastidieuses du processus de développement, et le typage statique et la compilation avec des IDE puissants sont d'énormes avantages dans ce processus de gestion. – clemahieu
pourquoi était-ce downvoted? J'aime cette réponse. (Je vais upvote plus tard) –
Cela a été mentionné en quelque sorte de manière tangentielle, mais la question, telle que formulée, oppose «statiquement typé» et «script», et c'est une fausse dichotomie. Il est possible d'avoir les deux, dans des langages comme F #, où il y a une syntaxe succincte, une inférence de type, et un interactif REPL. Il y a des compromis et des tensions des deux côtés, mais vous obtenez beaucoup du meilleur des deux mondes.
Dans mon expérience, deux choses sont la décision la plus importante que vous devez faire avant de commencer la conception/codage:
Il est inutile d'utiliser C++ si vous n'avez même pas l'idée des modèles ou de la POO en général.
Imho le point le plus important, parce que par exemple vous voulez coder STH comme Twitter, vous pouvez écrire votre propre serveur web omnipotent dans Lisp et pirater des choses comme javascript- ou forme-convenience-fonctions ensemble - mais pourquoi pas simplement utiliser à savoir Tomcat/Java/Wicket ou respectivement Apache/PHP/Synfony? Donc toutes les bases sont couvertes, bien testées et avec beaucoup de ressources en ligne. Encore plus, vous devriez considérer ORM-frameworks/wrapper de base de données - ils économisent beaucoup de temps et d'erreurs - si vous en avez besoin.En règle générale: si vous commencez à partir de zéro (c.-à-recherche) choisissez la langue que vous aimez le plus (et est assez puissant pour votre tâche), si vous faites du développement dans un domaine commun (c.-à-sites) la langue selon vos compétences et les outils déjà disponibles.
Si la performance est vraiment une préoccupation immédiate, respectez les langages de compilation.
Just my 0,02
C'est bon et tout sauf que je ne peux pas imaginer utiliser un langage de script sur C# (sauf quand vous n'avez pas le choix comme peut-être pour un addon). –
Pourquoi pas? Actuellement, j'utilise MATLAB pour SVM-stuff, car il a les outils pour cela. Bien sûr, C# pourrait éventuellement faire la même chose ... mais pourquoi devrais-je aller les 20 miles supplémentaires? – ShoX
$ Parce que Python est comme voler:
Voir aussi http://stackoverflow.com/questions/125367/dynamic-langauges-vs-static-type-languages –