Je viens de Java World et je me demande ce qui est si important de taper dynamique dans Python en plus d'erreurs manquantes tout en compilant le code?
Aimez-vous la dactylographie de Python? Avez-vous un exemple où il a aidé dans un grand projet? N'est-ce pas une erreur un peu sujette?
7 Réponses :
C'est une charge de votre esprit. Vous pouvez penser à la couleur rouge comme "rouge" (une constante) comme "255, 0, 0" (un tuple) ou "# FF0000" (une chaîne): trois formats différents, qui nécessiteraient trois types différents, ou une recherche complexe et des méthodes de conversion en Java.
Il rend le code plus simple.
Par exemple, vous pouvez écrire des fonctions à quoi vous pouvez passer un entier comme ainsi qu'une chaîne ou une liste ou un dictionnaire ou autre chose, et il sera en mesure de gérer de manière transparente tous de manière appropriée (ou jeter une exception s'il ne peut pas gérer le type). Vous pouvez faire des choses comme ça dans d'autres langues aussi, mais généralement vous devez recourir à (ab) utiliser des choses comme des pointeurs, des références ou Typecasts, qui ouvre des trous pour des erreurs de programmation, et c'est juste nature laide.
Comme vous êtes du monde Java, la réponse évidente serait que c'est génial de ne pas être obligé d'écrire tout ce que vous êtes obligé d'écrire, juste pour garder le système de type de Java heureux.
Bien sûr, il existe d'autres langages enregistrés de type statique qui ne vous oblige pas à écrire tout ce que Java vous oblige à écrire.
Même c # fait l'inférence de type pour les variables de la méthode locale!
Et il existe d'autres langages enregistrés de type statique qui fournissent plus de vérification des erreurs temporelles de compilation que Java fournit.
(les réponses moins évidentes pour - ce qui est si génial de taper dynamique en python? - Il faut probablement plus de compréhension de Python à comprendre.)
Il ne s'agit pas seulement d'une inférence de type (qui peut également être saisi de manière statique) mais le type est connu jusqu'au moment de l'exécution. Ie Bonjour (auto, objet): .... Le type d'objet est connu jusqu'à l'exécution, en python.
@Ocarryz >> Le fait que le type est connu jusqu'à l'exécution << voulez-vous dire non plus qu'au moment de l'exécution?
@Ocarryz >> qui peut aussi être statiquement typée << C'est pourquoi j'ai écrit "Il existe d'autres langues de type statiquement vérifiées qui ne vous forcent pas à écrire tout ce que Java vous oblige à écrire" et "même C # fait la conclusion pour Variables de la méthode locale! "
Aimez-vous dans Python?
C'est partie de Python. Aimer dans python est stupide.
Avez-vous un exemple où il a aidé dans un grand projet?
Oui. Chaque jour, je me réjouis que je peux apporter des changements et - à cause de la frappe de canard - ils sont raisonnablement localisés, passent tous les tests de l'unité, transmettent tous les tests d'intégration et rien n'est perturbé ailleurs. < / p>
S'il s'agissait de Java, les modifications nécessiteraient une refactorisation sans fin pour tirer des interfaces hors des classes afin que je puisse introduire des variations toujours autorisées sous la vérification du type statique de Java.
n'est-ce pas une erreur un peu sujette?
Pas plus que la typographie statique n'est. Un test d'unité simple confirme que les objets sont conformes aux caractéristiques attendues.
Il est facile d'écrire une classe en Java que (a) passe des chèques de compilation et (b) s'écrase horriblement au moment de l'exécution. Les moulages sont un bon moyen de le faire. Omet de rencontrer les classes l'intention est une chose commune - une classe peut compiler mais toujours pas travail . .
Le type de type statique est indécitable dans le cas général. Cela signifie qu'il existe des programmes qui sont statistiques de type-coffre-fort mais pour lesquels le checker de type ne peut pas prouver em> ils sont stables de type-sécurité et que le vérificateur de type doit donc rejeter ces programmes. En d'autres termes: il existe des programmes de type-sécurité que le checker de type ne vous permettra pas d'écrire. Ou encore plus succinctement: la typographie statique vous empêche d'écrire certains programmes. P> Ceci s'applique à tous les caractères statiques em> en général, pas seulement pour Java. P> Quant à Java spécifiquement: il a un système de type plutôt merdique. Son système de type n'est pas suffisamment expressif pour exprimer même les propriétés simples em>. Par exemple: où dans le type de Un autre problème avec Java est que son système de type a des trous si gros que vous pouvez conduire un camion à travers: P> statique vide java.util.arrays.sort (objet [] a) code> dit-il réellement que le résultat doit être, vous savez, triés? Ou que les éléments de matrice doivent être partiellement commandés? P> fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
+1 J'ai vraiment besoin de continuer à apprendre Haskell
+1, puis-je suggérer d'aller facilement sur le thème global anti-Java (ou même anti-basique) de votre message? Il présente des arguments convaincants, mais en utilisant des expressions telles que «Crappy», des trous si gros que vous puissiez conduire un camion à travers », ce n'est tout simplement pas un bon langage de programmation» ne fait pas vraiment quelque chose à une réponse déjà bonne.
En tant que programmeur Python, je n'écrirais pas une fonction FIB récursive - elle est massivement inefficace, à moins que vous niez les résultats. En Python, il est plus simple et plus efficace de l'écrire comme une boucle.
+1 ne prétend pas que nous puissions être typés statiquement sans être fortement typé
>> plutôt que Java n'est tout simplement pas un bon langage de programmation, tandis que Python est << pour une définition de "bonne". Pour une autre définition de «bon» comme $$$ faite par programmeurs et sociétés et ... L'évaluation pourrait être différente.
@gnibbler: hein? Il est parfaitement possible pour une langue d'être statiquement mais faiblement typée - C est généralement l'exemple canonique d'une telle langue.
@Daniel, bien sûr, tels que «statiquement dactylographiés», sont ouverts à l'interprétation, mais je ne considérerais pas que C soit vraiment typé de manière statique car il est possible de contourner le système de type à l'aide de CASTS / UNIONS, etc.
@Gouy, malheureusement bon! = Beaucoup de $$$. En fait, assez souvent, le contraire est le cas
Si je comprends bien, le terme de cette différence entre Java d'un côté et Haskell ou Python de l'autre est une dactylographie explicite contre la typage implicite. Le typing dynamique est encore plus flexible, mais la typographie statique implicite est un compromis parfaitement bon. (Je suis une tête python qui tire parti de taper dynamique régulièrement, mais je pense toujours que la plus grande faille dans des langues comme Java et C / C ++ est l'encombrement distrayant de dactylographie explicite)
@ssSokolow: Oui, c'est vrai. Notez que C # 3 et C ++ 0x effectuent en réalité la saisie implicite via une inférence de type, bien que dans les deux cas, vous devez explicitement leur dire d'utiliser implicite taper via le < Code> var et auto mots-clés, respectivement.
@Gouy: Les concepteurs de langue Java dépense beaucoup d'argent pour la publicité de la langue comme langue de génération de la prochaine utilisation, et ils ont oublié d'épargner certains pour la conception de la langue.
@Lie Ryan: Yup. Après tout, Sun a passé autant d'argent sur PR, ils ont fait faillite. À deux reprises. C'est vraiment triste, comparant le talent des personnes qui travaillaient sur Java avec le résultat: Guy L. Steele, Jr. (Créateur de forteress, co-créateur de schéma, rédacteur en chef de la spécification LISP commune, et General Lisp Genius), Phil Wadler (co-créateur de Haskell, créateur de liens, et l'homme qui a apporté la théorie de la catégorie et monads dans le monde de la programmation), Martin Odersky (créateur de Scala, Pizza et entonnoir), Gilad Bracha (créateur de Newspeak, StrongTalk et General Smalltalk génie) nommer juste quelques-uns quelques-uns.
-1 Vous commencez avec un principe intéressant qui aurait pu avoir du poids avec moi, que "il existe des programmes de sécurité [utiles] que le checker de type ne vous permettra pas d'écrire." Mais puis abandonnez-le et transparez-vous dans des arguments boiteux que la frappe statique ne attrape pas toutes les erreurs ou qu'il nécessite plus de texte.
Je soupçonne que la grande majorité des programmes Java non triviaux ont une dynamisme de taper.
Chaque fois en Java que vous faites une distribution de l'objet à un type explicite que vous faites de type dynamique de contrôle - cela inclut chaque utilisation d'une classe de collection avant génériques ont été introduits en 1,5. En fait, Java Generics peut toujours reporter une vérification de type jusqu'à l'exécution.
Chaque fois que vous utilisez une réflexion Java, vous faites une vérification de type dynamique. Cela comprend la cartographie d'un nom de classe ou méthode dans un fichier texte à une vraie classe ou méthode - par exemple Chaque fois que vous utilisez un fichier de configuration XML printemps.
Est-ce que cela fait des programmes Java fragiles et une erreur d'erreur? Les programmeurs Java passent-ils une partie importante de leur temps à suivre et à résoudre les problèmes de dactylographie dynamique incorrecte? Probablement pas - et non plus les programmeurs Python.
Certains des avantages de la dactylographie dynamique:
Beaucoup de modèles (par exemple de GOF) sont inutiles ou peuvent être mis en œuvre avec moins d'efforts dans des langages dynamiques dactylographiés avec une saveur fonctionnelle. En fait, beaucoup de motifs sont "intégrés" dans Python, donc si vous écrivez un code court et "Pythonic", vous obtiendrez tous les avantages gratuitement. Vous n'avez pas besoin d'itérateur, d'observateur, de stratégie, de méthode d'usine, d'usine abstraite et d'un groupe d'autres motifs communs dans Java ou C ++.
Cela signifie moins de code à écrire et (beaucoup plus important) moins de code à lire, à comprendre et à soutenir. Je pense que c'est le principal avantage des langues comme Python. Et à mon avis, cela dépasse grandement l'absence de typage statique. Les erreurs liées au type ne sont pas souvent en code Python et sont faciles à pêcher avec des tests fonctionnels simples (et de tels tests sont plus faciles à écrire dans Python que dans Java à coup sûr).
Je pense que cela est un peu trompeur: les motifs itérateurs et observateurs sont toujours utilisés, les usines et les stratégies sont simplement des références de fonction et la méthode d'usine est __ nouveau __ .
Le typage statique est une optimisation prématurée. (Pas mon opinion la plus universellement convenue sur la programmation.)
@Etam: voir, subjectif et argumentatif (sur le commentaire de David)
Question chargée: "Comment traiter avec Python Static Typing?" Argumentatif: "Qu'est-ce qui est si génial [...] en plus des erreurs manquantes tout en compilant le code" Question inutile: "Aimez-vous cela à Python?"
La typing dynamique est l'une des principales raisons pour lesquelles j'ai changé de python de Java. Pourquoi? Apprenez Python pour l'apprécier pleinement. Ce n'est pas quelque chose qui peut être facilement expliqué à quelqu'un avec la mentalité Java.
Typage dynamique: lorsque vous attrapez des bugs au moment de la compilation n'est pas assez excitant.
@WILL: Évidemment, mon programme est gratuit, le compilateur ne trouve aucune erreur.