Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Et bien moi, étant incapable de me rappeler par coeur des noms de fonctions de mes objets, j'apprécie une bonne autocomplétion. Sur un gros projet, un IDE c'est quand même un gain certain à mon sens mais bon ce n'était pas mon point.
Je code et maintiens des projets en c++, java, c# et PHP. Je suis surtout développeur d'API avant tout.
Et oui, pour moi ne pas faire attention au type de ses variables et balancer des entiers ou des floats à des fonctions pensées pour recevoir des strings c'est juste inacceptable. Et manque de pot, PHP accepte tout ceci très gentiment, ce qui est une bonne grosse source d'autogoals. Qui plus est, c'est suffisamment mal fichu pour que ça fonctionne par bol en exécution jusqu'au jour où...
Pour moi et au risque de paraître sec, si on ne fait pas attention au typage c'est qu'on est très imprudent, très mal habitué ou alors qu'on s'est trompé de métier.
Infinity - To The Top, shoot'em up développé en Haxe / OpenFL pour FLASH et Android, piou piou rythmé dans l'espace
La je confirme le bazar , le PHP Group a fait pas mal de nettoyage à ce sujet lors du passage à PHP 5.3, ce qui a d'ailleurs valu des rapports de bugs assez amusants comme celui-ci :
http://bugs.php.net/bug.php?id=50696
Ok en JSF tu redémarre combien de fois Tomcat dans la journée ?
Si tu savais le mal que je pense de JSF.
Pour moi ce framework était si mauvais au départ que je ne voulais pas de version 1.2, j'espérai juste qu'il aurait la mort atroce et douloureuse qu'il méritait.
Mes comparaisons étaient d'un point de vue langage principalement.
Juste mais je suis toujours rassuré quand je fais mon contrôle-espace et que j'ai le prototype ainsi que ma petite documentation des paramètres qui apparaissent. C'est un point sur lequel je suis un peu faible, la mémoire .Envoyé par Paul TOTH
Salut
Bla bla bla Typage fort statique vs typage faible dynamique, éternel débat.
Alors,
* Tes fonctions, méthodes variables PHP tu documenteras et complétion tu auras (Type Hinting tu utiliseras ).
* Ton application PHP tu testeras et problèmes tu n'aura pas (ou presque )
De toutes façons des tests unitaires et d'intégration sont quasi obligatoire lors de développement pro.
Ensuite , si nécessaire, ajout de tests de performances (je suis partisan du "tu codes et optimises que si nécessaire" (bon, bien sûr, ça n'autorise pas à faire le sagouin, hein !).
En java lorsque tu utilises une librairie en 1.4, toutes les méthodes retournant des collections retournent des collections d'objet. Obligeant des cast incessant (et surtout inutile au vu de la javadoc de ladite méthode). Bon, on peut, également ajouter un petit instanceof (pour se soucier des types comme vu plus haut) mais, pour ma part, je préfère que mon code pète plutôt qu'il gère un cas non prévu (sachant que la remontée d'erreur est à réaliser aussi bien en PHP et en Java... ce qui est bien c'est que ces deux langages bénéficient du mécanisme des exceptions ^^)
Quant aux types paramétrés dont le paramètre est perdu au runtime c'est assez frustrant de passer un paramètre à une classe mais également devoir passer un paramètre de type Class au constructeur pour ne pas perdre le paramètre à l'exécution.
Yann
Le typage statique permet d'avoir une meilleure sureté de code, il y a déjà un contrôle non négligeable du compilateur, soit il n'y a moins de risque de mettre des choux dans des souliers troués (bien que certains y arrivent quand même lol).
Le typage dynamique niveau sureté c'est moins fiable par contre cela à d'autres avantages notamment quand il s'agit de s'interfacer avec des composants pas trop nette au niveau des signatures. Du coup plus besoin de chercher quel type est celui qui sera le plus compatible le système se débrouille
D'ailleurs c'est une nouveauté dans je ne suis plus quel version du langage C#(qui est très récent et populaire), je pense notamment au type anonyme et à la sorte de mot clef 'dynamics'
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Et aussi on peut dire que ça fait quand même bientôt plus de 5 ans que j2se 1.4 est dépassé. Là je sais que tu vas répondre "oui mais y'a des librairies qui n'ont pas migrés" et je te dirais "oui mais c'est franchement rare de se retrouver coincé sans avoir le choix".
En gros tu peux ajouter à tes commandements
"Avec ton temps tu vivras"
Oui, on peut s'en sortir dans un monde idéal où on a le temps de mettre en place tous les palliatifs à ce qu'on n'a pas.
Mais soyons réaliste. Dans la vrai vie, on a des délais de livraison à tenir.
Lorsqu'on est loin de la deadline, on a plein de grands principes, on va faire ci, on va faire ça, on va respecter toutes les règles de l'art... Bref on perds du temps pour se faire plaisir.
Et plus la deadline approche, et plus ça devient : "peut importe ce qu'on fait, ce qui compte c'est que ça marche" :
- En générale, la doc est sacrifiée en premier pour récupérer du temps pour que ça marche.
- Puis on supprime les tests unitaires, (quoique beaucoup n'en font pas de toutes façon).
- Ensuite on supprime les tests d'intégrations.
- On finit par se contenter de quelques tests fonctionnels superficiels qui ne couvriront même pas toutes les fonctions essentielles.
- Et parfois, on livre même en sachant que ça ne marche pas
Si on ajoute à celà qu'en informatique, les retards font parti des règles de l'art, et que lorsque on estime une charge, on peut être sûr qu'on l'a sous-estimée...
J'ai qu'en même tendance à dire que pour avoir une application fiable malgré tout, le meilleur moyen de ne pas avoir de bugs c'est de commencer par ne pas en faire
Et de ce côté, le typage statique est qu'en même très utile pour empêcher d'écrire n'importe quoi à la source. On détecte immédiatement bon nombre d'erreurs de conception au moment même où on écrit le code (plutôt qu'au moment des tests).
C'est con à dire, mais si on se retrouve à additionner des choux et des carottes, c'est que la formule est fausse. Donc que toute l'analyse est fausse.
Il est qu'en même dommage de devoir attendre les tests pour ce rendre compte que l'approche du problème était erronnée !
Moi je trouve que les langages sans vérification des types à la compil ne font pas gagner du temps et ne simplifient rien. Ce sont des pièges à débutant !
Je connais pas mal de développeurs PHP a qui je n'ai jamais réussir à faire comprendre la différence entre une date et son format d'affichage (idem pour les nombres et le séparateur décimal).
De ma maigre expérience, j'ai appris que les tests ne sont pas une perte de temps ! Au mieux, ne pas les faire, permet de vendre plein de maintenance au client
De toutes façons n'ayant pas utilisé de langages faiblement typés sur un projet pro, je peux difficilement me prononcer. Au mieux, je peux dire que j'ai rencontré beaucoup de ClassCastException le long de mes devs java
Le problème du typage dans PHP c'est que ça peut fonctionner alors que ça ne devrait pas.
Enfin, je m'emploie le plus possible à respecter cette phrase simple : "nomme bien tes variables et documente bien tes APIs"
Je pense que c'est surtout ça qui permet d'éviter les erreurs.
Sinon, je suis d'accord avec toi même si je ne suis pas aussi catégorique au niveau du typage. Le typage faible demande plus de rigueur. C'est clair qu'il ne vaut mieux pas coder 12h dans la journée au risque de faire n'importe quoi ! Et, ce seul argument, ne disqualifie pas le langage PHP (en plus, plus ça va, plus j'ai l'impression qui se dirige vers un typage fort (il suffit de voir le TypeHinting).
Yann
Il me semble qu'il n'y a pas de consensus la dessus. Qu'est-ce que tu entends par typage faible et fort ?
Pour ma part, a contrario de fort, faible veut dire qu'il n'y a pas une importance qui est accordée au typage dans le langage (moins de typage = moins de sureté) comme c'est le cas de Php (même si php était compilé)
En général, de ce que je connais, les langages à typage dynamique n'accorde pas beaucoup d'importance au type sauf exception comme Python par exemple ?
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Au vu de tes remarques suivantes. Grosso-modo la même chose que toi.
Pour faire simple, en typage fort, il y a une vérification poussé de la cohérence des types (on ne peut pas ajouter des choux et des carottes, on ne compare pas une chaîne sde caractère et un nombre, etc.). Faible c'est l'opposé.
Alors que la caractéristique statique/dynamique désigne plus le moment où est déterminé le type et la capacité d'une variable à "changer" de type (ce qui peut influencer sur le côté fort/faible mais pas nécessairement : le type pouvant être fixé uniquement à l'initialisation de la variable mais fortement contraint pour toutes les autres opérations avec cette variable).
C'est exactement ça.
Et effectivement le typage de PHP est plutôt faible.
Je ne prétendrais pas connaître assez tous les langages existant pour être capable de dégager une tendance générale.
Mais dans les "exceptions" langages à typage dynamique relativement fort, je regardais aussi (et surtout) du côté des langages fonctionnels.
Je mettrais tout de même un bémol à ce type de liste. Autant il est globalement assez simple de séparer les langages dans deux catégories typage statique/typage dynamique, autant les catégoriser en typage faible/fort me semble plus difficile.
En effet la notion typage faible/fort n'est pas une notion avec deux comportements bien définis mais est plutôt représentée par toute une palette de cas possibles. La répartition de toute les cas imaginables en seulement deux cas va dépendre d'où tu places le seuil ce qui fort subjectif.
De mon point de vu, c'est plus une catégorisation relative qu'absolue.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager