Aeris a écrit 444 commentaires

Je pense que ces objectifs n'ont rien à voir avec le fait d'utiliser un langage statique ou dynamique. Je pense même que que l'on produit assez souvent des programmes en c++ peu stables malgré son typage statique.

Oui, on peut faire du crade avec tout, certains langages étant juste plus enclins que d'autres à faire du code dégueu.

J'ai un plus gros désaccord pour le refactoring: en effet le dynamique peut poser problème lorsque l'on renomme des méthodes ou ptit trucs du genre, par contre en cas de gros refactoring (modif d'archi), il me semble que le dynamique est là bien supérieur.

Pas convaincu.
Un refacto d'archi risque typiquement de casser l'intégralité de ton code Python, cause qu'elle laisse une chiée de truc pas refactorisé car pas détecté par l'IDE car pas de typage statique donc incapable de détecter qui est impacté.
Pour l'avoir vécu sur pas mal de projets assez conséquent en python, ça se finit généralement en séance de

while not working:
    run
    debug
    correct

Au moins en Java, la refacto corrigera déjà énormément plus de choses via la puissance du refactoring des IDE cause aide du compilo et analyse statique du code, et le restant pétera directement en rouge cramoisi tant que ça sera faux.

Dans tous les cas, tu ne peux pas faire du python comme tu ferais du c++. C'est pas la faute du python ou du typage dynamique, c'est la faute au dev qui veut du typage statique dans python. Les paradigmes sont différents, faut coder différemment.

J'ai jamais dis le contraire =)
C'est même une de mes principales conclusions : le code tient en plusieurs fichiers et/ou dépasser les 200 lignes ⇒ adios le dynamique, vive le statique ! En tout cas d'un point de vue stabilité / maintenance / évolutivité.

Du coup tu lis le code des bibliothèque que tu utilise pour savoir comment t'en servir ?

En Python, clairement tu y es justement obligé.
Va faire du X509 uniquement avec la doc de la lib du même nom en Python (http://packages.python.org/pyOpenSSL/openssl-x509.html), c'est juste impossible.
Tu es obligé d'aller voir ce qu'ils attendent comme type de paramètre.
set_subject(subject): Set the subject of the certificate to subject. ne te dit pas que subject doit être de type X509Name si tu ne vas pas voir dans le code…

En Java, abstract Principal getSubjectDN(): Gets the subject (subject distinguished name) value from the certificate., plus besoin d'aller voir le code pour savoir ce qu'on manipule. Et même sans la doc, ton IDE te donnera aussi le prototype du bidule (ce qui au final est équivalent, vu la pauvreté de la doc, totalement inutile à ce niveau).

Non mais tu carricatures pour Python et me fait dire ce que je n'ai pas dit. C'est quand même un langage qui ne manque pas de ressources documentaires …

J'ai jamais dis le contraire, mais elle n'est pas complète, blindée d'erreurs, ne comporte pas de doc sur les API internes, etc.
Elle est donc globalement inutile, étant donné que je devrais quand même faire tout le taff d'aller réellement voir comment c'est fait dedans pour que ça fonctionne.
Et que je passe mon temps à lancer mon appli et à la tester à 1000% pour être sûr qu'une runtime exception ne se pointera pas le jour de la recette.

Je ne peux avoir confiance en une doc si je n'ai pas la preuve qu'elle est correcte.
Comme personne n'est capable de me donner cette preuve pour aucune des docs existantes actuelles, alors toute documentation est inutile (doc type doxygen/javadoc j'entend).

Encore une fois, non et non … ça rejoint ce que je te disais plus haut sur la gestion de ton travail d'équipe.

On peut continuer dans les postulats si tu veux :
Postulat n°4 : on a toujours une brebis galeuse dans l'équipe
Le but du jeu est de la détecter immédiatement, pas le jour de la recette.
Et le typage statique est assez efficace pour ça, ça l'obligera même à venir te poser des questions parce que le compilo gueule plutôt que de faire un truc à l'arrache qui semble plus ou moins tomber en marche subitement par moment.

Pour la doc, y'a pas à argumenter plus, c'est une vision différente que l'on a toi et moi. Ton point de confiance est dans le compilateur, moi dans les docs de qualités (et elle n'est pas aveugle ;) )

Même la doc python ou java est foireuse à souhaits, ou en tout cas ne peut pas être considérée comme fiable. Alors celles de nos projets… Je t'ai dis, j'attend toujours une doc en qui je puisse avoir confiance…

documenter son architecture et de faire une couche intermédiaire qui se chargeait de faire les opérations en proposant une interface sécurisée et sa propre doc. Et bien depuis aucun souci sur la partie interface : de la doc de qualité + des entrées sécurisées, ça permet de fonctionner de manière fiable avec une potentielle passoire derrière.

Pour les docs d'archi et de conception, je suis d'accord avec toi que c'est possible et même obligatoire. Mais pour le détail nécessaire au développeur lambda, les docs ne sont généralement pas suffisantes…
Prend l'exemple de ton API espagnole. OK, aujourd'hui ça fonctionne. Mais demain ? Si tu dois faire évoluer la partie moisie, c'est juste mort, avec ou sans doc.

C'est plus affreux à ce niveau… C'est carrément du suicide collectif !
Et niveau maintenabilité… hum… No comment =)

Si mon utilisateur final est un développeur qui fait du code merdique, ça ne me regarde pas.

Si c'est quelqu'un de ton équipe, si.
Et t'es bien content que l'intégration continue pète gentillement sur chacun de ses commits plutôt que de te rendre compte pendant une recette qui a codé grave de la daube :þ

Quelqu'un me remplace, il hérite d'une magnifique doc, de plein de schémas, qui auront pris plein de temps à faire mais assureront la pérennité des projets au delà de ma petite personne.

Des docs de conception ou d'architecture, certes, ça se fait et ça se trouve.
Mais trouve-moi une seule doc type javadoc ou doxygen où tu peux lui faire aveuglément confiance… C'est généralement blindé d'erreur de copiés/collés, de trucs refactorisés mais sans mise-à-jour de la doc, voire même pas documenté du tout.

Et en plus, avoir une doc (par exemple en python) capable d'avoir un niveau de détail suffisamment fin pour éviter les erreurs qu'auraient détectées un compilateur, c'est juste inenvisageable.
Si tu prends le add(duck) précédent, soit tu le documentes avec un simple duck : canard à ajouter, doit être de type Duck ou dérivé et autant avoir un joli compilateur pour faire ce travail de vérif en plus de perdre tout intérêt au duck-typing, soit tu le documentes avec un gros duck : canard à ajouter, doit répondre à la méthode fly, quack, swim et posséder les attributs feathers, qui, en plus de ne sûrement pas être exaustif, sera une simple plaie ambulante à maintenir…

J'aimerai vraiment pas bosser dans tes conditions…
Trouve-moi une seule doc qui soit disponible et sans erreur (avec la preuve qui va bien, hein)…
Même la doc officielle python est truffée d'erreurs en tout genre.

Postulat n°1 : ton utilisateur est une buse…
Postulat n°2 : demain, t'es plus là…
Postulat n°3 : la doc n'est jamais à jour, cohérente ni même disponible…

Étant donné qu'un utilisateur peut être utilisateur final et/ou développeur, plus le compilo te détectera des erreurs a priori, et non pas uniquement a posteriori au runtime, mieux tu te portes.
Idem, plus il est capable de t'aider (via l'IDE) mieux tu t'en porteras.

Bon, j'ai tapé trop vite au clavier, il faut bien sûr inverser correct et incorrect :þ

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 !