Aeris a écrit 435 commentaires

Soit le cas est correct, et il doit péter une erreur/exception
Soit il est incorrect, et il doit conduire à une exécution correcte du code, et surtout ne pas être source d'erreur plus loin dans le code (cas du canard à la con qui passe le « add » et ira péter les plombes plus loin).

Les cas aux limites seront justement testés unitairement.

def date_de_naissance(int, int, int)

Soit tu sais ce que tu fais : new DateTime(2012, 12, 25, 0, 0)
Soit tu veux vraiment être sûr : new DateTime().withYear(2012).withMonthOfYear(12).withDayOfMonth(25).withTimeAtStartOfDay()
Mais ça serait vraiment aller chercher des pous…

Ce code est justement le genre de code à être tester et unit-tester, qui doit péter des exceptions si les valeurs sont incorrectes.
Et ceci n'a rien à voir avec du code statique ou dynamique.
Python et Java ont tous deux des manières de faire de rendre ce code robuste, via une factory par exemple. On est plus dans le domaine d'une bonne conception/architecture que dans le choix du langage proprement dit.

J'ai aussi du mal à me projeter dans un Python statique.
Mais quand je vois le temps que peut me faire gagner un langage statique et un IDE bien configurer via sa complétion automatique ou ses outils de refactorisation, c'est juste monstrueux.
Et après, le temps de chasse aux bugs, aux diverses erreurs de typo à la con, etc… Le rapport de Evan Farrer est assez éloquant là-dessus aussi.

Sur un code « v1.0 », je pense que le seul gain sera celui nécessaire à la recherche des infos pour savoir quoi appeler, avec quoi en paramètre et pour quel retour.
Pas folichon comme gain je pense, mais quand même (à vue de pif ~10% du temps).
Dès une « v2.0 » ou du dev à plusieurs, au revoir Python !!!

foo(int, int) est in-détectable non plus

Détectable, car justement, l'utilisateur n'aura aucun moyen de me balancer un « nonInt » en paramètre. Ou s'il le fait, le compilo le rappelera à l'ordre.

open(string)

Détectable aussi, via test unitaire.
Si tu lui passes un nom d'oiseau, typiquement ça doit te balancer un « No such file or directory »

On pourrait multiplier les exemples avec tout ce qui touche à l'interface utilisateur

Dans « utilisateur », il y a « utilisateur final », pour qui effectivement, tu dois survérifier tout ce qu'il est susceptible de te balancer, mais aussi « autre développeur » (aussi bien de ta propre équipe, mais peut-être aussi d'une autre équipe qui utilise ton API).

Le cas du canard à la con, c'est typiquement le cas d'un co-dev Python qui a fait son propre objet en mimant ce qu'il a pu déjà voir ailleurs, mais en omettant tout ce qui était du domaine des API internes, pourtant nécessaires au bon fonctionnement de l'application.
Dans le code de mon paste, c'est typiquement dès les 1ères lignes que le développeur de l'API aurait du refuser le canard boiteux (« f.addDuck(aFakeDuckWithoutFeathers) »). Sauf que pour faire ça, il aurait fallu avoir connaissance de toutes les méthodes que l'application est potentiellement en droit d'appeler sur l'objet en question. Littéralement impossible… sauf à réimplémenter du typage statique !

Un code conçu en TDD est refactorisable les doigts dans le nez, quelque soit le type de typage (ah ah) utilisé.

Je gros +1 là-dessus.
Mais faire de la TDD, c'est presque en contradiction avec le typage dynamique, ou en tout cas tout bonnement inutile.
En effet, tes tests U ne testeront que les cas utilisant les types que TOI tu as bien voulu tester.
Si un mec te balance un truc qui braille comme un canard, vol comme un canard, nage comme un canard, mais qui n'est pas un canard, tous tes tests U seront potentiellement verts, mais avec un plantage au runtime, sauf à avoir 100% de couverture de code.

Typiquement, le truc indétectable : http://pastebin.com/NYStSPRe
Tes tests U ne testeront jamais avec autre chose que du canard, et donc ne détecterons pas le cas où l'utilisateur (entendre aussi un autre développeur) va réellement merder.

C'est sûr qu'il faut un bon IDE aussi :þ

Mais, s'il n'y a pas de doc, ce n'est pas vraiment utilisable vu qu'on ne connais pas les conditions sur les paramètres (peut-on mettre un null, une liste vide…)
Ça peut être un problème certes. Mais idem en dynamique et en statique à ce niveau.
Et pour les contenus que tu cites :
* « null », cay mal http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
* Pourquoi une liste vide poserait problème ???

Avant même de parler de bugs ou de tests unitaires, on a déjà de très gros problèmes de productivité avec le typage dynamique.

De par sa nature même, un langage à typage dynamique interdit toute complétion automatique ou assistance à la refactorisation digne de ce nom. Cela ralenti énormément le développement.

Idem, je ne compte plus le nombre de fois où je me pose la question de ce qu'attend comme paramètre une fonction python ou ce qu'elle est sensée me retourner. Quand ce n'est pas littéralement un gros « data » tout moche, aussi bien en entrée qu'en sortie…
Développer en Python ou en Ruby, c'est passer plus de temps à regarder ce qu'a codé le voisin pour savoir comment utiliser son API que de coder son propre code.
(Et qu'on ne me parle pas de Javadoc, Doxygen, Sphinx, ou autre, je n'ai JAMAIS vu une documentation complète et correcte, et encore moins sur des API internes…)
On est à des années-lumières de la productivité d'un langage à typage statique type Java, où l'IDE va directement sortir les bons types de paramètres de la fonction, voire même y placer les variables disponibles qui correspondent (merci Eclipse !).

Enfin, la refactorisation de code est juste une hérésie en dynamiquement typé.
Comme l'IDE ne peut être d'aucune sorte d'utilité, réécrire une méthode, renommer un paramètre ou introduire du polymorphisme ou une super-classe, et on a la quasi-certitude d'une énorme régression qu'on ne détectera qu'à la prochaine exécution (loi de Murphy aidant, la probabilité que cela arrive en production avoisine les 100%…).

L'étude réalisée par Evan Farrer est intéressante, mais arrive trop tard dans la chaîne de développement.
Surtout qu'apparement, vu la popularité des librairies analysées, les bugs non détectés ne devaient pas être si méchants et fréquents que ça.
Avant de penser à corriger du bug ou à implémenter du test unitaire (quoi que TDD, tout ça tout ça, mais je vous laisse imaginer le calvaire en Python ou Ruby…), il faut déjà l'avoir écrit, le code =)

Dernièrement je suis passé par les mêmes étapes que toi =)

Mon petit nouveau est un Clévo W251HUQ, plus cher que les Clévo dispos chez LDLC mais configurable à l'envie.
Support Linux excellent, y compris sur les trucs vraiment très chiants sur le sujet d'habitude (wifi, video, webcam…).
Très très très content de mon acquisition.

Pour Dell, oublie complètement, c'est hors de portée du particulier. Les portables sans OS sont uniquement réservés aux (très) grands comptes, et pour Monsieur Michu (même moins Michu que la moyenne), ça sera la croix et la bannière pour obtenir le moindre remboursement, voire même pire ils sont prêts à te facturer la suppression du Windows (à ma dernière tentative, 300€…) !

MySQL est aussi totalement incapable de gérer les schémas.

CREATE SCHEMA foo passe sans soucis… mais créé une base de données foo au lieu d'un schéma.
En effet d'après la doc : CREATE SCHEMA is a synonym for CREATE DATABASE !

Il est donc impossible d'avoir 2 schémas portant le même nom dans 2 bases de données différentes… Ce qui enlève tout intérêt à leur utilisation !