Que nous propose donc Pierre Tramo, J2EE Lead Architect, pour la refonte de Linuxfr en 2009 ?
Du J2EE bien sûr !
Le cahier des charges : Refaire linuxfr pour noel 2009. La version beta doit être livrée le 1er septembre.
Buget : mieux vaut ne pas y penser.
Déroulement :
Janvier 2009
####
Arrivée des consultants. Ben oui, tout projet J2EE digne de ce nom vient avec sa panoplie de consultant avec des cravates mal attachées et qui jouent tout le temps à cochonland, miniville et autres jeux en flash. C'est un peu une sorte de symbiose naturelle : vous ne trouverez jamais l'un sans l'autre.
Un laptop est donné à chaque consultant. Les deux premières semaines sont passées à configurer le laptop. Chacun installe Eclipse sauf deux qui installent IntelliJ et réclament les licences pour pouvoir l'utiliser. Tous les consultants sont sous Windows sauf un, qui connait bien Linux. Il a installé une Ubuntu puis installé tout à la main depuis les sources.
Les premières réunions sont tenues pour décider de l'architecture. Parce qu'un bon projet, c'est avant tout une bonne architecture. Il est décidé d'utiliser Jboss parce que c'est un serveur d'application libre, ce qui correspond à la philosophie du site. Un représentant de Linuxfr demande ce qu'est un serveur d'application. Un consultant lui fait un diagramme qu'il avoue ne plus comprendre lui-même à la fin. Les premiers shémas voient le jour.
Prise de contact. Le projet est baptisé "Linuxfr-NG". Il suivra un modèle MVC strict. Il utilisera Spring, Struts et plein d'autres noms que seuls les javaistes semblent comprendre.
Février
####
Les consultants installent tous Jboss et, en conséquence, demandent un triplement de la taille de la Ram de leur portable. Deux consultants sont déjà infestés de virus et spamment tout le réseau. Un autre des consultant leur installe un antivirus piraté mais "qui est bien mieux que celui fourni (sic)".
Le shéma des classes est commencé en UML. Fin février, ce shéma s'imprime déjà sur 8 feuilles A4 avec polices en taille 8 qu'il faut assembler dans la salle de réunion.
Un des meneurs identifies différents mécanismes fort semblables et décide de les abstraire avec des Design Patern. Les commentaires et les journaux seront issus d'un FactoryOfUserInput.
Beaucoup de discussions sur le meilleur wiki et le meilleur bugzilla à adopter.
Mars
###
Un problème fondamental est identifié dans ce premier design UML. Tout est refait. Un des consultants entre dans le top 10 de miniville.
Beaucoup de discussions pour savoir si une classe donnée du diagramme UML appartient à M, à V ou à C.
Avril
###
Ce nouveau design semble beaucoup mieux que le précédent. Chaque commentaire est maintenant généré à partir d'un objet FactoryOfSingletonFactoryOfUserComment, ce qui est beaucoup plus propre d'un point de vue MVC (sic). Les consultants suivent une formation sur le développement agile et chacun assigne un rôle à un autre consultant tout en lui collant des post-its de couleur sur l'écran de chaque bug dont il doit s'occuper.
Un couche d'abstraction est créée afin d'intégrer dans la View certains éléments du Controller.
Mai
###
Un des consultants remarque que les tests unitaires écrit en janvier ne se lancent même plus depuis des mois. Il corrige le problème et installe un plugin qui envoie un mail à chaque fois qu'un test ne tourne plus après un commit.
À chaque commit, chaque consultant reçoit 150 mails.
Le chef de projet estime que le bouton "poster un commentaire" fait partie de la View, pas du controller. On décide faire des classes abstraites avec héritage multiple pour satisfaire tout le monde.
Juin (2009 toujours)
###
Réunion avec les clients. La deadline va être difficile à tenir. Si un dépassement de budget est envisageable, on suggère d'embaucher de la main d'oeuvre supplémentaire.
Le nombre de consultants est doublé (et tant pis pour la dépense). Les nouveaux arriveront début juillet.
Le fichier UML fait à présent 16 pages A4. Le code source (pour la plupart généré) atteind 300Mo. Certains fichiers XML de description des propriétés atteignent les 20.000 lignes. Le but de ces fichiers est d'être facilement modifiable par un non-programmeur, le XML étant plus facile que le java.
Juillet
###
Les nouveaux arrivent. Dans le tas se trouve 2 tchèques qui parlent anglais pas trop mal mais sont électroniciens de formation, il n'ont jamais fait de java, 2 italiens qui ne parlent qu'italien.
Le mois de juillet est passé à leur installer l'environnement de développement. On découvre que la procédure d'installation (17 pages sur le wiki, et des longues) n'est plus du tout à jour.
Suite à l'utilisation de librairies spéciales, le projet ne tourne plus que sous Windows. Le consultant qui était sous Linux réinstalle WinXP.
Aout
###
La moitié de l'ancienne équipe travaille à "lancer" les nouveaux dans le projet. Cela commence par leur expliquer ce qu'est Eclipse et comment créer un projet. Les italiens ne pigent rien mais prennent note sur des cahiers. La compilation du projet avec Maven prent 34 minutes en moyenne mais sur une installation fraîche sans aucun cache, cela peut monter à 2h. L'output de la console tourne dans les 30.000 lignes à chaque fois.
Un des tchèques demandent si les tests unitaires vont dans M, dans V ou dans C. Trois réunions s'en suivent parce que certains jugent la question pertinente.
Septembre
###
Implémentation de l'objet AbstractFactoryOfFactoryOfSingletonFactoryOfUserComment. On assigne à un des tchèques la tâche d'écrire les tests unitaires pour tout ce qui a été écrit entre mai et septembre.
La beta est reportée au 1er octobre avec démonstration devant les managers. Le code source fait à présent un total de 800Mo. Le consultant qui utilise Linux ajoute, dans le prototype, un interpréteur Python utilisant Jython car "ça peut toujours servir".
Le wiki comporte 179 pages et la page de garde ainsi que ses descendants directs n'ont plus été modifiés depuis juillet.
À chaque modif, le projet doit être entièrement recompilé pour pouvoir tester. Le serveur doit être également relancé.
Octobre
###
Démonstration du prototype. Le chef de projet ouvre 5 consoles et tape, dans chacune, une commande qui fait facilement 3 lignes de la console en question. Il appuie sur enter, le PC crie et chauffe.
Après quelques minutes de défilement ininterrompus dans les consoles, une interface ressemblant à éclipse apparait. Le tout utilisant la skin Swing. c'est moche à souhait mais le chef de projet, tout fier, explique qu'ils ont utilisé le toolkit eclipse qui permet, par exemple, d'ajouter des "satellites". Au milieu de cette interface, une fenêtre affiche une vue de ce qui ressemble à une liste, genre ce que phpmyadmin affiche quand on explore une table mysql.
Le chef de projet explique que ceci est l'interface d'administration de l'administration du serveur de commentaires. Personne ne comprend.
Il passe ensuite sur une fenêtre Firefox qui met 15 secondes à s'afficher ("désolé, ce PC n'a que 2 Go de Ram mais sur un cluster de serveur, y'a pas de problème hein").
Dans son Firefox apparaît un page blanche avec quelques liens incompréhensibles et un logo Jboss dans le haut de la page.
"Bon, bien sûr, c'est pas l'interface définitive hein ! Ici j'utilise l'interface Jboss et EJB."
Il scrolle. Dans le bas apparait un champ avec un boutton "poster le commentaire".
Le chef de projet tape un petit texte et appuie sur le bouton. Le texte s'affiche alors en haut du champ, en noir.
"Et voilà, commentaire posté !" Il se retourne avec un grand sourire. Voyant le visage des clients, il ajoute : "bien entendu, ce n'est qu'un exemple ! Notre architecture permet une grande souplesse. Imaginez que je souhaite définir un journal, il me suffirait de modifier ça et ça (il ouvre eclipse puis étale sur la table 32 pages attachées sur lesquelles est affiché l'architecture UML).
Les managers sont un peu perplexe.
Novembre
###
La pression de la démo étant passée, le projet n'avance plus trop. Beaucoup de vacances avec la toussaint. Le code des tests unitaires est refactorisé. Trois consultants travaillent sur un framework permettant de gérer plus facilement les tests unitaires du projet (dont près de la moitié passent).
Décembre
###
Le projet a du retard et ne pourra pas être mis en production en janvier 2010. Il est décidé de reprendre la maitenance de la version Templeet et de réduire l'équipe qui travaille sur Linuxfr-NG.
Le chef de projet livre une documentation de 240 pages sur l'état actuel du framework, sur l'étude de faisabilité, sur les forces et faiblesses du projet. Le tout compile un rapport que chaque consultant a du faire. Il y est estimé que le site sera fonctionnel en juin 2010 mais qu'il est important de ne pas s'éparpiller.
Juin 2010
###
Seul 5 consultants sont encore présents pour travailler sur le projet. Ils font principalement la documentation des bugs qu'ils trouvent et qui empêche le projet de se lancer depuis la mise à jour de Windows en SP3.
Novembre 2010
###
Le projet est abandonné mais comme les consultants sont partis petit à petit, personne ne s'en rend vraiment compte. Deux consultants sont d'ailleurs encore là et aide l'équioe templeet depuis 2 mois. On leur donne des trucs à faire par ci par là.
Decembre 2010
###
Personne ne se souvient plus réellement de cette idée. Officiellement, le projet a été fusionné avec la maintenance de la version existante. Le serveur SVN et son 1,6Go de code source crashe, personne ne le restaure.
Journal Linuxfr en J2EE
7
jan.
2009
# Autre projet
Posté par IsNotGood . Évalué à 10.
Il y a des problèmes pour la tenue en charge, mais on compte sur la lois de Moore pour être prêt en 2018. Ça donne du temps.
[^] # Re: Autre projet
Posté par Bastes . Évalué à 6.
[^] # Re: Autre projet
Posté par pasBill pasGates . Évalué à 10.
[^] # Re: Autre projet
Posté par Bastes . Évalué à -10.
Et puis, il y aurait un petit avantage secondaire, tu n'aurais pas à déployer toute cette belle énergie juste pour pourrir les discussions où tu prends part.
[^] # Re: Autre projet
Posté par pasBill pasGates . Évalué à 10.
[^] # Re: Autre projet
Posté par Bastes . Évalué à -10.
[^] # Re: Autre projet
Posté par Thomas Douillard . Évalué à 10.
[^] # Re: Autre projet
Posté par Anthony Jaguenaud . Évalué à 7.
Toi, tu argumentes comme un enfant en primaire à l'école. Pour ton information, c'est pas très sympa pour toi ;-)
[^] # Re: Autre projet
Posté par Bastes . Évalué à -4.
[^] # Re: Autre projet
Posté par 2PetitsVerres . Évalué à 7.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Vive le vent !
Posté par Aefron . Évalué à 10.
# Grandiose
Posté par Pierrick Le Gall (site web personnel) . Évalué à 9.
Java, l'art de faire compliqué/complexe quand on peut faire simple. Java, sans IDE t'es rien. Mais bon, y'a des "ressources" (des gens) Java partout pour un coût variant du tout jeune diplômé à l'architecte Java (15 ans d'expérience, s'il vous plaît). C'est un ecosystème qui a encore de beaux jours devant lui : les SSII peuvent chiffrer des centaines de jours sur le moindre ajout d'écran dans une appli et pendant ce temps là, SUN met le paquet pour que les décideurs pressés soient convaincus que Java est la solution. Les écoles d'ingénieurs formant toutes à Java maintenant, la boucle est bouclée. Dans un projet d'informatique de gestion, même si tu ne veux pas faire de Java, les ressources disponibles et la mouvance actuelle font que tu vas forcément vers Java.
Cela dit, une interface Eclipse, c'est relativement beau et fonctionnel, faut pas être hypocrite.
[^] # Re: Grandiose
Posté par Miguel Moquillon (site web personnel) . Évalué à 9.
Java, l'art de faire compliqué/complexe quand on peut faire simple.
Je pense au contraire que la tendance de faire compliqué ce qui est simple vient en général de ce qui est entre la chaise et le clavier et pas nécessairement de Java ; parce que la plate-forme Java connait un nombre croissant de développeurs, et donc que l'on trouve aussi bien du moins bon que du bon, il est normal que l'on perçoit plus facilement ce genre d'attitude. En tout cas, on trouve bcp de parasites avec une insufférable suffisance.
En tout cas, ta phrase m'a fait penser à ce que j'ai lu un jour : 'Java est un langage pour débutant'.
Cela dit, une interface Eclipse, c'est relativement beau et fonctionnel, faut pas être hypocrite.
Oui ... et avec bcp (trop) de bogues. Quand je peux éviter Eclipse, je le fais.
[^] # Re: Grandiose
Posté par yellowiscool . Évalué à 1.
Envoyé depuis mon lapin.
[^] # Re: Grandiose
Posté par Buf (Mastodon) . Évalué à 10.
[^] # Re: Grandiose
Posté par suJeSelS . Évalué à 5.
Tu pense probablement à cette citation sortie à l'occasion d'une news concernant Arc:
Java was, as Gosling says in the first Java white paper, designed for average programmers. It's a perfectly legitimate goal to design a language for average programmers. (Or for that matter for small children, like Logo.)
Paul Graham ( http://paulgraham.com/arcll1.html )
[^] # Re: Grandiose
Posté par maximegb . Évalué à 7.
Pourquoi utiliser conjointement Struts et Spring ?
En utilisant Spring, on a besoin que de Tomcat en serveur, et non JBoss, bien plus lourd. (JBoss inclus Tomcat, et beaucoup, beaucoup d'autres choses).
(cf. http://static.springframework.org/docs/Spring-MVC-step-by-st(...) ).
J'ai voulu essayer Tomcat récemment, dans ma distribution Linux. Ca m'a pris 1 heure pour l'installer, le configurer, et essayer les exemples. Et c'était sur un PC avec 256 Mo de RAM.
[^] # Re: Grandiose
Posté par benoar . Évalué à 6.
Un des premiers trucs à faire dans ce tutorial est d'écrire un fichier XML pour ant de 100 lignes ... Franchement, ça me décourage rien qu'à le lire.
[^] # Re: Grandiose
Posté par ckyl . Évalué à 5.
On peut critiquer plein de choses, mais la ca devient vraiment ridicule... Ant c'est laid, c'est moche si on veut. Mais t'y passe une journée sur 2 ans de dev ! Lire ce code et comprendre chaque action ça m'a pas pris plus d'une minute.
C'est quoi ton environnement de dev si parfait ou tout est génial et y'a rien de chiant à faire ? Faut bien le compiler à un moment ton code, et personnellement entre ant, cmake, scons, make ou les autotools y'a rien qui me fait vraiment bander... En l'occurrence dans le fichier qu'ils donnent il n'y a pas d'information redondantes, je vois pas bien comment tu veux faire plus court. C'est juste le XML qui te gène ?
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Python.
Tu apt-get install les packages python-xxx qui sont nécessaires pour ton projet.
Tu lances "python main.py"
Et voilà...
Les gars, faut ouvrir un peu les yeux : quand tu dois commencer à utiliser des outils pour pouvoir utiliser tes outils, c'est un peu angoissant. La palme revient quand même à Gcc. Comme c'était compliqué de compiler, on a fait make. Comme faire un makefile, c'est conpliqué, on a fait configure. Comme configure c'était compliqué, on a fait autogen. C'est incroyable. Et Java fonce droit dans la même veine.
J'avoue que même en python, certains essayent de pourir un peu avec les eggs et des trucs comme ça. Ou pire : zope. Mais dans les projets modernes, tu peux trouver de très gros programmes en python qui se lancent avec python main.py. Pour le développement web, django a une philosophie très similaire.
Moi perso, dans mes projets, j'estime qu'un programme doit pouvoir se lancer avec un start.sh, rien d'autres. Si ce n'est pas le cas, le programme est mal fichu tout simplement.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par allcolor (site web personnel) . Évalué à 9.
Moi perso, dans mes projets, j'estime qu'un programme doit pouvoir se lancer avec un start.sh, rien d'autres. Si ce n'est pas le cas, le programme est mal fichu tout simplement.Je vois pas le rapport entre des outils pour compiler un langage compilé et lancer ce programme compilé et un programme interprété ou en lance l'interpréteur directement sur les sources.
Parce que je vois pas ce qui empêche de faire un start.sh pour n'importe quel programme.
[^] # Re: Grandiose
Posté par Jean B . Évalué à 1.
En réalité c'est plus compliqué que ça.
Quand tu lance l'interpréteur sur un fichier source il le compile automatiquement en byte code (.pyc) et se charge de déterminer si il faut le réutiliser ou non à la prochaine exécution en se basant sur la date de dernière modification.
En gros il fait un gros taf et correctement sans rien demander à personne. Les perf tombent un peu à la première exécution mais on s'en cogne.
Concernant les fameuses TypeError, les applis Java crashent peut être moins car le compilo impose de catcher toutes les erreurs mais si c'est pour faire comme éclipse et simplement balancer de fenêtres modales avec des messages imbitables ...
Et pour l'anectode si on veut coder aussi strict qu'avec un compilateur mais en Python on peut très bien utiliser PyLint ou autre.
[^] # Re: Grandiose
Posté par Octabrain . Évalué à 2.
[^] # Re: Grandiose
Posté par ckyl . Évalué à 1.
Tu passes de la compilation au lancement de l'application comme si c'était la même chose (en python c'est le cas).
Python est effectivement un très bon langage qui à lui aussi ses contraintes... Y'a pas de miracle ce que tu gagnes en souplesse tu le perds ailleurs...
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à -2.
Mais sinon, pourquoi vous voulez absolument compiler ? Quel est l'intérêt ? Ok, cela peut être intéressant pour des raisons de performances mais dans ce cas là on n'utilise pas Java.
Compiler, c'est un concept dépassé quand on fait du développement, cela ne devrait plus exister que pour l'optimisation d'un produit "fini".
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par Octabrain . Évalué à 9.
Ouch ! Et les vérifications (de type pour les plus basiques), qui t'évitent par exemple de te taper une méchante et cependant bête TypeError au moment le plus critique que tes tests unitaires (car j'imagine que tu en fais, c'est très sur la vague "développement agile/rapide") n'auront pas détectés, qu'en fais-tu ?
[^] # Re: Grandiose
Posté par Moonz . Évalué à 0.
[^] # Re: Grandiose
Posté par ckyl . Évalué à 10.
C'est un sujet à part entière tellement les limites sont flous.
> Mais sinon, pourquoi vous voulez absolument compiler ?
Dans un contexte de langage statiquement et fortement typé, un code qui compile est un code qui peut s'exécuter (ça ne dit pas qu'il est correct). Ton code python tu n'as aucune certitude qu'il est capable de s'exécuter dans n'importe quel cas. Il faut connaître tout les flow d'exécution possibles sur le bout des doigts, toutes les variables par cœur et ne jamais faire de typo ou tu le découvrira... un jour.
Ça n'a peut être pas d'importance pour toi, mais quand tu bosses sur un projet avec une équipe ça devient vite très difficile à gérer. Ouai c'est très agréable sur des petits trucs ou si tu bosses tout seul. J'aime bien scripter en Python
Si tu passes la phase de compilation à l'exécution (ou simplement que tu es en typage dynamique) ça peut péter n'importe quand à runtime pour des milliers de raisons.
Si tout les devs qui sont passés de Java 4 à Java 5 ne reviendraient pas en arrière ce n'est pas pour les caractères de cast gagnés ou l'introduction du printf. Les codes sont beaucoup plus robustes (CAML est une merveille dans ce domaine).
> pour des raisons de performances mais dans ce cas là on n'utilise pas Java.
Il y a énormément de raisons de ne pas utiliser Java mais là non. Si tu ne mets pas des mongoliens derrières le clavier, Java à des perfs très respectables. L'assembleur produit par hotspot est vraiment de bonne qualité, et je t'invite à comparer les sorties d'hotspot (voir http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_di(...) pour savoir comment activer le mode verbose) à celles de gcc fortran ou C. Le gagnant est assez rapide à trouver. Au dessus de ça, J2SE n'est pas un veau et les performances augmentent de manière significatives à chaque release. Le tableau de Java 1.[0-2] était totalement différent.
Je t'invite aussi à lire http://hal.inria.fr/docs/00/31/20/39/PDF/RT-0353.pdf . Tu peux implémenter les benchs en python, ça ne devrait pas te prendre plus d'un à deux mois.
Après tu peux rentrer dans un autre monde en tapant beaucoup plus bas niveau mais ce n'est pas le sujet ici.
[^] # Re: Grandiose
Posté par Moonz . Évalué à -1.
En Java non plus, cf le maintenant célèbre NullPointerException.
Et avec les annotations qui arrivent, il sera possible de faire des vérifications de type en Python. Ce sera au final proche de l'Objective-C qui permet à la fois de faire du typage statique et dynamique selon ce qui est le plus adapté pour ton projet, à la seule différence qu'en Python ce sera "par défaut" du dynamique tandis qu'en Objective-C c'est "par défaut" du statique.
> Si tu passes la phase de compilation à l'exécution (ou simplement que tu es en typage dynamique) ça peut péter n'importe quand à runtime pour des milliers de raisons.
Si tu ne le fais pas aussi. Non sequitur.
[^] # Re: Grandiose
Posté par lasher . Évalué à 3.
Pas tout à fait d'accord. Ce qui fait de Java un langage « presque » type-safe (« presque » à cause des types primitifs qui ne sont pas des objets), c'est la garantie que ton programme ne sera pas dans un état « bloqué » / « coincé » (stuck). Quand tu as un null pointer exception, ton programme se termine bien « correctement » (même si la sortie est une erreur). À titre de comparaison en C, comme il n'y a pas de sûreté des types, tu peux te retrouver avec des résultats totalement erronés sans pour autant avoir le moyen de vérifier « facilement » que c'est bien le cas.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 8.
Le langage Java est compilé en bytecode.
Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).
Quel est l'intérêt ?
Contrôle qualité le plus en amont possible.
La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule ?
Ok, cela peut être intéressant pour des raisons de performances mais dans ce cas là on n'utilise pas Java.
On peut vouloir un compromis niveau perf entre Python et le C.
Compiler, c'est un concept dépassé quand on fait du développement
Ce qui est dépassé, c'est de croire qu'on peut se passer de compilateur et que Python va tout révolutionner.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Dans ce cas, il faut utiliser un vérificateur de code où quoi que ce soit d'autres. Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.
De plus, quand tu développes, tu peux vouloir tester une fonction tout en sachant que le reste n'est pas encore développé. Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
L'utilisation du compilateur comme un indicateur de la qualité du code est l'un des trucs les plus effrayant qu'on puisse sortir pour justifier la compilation. Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
"La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule "
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps". Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois ("sinon y'a des erreurs du à des trucs pas recompilé mais qui devraient l'être (sic)"). Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Et quand bien même le temps serait vraiment ridicule, ce n'est pas une justification : tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Lors du développement d'un soft, personnellement je finis toujours par écrire un script qui compile, fais tout ce qu'il faut et qui lance le soft. Je modifie le code, lance mon script pour tester, modifie le code, lance le script, ...
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par windu.2b . Évalué à 7.
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur !"
Ben justement : utiliser le compilateur semble être tout à fait adapté puisqu'il comporte forcément un vérificateur de code.
Si ce dernier gueule, le compilateur renvoie l'erreur relevée.
" N'importe qui peut te pondre du code qui compile mais qui ne tourne pas."
C'est pour ça qu'on parle de bugs à la compilation (erreur syntaxique) et de bugs à l'exécution (pointeur 'null', dépassement de tableaux...)
"De plus, quand tu développes, tu peux vouloir tester une fonction tout en sachant que le reste n'est pas encore développé. Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester."
Et l'Homme inventa les interfaces.
"Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps". Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois ("sinon y'a des erreurs du à des trucs pas recompilé mais qui devraient l'être (sic)"). Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps)."
Un bon IDE peut compiler le code au fur et à mesure de son écriture. Eclipse (par ex) fait ça très bien, cela ne se ressent pas lors du développement, et voir en (quasi) temps réel les erreurs de syntaxe que l'on commet est un plus non-négligeable.
Et je préfère ça à ta méthode qui consiste à tout compiler d'un coup (donc traitement pouvant être long) pour s'apercevoir qu'on a oublié un ';' en fin de ligne...
"Lors du développement d'un soft, personnellement je finis toujours par écrire un script qui compile, fais tout ce qu'il faut et qui lance le soft. Je modifie le code, lance mon script pour tester, modifie le code, lance le script, ..."
Où est la différence avec un script Ant ?
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Mais juste une note pour Ant : j'aurais du préciser que j'écris ce script qui compile/lance sauf en python où c'est automatique. Le fait que Ant existe est la preuve que c'est une faiblesse du java mais Ant est justement un outil de plus à apprendre.
Ce que j'essaye d'expliquer c'est que, plus tu rajoutes des outils, plus tu complexifies et plus tu vas rajouter des outils pour simplifier. C'est une voie de garage par excellence et c'est complètement anti-productif. ("j'ai passé seulement 2heures et j'ai un super script Ant." Super. C'est 2h que tu n'as pas passé sur ton produit).
Je vais faire plus simple : j'ai deux machines qui font un travail. La première comporte un gros boutton rouge. La seconde comporte 5 bouttons : rouge, vert, mauve, jaune, bleu. Le manuel de la première explique qu'il faut appuyer sur le boutton pour la mettre en marche ou pour l'arrêter si elle est en marche. Le manuel de la seconde explique que le boutton mauve est un préchauffage, le boutton bleu l'initialisation, le boutton vert le lancement, le boutton rouge la confirmation du lancement et le boutton jaune l'arrêt de la machine.
Et toi, tu es en train de défendre que c'est logique d'appuyer sur le boutton bleu parce que, forcément, il faut bien initialiser la machine et que c'est une machine super facile à utiliser vu que quand tu veux la lancer il suffit de faire mauve, bleu, vert, rouge et encore, le mauve n'est pas toujours nécessaire, t'es pas obligé d'appuyer dessus si l'indicateur de température dépasse une certaine valeur.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par kowalsky . Évalué à 3.
jeu que tu développe en projet d'étude.
Ant, ça va te chercher le source par SSH, FTP, HTTP, WTFYW sur le server de dev, compile en local et repousse les class ou il faut sur le serveur de prod. ça, c'est super bien !
Ant, ça peut te lancer Firefox à la fin de la compilation de ta servlet avec les bon paramètre en URL.
Ant, ça peut te faire des compilations au petit oignon, avec de belle log au bonne endroit, toussa toussa.
Ant, ça te fait des Web Archive prêtent à l'emploi.
Ant, c'est un outil pour les projets conséquent, je m'en sert pas pour les trucs avec 20 class qui dorme dans un répertoire.
De plus, Ant, tu fais un fichier une fois, ensuite, tu le garde dans un coin et tu t'en sert toute ta vie.
[^] # Re: Grandiose
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Grandiose
Posté par Nonolapéro . Évalué à 1.
[^] # Re: Grandiose
Posté par Gof (site web personnel) . Évalué à 6.
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 2.
C'est donc que ca doit bien servir à quelque chose et pas seulement à compiler comme par exemple enchainer les test unitaires génerer la doc utilisateur, commiter avec un tag , mailer l'equipe avec le changeset, ....
Ah oui c'est vrai avec Ant/Java il y a une cible de plus la compil.
On en revient au sujet static vs dynamic typing
[^] # Re: Grandiose
Posté par benoar . Évalué à 3.
Gni ? Scons est écrit en python, mais n'est pas destiné pour python à la base ... T'as un exemple ?
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 3.
ton compilateur qui sert à rien :
- il rend ton programme plus rapide que si celui-ci était interprété
- il me permet de transformer mon programme dans un format standard utilisable par d'autre langages et outils.
- il me permet d'obtenir un fichier "portable" sans seposer de question existentielle sur l'encodage par défaut sur telle ou telle machine.
[^] # Re: Grandiose
Posté par Alex . Évalué à 3.
ton compilateur qui sert à rien :
- il rend ton programme plus rapide que si celui-ci était interprété
- il me permet de transformer mon programme dans un format standard utilisable par d'autre langages et outils.
- il me permet d'obtenir un fichier "portable" sans seposer de question existentielle sur l'encodage par défaut sur telle ou telle machine.
J'ai tendance a être daccord avec ploum
oui tu donnes de bonnes raisons d'utiliser un compilo, mais en phase de dev, je trouve que c'est un poids, une vérif statique du code ou une compile entre midi et 2 ou la nuit, ça me suffit, le reste du temps je trouve que c'est un poids, car souvent long.
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 3.
Le typage statique à un intérêt certain et il n'est pas forcément nécessaire de compiler pour utiliser un langage statique avec un interprète.
Avec les IDE actuels qui font de la compilation incrémentale ce n'est franchement plus un problème.
Les solution telle que Pylint apporte des solutions il est vrai, mais qu'en est t'il lorsque tu importes une librairie qui propose un contrat donné et que tu attends en fait un autre contrat (le fameux duck typing), genre un méthode qui ne figure pas dans la lib importée.
Si tu n'as pas fait la couverture de ton code correctement et que tu n'es jamais passé dedans dans tes tests, ca te pète à la figure devant le client.
Avec un langage statique et compilé ca n'arrive pas puisque ca compile pas.
[^] # Re: Grandiose
Posté par Alex . Évalué à 3.
Ce que je voulais dire, c'est que par exemple en ocaml on peut développer en mode interprété et compiler pour la livraison, il me semble qu'en python c'est également le cas, où l'on peut compiler en pyc pour la livraison.
La compilation incrémentale peut être un plus, en pratique sous eclipse ça a plus tendance à mettre ma machine sur les genoux et à m'empecher de bosser, de plus le fait de compiler est toujours plus lourd qu'une "simple" analyse statique du code.
Au sujet du duck typing je suis daccord avec toi, néanmoins ça arrive aussi avec du code compilé, comme par exemple en C++ quand le dev de la lib oublie d'utiliser un pointeur d ( c'est du vécu... et en plus c'était moi le dev en question ;) )
[^] # Re: Grandiose
Posté par Thomas Douillard . Évalué à 3.
Gni ? Une analyse statique ça peut être bien bourrain potentiellement suivant ce que tu veux analyser ... étant donné la difficulté du problème de vérification du code.
En C++, pour faire pêter le code avec une erreur de typage, il faut le vouloir, genre faire des casts de bourrains ... Pour ton histoire de pointeur, pas compris à quoi tu voulais faire référence, intuitivement je dirai utilisation d'un pointeur sur un objet alloué sur la pile, et dans ce cas c'est pas vraiment une erreur de type.
[^] # Re: Grandiose
Posté par Alex . Évalué à 0.
Gni ? Une analyse statique ça peut être bien bourrain potentiellement suivant ce que tu veux analyser ... étant donné la difficulté du problème de vérification du code.
Tout à fait, je pensais en fait juste aux erreurs de syntaxes et de typage, bref ce que le compilo vérifie également
Pour être complètement honnête, je n'ai utiliser la compilation incrémentale qu'en c++, ou éclipse refait un make all à chaque fois. Possible qu'en java cela soit mieu géré.
Pour ton histoire de pointeur, pas compris à quoi tu voulais faire référence
http://techbase.kde.org/Policies/Binary_Compatibility_Issues(...)
En c++ ce genre de truc est nécéssaire pour assurer la compatibilitée de tes libs. En réalité c'est un problème de mangling, mais bon, du point de vue développeur, ton programme plante à l'utilisation d'une classe précise (raccourci facile ? bon daccord... ;) )
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
mais avec des plateformes modernes comme .NET ou Java qui sont conçus pour être productif dans leur environnement de dev associé, cet argument tombe en miette. Il ne reste donc plus aucune raison de s'en passer.
[^] # Re: Grandiose
Posté par Octabrain . Évalué à 2.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 6.
S'il veut le transformer, il faut qu'il l'interprète, et pour ca il a intérêt à vérifier un ton code. Bref, c'est un premier rempart. Il ne remplace pas les autres outils de vérification, mais il est complémentaire, et a l'avantage d'être situé en amont de la chaîne (sur le poste du développeur). Bref c'est tout bénef, donc pourquoi s'en passer ?
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça
Blablabla. Les compilateurs sont pensés en binôme avec le langage, les possibilité de contrôle (qualité) statique du compilateur sont pris en compte dans la grammaire du langage. Évidemment avec un langage non conçu pour être vérifié statiquement/compilé comme Python...
t, surtout, cela n'a aucune valeur !
Ah bah oui, moi je connais des gens qui roulaient à 180km/h et qui se sont tués avec une ceinture de sécurité, c'est bien la preuve que la ceinture de sécurité n'a aucune valeur !
Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
public void foo()
{
//todo : implement this !
}
ca compile, et je peux tester autre chose.
Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
Mais c'est pas une méthode ! C'est pas un plus un gage de qualité ! C'est juste un outil qui permet d'éviter un certain nombre d'erreur, et qu'à ce titre il paraît idiot de chercher à s'en passer.
C'est comme les tests unitaires, les outils d'analyses statiques de code, toussa, ce sont des outils, qui offrent un certain nombre de vérification, et il est toujours mieux de les utiliser que de s'en passer.
Le bonus c'est que la plupart sont complémentaires.
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps".
C'est peanuts par rapport au nombre de vérification que fait le compilateur. Combien de milliers de tests unitaires en Python faudrait-il écrire pour effectuer toutes les vérifications que fait le compilateur Java ? et le temps d'exécution de ces tests ?
Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois
Bof, un serveur d'intégration fait tout ça très bien.
Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Sauf que toi t'as 100 fois plus de bugs à débogguer, pendant ce temps moi le compilateur il m'a prévenu 100 fois que ca servait à rien de lancer mon code et de chercher à comprendre, l'erreur elle est là, à la ligne 13, caractère 20, d'ailleusr il me suggère même quoi faire. Niveau perte de temps, je sais pas qui en perd le plus...
tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Forcement, si tu pars du principe que :
- faire l'analyse lexicale
- faire l'analyse syntaxique
- faire des vérifications sémantique : typage, initialisation des variables, etc.
- faire des vérifications de contrat d'interface, de versionning, etc.
tout ca ne sert à rien avant d'exécuter ton programme, effectivement tu dois rêver.
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Ben non, ca prouve juste une chose : que le temps de compilation est suffisamment anecdotique pour que tu recompiles systématiquement avant d'exécuter :-p
Ce qui est hallucinant surtout, c'est que t'es pas capable de te rendre compte du boulot que fait le compilateur (associé à un langage avec une syntaxe stricte et un typage statique). Tu dis que le compilateur fait rien, mais dans ta technique (sans compilateur), qui fait tout le "rien" du compilateur ? et quand ?
[^] # Re: Grandiose
Posté par lasher . Évalué à 5.
Je ... hein ? Un compilateur fait bien plus que ce que tu sembles croire.
La vérification des types, et la garantie de leur sûreté fait partie du rôle du compilateur... Quand la norme/le standard/la spécification du langage le permet. Par exemple en C, faire une vérification de type fiable est difficile, car le langage est faiblement typé. En Java, du moment qu'on exclut les types primitifs (donc pour tout le reste qui nous intéresse déjà beaucoup plus, à savoir les objets), il y a du lambda calcul un peu partout, avec une garantie de « type safety ».
Un compilateur sert aussi de « prouveur » -- même si le plus souvent les preuves ne sont que « partielles ». Je veux dire par là que le compilateur, en démontrant que des bouts de ton programme satisfont certaines propriétés -- par exemple, si tu fais une boucle dont l'en-tête est
M = 1000;
... // pas de réécriture de M
N = M
for (i = 0; i < N; ++i)
le compilateur devrait être capable d'inférer la borne de la boucle for, et du coup de déterminer certaines propriétés liées à ladite boucle. Bref, le compilateur est aussi là pour garantir certaines propriétés au programmeur concernant son programme. Après, la somme des propriétés dépend des objectifs du langage.
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.
Ben non. Plus tu peux déterminer de « fautes » en amont (je mets entre guillemets, parce que parfois soit on fait un truc « crade » mais qui va vite, soit on perd 10 à 20% de perfs, ou plus), et moins ton code risquera d'avoir de bugs. Plus exactement, en C, il est facile de compiler un code, « sans erreur », et que celui-ci plante, ou pire, donne un résultat inexact. En Java, ou encore « pire », en OCaml, certains types d'erreur (comme celles dues au transtypage, ou aux types en règle générale) sont totalement évitées car détectées à la compilation. Je ne vois pas ce que tu peux reprocher à ce comportement. Et oui, c'est clairement le rôle du compilateur de faire tout ça, car de son point de vue (et des specs du langage), il s'agit bien d'une erreur du programmeur.
Concernant l'inutilité de l'étape de compilation, je serais d'accord avec toi si les compilateurs étaient de bêtes traducteurs « code source » => « code machine », mais c'est très loin d'être le cas. Il y a bien sûr la partie front-end qui fait les analyses lexicales et grammaticales (et si je ne me trompe pas, une partie des analyses sur les types se fait à ce moment), mais juste après il y aussi le middle-end qui se charge de transformer le code pour l'optimiser, puis le back-end qui génère le code. Sans parler du fait que middle-end et back-end ont besoin de communiquer pour générer efficacement du code, etc.
Au final, un bytecode (bien) compilé, avec en plus du JIT pour les parties « chaudes » du programme peut permettre de gros gains de perfs au lancement de l'application.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Depuis le début, j'explique que je critique la nécessité de "compiler" à chaque fois dans un environnement de dev. Je ne critique pas le fait de checker le code et d'optimiser car c'est très utile mais, en cours de dev, ça devrait juste être facultatif.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ckyl . Évalué à 6.
Bha non tu ne trouves que *certaines* de ces errreurs. En gros tout ce que tu sais c'est que ton code tourne pour le flow d'exécution que tu as pris. On se retrouve toujours avec des flows d'exécution bizarres et merdiques en prod un fois qu'il y a un crétinutilisateur à l'autre bout.
Note que même si tu avais une couverture de code à 100% ça ne prouverait rien.
Si tu tiens vraiment à ne pas builder ton projet, tu noteras que les utilisateurs d'IDE en Java (il faut être très bête pour s'en priver) se retrouvent avec exactement le même comportement que python puisque seuls les classes modifiées sont recompilées. Cela dit, tu apprends assez vite que tu as tout intérêt à *toujours* tourner ton soft dans les *mêmes* conditions que tes utilisateurs.
On pourrait aussi parler des gros refactoring en typage dynamique, c'est toujours un grand moment de joie et de sérénité. C'est assez passionnant de passer son temps à chercher des canards boiteux.
Quand tu vois ce qui arrive encore à merder en ayant formatage de code/build/packaging automatique, une grosse suite de test unitaire/fonctionnel/intégration et un build après chaque commit. Bien je me dis que soit y'a des surdoués qui ne font jamais d'erreur soit y'a un paquet de c0wb0yz...
En pyton tu passes ton temps à lancer des execs pour voir si ton truc marchouille. Quand je lance un projet java en synchrone c'est par ce que les tests ont foiré, que les logs ne disent rien et qu'il est temps de brancher un debugger. Autrement tu lances les tests fonctionnels sur une autre machines et tu bosses sur autre chose. 12 secondes de compilation (32Mo de source) pour 40 minutes de tests... Quand tu n'es qu'au stade du test unitaire sur une nouvelle classe, avec un IDE c'est exactement comme python !
[^] # Re: Grandiose
Posté par Sachiel . Évalué à 2.
C'est juste qu'en Java il est compilé quand tu le tapes, dans ton IDE, avec les belles erreurs/warnings qui s'affiche directement, en te soulignant ce qui va pas et te proposant éventuellement un correction.
En python il est compilé juste avant l'exécution, et tu as une erreur quand tu lances ton programme...
Qui gagne le plus de temps à ton avis ? Celui qui détecte l'erreur en amont ou celui qui la détecte à l'exécution ?
[^] # Re: Grandiose
Posté par Alex . Évalué à 0.
et un bon ide ne se prend pas la tête à compiler à chaque fois que tu tapes une ligne, sinon quelle horreur pour les ressources.
[^] # Re: Grandiose
Posté par thedude . Évalué à 1.
Enfin, pas exactement, il va pas compiler a proprement parler le code fraichement tape, mais il va te souligner en rouge ton nom de classe si tu t'arretes de le taper pendant 2 secondes.
[^] # Re: Grandiose
Posté par Alex . Évalué à 2.
C'est bien ce que je disais ;)
Squeak arrive à faire ça très bien sans pour autant faire bruller ma machine ;)
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par thedude . Évalué à 1.
Apres, tu t'en sert souvent sur de gros projet, ou t'as besoin de faire beacuoup de choses. Donc forcement, ca bouffe des ressources, eclipse ou pas.
Pour l'ergonomie, ca s'addresse a des developpeurs, qui comprennent le fonctionnement intime d'une appli et ils peuvent donc se permettre certaines choses que tu peux pas te permettre dans une appli normale. Mais ouais, ya qq trucs qui sont bien pete couilles (le remapping des raccourcis est une horreur notamment, la gestion des plugins est assez foireuse aussi).
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Eclipse n'a tout simplement pas d'interface : c'est juste plein de fonctions (très puissantes et utiles, je l'admet) auxquelles on a assigné des bouttons et puis on a lancé ces bouttons au hasard dans une grosse fenêtre. Lotus Notes est comme ça, Open Office est dans le même genre. C'est la philosophie de GUI des années 90 quoi.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 3.
Genre le menu en clic droit qui est "presque" le même que le menu dans la barre d'outils.
Tu préférerais des menus ou la moitié des fonctionnalités sont présentes et l'autre dans la barre comme ca on est obligé de rechercher dans les 2 à chaque fois.
Pour ma part je constate que le menu contextuel porte bien son nom i.e qu'il est spécialisé en ft de l'objet qui est en dessous. Alors que la barre de tâche donne accès à des ft généralistes.
Ta critique adresse en fait l'architecture en plugin qui permet à chacun d'apporter sa pierre à l'édifice.
Forcément ca manque parfois d'homogénité, car les contributeur ne respecte pas tjs les mêmes règles et ne peuvent pas tjs anticiper toutes le extensions qui seront installéés par un utilisateur.
D'aileurs je crois me souvenir que tu adresses la même critique à Firefox qui suit la même philosophie.
Les offres plus contraintes ou moins populaires sont peut être plus homogène mais moins souple (ex: Chrome)
Tout est affaire de compromis entre souplesse et cohérence.
L'approche par plugin au moins facilite la diversité.
[^] # Re: Grandiose
Posté par thedude . Évalué à 2.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par Sachiel . Évalué à 1.
Compiler permet de détecter tes erreurs en amont tout en accélérant ton code pour quand tu vas le lancer plus tard. Tout ceci est fait pendant (j'insiste) que tu tapes ton code automatiquement, donc pendant que ton CPU est en attente.
Moi je vois les choses comme ça :
- tu détectes tes erreurs avant de lancer ton programme donc tu gagnes du temps sur leurs corrections.
- Tu à un code (pseudo-)compilé donc tu gagnes (un peu) de temps sur l'exécution du programme/des tests unitaires.
[^] # Re: Grandiose
Posté par kowalsky . Évalué à 2.
Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).
C'est quoi ce code natif ? De l'assembleur ? (Vrai question)
[^] # Re: Grandiose
Posté par ckyl . Évalué à 10.
http://en.wikipedia.org/wiki/Java_performance#Just-In-Time_c(...)
Voici un résumé très grossier:
On part sur un mode d'exécution interprété. On exécute le bytecode dans la JVM, à chaque instruction correspond une translation sur la machine cible. Quand une instruction à été exécutée on passe à la suivante.
Si Hotspot détecte que ça en vaut le coup, alors on produit du langage machine qui correspond, à peu près, au bytecode (si ca répond à ta question ce qu'on appel assembleur ce sont des symbole mnémoniques qui seront ensuite traduit en langage machine, une suite de bits). On se passera donc de l'étape de translation pour les prochaines exécutions. On peut faire des optims assez malines grâce au fait que l'on a accès à beaucoup d'informations: stats des exécutions précédentes, proco cible etc. Dans Hotspot il y a deux compilateurs qui sont plus ou moins agressifs.
Je disais à peu près car Hotspot est capable de faire de la désoptimisation. C'est à dire qu'il se permet de générer des optimisations non sûres reposant sur des hypothèses qui peuvent devenir fausses. Si il se rend compte à l'exécution que les hypothèses qu'il avait fait deviennent erronées, alors il remplace la frame optimisée par une autre moins optimisée et c'est reparti. Il se passe la même chose si entre la première moitié et la seconde de programme les prédiction de branches changent du tout au tout.
La JVM est vraiment une merveille d'optimisations (qu'on aime ou pas ce qui se trouve dessus). Les travaux sur le locking , les optimisations du compilateur, ou le garbage collector sont assez impressionnants. Voir: http://java.sun.com/products/hotspot/whitepaper.html
et http://java.sun.com/javase/technologies/hotspot/publications(...)
[^] # Re: Grandiose
Posté par kowalsky . Évalué à 2.
Merci beaucoup pour cette reponse ! Je ne regarderais plus jamais ma JVM comme avant ! :)
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Grandiose
Posté par benoar . Évalué à 2.
Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).
Python aussi est compilé en bytecode, et le bytecode est interprété. OK, il ne fait pas encore de JIT à part en utilisant PyPy, ce qui est plutôt expérimental.
[^] # Re: Grandiose
Posté par Fabimaru (site web personnel) . Évalué à 1.
Si t'as un module natif (pour un besoin quelconque), tu vas devoir avoir une version pour chaque archi, et pour chaque OS. Ou alors c'est l'utilisateur qui se tape la compil, avec les dépendances qui vont avec, ah ah. Autre problème.
À une époque pas si lointaine, il fallait Visual C++ pour compiler des modules pour Windows. Sauf si t'avais envie de te faire ta propre version de Python non-officielle avec GCC/MingWin.
Je vais proposer une parodie de ta solution: je fourni une image de VM pour mes programmes. Plus de dépendance de module. Plus de problème d'OS. Tout est réglé. Faite comme moi.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
C'est un bug de la distrib et ça se corrige. Mais c'est rarement le cas (et même très rarement) et, au moins, ce n'est pas le cas par défaut. Dans la toute grande majorité des cas, c'est ultra facile.
Et tu sais quoi ? Ta solution de VM est à présent utilisée par de nombreux logiciels qui se contentent de fournir une image Vmware d'un système configuré. (et à part ça, je vois pas le rapport avec ma solution à moi)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par Octabrain . Évalué à 8.
C'est pas un peu simplifié comme gestion de multiplateformes ?
> Tu lances "python main.py"
Tu rejettes distutils, soit, mais tu prends l'exemple de django (que je n'ai jamais vraiment utilisé, mais je vais m'inspirer de leur tuto) qui te génère X fichiers dès le début de ton projet. Puis dès que tu vas cumuler avec un autre outil ou 2, ça va vite reprendre l'allure d'usine à gaz que tu reproches à Java.
[^] # Re: Grandiose
Posté par Johan Charpentier (site web personnel) . Évalué à 3.
Un fichier settings.py, un fichier manage.py pour les commandes shell, un fichier url.py pour le root url conf. Auquel tu rajoute 2 fichiers mini par application (view.py et models.py) C'est tout.
5 fichiers au strict minimum pour faire tourner une instance Django qui permet déjà un paquet de choses.
Si tu veux des tests, des templates, des fichiers statiques, des middlewares, des fixtures, tu peux en rajouter mais tu n'est nullement obligé de le faire.
Je ne poursuivrai pas le débat car je connais trés mal distutils.
[^] # Re: Grandiose
Posté par grosprout . Évalué à 7.
Les gars, faut ouvrir un peu les yeux : quand tu dois commencer à utiliser des outils pour pouvoir utiliser tes outils, c'est un peu angoissant. La palme revient quand même à Gcc. Comme c'était compliqué de compiler, on a fait make. Comme faire un makefile, c'est conpliqué, on a fait configure. Comme configure c'était compliqué, on a fait autogen. C'est incroyable. Et Java fonce droit dans la même veine.
Ouais. Complètement d'accord. D'ailleurs, l'informatique en général c'est ça. À la base il y a le boulier, mais comme c'est trop compliqué, on fait un ordinateur. Mais comme compter en binaire c'est trop compliqué, on fait des langages de programmation. Vraiment n'importe quoi, cette démarche.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Par contre il doit connaitre, en plus du langage de programmation des tas d'outils pour faire fonctionner son langage de programmation et encore d'autres outils pour faire fonctionner les outils.
Se compliquer la vie pour tenter de la simplifier, c'est voué à l'échec sur le long terme, faut pas chercher très loin pour s'en rendre compte. Lorsqu'un programmeur passe 2 semaines pour réussir à compiler un projet sans toucher une ligne du projet lui-même (juste les makefile et les configure), n'importe qui avec un peu de recul dirait "mais c'est quoi ce délire ?". Mais bon, le nez dans le guidon est le lot de90% des gens. Y'a peu de gens qui se posent la question "mais au fond, c'est quoi le résultat qu'on aimerait avoir ?". Le problème de la vie c'est que poser cette question, c'est remettre en question le travail, les acquis, la souffrance endurée les années précédentes. Alors, on préfère se convaincre que la question ne doit pas être posée.
Autolink : http://ploum.frimouvy.org/?197-le-conte-du-mousse-et-des-vin(...)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est pas parcque l'outil est une merde qu'il faut remettre en cause le langage. Les autotools sont une bonne grosse daube niveau productivité, mais je peux te faire des autotools tout pourri pour gérer un gros projet Python avec les même problèmes.
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 5.
Avec Python tu as Django effectivement mais tu as aussi CherryPy, Pylons, TurboGears, Zope et j'en passe et des meilleurs.
En fait, tu as un standard / une spec qu'on appelle WSGI pour remettre de l'ordre dans tout ca et sur laquelle tous tes framework se basent ou le devraient, spec qui ressemble étrangement à une certaine API servlet et frameworks qui rappellent bien l'offre coté Java.
Et pour chacun d'eux lorsque tu ne prend pas la solution de base parce qu'elle se révele insuffisante en dehors du prototypage, que tu veux pouvoir choisir ton moteur de templating, ta base de donnée, ton ORM, tu dois te palucher des fichiers et des scipts de config à tire larigot l'homogénéité du standard XML en tant que fichier de conf en moins.
Tout pareil dis donc.
Pis avec le serveur web embarqué ca tient pas la route, il faut te coltiner l'interface avec un Apache / mod_python.
Mais là t'es chez toi en bon linuxien et admin tu maitrises tout ca en 3 ligne de commande et 2 fichiers. Ca tombe bien les javaiste aussi sont dans leur elt.
Pis après les libs standard pyhton sont pas suffisantes et tu veux récupérer tes proprs libs pour gérer le log ou encore te connecter à un annuaire LDAP ..
Et là fini les joies du "convention over configuration".
Avec Java c'est pareil . Tu peux faire mumuse avec un Tomcat et un framework unique et crâner en disant ca se fait en 3 clics
Reste que jusqu'il y a peu ( la phenomène RoR) on avait plus de fichier à configurer à la mimine et que le XML s'est imposé come standard avant cette apparition.
Tous tes frameworks python (hormis Zope que tu critiques pour sa lourdeur) sont issus de la même veine basée sur les conventions.
Rassures toi avec Java tu peux le faire aussi, quasiment tous les frameworks ont evolué en ce sens et d'autres sont né sur cette idée
comme par exemple Play qui est passé par ici
http://linuxfr.org/2008/09/04/24453.html
mais il doit en exister d'autres.
Bref ce que tu nous décris ce sont des pbs de choix de solutions d'architecture, de choix qui sont de plus en plus ardus à mesure qu'un ecosytème et son offre de composants s'enrichissent.
Python n'y échappe pas.
Reste le troll langage statique vs dynamique.
Ca tombe bien tu peux aussi utiliser ton langage dynamique préféré J2EE et ses librairies et frameworks comme JRuby On Rails qui est réputé plus robuste que son grand frère natifs, ou encore Grails et même Jython (avec ses wagons de release de retards) est présent.
A toi de choisir le mieux ou bien de rester avec ton Django, ses limites et qui à ce que je sache n'est toujours pas foutu de proposer un projet de forge convenable.
Mais tu as raison Django et ses 1928 sites à haute disponibilité témoignent pour lui
http://www.djangosites.org/
Bonne année à tous , elle démarre sur les chapeaux de roue.
Bozo pasJ2EEpasLeadArchitect
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 5.
La seule chose qui freine pour Ruby, Python et leurs frameworks, c'est que les SSII sont frileuses sur les nouvelles techs, ça on le sait ça a fait la même chose il y a 10-15 ans avec Java, et il y a 5-10 ans avec PHP. Et elles sont encore plus frileuses sur l'open-source parce qu'elles n'ont pas la "garantie" de fiabilité qu'offre un système vendu par une société commerciale, sur la base du "si ils le vendent ils vont écouter leurs clients / faire un bon produit / le maintenir / le faire évoluer". Et cet effet est aussi valable pour les clients de la SSII, qui même pour un prix supérieur préfèrent souvent des bases commerciales si elles ont une "garantie".
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben, tu l'avoues toi même dans le paragraphe suivant en tentant de trouver une explication à ce phénomène :)
c'est que les SSII sont frileuses sur les nouvelles techs, ça on le sait ça a fait la même chose il y a 10-15 ans avec Java, et il y a 5-10 ans avec PHP.
Java 1.0 : 1995
PHP 1.0 : 1995
Python 1.0 : 1994
Et cet effet est aussi valable pour les clients de la SSII, qui même pour un prix supérieur préfèrent souvent des bases commerciales si elles ont une "garantie".
Ben oué, une plateforme bien conçue, supportée, qui offre une rétrocompatibilité, forcement, ca demande des moyens que veux-tu.
Il est où le standard Python ? Elle est où la rétrocompatibilité dans Python 3.0 ? Elle est où la bonne conception du GIL à l'heure du multi-threading ?
Ah ces SSII, qu'est ce qu'elles attendent pour coder en Python ? Qui veut coder une application qui dans 10 ans sera inmaintenable parcque Python 5 aura cassé 2 fois la compatibilité et qu'on trouvera plus un couillon qui sait faire du Python 2.6 ?
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Personnellement, j'ai un gros problème avec Java (alors que c'est avec Java que j'ai commencé l'informatique, que j'ai failli abandonné le domaine jusqu'au jour où j'ai découvert le C). Et j'aime troller. Du coup, on comprend mieux mes messages ;-)
Mais plus sérieusement : J2EE est bien (waw, ça me fait mal de le dire). C'est la solution actuelle. Mais J2EE est devenu trop complexe, trop gros. Le futur est à des outils plus légers dont, je pense, font partie Django et Python. Et eux-même seront remplacés par autre chose dans quelques années, c'est l'évolution qui veux ça. Et selon que l'on soit conservateur, que l'on soit confronté à des problèmes présents, urgents et concrets ou que l'on soit idéaliste, rêveur et un peu visionnaire, on soutiendra Cobol, J2EE ou Python. Et dans quelques années, on rechangera...
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 3.
Cela dit pour moi Python n'est pas une alternative crédible à mon sens, cette plateforme est beaucoup trop bancale dans un contexte de plateforme généraliste. MS a .NET comme alternative sérieuse, mais y'a aussi Adobe qui se lance sérieusement côté serveur.
Comme je l'ai mis plus haut, Python existe pourtant depuis que Java a été créé, et ils n'ont pas du tout eu le même succès, ca me paraît être vraiment optimiste de croire que la vapeur va se renverser...
[^] # Re: Grandiose
Posté par lasher . Évalué à 6.
[^] # Re: Grandiose
Posté par wilk . Évalué à 3.
Si la maintenance d'un programme ne dépendait que de la compatibilité ascendante du langage ce serait merveilleux !!! Mais c'est déjà bien d'amener la discussion sur la maintenance, bien plus importante que la correction de bugs.
Déjà ça dépend de bien d'autres facteurs comme l'environnement système, les bibliothèques utilisées, les bases de données etc. Mais là tu vas nous expliquer, avec raison d'ailleurs, comment java résout le problème beaucoup mieux que python. Mais surtout ça dépend de la clarté du code et de la simplicité de son architecture. Et c'est là qu'entre en jeu les avantages des langages comme python avec un code beaucoup plus concis et beaucoup plus explicite. Souviens toi toujours de la règle qui dit qu'on passe beaucoup plus de temps à faire évoluer un code qu'à l'écrire ou à maintenir l'existant. Il ne faut pas se focaliser sur le bug de syntaxe, ce genre de bug, mis à part pour les départs de navette spatiale, généralement ils ne sont pas très gênant et se réparent dans tous les cas très rapidement. Et quand bien même, ce n'est ni par la compilation ni par les tests unitaires qu'on s'en protège, mais plutôt par des solutions de backup et de journalisation. Par contre le bug du client qui au dernier moment dit que ce n'est pas du tout ça qu'il voyait, celui la il est très fréquent et beaucoup plus difficile à déceler à la compilation ou au checker !
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 3.
C'est pas le seul soucis, mais ça reste un gros soucis quand même. Regarde les "experts Cobol", ils se font des couilles en or car ils sont devenus rares et indispensable à maintenir des applis codés dans une vieille techno. J'imagine même pas ce qu'adviendrait d'une application Python codé aujourd'hui dans 10 ou 15 ans...
Et c'est là qu'entre en jeu les avantages des langages comme python avec un code beaucoup plus concis et beaucoup plus explicite.
Bof. Quand on est habitué, un code java est tout à fait lisible. Ce qui compte le plus pour moi c'est le nommage, la séparation des responsabilité et l'intuitivité des choix de décomposition. Après quelque soit le langage, le développeur étant censé le maîtrisé...
Et quand bien même, ce n'est ni par la compilation ni par les tests unitaires qu'on s'en protège, mais plutôt par des solutions de backup et de journalisation.
Franchement quand on fait de la maintenance, pour moi la priorité c'est d'assurer la non-régression, et tout les outils/méthodes qui peuvent m'offrir un certain niveau de sécurité sont le bienvenu. Bien plus que les backups ou la journalisation qui sont des problématiques totalement différentes de la maintenance. Ca c'est une problématique d'exploitation/infrastructure qui est globalement indépendance de ton langage de programmation.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Un truc qui me fait peur avec les "experts J2EE", c'est qu'ils m'ont tous toujours tenu le même discours concernant la lisibilité du code :
- Les commentaires sont inutiles, un bon code parle de lui-même.
- Il faut écrire le moins de lignes possibles : pas d'espaces entre les classes, pas de commentaires "inutiles"
- Les commentaires nuisent à la lisibilité du code (sic).
Bon, ce n'est évidemment pas lié au langage mais je trouve significatif que tous les chefs de projets J2EE (et certains C++) m'aie sorti, à peu de choses près, ce genre de choses. Et généralement ces règles sont même écrites sur la page Coding Rules du wiki !
J'ai pour habitude, lorsque j'ai pris du temps à comprendre un bout de code, de mettre un commentaire expliquant ce que j'ai compris (histoire de pas devoir refaire le boulot). Durant ma brêve carrière J2EE, ces commentaires étaient systématiquement effacés par les commit après moi.
Mais je reconnais 100% que ce n'est pas techniquement lié au langage. Je pense que cela fait plus partie d'une culturee très présente dans le milieu J2EE.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 3.
En fait la philosophie marche à mon sens, à condition que :
- le code doit parler de lui-même. Et c'est pas facile. Mais c'est justement là le but de la philosophie "pas de commentaire" : faire en sorte que le code parle de lui-même.
- il ne faut pas s'empêcher de documenter les API (doxygen toussa)
- il ne faut pas s'empêcher d'ajouter un commentaire quand c'est pertinent (signaler la raison qui a conduit à utiliser telle ou telle méthode, signaler un lien vers un pattern, signaler un hack)
Bref, c'est une philosophie qui a du sens si son objectif est de forcer le programmeur à pondre un code qui parle de lui-même. Si l'objectif est uniquement de ne pas "polluer" le code, ca ne marche pas.
Car les commentaires ca reste compliqué à maintenir : bien souvent ils ne sont pas maintenus car pas "utiles" à la bonne exécution du programme, et du coup on se retrouve avec des informations obsolète, voir fausse ou contradictoire, bref une vraie plaie.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Personnellement, je suis en train de tester une nouvelle approche : plutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 1.
Pas convaincu :)
Personnellement je me pose systématiquement des questions existentielles au moment de nommer mes variables et méthodes, pour qu'elles soient le plus parlante possible et être compris sans commentaire supplémentaire.
lutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.
Oui ca revient à ce que je disais plus haut : il faut ajouter un commentaire quand le "pourquoi" n'est pas trivial. Ca paraît beaucoup plus pertinent. Pour le reste, il faut que le code soit auto-descriptif, il ne l'est pas par naturellement.
[^] # Re: Grandiose
Posté par lasher . Évalué à 4.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 2.
> en Java :
class Machin {
/**
...
*/
public String truc() {
...
}
/**
...
*/
public String truc(String blah) {
...
}
/**
...
*/
public String truc(String blah, int zorg) {
...
}
/**
...
*/
public String truc(String blah, int zorg, boolean asif) {
...
}
}
> en Ruby :
class Machin
=begin
...
=end
def truc(*args)
...
end
end
Rien que sur ce détail (il y en a d'autres) on est "obligé" si l'on veut bien commenter de se taper plusieurs blocs de commentaires là où un suffirait largement.
Pour inciter un codeur à accompagner son travail de commentaire, il faut qu'il ne se sente pas comme un bon Sisyphe à pousser un rocher qui de toute façon retombe dès que le sommet de la colline est atteint. S'il a l'impression que son travail est inutile, soit parce qu'il pense que son code est déjà limpide, soit parce qu'il voit que de toute façon une fois le code à peine modifié il faut faire trois fois autant de modifications de commentaires, le codeur il n'a pas très envie de commenter.
Oh, je suis sûr qu'il y a des moyens de "gruger" avec Java et de mettre en place du commentaire propre et non redondant, mais je n'ai pas passé beaucoup de temps sur cette plate-forme (ce qui me dérangeait plus que la redondance de commentaires c'est le redondance de code).
[^] # Re: Grandiose
Posté par Octabrain . Évalué à 2.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 3.
Par exemple, en Java, si une méthode à besoin de travailler sur un objet qui implémente une interface IJeSaisFaireQuelqueChose pour utiliser sa méthode abstraite faireQuelqueChose, alors je vais devoir implémenter l'interface pour chaque objet passé en paramètre, voir dans certains cas faire des héritages de classes définies dans des bibliothèques externes pour pouvoir leur coller juste une bête interface.
En Ruby, si une méthode à besoin d'un objets qui réponde à la méthode faire_quelque_chose(), il suffit que mon objet répondre à cette méthode et ça roule. Si vraiment je veux faire mon paranoïaque je peux tester si l'objet répond à la méthode à la réception de l'argument et lancer une exception si ce n'est pas le cas. Ca permet de découpler beaucoup mieux les classes.
Encore mieux, si j'ai une instance d'objet à passer à ma méthode, et qu'il n'a pas la méthode faire_quelque_chose(), je peux faire un module contenant une implémentation de faire_quelque_chose() et le coller à la volée à l'instance (ou à la classe) avant de le donner à manger à la méthode en question, ce qui simplifie énormément le développement orienté comportement.
On y gagne en lisibilité (code plus concis, moins de méthodes vides juste pour implémenter des interfaces, moins de méthodes qui se contentent d'en appeller une autre du même nom pour faire varier le nombre de paramètres, moins de sous-classes définies uniquement pour donner un nouveau comportement à du code existant), en temps (pour écrire des commentaires, des tests), et en réutilisabilité (pas besoin de se taper des diagrammes d'héritages ou des API de 1000+ pages pour réutiliser des libraries bien claires et bien commentées, le code est plus facile à découpler et facotriser).
Je sais que ça fait peur, on a l'impression qu'il n'y a plus de structure, que les autres développeurs (qui sont forcément nuls, fainéants, etc.) ne sont plus obligés de suivre strictement des lignes de conduite rigides et indépassables et vont faire de la merde, forcément, mais franchement, même avec Java un développeur qui fait de la merde peut vraiment faire des trucs bien puants, bien crados. Ce n'est pas la flexibilité du langague qui fait que l'on pond de la merde ou pas, c'est la méconnaissance des bonnes pratiques et la paresse.
[^] # Re: Grandiose
Posté par Octabrain . Évalué à 1.
La justification de l'imposition des types est débattue plus haut dans le thread.
[^] # Re: Grandiose
Posté par thedude . Évalué à 1.
et tu vas passer 2 jours en debug a comprendre ce qu'il se passe.
c'est pas equivalent. La seconde notion est certainement utile, mais elle n'est clairement pas du tout equivalente.
Un truc qui s'en rapprochera sera plutot un public void truc(Object[] obj);
Et si je vois un truc comme ca un jour dans du Java, c'est une balle dans la nuque sur la place publique pour le cochon qui l'a ecrit.
[^] # Re: Grandiose
Posté par Alex . Évalué à 0.
A la rigueur je préfère la méthode c++ avec des valeurs par défaut aux paramètres
[^] # Re: Grandiose
Posté par Bastes . Évalué à 4.
Et non, effectivement, les deux ne sont pas équivalente. On peut utiliser les deux notations pour produire des résultats identiques, mais si elles étaient équivalentent je n'aurais pas pris de temps ici pour pointer leur différence.
Sinon, oui on peut émuler le duck-typing en Java avec un tableau d'objets ou un hash (c'est d'ailleurs ce que tôt ou tard on finit par faire quand on en a assez de devoir faire évoluer X méthodes quand on change juste une petite chose dans l'un des paramètres fondementaux), mais c'est tellement plus simple d'utiliser un langage fait pour ça, d'autant plus que les types natifs de Java rendent souvent l'opération pénible.
Oh, je n'aime pas beaucoup répondre "ligne par ligne" parce que souvent les citations sorties du contexte sont mal interprétées, mais celle-là est trop belle :
Et si je vois un truc comme ca un jour dans du Java, c'est une balle dans la nuque sur la place publique pour le cochon qui l'a ecrit.
Ben oui, c'est bien là le problème. En Java, on dit ne pas aimer la répétition, mais prône la verbosité. Ruby prétends que la verbosité est contre-productive, et qu'elle n'est rien d'autre qu'une autre forme de répétition de structure. Par exemple, si en Java je veux qu'une méthode fonctionnant de la même façon soit donnée à plusieurs classes existantes n'ayant pas d'ancêtre commun modifiable, ça va m'obliger à :
- créer une interface
- créer des sous-classes de chaque objet
- créer un objet qui contienne ma méthode
- créer dans mes sous-classes un conteneur pour mon nouvel objet
- créer une instance du nouvel objet dans le constructeur de chaque sous-classes
- créer dans chaque sous-classes une méthode paravent pour appeller celle qui m'intéresse du nouvel objet
Beurk
En Ruby :
- créer un module contenant ce qu'il faut pour que ma méthode marche
- implémenter ma méthode (à la volée dans un instance ou dans la classe, ou dans la déclaration de ma classe si c'est moi qui la crée) pour chaque classe
Hop
[^] # Re: Grandiose
Posté par Bastes . Évalué à 2.
- intégrer mon module (à la volée dans un instance ou dans la classe, ou dans la déclaration de ma classe si c'est moi qui la crée) pour chaque classe
[^] # Re: Grandiose
Posté par 2PetitsVerres . Évalué à 2.
Mouais, je connais pas grand monde qui pense que les commentaires inutiles sont utiles. Au mieux, ils pourraient être pertinent.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Grandiose
Posté par windu.2b . Évalué à 3.
Parce qu'autant, on peut discuter longtemps de l'utilité (ou non) de commentaires au sein d'une méthode, autant je doute que quiconque remette en question les commentaires Javadoc précédant ladite méthode...
[^] # Re: Grandiose
Posté par Bastes . Évalué à 2.
Par contre, c'est toujours mieux de faire un code court et lisible qu'un code long et incompréhensible, à commentaire égal.
[^] # Re: Grandiose
Posté par wilk . Évalué à 3.
Encore faut-il retrouver le dit code ! J'ai encore quelques applis en java que je n'ai pas encore réécrite en python. Je passe mon temps à chercher où ce passe quoi ou à quoi pouvait bien servir tel autre code !
La encore Ploum a mis juste, on sent le vécu, le code était-il du M, du V ou du C !
Allez, je vais quand même avouer une chose, j'ai énormément appris quand j'ai fait du Java, à me structurer, à prévoir les failles etc. C'est un très bon langage théorique je dirai.
Franchement quand on fait de la maintenance, pour moi la priorité c'est d'assurer la non-régression, et tout les outils/méthodes qui peuvent m'offrir un certain niveau de sécurité sont le bienvenu. Bien plus que les backups ou la journalisation qui sont des problématiques totalement différentes de la maintenance. Ca c'est une problématique d'exploitation/infrastructure qui est globalement indépendance de ton langage de programmation.
La maintenance au niveau bug sur un programme qui tourne depuis 10 ans, normalement elle est quasiment inexistante... C'est d'ailleurs, pour ça, qu'on n'a plus les programmeurs qui vont avec. J'ai des applis qui ont une quinzaine d'années, en access et windev qui tournent comme des horloges, personne n'osera dire que c'est grâce au langage ! Par contre si je dois faire des grosses modifications, j'aurai plus vite fait de les réécrire en python que d'essayer d'aller voir si à l'époque j'écrivais du code maintenable ! Et la ce qui est important c'est d'avoir prévu des exports de données tout simplement.
Le piège, que Ploum a encore très justement mis en avant, est justement de penser que les problèmes d'exploitations sont différents des problèmes de programmation.
Dans 10 ans qu'est-ce qui m'empêchera de retrouver un environnement exactement identique à celui d'aujourd'hui ? Je n'ai besoin que de vim, python et deux ou trois librairies d'une taille ridicule. Grâce à la surveillance de Guido (de garder une implémentation simple) je suis même assuré de pouvoir corriger moi-même les éventuels bugs que je pourrai trouver dans le langage lui-même ou une des bibliothèques ! C'est là que ce jouera toute la différence dans le temps.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu m'expliques le rapport avec le langage ? L'organisation des sources et leur décomposition n'a pas grand chose à voir là dedans !
Par contre si je dois faire des grosses modifications, j'aurai plus vite fait de les réécrire en python que d'essayer d'aller voir si à l'époque j'écrivais du code maintenable !
Ah oué et demain t'as une faille de sécu et t'as 24h pour la corriger, tu fais quoi ? Tu réécris tout en Python ?
Grâce à la surveillance de Guido (de garder une implémentation simple) je suis même assuré de pouvoir corriger moi-même les éventuels bugs que je pourrai trouver dans le langage lui-même ou une des bibliothèques !
C'est le problème de ton "je". Si t'es plus là ? faudra trouver quelqu'un qui maîtrise Python 2.x quand tout le monde sera à Python 5. Le mec s'apercevra peut être même que le bug est dans une lib Python que plus personne ne maintient parcque elle a été réécrite 3 fois...
[^] # Re: Grandiose
Posté par wilk . Évalué à 2.
Tu m'expliques le rapport avec le langage ? L'organisation des sources et leur décomposition n'a pas grand chose à voir là dedans !
C'est tout simple, j'ai réécrit des programmes java en python, ils perdent statistiquement la moitié en lignes de code tout en devenant encore plus clairs et explicites (pas comme perl par ex). Ils perdent du volume d'une part parce que le langage est moins verbeux mais aussi par ce qu'il est moins contraignant.
Ah oué et demain t'as une faille de sécu et t'as 24h pour la corriger, tu fais quoi ? Tu réécris tout en Python ?
Je parle de grosses modifs. Si c'est pour corriger des bugs, quelque soit le langage comme je t'ai dit, ce n'est pas le plus gros problème, pas la peine de réécrire quoique ce soit.
C'est le problème de ton "je". Si t'es plus là ? faudra trouver quelqu'un qui maîtrise Python 2.x quand tout le monde sera à Python 5. Le mec s'apercevra peut être même que le bug est dans une lib Python que plus personne ne maintient parcque elle a été réécrite 3 fois...
Justement ce n'est pas le problème de mon "je" vu ça restera simple. L'avantage du KISS. Ce qui fait aussi que les soit disant problèmes d'incompatibilités entre les versions de python sont assez insignifiantes. Et de toutes façon, je me répète, l'environnement change beaucoup plus vite et oblige à beaucoup plus d'adaptations que les contraintes du langage.
Tu te focalises sur LE bug de l'application qui n'a pas évolué depuis 10ans et que tu n'aurais peut-être pas eu grace à la compilation...
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
Euh, même si tu divises le nombre de lignes par 2, je vois toujours pas le rapport, pour retrouver la méthode bidule, t'iras toujours la chercher dans la classe machin dans le fichier truc dans le dossier pouet.
Non ton argument tiens pas 2 minutes.
quelque soit le langage comme je t'ai dit, ce n'est pas le plus gros problème, pas la peine de réécrire quoique ce soit.
Mais mon argument c'était ca : il faut que tu trouves quelqu'un de compétent qui sache faire de genre de maintenance corrective minimale mais indispensable.
Moi je mets ma main à couper que dans 10 ans il va être super balaise de trouver un mec suffisament compétent pour intervenir rapidement sur ce genre d'appli, et je mets ma main à couper que la plupart des frameworks actuels ne seront plus maintenu pour Python 2.x, et qu'il faudra donc mettre la main à la patte de ces frameworks également... Bref, c'est vraiment un pari risqué pour n'importe quelle appli destiné à tourner pendant un petit moment.
Tu te focalises sur LE bug de l'application qui n'a pas évolué depuis 10ans et que tu n'aurais peut-être pas eu grace à la compilation...
On est plus dans la compilation là, on parle d'utiliser une plateforme mal conçu qui nécessite donc de subir des évolutions qui "cassent" l'existant. Un langage dont la sémantique n'est pas standardisé par un consortium d'industriel (ECMA, ISO, OASIS) et donc ne répond pas à leurs préocupation, un langage où les concepteurs disent "le GIL c'est pas un problème, le multi-threading ca sert à rien" (ca c'est visionnaire), bref, autant de chose qui font peur à n'importe quel ingénieur qui doit évaluer une techno pour être utilisée dans telle ou telle techno. Et un décideur qui a un ingénieur dubitatif devant lui, il prend peur et va se rassurer chez Sun MS ou autre IBM qui va lui offrir des garanties de support sur le long terme.
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 2.
Tu sors ca d'où ?
Les threads existent en python aussi.
http://docs.python.org/library/threading.html
Qu'est-ce qu le le GIL ?
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
http://en.wikipedia.org/wiki/Global_Interpreter_Lock
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 1.
Il existe des implémentations qui n'utilisent pas le GIL.
Merci à Timaniac de nous l'avoir pointé :)
http://linuxfr.org/comments/969578.html#969578
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Grandiose
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 2.
Python ne peut être un langage généraliste qui offre une plateforme complète puisqu'il s'appuie sur le C pour pallier ses défauts et rest un langage de glue.
Au fait c'est quoi la lib graphique native python.
Tkinter , non c'est du Tk et ca s'inspire de la philosophie Tcl.
wxWindows ? C++
Qt ? C++
Gtk ? C
Fox ? c++
Swt ? Java
Swing ? Java
C'est sûr que si on abandonne le GIL ca va faire mal, il doit bien y avoir des bouts de not thread-safe.
Guido a beau esquiver en invoquant le web et le fait qu'une architecture evolutive doit permettre de fonctionner sur plusieurs noeuds, et que les threads servent à rien, il y a tout le reste: les applis natives qui elles peuvent tirer avantage du multi-coeur.
Sans oublier les clients riches.
Merci Timaniac de m'avoir ouvert les yeux.
Ca me conforte dans le choix d'un langage dynamique au dessus de la JVM qui ne réinvente pas la roue: Groovy.
Je vais suivre Grails de plus en plus près
[^] # Re: Grandiose
Posté par Thomas Douillard . Évalué à 2.
Sauf si c'est pas le cas avec l'implémentation python :
* tu peux pas supposer grand chose sur l'ordre et le temps d'exécution de tes deux trheads, et l'un d'eux peut être interrompu en plein milieu d'une écriture disque. Si l'autre thread a besoin du même fichier, faut un mécanisme pour être sur qu'ils y accèdent pas tout les deux "en même temps".
* Pour la synchro, pareil, tu peux lancer un calcul dans un thread, laisser l'autre faire ce qu'il veut, et à un moment attendre la fin du calcul par exemple.
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 4.
Q. Multi-core processors will be standard even on laptops in the near future. Is Python 3.0 going to get rid of the GIL (Global Interpreter Lock) in order to be able to benefit from this feature?
A. No. We're not changing the CPython implementation much. Getting rid of the GIL would be a massive rewrite of the interpreter because all the internal data structures (and the reference counting operations) would have to be made thread-safe. This was tried once before (in the late '90s by Greg Stein) and the resulting interpreter ran twice as slow. If you have multiple CPUs and you want to use them all, fork off as many processes as you have CPUs. (You write your web application to be easily scalable, don't you? So if you can run several copies on different boxes it should be trivial to run several copies on the same box as well.) If you really want "true" multi-threading for Python, use Jython or IronPython; the JVM and the CLR do support multi-CPU threads. Of course, be prepared for deadlocks, live-locks, race conditions, and all the other nuisances that come with multi-threaded code.
http://www.artima.com/forums/threaded.jsp?forum=106&thre(...)
[^] # Re: Grandiose
Posté par Zenitram (site web personnel) . Évalué à 2.
Plus on parle de Python, et moins je comprend la "mode" Python : il y a des limitations relativement contraignantes, et la seule façon de passer outre est de... Changer de langage (Si j'ai bien compris, Jython ou IronPython ne sont pas 100% compatible avec Python, c'est ça?)
[^] # Re: Grandiose
Posté par Alex . Évalué à 1.
On critique la lourdeur de java, la question est de savoir si forker n fois une vm n'est au final pas plus consommateur de ressources (ptet pas pour 2 cores... mais bon quand on voit qu'intel à préparer un proto à 80 cores...)
Changer de langage (Si j'ai bien compris, Jython ou IronPython ne sont pas 100% compatible avec Python, c'est ça?)
jconnais pas python, mais si jai tout compris, si le langage reste le même, c'est tout ce qui a autour qui change (bindings C d'un coté, java ou .net de l'autre). Etant donné la variété de libs java qui éxiste, je ne pense pas que ça soit un gros problème. En fait AMHA la question est de savoir si les frameworks python (django, zope et cie) sont compatibles.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Perso, je vois le multicore comme une opportunité de faire tourner des processus différents, pas de gagner en perf sur mon programme monoprocessus. D'ailleurs, si les perfs sont si importantes pour ton programme, tu ne l'écris pas en Java ou en Python.
Je trouve donc que la discussion n'a pas beaucoup de sens et qu'avant d'optimiser un programme pour qu'il utilise le multi-core, il faut d'abord avoir le programme complètement fonctionnel et optimisé au poil sous tous les autres aspects.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par lasher . Évalué à 7.
Tout dépend le type de code. En Java, pour du code qui utilise du calcul intensif par exemple, avec beaucoup d'irrégularité mémoire (pointer chasing), on a des programmes aussi rapides qu'en C++ (à condition de faire du « vrai » C++, et pas du « C avec namespaces et templates » -- dans ce dernier cas, C gagne, mais pas forcément de beaucoup).
En Python, puisqu'on peut embarquer relativement simplement des fonctions C externes, il est dommage de ne pas avoir de « vrai » modèle de threads.
Dernière chose : l'argument du « de toute manière les codes actuels n'exploitent pas le multicore », bien qu'énonçant un fait véridique, n'est pas solide : jusqu'à il y a peu, l'intérêt d'utiliser du multiprocesseur en dehors de programmes serveur ou de certains programmes types (comme Photoshop/Gimp par ex) n'avait pas vraiment de sens. Maintenant qu'on est coincé à la même fréquence mais avec plus d'unités de calcul, il va falloir réapprendre à programmer pour inclure l'option parallèle. Parce que plusieurs coeurs c'est bien, mais s'ils doivent se partager non seulement la mémoire cache (4 Mo pour 2 coeurs c'est très bien, 4 Mo pour 4 ça devient pas très grand), mais aussi - et surtout - le bus mémoire, tes processus parallèles, pour peu qu'ils soient limités par l'accès à la bande passante mémoire, risquent de faire la gueule. Je ne parle même pas de la concurrence pour accéder à une carte réseau, ou un disque dur, etc. Le problème existait déjà avant, mais avec la présence de plusieurs coeurs, il s'amplifie.
En fait le multicore amène dans le grand public (et donc plus précisément aux programmeurs qui programment « pour » ledit grand public) des problématiques qui auparavant étaient réservées au domaine du calcul scientifique. Dans l'absolu, je préférerais de loin que tout soit programmé séquentiellement, car on s'enlève tout un tas de bugs potentiels, mais le fait est que je vois difficilement comment on peut se passer de paralléliser certains bouts de codes. Par exemple, un certain nombre de programmes qui permettent de faire du calcul scientifique sont faits en Python, avec derrière des bibliothèques mathématiques programmées en C. Bon, très bien. C'est juste dommage de ne pas pouvoir paralléliser les calculs quand ont sait qu'on a un système multicore. Idem pour tout ce qui est encodage, filtre pour images, etc.
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 2.
http://www.infoq.com/news/2007/05/ruby-threading-futures
Tu trouveras un point de vue intéressant et approfondi sur cette problématique du GIL pour ruby. Y est abordé la solution d'Erlang et de ses "lighweight processes" et de l'approche m:n qui résoud le cas des multi procs.
A comparer avec Stackless Python
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
En tout la fin de l'article résume bien la situation : y'a que JRuby et IronRuby qui offrent véritablement une concurrence d'exécution. La conclusion : "oué peut être bien que le futur des threads dans Ruby va évoluer".
Bref, à l'heure actuelle ils essaient juste de contourner le problème en proposant des solutions loin d'être friendly pour les programmeurs, et loin d'être friendly pour les perfs (la gestion multi-thread est plus efficace que multi-process au niveau OS, lancer plusieurs processus implique également le chargement de 2 VM, plus de conso mémoire toussa).
[^] # Re: Grandiose
Posté par Bozo_le_clown . Évalué à 2.
des threads natifs qui embarquent chacun leur propre ordonnanceur , c'est peut-être la voie à suivre.
Sinon, sous OS/2 je bossais avec de la mémoire partagée en C et je regrette cette époque.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Grandiose
Posté par Alex . Évalué à 2.
Les threads pratiques ? évidemment, mais ils apportent leur lots de galères
Les forks plus surs ? surement, mais ça manque de souplesse. L'idéal serait encore de laisser le choix aux dev (c'est un peu le cas avec jython ou jruby, mais je me laisse dire que ces implémentations ne sont pas encore au point, en tout cas c'est le cas pour jruby).
Néanmoins l'appoche de python semble avoir été faite dans un soucis de gain de perfs si j'en crois ce qui a été écrit ailleurs dans cette discussion.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
Nan de simplicité : faciliter l'utilisation de lib C sans se poser de question quand aux accès concurrent.
Du coup ils se retrouvent face à un piège : s'ils veulent ajouter le support de la concurrence sans casser l'existant, il sont obligé de mettre des locks partout par défaut (là où normalement le programmeur choisi intelligement où il faut les mettre);.. et c'est globalement 2 fois plus lent lors des tests qu'ils ont fait. Conclusion le choix de départ les conduits aujourd'hui dans une impasse : l'intérêt d'avoir plusieurs threads s'exécutant en parallèle devient de plus en plus intéressant (les machines neuves sont toutes multi-core) mais ils ne peuvent pas y passer sans casser la sémantique ou alors une lourde refonte de l'interpréteur avec un impact désastreux sur les perfs...
[^] # Re: Grandiose
Posté par wilk . Évalué à -2.
Si tu n'arrives pas à comprendre qu'un code plus court, plus concis et plus clair aide à s'y retrouver, je vois pas quoi rajouter... Mon argument ne tien peut-être pas a tes yeux deux minutes, mais ça fait quelques années que je l'apprécie au quotidien :-)
Moi je mets ma main à couper que dans 10 ans il va être super balaise de trouver un mec suffisament compétent pour intervenir rapidement sur ce genre d'appli,
J'ai du mettre quelques mois pour apprendre à sortir quelque chose de cohérent en java, en python ça m'a pris quelques jours. Je ne vois pas pourquoi dans 10 ans on aurait du mal à former quelqu'un dans un langage aussi simple et facile d'accès et qui ne bouge quasiment pas malgré ce qu'on peut lire ici.
un décideur qui a un ingénieur dubitatif devant lui, il prend peur et va se rassurer chez Sun MS ou autre IBM qui va lui offrir des garanties de support sur le long terme.
On en revient toujours au même. Quand on a un problème on s'imagine toujours que les autres les ont aussi, on regarde donc quels outils ils ont pour les résoudre au lieu de se demander s'ils ont eux aussi ces problèmes... L'IDE, le framework etc.
Un autre exemple tout bête. On dit souvent qu'il n'y a pas autant de livres sur python que sur java. Certe, mais autant en java j'ai du acheter d'énormes bouquins, en python aucun. Pourtant je fait exactement les mêmes choses avec... Y compris du multi-thread !
Un temps j'étais même fan de java, pourquoi j'aurai abandonné pour python ?
Soit parce que je suis compétent, et c'est donc un bon choix. Soit parce que je suis incompétent mais alors c'est encore mieux si un langage permet à un incompétent d'être encore plus productif ! ça devrait pourtant être l'inverse avec un langage qui rattrape autant d'erreurs ;-)
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
Effectivement, ca ne va pas de soit, donc je vois pas quoi d'autre rajouter non plus...
J'ai du mettre quelques mois pour apprendre à sortir quelque chose de cohérent en java, en python ça m'a pris quelques jours.
Forcement, quand t'as appris Java t'étais débutant :)
ne vois pas pourquoi dans 10 ans on aurait du mal à former quelqu'un dans un langage aussi simple et facile d'accès et qui ne bouge quasiment pas malgré ce qu'on peut lire ici.
Allez mon gars : y'a un bug critique dans l'appli, t'apprends python 2.6 et tu trouves d'où ca vient : je te préviens, ca vient peut être pas de l'appli mais du framework bidule qui n'est plus maintenu pour python 2.6.
T'as 24h si tu veux pas perdre ton job !
Y compris du multi-thread !
En exploitant un seul core de la machine, ca va t'es pas trop frustré ?
[^] # Re: Grandiose
Posté par Boa Treize (site web personnel) . Évalué à 4.
Cet exemple est complètement irréaliste. (Principalement à cause de la dernière phrase.)
[^] # Re: Grandiose
Posté par wilk . Évalué à 1.
C'est ça qui est génial, je peux rester débutant tout en assurant mon job grâce au Python !
Je reviens sur mon paradoxe, autant on trouve pléthore de raisons pour obliger les développeurs à faire du java, autant tous ceux qui utilisent python l'on fait par choix. Curieux non ?
Bon j'arrête sinon je vais être obligé de raconter ma vie ;-)
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par Fabimaru (site web personnel) . Évalué à 2.
J'ai mieux à faire de mes journées que de traquer la mémoire corrompue aléatoirement, c'est pour ça que pour contrer ces incompétents je vote "Java"!
[^] # Re: Grandiose
Posté par Zenitram (site web personnel) . Évalué à 3.
s t n'a p a c q'u c p c.
Tu n'as pas compris?
C'est plus court, plus concis, plus clair, ce sont les premières lettre du début de ta phrase.
--> Ce n'est pas parce que c'est plus court, plus concis que ça aide à s'y retrouver, loin de la.
Désolé, mais un manque de typage, ça éclairci certes le code, mais je ne supporte pas : le débugguage de code non typé est bien plus chiant : c'est plus rapide à écrire, mais plus long à débugguer.
Ton affirmation est loin d'être évidente, si tu ne le comprends pas, je ne vois pas quoi rajouter...
[^] # Re: Grandiose
Posté par Alex . Évalué à 1.
Néanmoins faut pas éxagerer, php et python sont énormément utilisés, même si bien sur on reste loin de java.
Ah ces SSII, qu'est ce qu'elles attendent pour coder en Python ? Qui veut coder une application qui dans 10 ans sera inmaintenable parcque Python 5 aura cassé 2 fois la compatibilité
Mouais, enfin cest argument était également applicable à java à sa sortie : pourquoi prendre le risque de miser sur une techno faites pour l'embarqué, alors qu'on avait déjà smalltalk, c++, etc... et dont on avait à l'époque pas plus de garantie sur la compatibilité ascendante.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 1.
Ben java n'a pas été adopté dès le début dans le l'industrie, c'est venu progressivement.
Quand les versions suivantes sont sorties, les décideurs étaient rassurés : support Sun, politique de compatibilité et de support des anciens API, etc.
Python, ils cassent la rétro-compatibilité de manière explicite. Si j'étais décideur ca me ferait peur.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 3.
Au grand maximum, que Python "casse la rétro-compatibilité peut effrayer les ingénieurs, qui sont en contact avec la technique, mais d'une part pas forcément, d'autre part pas forcément plus que la rétro-compatibilité forcenée de Java qui lui fait maintenir des types natifs non-objet contre vents et marée malgré toutes les complications que ça implique pour les développeurs, la maintenance, la propreté du code et la standardisation.
Par contre, c'est vrai qu'un décideur aura tendance à être plus en contact avec des infos sur les technologies commerciales puisqu'elles font de la pub à longueur de page dans la presse "spécialisée" (souvent sous forme d'articles d'ailleurs), donc il est naturel que Java ait des facilités à se maintenir dans les SSII où la direction n'est généralement pas proche du technique...
[^] # Re: Grandiose
Posté par benoar . Évalué à 3.
[^] # Re: Grandiose
Posté par Zenitram (site web personnel) . Évalué à 1.
Non.
Pour toi 8 ans c'est peut-être super-méga-génial, moi j'en rigole : le code que j'ai pondu il y a 15 ans en C fonctionne toujours aujourd'hui, ça c'est du "pas mal".
Et je sais que le code que je pond aujourd'hui en C/C++ sera compatible avec la prochaine norme C++, ce qui me rassure.
Chacun son truc, je n'ai personnellement pas compris l'engouement sur Python, je dois être hermétique aux nouveautés mais tout ce que Python fait, je sais le faire "mieux" et plus maintenable pour le futur en C/C++. Avant, on parlait de Perl à fond, puis Java à fond, puis RoR, et maintenant Python, en attendant le suivant (C#? Mono? Autre?) : est-ce vraiment pérenne? Combien d'interpréteurs Python? Un seul. Qui décide comme il veut de casser la compatibilité. Hum, c'est facile d'être seul pour développer son "langage", le C/C++ a montré, lui, qu'on peut avoir plusieurs "concurrents" et une plus grande évolutivité.
[^] # Re: Grandiose
Posté par lasher . Évalué à 4.
Même en utilisant les bibliothèques C qui vont bien, il faut bien avouer que les langage dits de 4è génération (Python, Ruby, Perl, et dans une moindre mesure - car orienté web uniquement - PHP) permettent de développer bien plus rapidement quelque chose de fonctionnel qu'en C. De plus très souvent, si on veut tout refaire « depuis zéro » (parce qu'on aime réinventer la roue, parce qu'on a le syndrôme du « Not Invented Here », ou tout bêtement parce qu'une vraie bonne raison le requiert), ces langages proposent nativement tout un tas de trucs (tables de hachage, augmentation dynamique et implicite de la taille des tableaux, etc). En C, je n'en parle même pas. En C++, certes, il y a la STL, mais il y a tout de même de gros écueils à éviter, et des subtilités parfois très euh ... subtiles. Un exemple tout bête :
for (i = <un_certain_type_d_iterateur;<condition>; i++) {
// quelque chose à faire
}
Bon, ben si l'opérateur '++' a été surchargé, on se retrouve avec deux évaluations de l'objet i, ce qui d'un point de vue perfs est pas génial. On me dira que oui mais bon, quand on surcharge un opérateur, il faut faire gaffe, mais c'est un exemple relativement simple de pourquoi C++ est loin d'être le meilleur langage « universel ». Je préfère 100 fois un programme Perl ou Python. S'il y a besoin d'aller vite, évidemment, alors il faut commencer à fureter du côté de C ou C++. Et même là, parfois on a des surprises.
Sinon, le fait est que malgré l'ascension de Python et Ruby (et avant eux de PHP), Perl reste encore très utilisé (peut-être plus par les admins que par des dévs purs et durs, je te l'accorde). Perl date de 1987 d'après wikipedia. Il a été utilisé (et l'est encore) depuis vingt ans, je trouve que c'est déjà pas mal du tout. Certes, C est plus vieux, mais il lui manque une bibliothèque standard aussi fournie que celle de Java ou au moins C++ (oui, il y a la glibc, mais tout le monde ne veut/peut pas l'utiliser -- vu que c'est pas standard, justement).
Enfin, si on parle de C++, le principal problème à mon avis est le fait que malgré l'existence d'une norme, l'implémentation de celle-ci est partielle au mieux [1] (je pense à C++98 notamment). Je ne parle même pas de la compatibilité entre compilateurs, ou des classes qui existent désormais dans la STL, mais qui sont redondantes avec celles mises au point par de gros frameworks (genre Qt) à l'époque où aucun standard n'existait, mais évidemment avec des différences de comportement, d'API, etc.
Tout ça pour dire quoi ? Affirmer qu'on fait mieux et plus maintenable que Python (ou un langage du genre) peut être vrai, mais je doute très fortement que ce soit réalisé dans les mêmes délais (après, faire du code crade, quel que soit le langage, c'est possible, bien sûr).
[1] Et même en C, C99 n'est pas implémenté intégralement, même par GCC, à cause de fonctionnalités « avancées » voulues par le comité de normalisation mais qui sont fichtrement difficiles à mettre en oeuvre.
[^] # Re: Grandiose
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca ne parle pas beaucoup du langage en lui-même!
Oui, Python et consort ont l'avantage de fournir une bibliothèque "standard" bien plus fournie que C/C++.
Mais avait-on besoin d'inventer un nouveau langage pour proposer une bibliothèque qui aide au développement? Je ne pense pas.
C'est relativement simple de fournir une bibliothèque "standard" quand on est le seul à proposer une implémentation (comme Python le fait).
Certes, l'avantage de Python est de proposer un éco-système plus complet (Langage + Bibliothèque), mais est-ce que ça en fait un langage "mieux"? Ca aide sûrement au développement rapide quand ce dont on a besoin est dans la bibliothèque Python et pas dans la bibliothèque C/C++, mais quand on doit faire un truc qui n'existe pas des deux côté, quel est l'avantage de Python en tant que langage?
Ce que je trouve dommage est qu'on doivent s'obliger à inventer un langage "approprié" la où on aurait pu faire une bibliothèque pour un langage déjà existant.
Personnellement, je reste quand même non motivé pour utiliser des langage dont il n'existe qu'un "compilateur" (ou interpréteur) : je doute de leur pérennité (et Python 3 me le confirme : des programmes en Python 2 ne vont bientôt plus avoir d'interpréteur supporté et qui évolue, vu que les efforts vont être mis sur Python 3)
Me reste plus qu'à porter la bibliothèque standard Python en C++ pour lui enlever cet avantage :-D.
[^] # Re: Grandiose
Posté par benoar . Évalué à 3.
Et en ce qui concerne le "cassage" de la 2.x, faudrait vous renseigner, c'est pas du cassage de tordu : c'est juste pour quelques trucs qui étaient déjà "borderline" ...
[^] # Re: Grandiose
Posté par lasher . Évalué à 4.
Pas que. Je développe en C et Perl (C pour mes « vrais » programmes, Perl pour des scripts qui exploitent et post-traitent les sorties de mes progs C). Ne serait-ce qu'à cause de la façon dont le typage fonctionne dans chaque langage, en Perl je fais des choses qui fonctionnent aussi rapidement qu'en C (du moment que le goulot d'étranglement est le disque dur ou le réseau, honnêtement, Perl/Python/etc n'ont rien à envier à C/C++) mais ça me prend facilement cinq fois moins de temps.
Par exemple j'ai des fichiers dont le format se rapproche du CSV. Je dois manipuler les données dans tous les sens. En Perl [1] je n'ai eu qu'à me faire un petit module pour manipuler ce genre de fichiers (dont la fonction principale est quelque chose du genre csv_to_array() ), et surtout, une fois que j'ai récupéré mes données sous forme de tableau 2D, je peux les traiter en foutant le tout dans un tableau de hachage (qui est un type natif de Perl, pas besoin d'appeler une bibliothèque externe, et si je veux faire un hash de hash, tout est fait dynamiquement ... En C, et même en C++, ce serait quand même assez galère à obtenir comme comportement), un autre tableau, etc. En C, pour faire la même chose (ie faire mon petit module d'extraction « brute » de données, et le post-traitement à proprement parler), j'aurais eu non-seulement plus de lignes de code (ça à la limite, on s'en fiche, si c'est bien écrit et encapsulé), mais aussi bien plus de manipulations de fonctions pour extraire les infos en fonction de la nature de mes données. Je ne peux pas trop expliciter plus, mais tout mon discours ici est de dire que, même si j'adore vraiment le C, quand il s'agit de développer vite une application qui n'est pas trop intensive niveau I/O, utilisation CPU, etc., alors Python/Perl/Ruby & co sont clairement de meilleurs choix selon moi. Je ne parle même pas du côté merveilleux de Python à pouvoir accepter des fonctions C « directement » quand on a besoin de perfs supplémentaires (en Perl on peut aussi faire, mais c'est beaucoup, beaucoup plus lourd).
[1] Je ne connais pas assez bien Python, donc je ne peux pas trop en parler, et de façon générale il faudrait que je m'y prenne différemment car il est fortement typé, donc les opérations sur des floats ou des strings devraient être « explicites », mais ce serait évidemment faisable aussi.
[^] # Re: Grandiose
Posté par dab . Évalué à -1.
Php uniquement orienté web ? J'en parlerai à mon /usr/bin/php tiens.
[^] # Re: Grandiose
Posté par lasher . Évalué à 2.
[^] # Re: Grandiose
Posté par dab . Évalué à 1.
Le php peut très bien être utilisé en tant que langage de script et il est difficile de faire d'un script de ci de là, un projet d'envergure.
[^] # Re: Grandiose
Posté par lasher . Évalué à 2.
Maintenant, oui, on peut se servir de PHP comme d'un langage de script « générique ». Il n'a juste pas été fait pour ça à la base.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben de Python 3 tiens !
La maintenance de Python en soit c'est pas le problème, ce qui va être difficile à maintenir c'est tous les outils, frameworks et compétences futures !
[^] # Re: Grandiose
Posté par benoar . Évalué à 2.
Tu peux très bien faire des libs qui sont compatibles entre Python 2.x et 3. Le "cassage" fait qu'il faut juste changer quelques trucs pour qu'ils passent en 3.0, mais ça restera compatible 2.x.
[^] # Re: Grandiose
Posté par lasher . Évalué à 2.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 2.
Par contre, Ruby et Rails commence à séduire les hébergeurs et les structures plus petites, à cause de la productivité, la lisibilité du code, la fiabilité (suite de tests intégrée, pas très difficile à mettre en place), le fait de maîtriser beaucoup mieux le workflow et la facilité de réutilisation des plugins / gems souvent assez peu intrusifs. Il a aussi séduit des startups qui développent des sites commerciaux (ou pas), et qui n'ont pas les moyens ni le besoin de faire appel à d'énormes machineries pour leurs débuts, et veulent un code propre qui évolue rapidement.
A ce propos, et sans vouloir t'offenser, la rétro-compatibilité n'est pas l'apanage de Java. Ce n'est pas parce qu'une plate-forme open-source évolue qu'elle ne répercute pas des corrections critiques sur les version "vivantes" précédentes, et même pour d'importants sauts de versions il est fréquent que l'essentiel du code existant reste viable à quelques légères modifications près.
Sinon, je ne peux pas tellement parler de python, je n'y ai pas (encore) mis les pieds, mais je ne vois pas en quoi un système à base Python ou Ruby ne pourrait pas tenir 10 ans, voir plus, à condition que, comme pour une appli Java de cette ancienneté, il y ait de la maintenance et de la mise à jour effectué. Il se trouve que pour Ruby, Python, ou d'autres logiciels Open-Source, on a envie de faire évoluer la plate-forme au cours de la vie d'une application, personnellement je ne vois pas de mal à ça, je trouve plutôt ça positif. A ma connaissance, c'est d'ailleurs ce qui se passe pour toute plate-forme de développement tant qu'elle n'est pas morte. Evidemment, ça devient de plus en plus difficile de trouver des développeurs COBOL de nos jours, mais les développeurs COBOL sont également de moins en moins demandés, ceci accompagne cela...
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . Évalué à 1.
Je ne dis pas que c'est l'apanage de Java. Je dis juste que c'est pas celui de Python.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 2.
[^] # Re: Grandiose
Posté par lezardbreton . Évalué à 2.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 2.
[^] # Re: Grandiose
Posté par Fabimaru (site web personnel) . Évalué à 2.
(sur le coup j'ai sursauté)
[^] # Re: Grandiose
Posté par Bastes . Évalué à 2.
[^] # Re: Grandiose
Posté par benoar . Évalué à 2.
[^] # Re: Grandiose
Posté par pini . Évalué à 2.
Ada avec les Gnat Project Files : tu donnes le répertoire avec les sources, le fichier qui contient la procédure de départ, les flags pour la compile et le reste roule tout seul. Même sur des gros programmes, ça fait pas des fichiers inbitables de n*1000 lignes.
[^] # Re: Grandiose
Posté par Octabrain . Évalué à 4.
J'imagine que cela entretient aussi l'image du programmeur java stupide qui collera sans sourciller du code qu'il ne comprend pas, qui n'a quasiment aucune compétence de programmation, ni aucune "culture" ou recul.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 10.
- tu dois utiliser windows parce que sinon tes petits camarades te regardent d'un drôle d'air
- tu dois utiliser ms office parce que sinon ton chef de projet n'aime pas que tu blaste involontairement ses outils avancé de productivisation positronique qui lui gagnent le temps qu'il perd à les utiliser
- comme tout le monde est sous Eclipse on va utiliser SVN plutôt que GIT pour gérer les versions même si c'est moins bien
- le temps qui devrait être alloué à la rédaction de tests est offert en cadeau au client, mais on pressurise l'équipe pour faire le travail dans le temps vendu, donc pas de tests unitaires
"Bureaucracy expands to meet the needs of the expanding bureaucracy." Oscar Wilde
Quand on en est là, ça fait ça que le projet soit en Java, en PHP, en Ruby on Rails ou en C, ça sera la même chose partout. Mais c'est vrai que Java facilite quand même beaucoup l'arrivée à ce stade au sein même des équipes de développement.
[^] # Re: Grandiose
Posté par benoar . Évalué à 3.
Le jour où "ceux d'en bas" se rendront contre que leur argumentaire contre les tares de l'état sont là pour qu'ils recréent les mêmes, mais les leurs, autre part, on aura fait un grand pas.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 1.
Enfin, ça dépend ce qu'on appelle inefficace, si l'objectif est d'en foutre plein les fouilles à un petit nombre, alors le modèle économique ultra-libéral est très bien fait. Si bien fait qu'il permet aux gagnants de provoquer des crises, les faire payer par la collectivité sans rien donner en échange, même pas de vagues promesses de mieux se conduire, et de continuer à dire du mal de l'état et des services publiques.
[^] # Re: Grandiose
Posté par peck (site web personnel) . Évalué à 4.
Personne ne note, mais ca me rappelle une blague en 200 d'un mec qui cherchais quelqu'un avec 7 ans d'expérience en java ...
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par titi toto . Évalué à 3.
Ah bon. Enfin, j'imagine que certains considérent emacs comme un IDE.
[^] # Re: Grandiose
Posté par Bastes . Évalué à 3.
# Je n'aurais qu'une seule chose à dire...
Posté par Maclag . Évalué à 10.
[^] # Re: Je n'aurais qu'une seule chose à dire...
Posté par Bastes . Évalué à 10.
Oh que je suis content de ne plus être en SSII...
[^] # Re: Je n'aurais qu'une seule chose à dire...
Posté par Laurent Cligny (site web personnel) . Évalué à 10.
# Ce que j'attends avec impatience...
Posté par Vlobulle . Évalué à 10.
[^] # Re: Ce que j'attends avec impatience...
Posté par B16F4RV4RD1N . Évalué à 10.
Bravo pour ce splendide et hilarant journal Ploum. Il aurait été sorti le 31 décembre 2008, j'aurais dit que c'était le plus drôle de l'année, là c'est encore tôt mais c'est en bonne voie :)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Mdr
Posté par Arnaud . Évalué à 4.
Heureusement, depuis, les choses ont évolué et beaucoup de ces pseudo-consultant virés depuis sont revenus par une autre porte, convertis à des technicobuzz plus récents (méthodes Agiles, par exemple : rien de mauvais en soi mais si mal "consulté"...). Et la technologie aussi, elle, a évolué, un peu, quoi, si...
Tiens, je devrais écrire une parodie "mise à jour" sur J2EE :)
# Un grand MERCI pour cette crise de rire! :D
Posté par astennu . Évalué à 10.
[^] # Re: Un grand MERCI pour cette crise de rire! :D
Posté par David Carlier . Évalué à 5.
Les consultants installent tous Jboss et, en conséquence, demandent un triplement de la taille de la Ram de leur portable...
Rien que ça m'a arraché un grand sourire mais c'est tellement réaliste
[^] # Un grand MERCI aussi!
Posté par Panda Voyageur (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Un grand MERCI pour cette crise de rire! :D
Posté par Fabimaru (site web personnel) . Évalué à 9.
[^] # Re: Un grand MERCI pour cette crise de rire! :D
Posté par Hugues (site web personnel) . Évalué à 1.
Trop fastoche : il suffit de savoir si c'est toi qui paye :-))
# Tout est vrai
Posté par Feeks . Évalué à 10.
A part le coup de l'héritage multiple, rien n'est éxagéré...
[^] # Re: Tout est vrai
Posté par yellowiscool . Évalué à 6.
Envoyé depuis mon lapin.
[^] # Re: Tout est vrai
Posté par TImaniac (site web personnel) . Évalué à 10.
[^] # Re: Tout est vrai
Posté par windu.2b . Évalué à 3.
Loin de moi l'idée d'y avoir recours, mais c'est toujours bon à savoir...
[^] # Re: Tout est vrai
Posté par TImaniac (site web personnel) . Évalué à 5.
# Tellement vrai
Posté par Loic Dreux . Évalué à 7.
[^] # Re: Tellement vrai
Posté par Bastes . Évalué à 6.
[^] # Re: Tellement vrai
Posté par Axel R. (site web personnel) . Évalué à 2.
Axel
[^] # Re: Tellement vrai
Posté par Bastes . Évalué à 1.
Après chacun ses envies, il y en a qui tolèrent très bien ça s'il y a un gros chèque à la fin du mois...
[^] # Re: Tellement vrai
Posté par letsyl . Évalué à 1.
C'est quoi le nom de cette SSII ?? :o)
[^] # Re: Tellement vrai
Posté par Bastes . Évalué à 1.
# J'ai l'impression d'être vendredi tous les jours
Posté par manatlan (site web personnel) . Évalué à 10.
C'est vraiment agréable de ne plus attendre le vendredi pour sourire.
[^] # Re: J'ai l'impression d'être vendredi tous les jours
Posté par liberforce (site web personnel) . Évalué à 9.
Hum... Je te conseille si c'est le cas d'aller voir un psy ou d'aller sur viedemerde.fr...
[^] # Re: J'ai l'impression d'être vendredi tous les jours
Posté par David Carlier . Évalué à 2.
# Rire jaune
Posté par Stibb . Évalué à 6.
Remarquez comment la "philosophie" du développement Agile est fièrement mis en avant au début et royalement non appliqué par la suite :)
Bravo
Gaetan
[^] # Re: Rire jaune
Posté par Bastes . Évalué à 10.
"Mes chers amis, en tant que chef de projet j'ai une bonne nouvelle : Nous allons pratiquer la nouvelle méthode Agile de développement.
Je n'ai pas besoin de vous expliquer Agile, il y a la wikipedia pour ça.
Bien entendu, dans un premier temps et pour respecter les deadlines, nous allons nous contenter de certaines pratiques et exclure les choses qui font perdre du temps inutilement comme le codage par pair (pas besoin de mettre 2 personnes sur un même code) et les tests automatisés (on ne va pas perdre du temps à installer et écrire une suite de test, je vous fais confiance pour faire du bon code qui marche du premier coup n'est-ce pas ?) et plutôt que de faire du refactoring, on va bien concevoir notre architecture de classe dès les début pour prévoir tous les cas.
Oh, et aussi, toutes les communications avec le client passent par moi, et le cahier des charge, les specs fonctionnelles et les specs techniques ont été établies préalablement par un cabinet de consultant.
Messieurs, au travail."
[^] # Re: Rire jaune
Posté par Cyberdivad . Évalué à 3.
[^] # Re: Rire jaune
Posté par Fabimaru (site web personnel) . Évalué à 5.
Je suppose qu'on a tous plus ou moins ce genre d'anecdote (comme refaire les specs quand le projet est sensé être abouti à 80%). Ça me fout les boules d'être entrainé dans ce genre de situation, j'en ressens une grande impression d'impuissance, et d'être amené de manière inéluctable à faire une grosse bouse.
[^] # Re: Rire jaune
Posté par Stibb . Évalué à 2.
Alors que pour un chef non technique, plus c'est compliqué, mieux ça doit être...
[^] # Re: Rire jaune
Posté par Sébastien B. . Évalué à 6.
Tu vas acheter ton beurre chez la boulangère toi ?
[^] # Re: Rire jaune
Posté par Fabimaru (site web personnel) . Évalué à 4.
http://www.google.fr/search?q=boulang%C3%A8re+site%3Alinuxfr(...)
Je suis près à parier que c'est la profession non-liée à l'informatique la plus référencée sur linuxfr.org
[^] # Re: Rire jaune
Posté par Gof (site web personnel) . Évalué à 1.
Plus précisément sur président.
[^] # Re: Rire jaune
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Rire jaune
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Rire jaune
Posté par Stibb . Évalué à 5.
Savent pas qu'un bug peut être conceptuel, ie, pas de bug de codage mais que l'archi en elle meme puisse etre vereuse, et qu'il faille tout changer.
sans savoir qu'il y a une contradiction forte entre la "productivité" (bien souvent résumé au nombre de ligne de code écrite, ou, parfois, au nombre de bugs résolu ou de feature développé/semaine) et "qualité". Les deux partages la même quantité de ressource (le cerveau de l'ingé), donc on peut pas tirer sur l'un sans diminuer 'autre.
Et il savent ce que sont les maths, c'est pas dûr je te dis :
- un ingé de base corrige 1 bug/jour
- deux ingé corrigeront 2 bug/jour
...
Ca lui viendrait pas à l'esprit qu'un bug mal corrigé puisse en générer 15.
si 2 ingé sur le même poste n'écrivent qu'1 feature/jour (ou corrige qu'1 bug/jour) il produise du code meilleur pour plein de raison psychologiques difficilement mesurable :
Exemple, moi :
1) quand je suis seul je code comme un porc, personne peut me relire sur le fond, dans les revues les collegues s'attaquent qu'aux erreurs esthétiques, un if mal indenté, des variables qui respectent pas la nomenclature,...) sans savoir si le code fonctionne réellement. Evidement je suis un Dieu et je fais aucun bug (en fait j'ai développer une technique secrete "masquage de potentielle probleme sous une argumentation fumeuse", et quelques points en "correction de mes bugs en revue de code des autres bugs... et parfois des miens), mais tout le monde ne l'est pas.
2) quand un gars est a coté de moi et comprend ce que je fais, à la premiere erreur il me le fait remarqué. Evidement au début ça gonfle et j'ai envie de lui faire manger mon clavier, mais quand on se rend compte des résultats (j'ai pas de bug à corriger pendant les réunions, donc je peux dormir), j'adhére totalement en tant que développeur.
Si j'étais manager je l'appliquerais immédiatement. Mais, perso, je suis pour une approche hybride:
- phase de prototyping : méthode agile 100%, release early/often, codage par pair, test driven development,...
- phase de développement industriel traditionel (si absolument nécessaire pour un grand compte par exemple, une fois l'archi trouvée et validée) : on reprend le cycle en V avec un beau cahier des charges, un plan de test bien propre, un développement... qui est déjà fait un test sur terrain bien lourd et bien complet.
[^] # Re: Rire jaune
Posté par Bastes . Évalué à 7.
"Ah, ben vous l'avez déjà presque terminé en fait, c'est bien, vous avez un peu vu gros pour le devis initial mais me voilà rassuré, vous allez nous développer ça moitié prix *wink*wink* *nudge*nudge*".
Pour que l'utilisation du prototypage fonctionne, il faut alors que les deux équipes client et développeur soient proches pour discuter du bidule fréquemment (sinon c'est difficile de prototyper correctement sans se viander en cours) et pour que le client réalise que le prototype ne peut pas être le machin final ni servir directement de squelette ou de base et réduir le temps de travail prévu (cf plus haut).
Ou alors, si ça bloque, il reste la technique de bâtard (mais elle a déjà fonctionnée) :
- on fait un prototype "dans son garage" sans en avertir le client
- on fait rapidement une spec. fonctionnelle bourrée de captures d'écran du prototype, et on dit que c'est juste une maquette
- on laisse le client faire "ouaou" à la réunion de validation, et on est quand même mieux préparé pour mettre en production
[^] # Re: Rire jaune
Posté par Stibb . Évalué à 2.
Les managers ont peur des erreurs. Pour eux c'est le mal absolu de faire des erreurs, ils ne comprennent pas qu'en faisant des erreurs (en prototypage) on apprend et que la prochaine fois (en développement réel) on code mieux. Alors ils changent le projet d'équipe... et ça recommence.
Perso, sur certains projet maintenant je me dis que j'ai vraiment écrit de la merde à un moment, et que si je devais refaire tel algo je le ferais différement. Mais si je prend pas le temps de me planter, évidement je n'apprend pas et je ponds un truc qui marche mais qui n'est pas parfait.
Faut leur apprendre à valoriser les erreurs au lieu de comptabilisé ça dans un tableau et tenter de le réduire au strict minimum. C'est ce que le développement agile promouvoit : releae often pour identifier immédiatement les soucis, et ne pas hésiter à réécrire le code from scratch quand on est dans l'impasse, au lieu de maintenir un code dépassé.
# pas mal !
Posté par Jérôme . Évalué à 6.
Le principal problème des développements JEE c'est en effet les gens qui aiment faire de manière complexe ce qui peut être fait simplement.
Et puis après tout une ré-écriture de LinuxFR en java ça peut être marrant à faire.
(Ca y'est j'ai marché dedans)
Y-a-t-il des gens motivés ? :-)
[^] # Re: pas mal !
Posté par Arnaud . Évalué à 3.
[^] # Re: pas mal !
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: pas mal !
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
# Sympa mais ...
Posté par chl (site web personnel) . Évalué à 2.
Janvier 2009
Tous les consultants sont sous Windows sauf un, qui connait bien Linux. Il a installé une Ubuntu puis installé tout à la main depuis les sources.
Puis :
Juillet
Suite à l'utilisation de librairies spéciales, le projet ne tourne plus que sous Windows. Le consultant qui était sous Linux réinstalle WinXP.
Enfin :
Septembre
Le consultant qui utilise Linux
Lisez les journaux !
[^] # Re: Sympa mais ...
Posté par FabienC . Évalué à 5.
[^] # Re: Sympa mais ...
Posté par windu.2b . Évalué à 9.
(c'est trollesque depuis le début, donc je sors pas :-p )
[^] # Re: Sympa mais ...
Posté par ZeroHeure (site web personnel) . Évalué à 3.
(il utilise RedHat et Ubuntu)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Sympa mais ...
Posté par Tom D . Évalué à 4.
"Le consultant qui [connait] Linux" ou "Le consultant qui[, d'habitude,] utilise Linux"
Tom
# Top 10
Posté par Benbben . Évalué à 5.
Qui connait SAP DreamWeaver ? Le meilleur, ou le pire c'est selon le point de vue, de J2EE et de SAP, ensemble !
Le dernier grand projet auquel j'ai participer pour un client du TOP 10 aéronautique dans une SSII dans le Top10 bien entendu ! mdr
Remarquer bien que le développement en couche et modèle MVC c'est aussi très tendance chez Billou et dot.Net !
[^] # Re: Top 10
Posté par Sylvain (site web personnel) . Évalué à 2.
[^] # Re: Top 10
Posté par nodens . Évalué à 1.
Pas faux... Et ça marche même avec php, d'ailleurs ;-)
Le mot clef là dedans c'est euh... FOUTAISES ! ;-)
# tu nous tiens en haleine !
Posté par Touns . Évalué à 4.
# C'est trop drôle
Posté par pini . Évalué à 1.
Cependant, sans vouloir paraître péremptoire, ce serait encore mieux si l'orthographe n'écorchait pas les yeux (franchement "shéma", c'est pas joli-joli comme erreur).
[^] # Re: C'est trop drôle
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: C'est trop drôle
Posté par pini . Évalué à 1.
Et comme je déteste faire des fautes, je suis content quand on me les pointe.
Et donc, je me permets de rendre la pareille en pointant celles des autres (à la différence que c'est plus jouissif dans ce sens là).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.