Ca va souvent de paire avec la programmation par copier/coller qui est une hérésie quand on utilise un langage objet (avec un autre langage aussi d'ailleurs)
Pour les tests, ça me parait évident, bien que les test unitaires n'ont pas l'air d'être évidents pour tout le monde.
De la même manière utiliser un outils de suivi de bug me semble tellement indispensable que je m'aperçoit que je ne l'ai même pas mentionné.
Pour la doc, c'est important, mais il faut éviter de faire de la doc pour faire de la doc.
Moins il y en a et mieux c'est (il faut la maintenir à jour), mais il y a un minimum à fournir
.
Pour la forme, le wiki c'est pas mal (mieux qu'un tas de fichiers bien enfouis sur un lecteur partagé en tout cas)
Mais c'est pas optimal non plus, au bout d'un moment, les gens oublient de mettre à jour le wiki, et de plus les non-informaticiens ne sont pas toujours à l'aise avec.
Si on va par la, la plupart des langage objets sont des descendants de Smalltalk. .
Ca me semble un peu léger comme points communs.
Pour ce qui est de la programmation par contrat, j'ai encore des doute (mais j'ai peut-être pas encore tout compris).
Nul doute sur le fait que celà puisse éviter des bugs. Sur la théorie, je suis tout à fait d'accord.
Par contre là ou j'ai des problèmes, c'est qu'au niveau d'une application réelle, bien souvent une (post|pre)condition, ou un invariant non vérifié doit être gérer par l'application en tant qu'"erreur métier", et pas planter l'appli sur une rupture de contrat.
Cela implique de coder deux fois les choses: une fois pour le contrat, et une fois pour gérer l'erreur métier, moi je trouve pas ça terrible.
Cela est peut-être utile pour la phase de debug, mais je n'ai pas encore trouver une bonne manière d'organiser tout ça, et en plus ça complexifie encore un peu le développement: certain dev peuvent se sentir protégé car ils ont bien codé leur contrats, mais livre-t-on le code avec ou sans les contrats.
En fait un contrat, utilisé hors de la programmation d'un composant générique, réutilisable (ce qui arrive peu souvent en fait), ça me parrait être un voeux pieux, un peu comme quand je tombe sur un commentaire qui dit: "ça ne devrait pas arrivé" (donc on ne fait rien). L'expérience montre que les utilisateur ont de l'imagination.
Il est vrai que je ne connais pas très bien Eiffel, mais de ce que j'en sais, ça n'a pas grand chose à voir avec Smalltalk, mis à part que c'est un langage objet.
Perso je préfère le for, pour la portée de la variable d'indice.
En utilisant que la forme la plus simple.
évidemment le must, c'est une collection avec un itérateur.
Le problème avec le while, c'est qu'il y a toujours un zozo pour t'insérer un truc entre l'init, et la boucle. Et après le premier, un autre ce dit pourquoi pas moi...
En plus maintenant, en Java au moins, la boucle for est beaucoup plus jolie que le while.
J'aime bien que mes variable soient déclarée au plus près de l'endroit ou elle sont utilisée.
Python est sensiblement plus lent que Java.
Mais Python favorise l'utilisation de lib natives,
par exemple pour le calcul numérique, ce qui équilibre les choses.
Cependant de mon expérience cette lenteur relative ne devient que rarement pénalisante.
Pour moi, sur un algo d'apprentissage numérique, la phase d'apprentissage était vraiment super lente. Mais je l'avait un peu fait exprès, j'avoue, en implémentant naïvement l'algo entièrement en Python, pour voir le gain et la facilité d'utiliser Numeric plus tard.
La "migration" vers Numeric a été super rapide, et le gain plutôt impressionnant.
Le problème du cast, c'est que la vérification se fait à l'exécution, ce qui je trouve va un peu à l'encontre de l'esprit typage fort de java (typage correct, mais plantage à l'execution)
Mais en même temps je ne vois pas trop une autre façon de faire, sans impliquer les generics, ou l'inférence de types.
Pour les NullPointerException, à part utiliser un langage fonctionnel pur, ou langage qui permette de declarer les variable "non nulles", je ne vois pas de solutions.
Pour le cast, c'était une manière de gérer le polymorphisme sns les generics.
Maintenant les generics permettent de faire propre pour les collection, mais apportent d'autres soucis (lisibilité, complexité, etc.)
Pour ce qui est de la portabilité binaire, franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows, pour Java, la pub "Run everywhere" s'est rapidement transformé en "Test everywhere".
En tout cas pour moi, le "run everywhere " de Java s'est toujours vérifié, et je n'ai jamais été embêté par des problèmes de portabilité. C'est un des atouts majeurs de Java. J'ai ouï dire qu'il n'en était pas de même dans l'embarqué, mais je ne l'ai pas expérimenté moi-même.
Pour ce qui est de la normalisation, je ne suis pas sur de ce que ça apporte, Ruby et Python vivent bien sans être normalisé..
Je ne sais pas si la normalisation peu y faire quelque chose,
mais pour Ruby, le fait qu'on ai pas de vrai visibilité sur l'avenir du langage me parait un gros point faible. je trouve la doc assez faible aussi, mais je pense que c'est l'esprit de la communauté.
Pour Python, Guido gère très bien l'évolution de son langage, la normalisation n'apporterait sûrement pas grand chose. La doc est excellente.
Donc oui, il y a moyen de faire correctement les choses, sans normaliser.
Et sinon c'est sympa de signaler le code sale, tes successeurs sur le code te remercieront pour ça ;)
Au moins quand c'est pas signalé, je pré-suppose l'ignorance, et ça m'incite à l'indulgence. Dans ton cas, c'est la peine maximale! ;)
En fait ce que je veux dire, c'est que le travail en équipe est déjà difficile quand le code est nickel, il faut éviter de se créer des problèmes en plus inutilement. En réalité, quand tu mets ton code au propre, que tu prends le temps de faire les choses comme il faut, tu gagnes du temps, et tu en fait gagner au autres membre de l'équipe.
Mais ça, c'est pas tout le monde qui le comprends, et même parfois les chef dans une équipe de dev ont du mal à le comprendre, trop pris dans une course aux nouvelles features.
Pour moi le rêve, c'est quand ton chef dit:
"ça marche, c'est propre , c'est testé, c'est documenté(dans le code c'est mieux)"?
Si tu dis oui, il te répond:
"je peux voir?" ou un truc du genre. C'est pas trop pour faire la police, mais pour faire comprendre aux débutant par exemple, que si tu dis:
"j'ai pas activé le code parce que..." ou alors "oui, mais il faudrait d'abord que...", c'est que c'est pas fini.
Et si c'est pas trop la course, un de tes collègue regarde ce que tu as fait, pour voir s'il comprend tout.
Quand tu arrive, tu te dis, c'est quoi ces maniaques, et après tu comprends ton bonheur :)
Heu désolé, mais le code écrit par des matheux, c'est souvent pas la joie.
Par contre pas mal de developpeurs laissent le code comme ça leur vient au premier jet, alors qu'il savent ce qu'il faudrait faire pour correctement le refactoriser, et ça c'est criminel.
Cela dit ça ne me pose pas de problème, tant que je n'ai pas besoin de bosser avec ces développeurs.
D'ailleurs pas mal de prog fonctionne parfaitement bien vu de l'extérieur, alors que quand on voit le code, c'est tout pourri ;)
En fait je suis plutôt un partisan du monde Python, et par conséquent je suis d'accord avec toi sur la statégie d'optimisation :)
Par contre pour le C++pour moi c'est un des pires languages qui puisser exister, il faut sûrement être malade, ou dépressif pour vouloir coder dans ce langage ;)
Pour le C je peux comprendre, pour le bas niveau, ou l'optimisation, ce langage a au moins l'avantage de la simplicité (comparé au C++).
Encore que me concerant dans ce cas je me tournerait plutôt vers ocaml, si possible
Sinon, Python + bindings conjugue à merveille la programmation de haut niveau avec les performances.
Un bémol cependant, tu fais alors une concession sur la portabilité, si la lib n'existe pas sur les plateformes qui t'interessent.
Alors qu'avec java tu reste portable, et c'est un argument qui se défend, suivant le contexte.
Connaitre la machine c'est bien, mais pas indispenssable.
Par contre, connaitre les structures de données qu'on utiliser, c'est indispensable: les plus gros gains de perf se font sur l'algorithmique.
Sinon, j'ai pas envie de passer ma vie à optimiser, mais je préfère développer des fonctionnalité à temps, tout simplement parce que je ne dispose pas d'un temps infini. Donc je ne veux pas être obligé de gérer la taille des entiers , les float, double & co: il faut savoir s'arrêter. De plus ce genre d'optimisation n'est souvent pas portable, et générateur de bug.
Je préfère un langage/lib qui m'expose des types de plus haut niveau, ce qui ne dispense pas d'être implémenté de manière performante.
Donc en résumé, ce que tu dis peut s'appliqué pour ceux qui écrivent des lib en C, s'ils savent ce qu'il font. Pour les autres je conseille de s'appliquer sur le fonctionnel et la validité de leur code: avoir rapidement un résultat faux (ou un plantage), ça sert à rien.
Pour les Vector et Hashtable, il ne sont pas deprecated à ma connaissance, ms devraient surement l'être, voir même suprimés. Je justement attirer l'attention sur le fait que beaucoup de dev java ne connaissent que ces structure de données qui sont synchronisées par défaut, ce qui bouffe de perf, alors que bien souvent on en a pas besoin. Il faudrait les supprimer (ou déprécier si on veut garder la compatibilité) car il existe d'autres moyens pour synchoniser une collection, et ça ne simplifie pas l'api.
mais le simple renommage de libéllé, ça va ! (c'était ton exemple de départ), un outil de refactoring le fera sans problème
En fait non, car c'est une String, pas besoin de refactoring pour ça.
En ce que je tentais d'expliquer c'est que "pas de test unitaire"
-> "pas de refactoring" -> "croissance anarchique du code"
Dans le cas de mon petit libellé, le plus dur c'est de trouver ou il se cache, dans un monceau de page nommées n'importe comment, et pour ça d'être obligé de suivre du code inutilement compliqué.
Sinon, les tests unitaire, j'ai pratiqué, alliés à d'autres idées venant de XP (intégration continue, travail à deux, etc.), et oui, indéniablement, ça fait gagner du temps, et de la *qualité*
je ne vois pas ce qui risque d'être cassé si ton outil de refactoring fonctionne correctement !
En fait je prends refactoring au sens large. Ca comprends donc tout ce qui est gérable par un outils de refactoring mais aussi, la suppression de code mort (est-il bien mort d'ailleurs), la réecriture de code pourave
, changement de structures de données inefficaces, réécriture de requêtes, etc.
Et souvent, sur des projets avec test unitaire, j'ai choppé des différences de comportement, minimes, mais en fait pas tant que ça: par exemple une methode renvoit une liste vide, alors qu'un null est attendu dans certains cas. Ou alors lève une exception sur un parametre qui ne devrait pas être accépté, ms qui passait, par hasard dans l'implémentation précedende.
Au passage j'ajoute que bien souvent, on choisit les outils pour toi, et tu n'a pas forcément des choses aussi puissante que eclipse,
après, il faut toujours avoir la possibilité de revenir en arrière (sauvegarde et/ou fonction proposé par l'outil)
On est d'accord. Mais il te faut un retour pour savoir si tu retournes ou non en arrière: le premier retour c'est les tests unitaires.
De plus, une fois le code livré, le "undo" c'est plus compliqué.
Dans le meilleurs des cas la validation chope le bug, et ça fait un bug interne. Tu reviens à la version qui marche.
Mais souvent: la validation n'est pas efficace, et bien souvent les tests sont réalisés à la main, et donc il est très rare que l'equipe de validation refasse des tests sur des choses déjà testés et qui marchaient avant.
Je confirme.
Et quand tu arrive sur des projets à long terme, réalisés par des
prestataires dont les mission n'exèdent pas quelques mois, c'est le ponpon:
Modifier un libellé peut facilement prendre une demi journée, le temps de retrouvé le code dans les centaines de milliers de ligne amassée au fil du temps. Comme rien n'est testé, il faut faire super gaffe à ce que tu touches, et impossible de faire le moindre refactoring: trop peur de casser. Donc plus ça va ,et pire c'est.
Le bonheur quoi!
Concernant les paramêtre en dur, c'est bien joué, on à l'impression que la configuration est épérpillée partout dans le code, or c'est faux.
Ces frameworks reposent sur des langage interprètés, on a donc pas la nécessité d'externaliser la configuration pour éviter la recompilation.
Pourquoi utiliser un autre langage pour la configuration (XML par exmple), si on en a tout simplement pas besoin?
Par contre là ou je suis d'accord, c'est que RoR est un peu trop "Convention", c'est pourquoi je préfère Turbogears par exemple, qui utilise moins de "magie"
Sinon JEE c'est bien, mais c'est pas parqu'on est en entreprise qu'on est obligé de l'utiliser. J'ai souvent vu des appli ou on mettait derrière une archi répartie, avec load balancing, replication des noeuds et tout, alors qu'un trois tiers à base de Python ou Ruby aurait largement suffit.
Ceci juste parque les gens qui décident ont l'habitude de toujours faire "classique". Ce qui aboutit à une complexité qui n'est pas nécessaire, à tous les niveau: développement, test, integration, production.
JEE apporte bcp de possibilité dont on a généralement que faire, et peu de gens peuvent prétendre les maitriser, dans la pratique, bcp de developpeurs rament et bricolent. Je suis plutôt pour des solution plus simples quand elles sont suffisante: encore faut-il se poser la question avant d'imposer une architecture pour un projet.
Effectivement c'est très personnel et ça dépend des gouts, mais tu ne m'enlèvera pas de l'idée que certains languages ne facilitent pas la maintenabilité.
Pour moi font partie des "bon langage":
- Python pour la vie de tous les jours on ne se prends pas la tête avec ;)
- Haskell et Ocaml pour "s'amuser" et apprendre (là on peut se prendre la tête;)
- Smalltalk même si c'est mort, c'est avec ça que j'ai saisi ce que c'était que la programmation objet
- Ruby: Smalltalk en moins bien, mais vivant ;)
- Java: c'est pas mon préféré, mais ça passe encore
Les mauvais langage:
- Perl: syntaxe et sémantique super compliquée
- Shell: j'aime pas c'est tout
- PHP
- VB (facile;)
- C sauf pour a des fin d'optimisation, ou pour gérer le bas niveau.
- C++ : inutilement compliqué
Pour dire les choses brutalement, JSP c'est permetre d'utiliser du Java dans du HTML, plus ou moins proprement (utilisation de taglibs, ou pas etc.)
Ou plus exactement c'est une manière de générer du HTML à partir de Java.
A la limite on peut comparer Java et PHP, mais JSP et PHP, je ne vois pas trop.
Si tu veux mon avis, PHP c'est un peu le Perl des langage web:
facile à mettre en oeuvre en apparence, mais ça devient vite inmaintenable, à moins d'utiliser un framework au dessus de PHP, mais je pense qu'il y a mieux.
Le Java c'est plutôt le contraire: super lourd à mettre en oeuvre pour les applis web, par contre on a tout ce qu'il faut pour développer du code maintenable (même si certains développeurs arrivent à écrire des choses abominable, ms je dirais, c'est quand même moins pire qu'en PHP)
Posté par パパフラクス .
En réponse au journal Caméléon.
Évalué à 1.
En fait j'ai déjà essayé.
Je pense qu'un plugin eclipse c'est effectivement la bonne voix.
Le plugin Haskell bien que minimal est assez sympa a utilisé:
on a le "outline" des fonction, et le surlignage en rouge des erreurs et warnings, qu'on peut configurer en passant les parametres au compilo.
Pour caml, ben il n'y a pas encore grand chose, et j'ai pas l'impression que ça va progresser.
Un de ces jours il faudra que je m'interesse au fontionnement des plugins sous eclipse, ça a pas l'air évident à première vue.
Il me semble avoir lu quelque part qu'on pouvait utiliser Haskell pour coder tout ou partie d'un plugin eclipse, je ne sais pas si c'est vrai, mais ça pourait être interessant, notamment pour la partie parsing, et analyse de l'abre de syntaxe.
Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).
Je ne dis pas qu'il faut mettre du java dans ses JSP, d'ailleurs je ne le fais pas.
C'est justement les taglib que je n'aime pas: cette manie de faire de la programmation en XML, désolé mais ça me saoule. D'ailleurs rien à vois mais ça m'y fait penser: ant est pas mal non plus à ce niveau là.
Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.
Ben des fois tu change de projet, de client ou tu bosses sur plusieurs en même temps.
Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage
Ce que j'aime pas avec les jsp, c'est qu'il te faut connaitre tout un tas de taglib, dont les mots clé sont evidemment différent de ceux de java, et la sémantique pas toujours très claire. Et accessoirement il faut aussi connaitre EL.
[^] # Re: vocabulaire
Posté par パパフラクス . En réponse au journal Bonnes pratique pour le développement. Évalué à 3.
Oui je suis bien d'accord!
Ca va souvent de paire avec la programmation par copier/coller qui est une hérésie quand on utilise un langage objet (avec un autre langage aussi d'ailleurs)
[^] # Re: vocabulaire
Posté par パパフラクス . En réponse au journal Bonnes pratique pour le développement. Évalué à 2.
Pour les tests, ça me parait évident, bien que les test unitaires n'ont pas l'air d'être évidents pour tout le monde.
De la même manière utiliser un outils de suivi de bug me semble tellement indispensable que je m'aperçoit que je ne l'ai même pas mentionné.
Pour la doc, c'est important, mais il faut éviter de faire de la doc pour faire de la doc.
Moins il y en a et mieux c'est (il faut la maintenir à jour), mais il y a un minimum à fournir
.
Pour la forme, le wiki c'est pas mal (mieux qu'un tas de fichiers bien enfouis sur un lecteur partagé en tout cas)
Mais c'est pas optimal non plus, au bout d'un moment, les gens oublient de mettre à jour le wiki, et de plus les non-informaticiens ne sont pas toujours à l'aise avec.
[^] # Re: Et Eiffel ?
Posté par パパフラクス . En réponse à la dépêche Squeak stimulé par le projet OLPC. Évalué à 2.
Ca me semble un peu léger comme points communs.
Pour ce qui est de la programmation par contrat, j'ai encore des doute (mais j'ai peut-être pas encore tout compris).
Nul doute sur le fait que celà puisse éviter des bugs. Sur la théorie, je suis tout à fait d'accord.
Par contre là ou j'ai des problèmes, c'est qu'au niveau d'une application réelle, bien souvent une (post|pre)condition, ou un invariant non vérifié doit être gérer par l'application en tant qu'"erreur métier", et pas planter l'appli sur une rupture de contrat.
Cela implique de coder deux fois les choses: une fois pour le contrat, et une fois pour gérer l'erreur métier, moi je trouve pas ça terrible.
Cela est peut-être utile pour la phase de debug, mais je n'ai pas encore trouver une bonne manière d'organiser tout ça, et en plus ça complexifie encore un peu le développement: certain dev peuvent se sentir protégé car ils ont bien codé leur contrats, mais livre-t-on le code avec ou sans les contrats.
En fait un contrat, utilisé hors de la programmation d'un composant générique, réutilisable (ce qui arrive peu souvent en fait), ça me parrait être un voeux pieux, un peu comme quand je tombe sur un commentaire qui dit: "ça ne devrait pas arrivé" (donc on ne fait rien). L'expérience montre que les utilisateur ont de l'imagination.
[^] # Re: Et Eiffel ?
Posté par パパフラクス . En réponse à la dépêche Squeak stimulé par le projet OLPC. Évalué à 2.
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par パパフラクス . En réponse au sondage Le Javascript c'est. Évalué à 2.
En utilisant que la forme la plus simple.
évidemment le must, c'est une collection avec un itérateur.
Le problème avec le while, c'est qu'il y a toujours un zozo pour t'insérer un truc entre l'init, et la boucle. Et après le premier, un autre ce dit pourquoi pas moi...
En plus maintenant, en Java au moins, la boucle for est beaucoup plus jolie que le while.
J'aime bien que mes variable soient déclarée au plus près de l'endroit ou elle sont utilisée.
[^] # Re: Java oui, c'est lent
Posté par パパフラクス . En réponse au message Lenteur de Java ?. Évalué à 2.
Mais Python favorise l'utilisation de lib natives,
par exemple pour le calcul numérique, ce qui équilibre les choses.
Cependant de mon expérience cette lenteur relative ne devient que rarement pénalisante.
Pour moi, sur un algo d'apprentissage numérique, la phase d'apprentissage était vraiment super lente. Mais je l'avait un peu fait exprès, j'avoue, en implémentant naïvement l'algo entièrement en Python, pour voir le gain et la facilité d'utiliser Numeric plus tard.
La "migration" vers Numeric a été super rapide, et le gain plutôt impressionnant.
Il existe également <a ref='"http://psyco.sourceforge.net/introduction.html">Psyco qui permet d'améliorer les perf.
Cependant je n'ai jamais essayé.
[^] # Re: mon avis
Posté par パパフラクス . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Les templates, ça n'existe que depuis très peu de temps.
Je me suis mis dans le contexte java < 1.5 car il me semble que c'est ce à quoi le monsieur faisait référence.
Il est vrai que ce problème est aujourd'hui grandement résolu.
[^] # Re: mon avis
Posté par パパフラクス . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Mais en même temps je ne vois pas trop une autre façon de faire, sans impliquer les generics, ou l'inférence de types.
[^] # Re: mon avis
Posté par パパフラクス . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Pour le cast, c'était une manière de gérer le polymorphisme sns les generics.
Maintenant les generics permettent de faire propre pour les collection, mais apportent d'autres soucis (lisibilité, complexité, etc.)
[^] # Re: mon avis
Posté par パパフラクス . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 3.
En tout cas pour moi, le "run everywhere " de Java s'est toujours vérifié, et je n'ai jamais été embêté par des problèmes de portabilité. C'est un des atouts majeurs de Java. J'ai ouï dire qu'il n'en était pas de même dans l'embarqué, mais je ne l'ai pas expérimenté moi-même.
Pour ce qui est de la normalisation, je ne suis pas sur de ce que ça apporte, Ruby et Python vivent bien sans être normalisé..
Je ne sais pas si la normalisation peu y faire quelque chose,
mais pour Ruby, le fait qu'on ai pas de vrai visibilité sur l'avenir du langage me parait un gros point faible. je trouve la doc assez faible aussi, mais je pense que c'est l'esprit de la communauté.
Pour Python, Guido gère très bien l'évolution de son langage, la normalisation n'apporterait sûrement pas grand chose. La doc est excellente.
Donc oui, il y a moyen de faire correctement les choses, sans normaliser.
[^] # Re: mouaich
Posté par パパフラクス . En réponse au journal "L'informatique Paradoxale". Évalué à 7.
Et sinon c'est sympa de signaler le code sale, tes successeurs sur le code te remercieront pour ça ;)
Au moins quand c'est pas signalé, je pré-suppose l'ignorance, et ça m'incite à l'indulgence. Dans ton cas, c'est la peine maximale! ;)
En fait ce que je veux dire, c'est que le travail en équipe est déjà difficile quand le code est nickel, il faut éviter de se créer des problèmes en plus inutilement. En réalité, quand tu mets ton code au propre, que tu prends le temps de faire les choses comme il faut, tu gagnes du temps, et tu en fait gagner au autres membre de l'équipe.
Mais ça, c'est pas tout le monde qui le comprends, et même parfois les chef dans une équipe de dev ont du mal à le comprendre, trop pris dans une course aux nouvelles features.
Pour moi le rêve, c'est quand ton chef dit:
"ça marche, c'est propre , c'est testé, c'est documenté(dans le code c'est mieux)"?
Si tu dis oui, il te répond:
"je peux voir?" ou un truc du genre. C'est pas trop pour faire la police, mais pour faire comprendre aux débutant par exemple, que si tu dis:
"j'ai pas activé le code parce que..." ou alors "oui, mais il faudrait d'abord que...", c'est que c'est pas fini.
Et si c'est pas trop la course, un de tes collègue regarde ce que tu as fait, pour voir s'il comprend tout.
Quand tu arrive, tu te dis, c'est quoi ces maniaques, et après tu comprends ton bonheur :)
[^] # Re: mouaich
Posté par パパフラクス . En réponse au journal "L'informatique Paradoxale". Évalué à 5.
Par contre pas mal de developpeurs laissent le code comme ça leur vient au premier jet, alors qu'il savent ce qu'il faudrait faire pour correctement le refactoriser, et ça c'est criminel.
Cela dit ça ne me pose pas de problème, tant que je n'ai pas besoin de bosser avec ces développeurs.
D'ailleurs pas mal de prog fonctionne parfaitement bien vu de l'extérieur, alors que quand on voit le code, c'est tout pourri ;)
[^] # Re: Plop !
Posté par パパフラクス . En réponse au journal "L'informatique Paradoxale". Évalué à 0.
En fait je suis plutôt un partisan du monde Python, et par conséquent je suis d'accord avec toi sur la statégie d'optimisation :)
Par contre pour le C++pour moi c'est un des pires languages qui puisser exister, il faut sûrement être malade, ou dépressif pour vouloir coder dans ce langage ;)
Pour le C je peux comprendre, pour le bas niveau, ou l'optimisation, ce langage a au moins l'avantage de la simplicité (comparé au C++).
Encore que me concerant dans ce cas je me tournerait plutôt vers ocaml, si possible
Sinon, Python + bindings conjugue à merveille la programmation de haut niveau avec les performances.
Un bémol cependant, tu fais alors une concession sur la portabilité, si la lib n'existe pas sur les plateformes qui t'interessent.
Alors qu'avec java tu reste portable, et c'est un argument qui se défend, suivant le contexte.
[^] # Re: Plop !
Posté par パパフラクス . En réponse au journal "L'informatique Paradoxale". Évalué à 5.
Par contre, connaitre les structures de données qu'on utiliser, c'est indispensable: les plus gros gains de perf se font sur l'algorithmique.
Sinon, j'ai pas envie de passer ma vie à optimiser, mais je préfère développer des fonctionnalité à temps, tout simplement parce que je ne dispose pas d'un temps infini. Donc je ne veux pas être obligé de gérer la taille des entiers , les float, double & co: il faut savoir s'arrêter. De plus ce genre d'optimisation n'est souvent pas portable, et générateur de bug.
Je préfère un langage/lib qui m'expose des types de plus haut niveau, ce qui ne dispense pas d'être implémenté de manière performante.
Donc en résumé, ce que tu dis peut s'appliqué pour ceux qui écrivent des lib en C, s'ils savent ce qu'il font. Pour les autres je conseille de s'appliquer sur le fonctionnel et la validité de leur code: avoir rapidement un résultat faux (ou un plantage), ça sert à rien.
Pour les Vector et Hashtable, il ne sont pas deprecated à ma connaissance, ms devraient surement l'être, voir même suprimés. Je justement attirer l'attention sur le fait que beaucoup de dev java ne connaissent que ces structure de données qui sont synchronisées par défaut, ce qui bouffe de perf, alors que bien souvent on en a pas besoin. Il faudrait les supprimer (ou déprécier si on veut garder la compatibilité) car il existe d'autres moyens pour synchoniser une collection, et ça ne simplifie pas l'api.
[^] # Re: Plop !
Posté par パパフラクス . En réponse au journal "L'informatique Paradoxale". Évalué à 2.
[^] # Re: test unitaires?
Posté par パパフラクス . En réponse au journal Un quart des développeurs ne testent jamais leurs programmes.. Évalué à 4.
En fait non, car c'est une String, pas besoin de refactoring pour ça.
En ce que je tentais d'expliquer c'est que "pas de test unitaire"
-> "pas de refactoring" -> "croissance anarchique du code"
Dans le cas de mon petit libellé, le plus dur c'est de trouver ou il se cache, dans un monceau de page nommées n'importe comment, et pour ça d'être obligé de suivre du code inutilement compliqué.
Sinon, les tests unitaire, j'ai pratiqué, alliés à d'autres idées venant de XP (intégration continue, travail à deux, etc.), et oui, indéniablement, ça fait gagner du temps, et de la *qualité*
[^] # Re: test unitaires?
Posté par パパフラクス . En réponse au journal Un quart des développeurs ne testent jamais leurs programmes.. Évalué à 5.
En fait je prends refactoring au sens large. Ca comprends donc tout ce qui est gérable par un outils de refactoring mais aussi, la suppression de code mort (est-il bien mort d'ailleurs), la réecriture de code pourave
, changement de structures de données inefficaces, réécriture de requêtes, etc.
Et souvent, sur des projets avec test unitaire, j'ai choppé des différences de comportement, minimes, mais en fait pas tant que ça: par exemple une methode renvoit une liste vide, alors qu'un null est attendu dans certains cas. Ou alors lève une exception sur un parametre qui ne devrait pas être accépté, ms qui passait, par hasard dans l'implémentation précedende.
Au passage j'ajoute que bien souvent, on choisit les outils pour toi, et tu n'a pas forcément des choses aussi puissante que eclipse,
après, il faut toujours avoir la possibilité de revenir en arrière (sauvegarde et/ou fonction proposé par l'outil)
On est d'accord. Mais il te faut un retour pour savoir si tu retournes ou non en arrière: le premier retour c'est les tests unitaires.
De plus, une fois le code livré, le "undo" c'est plus compliqué.
Dans le meilleurs des cas la validation chope le bug, et ça fait un bug interne. Tu reviens à la version qui marche.
Mais souvent: la validation n'est pas efficace, et bien souvent les tests sont réalisés à la main, et donc il est très rare que l'equipe de validation refasse des tests sur des choses déjà testés et qui marchaient avant.
[^] # Re: test unitaires?
Posté par パパフラクス . En réponse au journal Un quart des développeurs ne testent jamais leurs programmes.. Évalué à 9.
Et quand tu arrive sur des projets à long terme, réalisés par des
prestataires dont les mission n'exèdent pas quelques mois, c'est le ponpon:
Modifier un libellé peut facilement prendre une demi journée, le temps de retrouvé le code dans les centaines de milliers de ligne amassée au fil du temps. Comme rien n'est testé, il faut faire super gaffe à ce que tu touches, et impossible de faire le moindre refactoring: trop peur de casser. Donc plus ça va ,et pire c'est.
Le bonheur quoi!
[^] # Re: Quelle place pour les pages web ?
Posté par パパフラクス . En réponse au message php vs jsp?. Évalué à 2.
Ces frameworks reposent sur des langage interprètés, on a donc pas la nécessité d'externaliser la configuration pour éviter la recompilation.
Pourquoi utiliser un autre langage pour la configuration (XML par exmple), si on en a tout simplement pas besoin?
Par contre là ou je suis d'accord, c'est que RoR est un peu trop "Convention", c'est pourquoi je préfère Turbogears par exemple, qui utilise moins de "magie"
Sinon JEE c'est bien, mais c'est pas parqu'on est en entreprise qu'on est obligé de l'utiliser. J'ai souvent vu des appli ou on mettait derrière une archi répartie, avec load balancing, replication des noeuds et tout, alors qu'un trois tiers à base de Python ou Ruby aurait largement suffit.
Ceci juste parque les gens qui décident ont l'habitude de toujours faire "classique". Ce qui aboutit à une complexité qui n'est pas nécessaire, à tous les niveau: développement, test, integration, production.
JEE apporte bcp de possibilité dont on a généralement que faire, et peu de gens peuvent prétendre les maitriser, dans la pratique, bcp de developpeurs rament et bricolent. Je suis plutôt pour des solution plus simples quand elles sont suffisante: encore faut-il se poser la question avant d'imposer une architecture pour un projet.
[^] # Re: Quelle place pour les pages web ?
Posté par パパフラクス . En réponse au message php vs jsp?. Évalué à 2.
Pour moi font partie des "bon langage":
- Python pour la vie de tous les jours on ne se prends pas la tête avec ;)
- Haskell et Ocaml pour "s'amuser" et apprendre (là on peut se prendre la tête;)
- Smalltalk même si c'est mort, c'est avec ça que j'ai saisi ce que c'était que la programmation objet
- Ruby: Smalltalk en moins bien, mais vivant ;)
- Java: c'est pas mon préféré, mais ça passe encore
Les mauvais langage:
- Perl: syntaxe et sémantique super compliquée
- Shell: j'aime pas c'est tout
- PHP
- VB (facile;)
- C sauf pour a des fin d'optimisation, ou pour gérer le bas niveau.
- C++ : inutilement compliqué
[^] # Re: Quelle place pour les pages web ?
Posté par パパフラクス . En réponse au message php vs jsp?. Évalué à 1.
mais tu aura du mal à me faire croire que PHP est un "bon language"
[^] # Re: Quelle place pour les pages web ?
Posté par パパフラクス . En réponse au message php vs jsp?. Évalué à 1.
Ou plus exactement c'est une manière de générer du HTML à partir de Java.
A la limite on peut comparer Java et PHP, mais JSP et PHP, je ne vois pas trop.
Si tu veux mon avis, PHP c'est un peu le Perl des langage web:
facile à mettre en oeuvre en apparence, mais ça devient vite inmaintenable, à moins d'utiliser un framework au dessus de PHP, mais je pense qu'il y a mieux.
Le Java c'est plutôt le contraire: super lourd à mettre en oeuvre pour les applis web, par contre on a tout ce qu'il faut pour développer du code maintenable (même si certains développeurs arrivent à écrire des choses abominable, ms je dirais, c'est quand même moins pire qu'en PHP)
Pour moi, le plus agréable à utiliser sont des choses du genre
http://www.djangoproject.com/
ou bien http://www.turbogears.org/
Python me semble le language le plus adapté pour le développement web.
Je mets pas rails car il n'a pas besoin de pub ;)
[^] # Re: EclipseFP ?
Posté par パパフラクス . En réponse au journal Caméléon. Évalué à 1.
Je pense qu'un plugin eclipse c'est effectivement la bonne voix.
Le plugin Haskell bien que minimal est assez sympa a utilisé:
on a le "outline" des fonction, et le surlignage en rouge des erreurs et warnings, qu'on peut configurer en passant les parametres au compilo.
Pour caml, ben il n'y a pas encore grand chose, et j'ai pas l'impression que ça va progresser.
Un de ces jours il faudra que je m'interesse au fontionnement des plugins sous eclipse, ça a pas l'air évident à première vue.
Il me semble avoir lu quelque part qu'on pouvait utiliser Haskell pour coder tout ou partie d'un plugin eclipse, je ne sais pas si c'est vrai, mais ça pourait être interessant, notamment pour la partie parsing, et analyse de l'abre de syntaxe.
# Lien
Posté par パパフラクス . En réponse au journal Caméléon. Évalué à 3.
Ou alors je suis fatigué...
http://home.gna.org/cameleon/index.fr.html
[^] # Re: Former des développeurs Python/Zope compétents
Posté par パパフラクス . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 2.
Merci, ça fait toujours plaisir
Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).
Je ne dis pas qu'il faut mettre du java dans ses JSP, d'ailleurs je ne le fais pas.
C'est justement les taglib que je n'aime pas: cette manie de faire de la programmation en XML, désolé mais ça me saoule. D'ailleurs rien à vois mais ça m'y fait penser: ant est pas mal non plus à ce niveau là.
Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.
Ben des fois tu change de projet, de client ou tu bosses sur plusieurs en même temps.
Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage
Ce que j'aime pas avec les jsp, c'est qu'il te faut connaitre tout un tas de taglib, dont les mots clé sont evidemment différent de ceux de java, et la sémantique pas toujours très claire. Et accessoirement il faut aussi connaitre EL.
Regarde l'exemple fourni sur le site de KID :
http://www.kid-templating.org/trac/wiki/KidExamples
C'est quoi dans les attributs? ben c'est du python: j'ai rien de plus à savoir. pas de langage pour les expression, ou autre taglib.