Salut,
Utilisateur intensif du projet Struts, j'étais tombé sur un bug qui, d'ailleurs, avait déjà été découvert 1 an avant par une autre personne. Ce bug est toujours ouvert...
Comme je voyais d'où venais ce bug, j'ai décidé de le corriger mais, voilà, le projet Struts est un gros projet.
Résultat :
- j'ai passé 3 jours à télécharger les bonnes sources et à intégrer mon projet dans mon IDE favori,
- j'ai passé 2 heures à corriger le bug,
- les modifs sont restées sur mon ordi, faute de savoir comment les soumettre.
Je sais que la soumission du patch n'est pas très compliqué, je trouverais bien avant que le bug soit corrigé par quelqu'un d'autre...
Le problème, c'est que, il me semble, tous les gros projets doivent avoir le même problème. Comme tous les projets du libre tendent à devenir gros (je pense à Firefox, OO.org, Evolution, ou des projets largement utilisés comme ça), je pense qu'il faudrait sérieusement réfléchir à des moyens de pas rebuter les contributeurs non-régulier de tels projets.
J'aimerais avoir des retours de personnes qui ont essayé, avec succès ou pas, de contribuer à des projets de grosse taille...
Jean Parpaillon
Journal De la difficulté de contribuer à des gros projets
27
juin
2005
# ...
Posté par Marc (site web personnel) . Évalué à 3.
[^] # Re: ...
Posté par Jean Parpaillon (site web personnel) . Évalué à 5.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # editeur à la place de l'IDE
Posté par free2.org . Évalué à 4.
en fait on peut configurer emacs/vim pour les transformer en IDEs capables de fonctionner sur n'importe quelle archive décompréssée, sans avoir à créer un projet à chaque fois
[^] # Re: editeur à la place de l'IDE
Posté par Victor . Évalué à 1.
[^] # Re: editeur à la place de l'IDE
Posté par free2.org . Évalué à 1.
[^] # Re: editeur à la place de l'IDE
Posté par Tonton Th (Mastodon) . Évalué à 10.
Pour les projets en C, je conseille vivement cscope qui roxorize les mamans ours. Il est parfaitement adapté à ce genre de recherches. Je suppose qu'il existe des équivalents pour d'autres langages, mais pour les "C-addicts", c'est vraiment d'la balle atomique.
http://cscope.sourceforge.net/index.html(...)
[^] # Re: editeur à la place de l'IDE
Posté par rangzen (site web personnel) . Évalué à 2.
???
[^] # Re: editeur à la place de l'IDE
Posté par free2.org . Évalué à 3.
Sinon ils ont été racheté depuis par Caldera, et c'est Caldera les méchants aujourd'hui (meme s'ils ont changé de nom pour s'appeler SCO)
et tant que un juge n'a pas pris de décision finale (mal embarquée pour SCO, cf le cour de l'action SCOX), on se contrefout de SCO
[^] # Re: editeur à la place de l'IDE
Posté par gc (site web personnel) . Évalué à 5.
les mamans ourses. c'est féminin boudiou.
[^] # Re: editeur à la place de l'IDE
Posté par Papey . Évalué à 5.
[^] # Re: editeur à la place de l'IDE
Posté par Philippe F (site web personnel) . Évalué à 3.
[^] # Re: editeur à la place de l'IDE
Posté par Tonton Th (Mastodon) . Évalué à 2.
Je viens de regarder, effectivement ça semble bien. Je vais l'essayer dans la journée, peut-être...
Mais c'est un gros truc graphique, alors que cscope est en mode texte, et reste utilisable même sur des toutes petites machines ou à travers un lien ssh peu véloce. Sur ce, plouf-piscine.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 4.
[^] # Re: editeur à la place de l'IDE
Posté par Marc (site web personnel) . Évalué à 7.
Pour le "aller à", tu utilises etags.
Pour gdb, tu fais M-x gdb.
Ça prend quoi...5min pour connaitre les commandes de base.
Si tu veux un projet eclipse, libre à toi de le fournir, mais pour bcp, ça servirait à rien et imposer un IDE, je trouve pas ça une très bonne idée.
[^] # Re: editeur à la place de l'IDE
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 8.
Tu me confirmes que etags a depuis mon dernier essai bien évolué pour t'amener à la définition de la bonne méthode dans le bon objet ? Sinon, c'est poubelle direct.
Enfin comparer Eclipse et Emacs c'est avoir une franche méconnaissance de Eclipse. En terme d'IDE il y a pas photo, mon choix est vite fait (et j'utilise Emacs depuis plus longtemps que Eclipse). Puis gdb c'est gentil, mais de même, le comparer au debugger Eclipse ça fait doucement sourire...
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 10.
[^] # Re: editeur à la place de l'IDE
Posté par Frédéric RISS . Évalué à 6.
De plus, le mode de saisie par défaut ne me plait pas et malgré des menus contextuels avec 50 options, pas moyen de lui dire comment identer mes sources.
Pour information, le debugueur d'eclipse est GDB, alors ta remarque me fait 'doucement sourire' :). En plus l'interfacage est très limité même au niveau des fonctionalités exposées par l'interface (impossible d'afficher l'assembleur brut, il y a toujours les lignes sources, ce qui fout la merde sur du code optimisé). La perspective de debug n'offre pas d'avantages 'graphiques' (comme la zone de graphe de gdv) et interdit l'usage de fonctions avancées...
Les parseurs d'erreurs GNU make/gcc sont extremement mauvais, ce qui fait qu'il faut regarder dans la console pour avoit le message d'erreur correpsondant au marqueur mis dans la marge.
Bref, Eclipse pour du Java c'est l'outil le plus formidable du monde, mais pour du C++ il n'est tout simplement pas prêt.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 3.
Oué mais le fait est qu'on parle Java là, et même si Eclipse est pourri pour C++ par rapport à emacs, l'inverse est aussi vrai : emacs est pourri pour Java par rapport à Eclipse.
[^] # Re: editeur à la place de l'IDE
Posté par PachaFonk . Évalué à 3.
Java a été nomé pour la première fois dans le post juste avant le tien, pas avant...
Donc, non, on ne parle pas de Java là ....
C'est un troll emacs/Eclipse (tiens, où est vi ?), pas un troll Java/C++...
Un peu de concentration messieurs !!!
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 3.
J'ai voulu proposer une solution pour le cas du journal : en l'occurence le projet Struts est en Java.
[^] # Re: editeur à la place de l'IDE
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Sous Emacs, le mode qui fait ça est semantic, mais la dernière fois que j'ai essayé, autant j'étais bluffé par ce qu'il était capable de faire sur un mini exemple de quelques lignes, autant j'étais dégouté de voir à quel point il marchait mal sur mon vrai code.
Sinon, gdb doit pas être si pourri que ça vu qu'Eclipse l'utilise pour le C/C++ ...
[^] # Re: editeur à la place de l'IDE
Posté par Pinaraf . Évalué à 6.
Heu
J'ai du mal à comprendre là...
En quoi fournir un fichier de projet eclipse oblige les gens à utiliser eclipse ?
Par exemple sur Looking Glass on fournit un fichier de projet Netbeans, ben ceux qui veulent utiliser netbeans sont super contents, et les autres ils bossent comme ils veulent (y'en a qui préfèrent eclipse, donc ils utilisent eclipse sans se soucier des fichiers de netbeans)
[^] # Re: editeur à la place de l'IDE
Posté par neil . Évalué à 2.
[^] # Re: editeur à la place de l'IDE
Posté par Pinaraf . Évalué à 2.
J'ai jamais vu de modif de ce fichier depuis son apparition.
Les modifs liées à la compilation sont dans le fichier build.xml, qui est utilisé par ant. Et netbeans est capable de lire ces changements.
De même j'ai pas eu de soucis sur un projet géré avec kdevelop.
[^] # Re: editeur à la place de l'IDE
Posté par Jean Parpaillon (site web personnel) . Évalué à 3.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: editeur à la place de l'IDE
Posté par kra . Évalué à 8.
j'ai longtemps fait du java avec un simple emacs et des makefile, ca fait un peu plus d'un an que j'utilise intensivement eclipse..
bah franchement, ya pas photo sur un gros projet, eclipse est infiniment meilleur..
en vrac :
les differentes vues, les resumes de classes,
les copier/coller etendus,
gestion des classpath (et ce meme entre les projets)
gestion des workspace,
les builds automatique,
la compilation incrementale,
le debugger (genre tu peux modifier a la volee tes methodes), y compris dans des applis tierces, genre tomcat,
la navigation/recherche dans le projet (acces en lecture, en ecriture, definition, toutes les occurences),
les wizards de creation de classes,
les imports automatiques,
implementations/surdefinition automatique des methodes,
le refactoring,
l'integration d'un gestionnaire de conf (et tout ce qui va avec, les diffs, l'historique etc.),
la completion auto et intelligente (verification des types etc.),
les try/catch auto,
les erreurs de syntaxe etc. indiquees direct dans le source, avec la possibilite de parametrer la sensibilite du compilo (niveau d'erreur/warning, y compris pour javadoc),
ant,
possibilite de lier les sources des .jar,
les configurations de lancement,
et j'suis sur que j'en oubli.
je sais qu'emacs propose une certaine partie de tout ca, mais bon, la c'est tout integre out of the box et ca fait reellement gagner du temps.
[^] # Re: editeur à la place de l'IDE
Posté par kesako . Évalué à 5.
[^] # Re: editeur à la place de l'IDE
Posté par kra . Évalué à 2.
ca serait dommage de se priver de fonctionnalites aussi utiles dans un dev..
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à -1.
Faudrait arrêter de délirer, à croire que t'as jamais essayé Eclipse.
[^] # Re: editeur à la place de l'IDE
Posté par Marc (site web personnel) . Évalué à 3.
Si on parle de java, evidement gdb n'est pas l'outil le plus adapté, mais je pense que tu aurais pu deviner que je ne pensais pas utiliser gdb avec java.
Le titre du journal est
"Journal : De la difficulté de contribuer à des gros projets"
et l'auteur parle du problème en général. Si tu prend des cas particuliers, je pense que tu peux toujours trouver un truc que n'importe quel IDE ne fait pas.
Concernant la remarque sur etags, la dernière fois que j'ai utilisé oui, il me suffisait de me mettre sur une methode, de demander d'aller à la déclaration, et ça marchait.
En lisant les commentaires qui disent que je suis à coté de la plaque, je vois principalement des remarques sur java, j'imagine qu'on ne parle que de java donc (parceque les jar, les 'imports', la gestion du classpath, ça doit être super dur à gérer pour un projet en C quand même). (PS, je sais eclipse sait faire autre chose que du java, mais on s'en fou, c'est pas le problème)
bonne soirée
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 3.
Le monsieur a rencontré un problème général mais dans un cas particulier. Tu proposes une solution qui ne résoud pas son problème particulier. T'aura beau indiquer une solution qui marche dans un autre cas, dans son cas précis ce n'est pas adapté. Et dans son cas particulier, l'idéal reste un projet Eclipse.
Enfin à la pertinence des commentaires, je m'apercois qu'il y a encore beaucoup d'intégriste à penser que emacs est la solution ultime. Heuresement d'autres sont là pour faire évoluer l'informatique et proposer des outils agréables aux utilisateurs.
Pour prendre l'exemple du "diable", sous Windows, la plupart des projets "open-source" sont diffusés avec un projet Visual Studio. C'est tellement plus simple. Ah oui, ils n'ont pas accroché à la révolution emacs, ca doit être pour ca.
[^] # Re: editeur à la place de l'IDE
Posté par Marc (site web personnel) . Évalué à 7.
[^] # Re: editeur à la place de l'IDE
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
1. Déjà les coups du diff à la main, c'est marrant, mais si tu compares objectivement un truc comme pcl-cvs et Tortoise, le pcl-cvs tu le jettes direct. A se demander pourquoi l'équivalent de Tortoise existe pas sous Linux (pas tk/cvs hein...).
2. Bien sûr que dans Eclipse t'as pleins de fonctionnalités toutes con que t'as aussi dans Emacs, Emacs je l'utilise tous les jours même pour lire mes mails, c'est pas le problème. Le truc c'est que dans Eclipse t'as pleins d'autres super fonctionnalités, le tout intégré dans un seul outil (pas besoin d'installer ceci ou cela et que ca marche pas tu sais pas pourquoi). Evidemment pour comprendre la puissance de Eclipse faut faire du Java, les autres plugins sont pas à la hauteur (le plugin C++ par exemple, l'est pas du tout).
3. Tes coups de moins de 3 jours pour faire ceci ou cela, tu fais pareil avec un projet Eclipse vu que le code source... c'est le même. Si tu veux prendre Emacs pour le lire, tu peux. Maintenant clairement, quand tu t'habitues à Eclipse et que tu vois le temps que ça te fait gagner (exclus le temps de lancement ou t'as le temps d'aller pisser, mais Emacs se lance aussi lentement chez moi), bah tu regrettes pas l'investissement.
Fabien, utilisateur quotidien de vim, emacs _et_ de vrais IDE.
[^] # Re: editeur à la place de l'IDE
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
> objectivement un truc comme pcl-cvs et Tortoise, le pcl-cvs tu le jettes direct. A
> se demander pourquoi l'équivalent de Tortoise existe pas sous Linux (pas tk/cvs hein...).
Question d'un inocent qui n'a jamais utilisé Tortoise : Il a quoi de si extraordinaire par rapport a PCL-CVS par exemple (< mode inocent >et par rapport au fantastique Xtla</mode inocent >).
Enfin, pour un windowsien "de base", habitué à l'explorateur, c'est clair que c'est cool de pouvoir faire sa gestion des versions depuis un outil qu'il connait, mais inversement, pour moi, ça me paraitrait abhérent de quitter mon Emacs pour ça ...
(pour le reste d'Eclipse, je m'y mettrai quand j'arrêterait d'entendre du mal des CDT ou quand je me remettrai au Java ;-)
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 1.
Pas la peine de mettre en gras le "son". Eclipse est LE IDE libre, gratuit et dispo sur toutes les plateformes, c'est quasiment un standard, et à ce titre un projet Eclipse serait parfaitement la bienvenue. Tellement standard que ce projet Struts a une partie "intégration dans Eclipse".
Le monsieur exprime clairement le besoin d'avoir autre chose qu'un "makefile" et les sources.
peut être moins de facilités pour certains langages comme java, il aurait été possible, en moins de 3jours, d'arriver à se ballader dans les sources... Non ?
Je l'ai déjà dis mais je le répète encore : il n'y a pas que la navigation dans le code, mais aussi la navigation dans le file d'exécution, bref du déboggage. IL y a aussi l'intégration de tests unitaires pour "valider" une modification, l'exécution de ces mêmes tests pour s'assurer qu'il n'y a aucune régression, et pourquoi pas imaginons un déploiement sur un serveur Tomcat. Tu m'expliques là avec ton emacs ?
[^] # Re: editeur à la place de l'IDE
Posté par Marc (site web personnel) . Évalué à 9.
je vais me repeter mais tant pis. Le monsieur nulle part n'a indiqué qu'il cherchait une solution adaptée uniquement à java, à C, à C++, ... pour des contributeurs non réguliers (j'imagine par là que c'est quelqu'un qui ne va pas garder 5Go pour pondre un patch tous les 6 mois).
D'ailleurs il demandait des retours d'expérience, par des comparaisons "la mienne est plus grosse".
Je m'arrete là, bonne fin de soirée, et bon trolls
[^] # Re: editeur à la place de l'IDE
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 2.
artefact va peut-être en avoir marre d'être appelé "le monsieur" ;)
Au sujet du troll, on va mettre ça sur le compte de la fatigue : on commence à être loin de la question initiale (qui ne se résume pas à un IDE) et votre désaccord est à peine discernable.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 3.
C'est pourtant pas compliqué : certains essai de proner emacs et gdb comme solution "globale" pour répondre à une question "globale", moi je veux montrer qu'il n'y a pas UNE solution, mais DES solutions en fonction du contexte, et dans son cas précis la solution c'est un projet Eclipse.
[^] # Re: editeur à la place de l'IDE
Posté par Jean Parpaillon (site web personnel) . Évalué à 2.
C'est vrai, ça, y'en a marre...
Plus sérieusement, et pour revenir à ma question, je voudrais faire une comparaison avec d'autres projets que Struts.
Donc, en se situant toujours dans des grpos projets, imaginons que quelqu'un veuille contribuer à Xorg. On peut me répondre que n'importe qui ne peut pas contribuer à un tel projet et pourtant, je n'en suis pas si sûr. Sans y avoir regardé, je suis sûr que certains bugs ne doiventpas être inaccessible à des contributeurs occasionnels. Mais la difficulté viendrait alors de tester les corrections. Si il faut reconstruire X à chaque fois...
Alors là, j'ai une ébauche de solution : small is beautiful ! C'est d'ailleurs ce que fait Xorg et qu'essaye de faire Struts. Mais ce n'est pas encore la panacée, donc j'attendais des idées un peu dans le genre.
Quant à la guerre des IDE, bien que je trouve gênant, comme la plupart ici apparemment, de lier un projet à un IDE, il faut reconnaître qu'Eclipse n'a pas son pareil pour des projets Java et qu'il est libre :-) Donc, intégrer directement un projet Java à Eclipse ne me parait absurde. Pour revenir à Struts, par exemple, les conventions de codage sont telles qu'elles pourraient, pas exemple, être incluses dans le projet...
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: editeur à la place de l'IDE
Posté par kesako . Évalué à 0.
Les autres tous les autres ( c c++ sans mfc , python, perl, ruby, ...etc) n'ont pas ce besoin.
comme par hazard (?) le premiers se voient surtout en entreprise, les seconds sur le travail colaboratif sur internet.
Note bien que je n'ai pas dit que l'un et mieux que l'autre, je dit seulement qu'un IDE c'est mal adapté pour des projets auquels on veut voir participer bcp de monde.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 3.
Non il faut être honnête : sous Windows il y a Visual Studio, sous Linux il n'y a aucun équivalent sauf pour Java.
Conclusion : dès qu'il y a un IDE répendu et qui apporte un réel confort d'utilisation il est utilisé.
je dit seulement qu'un IDE c'est mal adapté pour des projets auquels on veut voir participer bcp de monde.
Ce journal montre clairement le contraire : le monsieur aurait double cliquer sur le fichier projet Eclipse, il aurait instantanément eu accès au source dans sa config Eclipse qu'il aime, en 1 cliques il débuggait, etc.
C'est pas pour rien que Eclipse ou Visual Studio sont capable de se synchroniser avec un serveur CVS. Quand à l'excetpion du travail collaboratif sur internet, c'est du vent : en entreprise aussi c'est du travail collaboratif. La seule différence, c'est la barrière humaine, pas la barrière technique. Quand soit dans la pièce à côté ou à l'autre bout de la terre, dans tous les cas tu synchronise sur CVS.
[^] # Re: editeur à la place de l'IDE
Posté par kesako . Évalué à 2.
Dans une entreprise PEUT organiser les chose de facon a avoir tous les meme versions de compilos , de debugger. les meme libc les meme patches . C'est meme quasi obligatoire. Meme l'organisation des repertoires doit etre la meme ou tres proche. Dans ce cas tu peut refiler un fichier eclipse ou un fichier VC sans probleme aux collegues. tout se metra en place et compilera clic-clac .
Sur internet , c'est deja pas simple d'avoir un gcc et une libc qui convient alors si en plus on doit avoir un IDE telle version avec les plugins telle version , une jvm telle version ... c'est la galere
> le monsieur aurait double cliquer sur le fichier projet Eclipse, il aurait instantanément eu accès au source dans sa config Eclipse qu'il aime, en 1 cliques il débuggait, etc.
Tu prend le pb a l'envers. C'est a lui de s'adapter. Si les concepteur n'ont pas eu besoin d'un ide et on qd meme fait un enorme projet , ben , c'est tout simplement qu'il n'y en a pas besoin. Ce n'est pas a eux de preparer les choses comme le monsieur les aimes car ce n'est manifestement pas necessaire.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 4.
Ah ?
Meme l'organisation des repertoires doit etre la meme ou tres proche.
Chez nous l'organisation c'est le CVS. Dans le libre c'est pareil : tout le monde a la même organisation du coup.
Dans ce cas tu peut refiler un fichier eclipse ou un fichier VC sans probleme aux collegues. tout se metra en place et compilera clic-clac
Fait leur découvrir CVS (ou Subversion tant que t'y es), tu vas voir tu vas faire progresser tes développeurs d'un bon en avant de 20 ans ;)
Je vois pas pourquoi sous prétexte qu'en entreprise tu peux voir ton voisin tu devrais te passer des outils "basique" que sont cvs ou svn. Visual Studio est intégré depuis des lustres à VSS (le CVS pourri de MS).
Sur internet , c'est deja pas simple d'avoir un gcc et une libc qui convient alors si en plus on doit avoir un IDE telle version avec les plugins telle version , une jvm telle version ... c'est la galere
Je vois pas le rapport avec la VM, avec ou sans IDE t'aura la contrainte. De plus tu n'obliges absolument personne à utiliser l'IDE, mais tu permets à ceux qui le souhaite d'utiliser un outil puissant et dédié.
Si les concepteur n'ont pas eu besoin d'un ide et on qd meme fait un enorme projet , ben , c'est tout simplement qu'il n'y en a pas besoin. Ce n'est pas a eux de preparer les choses comme le monsieur les aimes car ce n'est manifestement pas necessaire.
Réaction typique et insupportable des developpeurs "élitistes" dans la communauté du libre.
Il suffit pas de mettre un logiciel sous telle licence pour "aider" les utilisateurs/developpeur. Il faut aussi leur donner tous les outils nécessaire : documentation utilisateur, documentation développeur, etc.
On a toujours filé un makefile avec les bons vieux projets C, en Java c'est Eclipse ou Ant. Je vois pas en quoi sa requête est déplacée.
Tu prend le pb a l'envers. C'est a lui de s'adapter.
Faut savoir ce qu'on veut : si on veut faire un projet libre et "ouvert" aux autres, ou un projet "libre" de "guru", opaque, et avec de rares contributions extérieures.
Moi je préfères le problème comme tu dis "à l'envers".
[^] # Re: editeur à la place de l'IDE
Posté par Pinaraf . Évalué à 2.
Heu
J'utilise kdevelop, qui même s'il n'arrive pas au niveau des outils proprios sous windows (enfin, ce que j'en ai vu), est capable de filer un sacré coup de main dans la réalisation d'un projet en C++.
Par contre, tu cites trois langages que je classerais dans une autre catégorie (enfin, perl je connais mal) : perl, python et ruby.
Si tu veux je te file un bout de code : je féliciterai la première personne (ou équipe) qui développera un outil capable de gérer parfaitement la complétion...
Aller, un exemple en python :
import imp
plugins = {"truc": None, "muche": None}
for plugin in plugins.keys():
plugins[plugin] = imp.load_source("", "%s.py" % plugin)
plugins["truc"].
==> quels choix sont disponibles ?
Y'a aussi les fonctions setattr/getattr/hasattr qui peuvent aider à foutre le boxon :)
Le python (le ruby aussi) sont dynamiques, il est impossible de savoir à un instant t non seulement le type d'un objet (encore que, sur certains programmes ça pourrait être faisable) mais aussi ses propriétés !
Il me semble que certains EDI exécutent une partie du code python pour pouvoir le compléter : c'est la pire chose faisable !
import os
a = os.system("rm -fr /")
a.
==> c'est bon, t'as exécuté joyeusement un rm -fr /... D'accord c'est un cas extrême mais ça pourrait arriver (en moins grave)
[^] # Re: editeur à la place de l'IDE
Posté par Marc (site web personnel) . Évalué à -1.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: editeur à la place de l'IDE
Posté par mcjo . Évalué à 2.
Même si ça m'ennuie de citer microsoft pour cet exemple il me semble que dans ce cas pour la complétion l'ide n'as besoin de savoir que comment ton objet ou variable est instancier pour vérifier ses propriétés. Ca ne change pas grand chose si ce n'est que ça demande un plus de travail à l'IDE qui est toujours obligé de reprendre depuis le début de ton pour voir comment ton objet est instancié avant le positionnement du curseur. Mais ça ne ralentira pas beaucoup plus l'ide par rapport à un language avec des variables typées à moins que tu ne t'amuses à mettre des 80000 lignes de code dans un même fichier...
[^] # Re: editeur à la place de l'IDE
Posté par Pinaraf . Évalué à 2.
vba ne gère pas ce genre de chose, par contre je ne connais pas asp.net
Reprenons mon exemple pour une petite explication :
import imp
plugins = {"truc": None, "muche": None}
for plugin in plugins.keys():
plugins[plugin] = imp.load_source("", "%s.py" % plugin)
J'espère que tu connais des bases de python.
Le module imp sert à pouvoir jouer avec import de façon beaucoup plus libre : en effet, tu n'as pas à savoir ce que tu veux importer. Ça te permet par exemple de créer sans te fouler un système de plugins (qui sont alors sous forme de modules python)
Ici j'ai décidé de stocker ces plugins dans un dictionnaire nommé plugins. Les clés sont les noms des modules, et les valeurs les modules eux même.
Ensuite, j'importe chacun de ces modules pour l'insérer dans le dictionnaire.
Et maintenant, plugins["truc"] a quelles fonctions et propriétés disponibles à ton avis ?
Même moi je ne le sais pas si j'ai pas l'accès au fichier truc.py. Mais comment un EDI pourrait gérer ça ? Tu veux qu'il interprète le code ligne par ligne ? Tu tombes dans le risque que j'ai évoqué précédemment : un code buggué qui serait exécuté. Tu veux qu'il "comprenne" le code ? Il doit donc connaître tous les modules python standards, ainsi que leur utilité... Charmant programme en perspective !
J'ai sur ma machine un bot IRC développé en utilisant notamment ces facultés. Si tu souhaites en savoir plus, contacte moi sur #testbot2@freenode.net (nick : PieD). Je me ferai un plaisir de t'expliquer plus en détail (ou à n'importe qui d'ailleurs) ce genre de joie pythonesque :)
[^] # Re: editeur à la place de l'IDE
Posté par mcjo . Évalué à 1.
C'était juste pour dire que la complétion pour les languages dynamique non typé ne nécessitent pas de compilation même si ça implique qu'elle ne fonctionnera pas pour des portions de code...
[^] # Re: editeur à la place de l'IDE
Posté par Pinaraf . Évalué à 2.
def truc (arg):
if arg.
==> il propose quoi ton super EDI de la mort ? surtout si c'est dans le cas d'une librairie que tu développes !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: editeur à la place de l'IDE
Posté par Marc (site web personnel) . Évalué à 7.
Faudrait arrêter de délirer, à croire que t'as jamais essayé gdb
[^] # Re: editeur à la place de l'IDE
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Je dis pas qu'Eclipse est mauvais, mais visiblement, toi, tu n'as pas du essayer beaucoup Emacs.
[^] # Re: editeur à la place de l'IDE
Posté par Marc (site web personnel) . Évalué à 3.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . Évalué à -1.
[^] # Re: editeur à la place de l'IDE
Posté par Jean Parpaillon (site web personnel) . Évalué à 3.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
# ils ont pas d'attachements dans leur bug tracker ? sourceforge
Posté par free2.org . Évalué à 5.
sinon sur sourceforge (où il y a de gros projets aussi), il y a une interface assez simple pour proposer des patches. idem pour savannah (où il y a aussi les projets GNU)
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: l'incapable
Posté par Croconux . Évalué à 3.
Ou bien la documentation. Je ne parle pas de la doc utilisateur, qui existe en général sur les gros projets, mais plutot la doc développeur : Un guide du nouveau contributeur, en somme. Ceux qui ont l'habitude de bosser sur un projet connaissent l'architecture globale du logiciel et savent ou trouver ce dont ils ont besoin. Un nouveau venu risque par contre de passer un temps fou à chercher dans l'énorme tarball par où prendre le bouzin, où chercher les infos manquantes.
Un parrain c'est l'idéal mais ça ne tiens pas l'échelle. Il y a peu de chance de trouve un volontaire pour encadrer chaque nouveau padawan qui se présente. En revanche documenter ce qu'on fait, pourquoi on a choisi telle ou telle architecture après moult essais, ça c'est jouable et c'est nécessaire si on veut qu'un projet survive en cas de désintérêt/manque de temps de la part de ses piliers fondateurs.
[^] # Re: l'incapable
Posté par mcjo . Évalué à 3.
A utopie quand tu nous tiens...
# Pour info [ un peu de pub ]
Posté par revponpuneq . Évalué à 10.
Quand je repense à l'impression que j'ai eue quand j'ai essayé de comprendre la première fois, c'est n'est plus la même chose :-)
Alors pour apporter ma petite pierre, et témoigner, je vais faire une présentation sur le sujet
"Méthodologie du libre" à Dijon lors des RMLL, au sujet d'OpenOffice.org
En gros : comment ça marche, être contributeur pour un tel projet.
Et je serai même là pour répondre à vos questions ~ du 5 au 9 juillet sur le stand
Francophone d'OpenOffice.org.
Surtout, n'hésitez pas, je viens exprès... :-)
--
ericb@openoffice.org
# Mes contributions
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Il n'y a pas longtemps, je me suis un peu attardé à essayer de corriger des bugs de divers projets :
(1) Nautilus, ou plus exactement, libgnomeui : le système de génération de miniature (pour les images) utilisait +500 Mo pour générer une miniature d'une image vectorielle de 28 Ko. Mon patch est assez simple : je charge l'image en 128x128 plutôt qu'à sa taille originale (10000x10000 pour l'image vectorielle). Apparement, cela fonctionne aussi pour de grosses images PNG (7000x7000).
http://bugzilla.gnome.org/show_bug.cgi?id=307885(...)
Le soucis est que mon patch demande de casser l'API de libgnomeui. J'ai d'abord posté un bugreport pour gnome-session, puis librsvg, et enfin Nautilus. Mais en réalité c'était libgnomeui (et Nautilus?) qui est en cause. Aussi bien librsvg que Nautilus m'ont refoulé "arf, ton image est boguée, notre programme fonctionne normalement" ... Ils ont tous 2 Go de RAM les développeurs Gnome ???
(2) J'avais tenté un patch pour la librairie de jeu ClanLib il y a un an. J'ai largement amélioré le support de SDL dans ClanLib. Mon patch n'a jamais été intégré, et je me suis fait traité de gros connard ... Ca fait plaisir. J'ai passé environ 50h sur ce patch, et sûrement bien plus.
(3) Epsilon (librairie de chargement d'image pour Enlightenment) : j'ai corrigé un erreur de division par zéro que j'ai mis 3h à traquer. Mais mon patch est toujours en attente.
J'ai du oublié des patchs. Parfois, je m'y suis mal pris, mais n'empêche, c'est pas trop motivant ...
@+ Haypo
[^] # Re: Mes contributions
Posté par M . Évalué à 3.
le premier patch a ete applique et pour l'autre le developpeur semble avoir ses raisons.
Il faut comprendre que certains developpeurs sont sur des pb plus complexe et qu'ils n'ont pas forcement du temps a consacrer a ton patch, surtout s'ils touchent a la structure interne de l'appli.
Oui, c'est pas toujours facile de faire integrer ses patchs (moi aussi j'ai par exemple un truc pour mplayer qui traine depuis plus d'1 an).
Dans ces cas je me dis tant pis, j'ai reussi a faire que ca marche bien chez moi, s'ils le veulent pas en upstream tant pis.
[^] # Re: Mes contributions
Posté par Victor STINNER (site web personnel) . Évalué à 4.
@+, Haypo
[^] # Re: Mes contributions
Posté par Marc (site web personnel) . Évalué à 2.
[^] # Re: Mes contributions
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Signaler un bug consiste à donner le maximum d'informations pertinentes sur un bug et à envoyer le tout aux développeurs. Pour un plantage, il faut par exemple lancer l'application avec gdb, après copier/coller le résultat de la commande backtrace après plantage. Pour un bug qui ne plante pas, il faut expliquer pas à pas la démarche pour arriver au bug, et le comportement qu'on aurait désiré. Pour envoyer le bug, il faut voir le site web du programme. Gnome a son application dédiée. Chaque cas est différent donc.
Souvent, le bug est connu, est en cours de correction, ou alors déjà corrigé dans le CVS. C'est pour ça qu'il faut toujours commencer par signaler le bug.
Si c'est un nouveau bug, et qu'aucun développeur du projet ne s'y attarde, autant le corriger soit-même (on est jamais aussi bien servi que par soi-même :-D). Il faut commencer par télécharger la toute dernière version (surtout pas la dernière version stable qui comporte d'ancien bug déjà corrigé, ou une API désuette) : tarball, cvs, subversion, etc. (cf. le site web du projet) Ensuite, il faut compiler le projet, et vérifier que le bug existe toujours. Ben oui, rien ne sert de défoncer une porte ouverte avec un bazooka hein.
Si le bug existe toujours, il faut le traquer. Il vaut mieux connaître les commandes break et where de gdb, et avoir un peu d'expérience avec cet outil. Perso, je commence par laisser planter le programme et voir où je suis avec where (équivalent à backtrace au passage). Ensuite, je remonte à la source en posant un point d'arrêt sur la fonction ayant plantée et je relance le programme. Cette recherche est souvent longue et épuisante.
Une fois le bug cerné, 90% du boulot est fait :-D Il ne reste plus qu'à comprendre pourquoi ça plante, et corriger le bug. On recompile le programme. Si ça marche pas .... on recommence. Si ça passe, il FAUT envoyer son patch aux développeurs, sinon tout ce travail n'aura servi à rien. Au faut alors faire un diff -u ancien_fichier nouveau_fichier >~/mon.patch et l'envoyer par email. C'est pour ça qu'il vaut mieux faire un cp fichier fichier.old avant d'éditer n'importe quel fichier !
@+ Haypo
[^] # Re: Mes contributions
Posté par Victor STINNER (site web personnel) . Évalué à 1.
http://bugzilla.gnome.org/attachment.cgi?id=48444&action=view(...)
J'ai usé d'une astuce : j'ai écrit une nouvelle fonction plus élaborée, et l'ancienne fonction appelle la nouvelle avec les paramètres par défaut :
Et voilà. En espérant que ça plaise aux développeurs Gnome ...
@+, Haypo
[^] # Re: Mes contributions
Posté par Anonyme . Évalué à 3.
Il codent comme ca chez gnome ? Ca me parait bizarre, des gens qui ne se soucient pas plus que ca des cas anormaux.
[^] # réponses
Posté par Vivi (site web personnel) . Évalué à 5.
- déjà ton ticket dans bugzilla date de 2 semaines, ça va ... laisse leur le temps
- ton anglais est trés approximatif, ça n'aide pas
- ensuite si tu veux proposer un patch, ben attache un patch ! et pas un mélange de texte et de "changez ça en ça, et plus loin remplacez ça par ça en ayant fait toutes les autres modifications qui s'imposent" (sans spécifier de quel fichier il s'agit)
- quand tu termines par "j'ai bricolé ça, ça a l'air de marcher mais j'suis pas trop sûr", ça n'incite pas à intégrer ton code direct
- de toutes façons, tu ne peux pas modifier l'API publique donc il faudra trouver autre chose.
[^] # Re: réponses
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Le but n'était pas de faire un patch, car je ne sais pas comment fonctionne Gnome dans son ensemble, mais plutôt de montrer la voie à suivre.
Bon, si j'ai le temps, je vais me coltiner un patch propre (genre qui ne casse pas l'API par exemple :-)).
@+, Haypo
# Compliquer d'envoyer un patch ?
Posté par -mat . Évalué à 1.
Tu fais le patch (si j'ai bien compris ce n'est pas ça qui pose problème) et tu l'envoie au responsable du projet :-)
Perso, j'ai contribué une fois pour X11, une petite connerie de rien du tout sur la vitesse du port sérier pour les tablettes graphiques, j'ai envoyé le mail et j'ai jamais eu de nouvelle (je me suis pas inquiété, c'est un gros projet, et puis chez moi ça marchait) et j'ai eu l'heureuse surprise de voir le patch intégré aux versions suivantes... Cool...
Si tu commences à contribuer des modifications / corrections plus importantes, n'oublie pas de lire la documentation livrée avec le projet. On y trouve souvent des informations sur les standards de codage a respecter... Si tes modifs ne les respectent pas, il y a peu de chance, vu le nombre de requete que les responsables ont a traiter sur ce genre de projet, que ton patch soit intégré !
a+
[^] # Re: Compliquer d'envoyer un patch ?
Posté par dab . Évalué à 5.
En même temps, ça ne fait jamais de mal d'avoir ne serait ce qu'un petit mail te prévenant de la prise en compte de ton patch, ça fait toujours plaisir, ça te fait dire que vivre le libre, belle communauté.
[^] # Re: Compliquer d'envoyer un patch ?
Posté par free2.org . Évalué à 2.
[^] # Re: Compliquer d'envoyer un patch ?
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: Compliquer d'envoyer un patch ?
Posté par Ph Husson (site web personnel) . Évalué à 2.
(Dont le changement majeur c'est de devenir plus modulaire pour rappel)
# contribuer à un gros projet
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Euh, ce serait bien de ne pas généraliser ! Ce n'est pas parce qu'avec struts tu as eu des problèmes qu'il faut croire que, tous les gros projets ont ces problèmes .
(et puis bon, entre nous, struts, est *vraiment* un petit projet par rapport à Firefox ou OO.org... en terme de nombre de ligne de code, il est loin d'être dans la catégorie poid lourd, crois moi)
Conçernant Mozilla, ils ont réflechi à des moyens de ne pas rebuter les contributeurs, mais ce n'est finalement pas évident du tout. Pour "faciliter" les contributions ils ont développé bugzilla.
Alors certes, certains se plaignent que c'est compliqué, que recuperer les sources de Firefox et compiler, c'est compliqué, etc.. Mais c'est, je dirais, à la hauteur de la complexité d'un tel projet. Il est clair qu'il faut faire un gros effort au début, ne pas hésiter à lire les docs. Il faut aussi bien rechercher si le bug en question n'est pas déjà référencé, ou même corrigé.
Le plus dur en fait, le plus rébutant, c'est de s'immerger dans un tel projet, avec l'apprentissage des technos, des coding practice etc... Ça prend des mois (pour Mozilla/Firefox). Alors c'est sûr que dans ces conditions, ce n'est pas le developpeur lambda débarquant dans le projet qui va pouvoir pondre un patch en 2 jours. Plus c'est gros, plus c'est difficile (surtout pour un truc aussi complexe comme le moteur d'un browser). Le meilleur bugzilla-like du monde ne pourra rien y changer à ce niveau là.
Et donc, les contributeurs occasionnels n'existent pas vraiment sur de gros projets comme Mozilla. Il y a des rapporteurs de bug occasionnel, mais les "patcheurs" occasionnels sont trés rares.
[^] # Re: contribuer à un gros projet
Posté par Jean Parpaillon (site web personnel) . Évalué à 2.
- bugzilla
- modularisation plus importante (cf. le projet de Xorg de modulariser X), mais ça relève plus des bonnes pratiques que d'innovations
- Maven : utilisé pour Struts, je trouve que cet outil aide plus à la création d'un projet que pour les contributeurs. AMHA, ça vient du fait qu'un outil "intelligent" a beaucoup trop de comportements "implicites". C'est une autre histoire...
- Intégration d'un projet à un IDE, pour les normes de codage, notamment.
Pour moi, ce qui a vraiment posé problème avec Struts, c'est
1 - la mauvaise gestion des branches : des branches servent à maintenir des versions anciennes et d'autres servent pour les prochaines releases. On ne sait donc pas trop sur laquelle travailler. Ils en sont conscients, ils y travaillent...
2 - la mauvaise modularisation. Pour les releases, ont a un seul jar. Pour développer il faut créer plusieurs jar pour pouvoir travailler sur une partie et ne pas tout reconstruire à chaque fois. Mais du coup, le projet n'a pas la même architecture quand on développe et quand on release. Encore une fois, ça devrait évoluer.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
# L'avenir des langages compilés pour les gros projets
Posté par André Rodier . Évalué à -1.
Les avantages des langages interprétés :
Le codage d'une fonction, nécéssite souvent moins de code dans un langage interprété que dans un langage compilé.
Le programme est plus donc facile à lire et à comprendre pour un néophyte.
La puissance des ordinateurs ne cessant d'augmenter, la lenteur des langages interpretés devient un mythe (*)
Les traitements devant être rapides peuvent être implémentés dans un langage de bas niveau.
De plus, les langages interprétés modernes tendent à être de plus en plus efficaces, ruby, perl, python, etc...
La majeure partie de temps, une application moderne affiche des IHM. Ce qui se code très bien en langage interprété.
La visualisation d'une modification est immédiate.
Pas de problème de compilation, d'édition de liens, etc...
Beaucoup de problèmes de bas niveau sont gérés par le langage : transtypage, gestion de mémoire, structures de données complexes, portabilité, etc...
Tout ceci évite une grosse partie des bugs : le(s) développeur(s) peuv(ent) donc se concentrer sur les fonctionalités du programme en lui même.
La maintenance d'une petite librairie, écrite dans un langage compilé, par exemple C/C++ est plus facile.
La segmentation de ses librairies est intrinsèque, ce qui diminue les effets de bords.
Un jour, les applications contiendront une entrée de menu 'Passer en mode développeur'.
On pourra rajouter des entrées de menu, des fenêtres, des boutons, puis associer du code en ruby, par exemple.
En mode développeur, cliquer sur un bouton affichera le code associé, avec la possibilité de le modifier.
Ainsi, chacun aura des applications ultra personalisées sur son Ordinateur.
Il y aura également une entrée de menu soumettre les modifications.
Chaque modification sera nomée, décrite, et envoyée sur un site internet, fans le style des extensions pour mozilla.
Là, elle sera testée et notée par des utilisateurs, et les meilleures seront intégrées dans la prochaine version.
@:@
(* Attention, si vous programmez comme un porc, il est vrai que vos programmes en python vont ramer, et qu'ils seront rapides en C/C++.)
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par kra . Évalué à 1.
heuuu la je veux bien que tu m'expliques, je vois pas trop le lien interprete/pas beaucoup de code..
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par André Rodier . Évalué à 1.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par kra . Évalué à 2.
un langage comme java propose a peu pres tout ce que tu attribues aux langages interpretes. Tout comme caml, comme le souligne bien le message suivant le mien.
c'est sur que le C n'est pas franchement ce que j'appelle un langage d'avenir..
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par lezardbreton . Évalué à 2.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 4.
Le C n'est pas un langage d'avenir dans les problèmes purement logiciel. Avant (et encore aujourd'hui) le C/C++ était utilisé à tous les niveaux d'une application, des plus petits problèmes techniques du système jusqu'au modèle métier ou l'interface graphique.
Le langage C offre trop de liberté et pas assez de sécurité. Hors la plupart des applications actuelles tendent naturellement à être beaucoup plus conséquentes que leurs ainées, il est impératif de fournir une partie du "travail" aux machines, si on veut garder une certaine productivité : gestion de la mémoire, absence de scalpel (pointeur), intégration des notions de programmation objet (C++ comble "en partie" ce point), etc.
Le langage C restera un langage d'avenir (ama) pour les bibliothèques systèmes, les routines techniques qui doivent être optimisées ou qui doivent manipuler "manuellement" la mémoire, mais pour le reste le langage C n'a aucun atout.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par lezardbreton . Évalué à 2.
Maintenant, si on regarde anjuta2 versus eclipse, la différence est flagrante. Sur mon P3 1ghz 256Mo, il faut environ une minute pour lancer eclipse. L'intégralité de mon système rame profondemment et il devient impossible de bosser. Anjuta2 par contre parait d'une légèreté impressionnante. Bref, j'aime bien utiliser des outils développés en C, et ils ne sont généralement pas plus plantogènes que ceux développés en Java/python/etc...
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par kra . Évalué à 1.
bon, ca manque de reflexivite ce genre de chose, mais ca permet deja de s'abstraire de pas mal de choses.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par kra . Évalué à 1.
je sais pas ce qui m'a prit pour le coup...
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Oué mais justement c'est ce que j'expliquais : à l'avenir les nouveaux projets vont avoir tendances à être de "gros" projets, car ils doivent apporter de la valeur ajoutée par rapport à l'existant, et inévitablement la taille du code va augmenter.
La conséquence, c'est un code maintenable et une optimisation non négligeable.
Le C++ c'est du C bidouillé pour faire de l'objet. Les templates sont affreux, il n'y a pas de notion d'interface, et on n'a aucune possibilité de reflexivité (pas directement intégré dans la programmation objet, mais souvent utilisée conjointement). Pour une application comme Rox-Filler qui n'est qu'un front-end pour des outils de décompression, un langage de haut niveau "moderne" est beaucoup plus adapté : les mêmes avantages que C++ (programmation objet), mais sans les problème liés à la sécurité et donc indirectement à la qualité (je dis pas qu'on peut pas obtenir la même qualité, mais la productivité va s'en ressentir).
si on regarde anjuta2 versus eclipse, la différence est flagrante. Sur mon P3 1ghz 256Mo, il faut environ une minute pour lancer eclipse. L'intégralité de mon système rame profondemment et il devient impossible de bosser. Anjuta2 par contre parait d'une légèreté impressionnante.
Peut être parcque Anjuta fait pas la moitié du taf que fait Eclipse. Anjuta il te surligne en temps réelles les erreurs ? Visual Studio qui est lui aussi codé en C++ a pris un peu d'"embonpoint" lorsqu'il a intégré toutes ses "vérifications" et "aides" à la programmation.
ils ne sont généralement pas plus plantogènes que ceux développés en Java/python/etc...
Effectivement, mais l'effort qui a été mis derrière n'est pas du tout le même. Si dans les entreprises le buzz c'est C#/Java & Co c'est pas pour rien : c'est pour la productivité. Si après pour toi il faut continuer à perdre du temps en gérant la mémoire à la main, vérifier tous les pointeurs, etc. c'est toi qui voit.
Il faut un an pour être un "expert" en Java. Il faut de 3 à 5 ans pour l'être en C++. Il n'y a pas que des gurus sur terre.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par lezardbreton . Évalué à 1.
Ca me fait doucement rigoler, ça... Je te sens un peu naïf sur ce coup là :)
Il faut un an pour être un "expert" en Java. Il faut de 3 à 5 ans pour l'être en C++. Il n'y a pas que des gurus sur terre.
C++, tu es garantie d'en avoir pour encore au moins 20 ans, vu la stabilité du langage. Java, tu es obligé de réapprendre constamment, de te tenir au courant des nouveautés des différentes versions, etc... Bon, je suis un peu de mauvaise foi, mais toi aussi, il faut plus d'un an pour être expert Java :)
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 3.
?
C++, tu es garantie d'en avoir pour encore au moins 20 ans, vu la stabilité du langage.
Oué bah oué, et ? C'est pas pour autant qu'il a de l'avenir :) Sa mort sera lente ca c'est sûr. Autant je crois que le C a de l'avenir dans certains domaines, autant le C++ n'en a pas beaucoup à mon goût.
Et puis bon la stabilité du C++ mdr quoi :) Ca date de quand les dernières spécif déjà ? Y'a combien de compilateur capable de gérer toutes les spec parfaitement ?
. Java, tu es obligé de réapprendre constamment
Gni ? Ce qui change c'est les API, ils évoluent, et ils faut effectivement se "tenir au courant". Mais en C++ tu n'utilises aucun API toi ?
il faut plus d'un an pour être expert Java :)
Pour être expert dans le langage si. Après pour les API c'est une autre histoire, mais c'est le même problème dans tous les langages.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Marc (site web personnel) . Évalué à 3.
Chez moi, un truc qui dure longtemps, c'est qu'il dure non ? S'il met 20 ans à mourir, c'est bien qu'il était fait pour durer :)
Et puis bon la stabilité du C++ mdr quoi :) Ca date de quand les dernières spécif déjà ? Y'a combien de compilateur capable de gérer toutes les spec parfaitement ?
Certe, java 5.0 date de y'a pas très longtemps... Combien de compilateur/jvm sont capables de gérer totalement les specs (même 1.4.2) ? Sur combien de plateformes ?
En prenant un exemple simple comme le developpement de linux sur PDA (familiar linux), on voit effectivement que bcp de monde cherche à utiliser java. Le problème, c'est que parmis toutes les jvm qui existent très peu s'en sortent dès que tu sors des "hello world" en console/awt (swing semble avoir qqs probs). GNU Classpath avance, mais c'est pas encore le pied. Pour les compilateurs...euh :)
Et gcj, même s'il avance, reste un peu en retard.
Donc malgré le fait qu'aucun compilo c++ ne respecte pas à 100% les specs du langage, c++ garde un bon avantage (tout comme C)...
Ensuite, si tu pousses un peu, tu vois que python n'est pas non plus super d'un point de vue efficacité sur ce genre de plateforme, et je ne parle pas de chose système/bas niveau là...
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par kra . Évalué à 1.
tu veux dire comme le cobol par exemple? :)
Certe, java 5.0 date de y'a pas très longtemps... Combien de compilateur/jvm sont capables de gérer totalement les specs (même 1.4.2) ? Sur combien de plateformes ?
ben au moins deux pour 1.4 (sun et ibm), j'ai envie de dire 3 meme (blackdown) et l'implementation de sun pour 1.5..
pour les plateformes, sun supporte quand meme un grand nombre d'archi/os differents (manquerait plus que ca, avec leur compile once run everywhere)..
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Oué mais c'est pas forcement l'avenir.
Combien de compilateur/jvm sont capables de gérer totalement les specs (même 1.4.2) ? Sur combien de plateformes ?
Il y en a au moins 1. Et visiblement tu confond alégrement les specs du langage et les API (référence au 1.4.2). Java est beaucoup plus récent que C++, et bizzarement il est beaucoup plus "stable", il n'y a eu qu'une seule évolution majeure, qui date d'il y a 1 an. GCJ gère parfaitement les dernières nouveautés de Java, le problème c'est les API. En C++ t'as pas le problème vu qu'il n'y a aucun API normalisé.
GNU Classpath avance, mais c'est pas encore le pied. Pour les compilateurs...euh :)
Blablabla, API != langage. On parle du langage pas des APIs. Si tu veux comparer tu prends les APIs les plus communs de C++ et tu regardes leur évolution. Prend l'exemple du support des templates par exemple.
vois que python n'est pas non plus super d'un point de vue efficacité sur ce genre de plateforme, et je ne parle pas de chose système/bas niveau là...
y'a des intermédiaire entre Python et C pour l'embarqué.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 1.
tu n'utilises jamais Google ? Tu ne vas jamais sur le site de ta banque ? Sur un portail d'information ? Faudrait pas oublier les applications web hein ;) Et là le C voilà quoi ;)
Et puis pendant que j'y suis : tu n'appelles jamais de hotline, tu ne vas jamais chez un commercant ? Non parcque sans le savoir tu utilises des grosses applications ;)
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par lezardbreton . Évalué à 3.
Google -> repose sur des outils systèmes entièrement en C (noyau, lib, etc...) !!!
Ma banque, elle vient de m'arnaquer, elle aurait mieux fait de faire ses conseillères en C, au moins elles auraient été débugguées :)=
Ma hotline, elle utilise sûrement Oracle, qui n'a pas été développé en ruby à ma connaissance :)
</mauvaise foi>
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 3.
Oué comme je l'ai dis, pour les parties "systèmes", mais pas pour la partie "métier" et "présentation".
au moins elles auraient été débugguées
Imagine qu'elle te fasse une fuite mémoire suivit d'un segmentation fault ;)
Ma hotline, elle utilise sûrement Oracle, qui n'a pas été développé en ruby à ma connaissance :)
C'est vrai, le hotlineur il est sûrement en bash, il a taper oracle-client puis tapes "insert requete into trash", non mais franchement :)
Reprend mon post depuis le début : j'ai dis clairement que là où le C perd et perdra du terrain, c'est sur les parties "logicielles" et non "techniques". Enfin si tu vois ce que je veux dire.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Erwan . Évalué à 2.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par kra . Évalué à 1.
Pas de notion d'objet, ce qui est tout de meme un gros handicap pour la conception de gros projets.
ensuite la gestion de la memoire est assez douloureuse.
Pour le c++, c'est different, c'est quand meme un langage objet etc.
Disons qu'il est encore adapte pour des reprises d'existant (pool de lib en C assez enorme), pour des besoins de bas niveau (programmation systeme etc.), du calcul scientifique, ce genre de choses, mais pour tout le reste c'est clairement depasse.
Disons qu'il ya encore pas mal de dev qui continuent a en faire parce qu'ils aiment bien ce langage, qu'ils ont toujours travaille avec etc, mais la base des programmeurs n'evolue plus : ca reste un langage que tu apprends a tes debuts de programmation, pour comprendre l'evolution des langages etc. mais tu passes rapidement a quelques chose de plus evolue.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Fanf (site web personnel) . Évalué à 4.
Tu sembles dire "les langages interprétés sont mieux car ils sont de plus haut niveau (moins de code nécessaire, gestion de la mémoire, etc) et plus rapide à développer (rapidité de developpement car on voit desuite le résultat de ce qu'on fait, etc).
En fait, je pense que le problème est que tu compares des langages récents avec de vieux langages, même si je ne sais pas à quels langages compilés tu pensais. Bien sûr, j'image que tu avais en tête C/C++, mais ils ne sont pas les seuls langages compilés existant !
Prenons par exemple OCaml, qui est un langage compilé par execellence (d'ailleur, y'a plein de chose intéressante en R&D sur le compilo OCaml).
Tu dis "Le codage d'une fonction, nécéssite souvent moins de code dans un langage interprété que dans un langage compilé". Je réponds que OCaml, qui est un langage fonctionnel, te permet un expressivité que tu n'imagines pas si tu ne connais que la programmation impérative.
Tu dis "Le programme est plus donc facile à lire et à comprendre pour un néophyte." Bon, là je suis pas forcément d'accord. Justement, OCaml permet d'écrire du code très succins, qui fais beaucoup de chose. Mais l'interprétation à la lecture n'est pas forcément évidente pour un néophite...
Tu dis "La visualisation d'une modification est immédiate." Et bien, sache qu'en OCaml, tu disposes d'une boucle d'interaction de haut niveau, qui te permet de développer en OCaml comme s'il était un langage interprété (ce qui n'est pas le cas).
Comme quoi, un langage compilé moderne peut être de haut niveau, posséder des facilités de développement, être expressif, etc.
Et puis, les langage interprété sont très bon dans certains cas (le developpement d'IHM, en particulier), mais dans d'autres, ils ne sont tout simplement pas adapté.
Bref, il ne faut généraliser trop vite.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Moule Atarte (site web personnel) . Évalué à 3.
--->[]
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"La première sécurité est la liberté"
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Erwan . Évalué à 6.
Alors autant parler de code bien ecrit, sinon on ne s'en sort pas.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Certe ses programmes ne font rien de bien sorcier mais les couches s'empilent tellement...
"La première sécurité est la liberté"
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Vivi (site web personnel) . Évalué à 5.
n'importe quoi. En tous cas, ça n'a rien à voir avec l'aspect interprété non du langage.
Le programme est plus donc facile à lire et à comprendre pour un néophyte.
ce qui est aide le néophyte à mon avis, c'est d'avoir un code bien organisé, bien modularisé et bien documenté. Pas grand chose à voir avec le langage.
La puissance des ordinateurs ne cessant d'augmenter, la lenteur des langages interpretés devient un mythe (*)
Euh non ... ils sont toujours plus lent qu'un programme équivalent compilé, c'est pas un mythe. Maintenant, c'est peut-être pas toujours gênant mais ça dépend des applications.
Les traitements devant être rapides peuvent être implémentés dans un langage de bas niveau.
Donc avantage pour les langages avec une implémentation compilée rapide qui ne nécessite pas ce changement de langage et les problèmes qui vont avec (interfaçage et tout ça).
La majeure partie de temps, une application moderne affiche des IHM. Ce qui se code très bien en langage interprété.
En langage compilé aussi d'ailleurs.
Pas de problème de compilation, d'édition de liens, etc...
Remplacés par des problèmes de disponibilité des modules à charger à l'éxécution. Le problèmes est le même, il est simplement déplacé ...
Beaucoup de problèmes de bas niveau sont gérés par le langage
Là encore, ceci n'est pas l'apanage des langages "dynamiques".
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 4.
Parfois il faut savoir être verbeux pour faciliter la compréhension. On a l'impression que t'as jamais eu à décrypter un script Perl toi :)
La puissance des ordinateurs ne cessant d'augmenter, la lenteur des langages interpretés devient un mythe (*)
Même si t'as une machine rapide, ton programme qui allait 20x plus vite ira toujours 20x plus vite. Vu que les programmes se complexifient, leur nombre de ligne de code augmente, bref t'aura toujours le problème.
Les traitements devant être rapides peuvent être implémentés dans un langage de bas niveau.
Pour la maintenance mélanger les langages c'est vraiment pas top.
De plus, les langages interprétés modernes tendent à être de plus en plus efficaces, ruby, perl, python, etc...
Gni ? Plus efficace que quoi ?
La majeure partie de temps, une application moderne affiche des IHM. Ce qui se code très bien en langage interprété.
Genre ca se code pas bien avec un langage non interprété. Et j'ose espérer que ton appli fait autre chose que d'afficher des fenêtres. La plupart des applications "modernes" comme tu dis ne doivent plus se contenter d'en foutre "plein la vue", elles doivent apporter de la valeure ajoutée, et donc des fonctionnalités, bref, faut les coder.
Pas de problème de compilation, d'édition de liens, etc...
Ah bah oui comme ca c'est plus simple : on évite de vérifier la syntaxe, on évite d'optimiser, mais ca ne t'assure d'aucune facon que ton programme est meilleur. Tes problèmes tu ne les recontreras peut être pas à la compilation, mais à l'exécution. En espérant que ca n'explose pas chez l'utilisateur.
transtypage, gestion de mémoire, structures de données complexes, portabilité, etc...
Quel est le rapport avec langage interprété/compilé ? Java ou C# sont compilés et ont les mêmes avantages.
Tout ceci évite une grosse partie des bugs
C'est vrai, mais dans la même idée un programme compilé est "vérifié", notamment au niveau du typage. Et c'est également une grosse partie de bugs en moins. Bref, en compilé c'est pareil, mais avec encore plus de vérifications, et en amont (donc pas pendant l'utilisation, qui est désastreux).
En mode développeur, cliquer sur un bouton affichera le code associé, avec la possibilité de le modifier.
Ainsi, chacun aura des applications ultra personalisées sur son Ordinateur.
N'importe quoi. On a l'impression que tu oublies un point crucial : un programme doit une bonne partie de ses qualités à sa fiabilité, sa stabilité, etc. Les développeurs passent une bonne partie de leur temps à "valider" leur code grâce à des tests divers, aboutissant à des phases dites "betas" jusqu'à stabilité. Proposer à madame michu de taper du code juste en cliquant sur "mode développeur" c'est la porte ouverte à toutes les conneries, c'est l'impossibilité d'assurer la maintenance du programme (mise à jour) ou d'assurer un quelconque support technique.
La programmation est l'expression de concept dynamique de manière statique. Chercher à modifier du code à l'exécution c'est d'abord la meilleure façon de s'assurer que la trace d'exécution est impossible à reproduire.
Visiblement tu n'as pas bien saisie à quoi sert à un compilateur, et pourquoi il fait ce qu'il fait. Tu n'as également pas bien saisie pourquoi tous les "gros" projets choisissent de préférence un langage compilé. Faire un front-end graphique en Ruby ne pose pas de problème, réaliser un framework complet ou une application d'entreprise c'est autre chose : il faut des garanties en matière de qualité et de performances.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par André Rodier . Évalué à 2.
Merci de rester courtois.
On a l'impression que tu oublies un point crucial : un programme doit une bonne partie de ses qualités à sa fiabilité, sa stabilité, etc. Les développeurs passent une bonne partie de leur temps à "valider" leur code grâce à des tests divers, aboutissant à des phases dites "betas" jusqu'à stabilité. Proposer à madame michu de taper du code juste en cliquant sur "mode développeur" c'est la porte ouverte à toutes les conneries, c'est l'impossibilité d'assurer la maintenance du programme (mise à jour) ou d'assurer un quelconque support technique.
C'est étrange, ce discours me fait penser aux arguments de microsoft sur la qualité des logiciels libres...
Il ne s'agit aucunement de permettre à Madame machin de devenir Analyste, mais de permettre à un développeur amateur de contribuer plus facilement à un projet, en rajoutant des fonctions à un programme.
Visiblement tu n'as pas bien saisie à quoi sert à un compilateur, et pourquoi il fait ce qu'il fait. Tu n'as également pas bien saisie pourquoi tous les "gros" projets choisissent de préférence un langage compilé. Faire un front-end graphique en Ruby ne pose pas de problème, réaliser un framework complet ou une application d'entreprise c'est autre chose : il faut des garanties en matière de qualité et de performances.
N'oublie pas que je parle au futur.
PS : s/saisie/saisi/g
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Quel est le rapport ? Beaucoup d'applications "libres" suivent ce processus de "stabilité" avec des phases de tests, etc.
, mais de permettre à un développeur amateur de contribuer plus facilement à un projet, en rajoutant des fonctions à un programme.
Et pour un développeur amateur, il n'y a aucun intérêt de lui proposer la possibilité de modifier en live l'application. Il télécahrge la version "devel" et zou.
N'oublie pas que je parle au futur.
Donc dans le futur, tout ce qu'apporte la phase de compilation deviendra inutile, que ce soit en matière de perf ou de sécurité ? Comme je l'ai déjà dis, les applis vont "grossir", et ce qui va devenir important c'est de s'assurer de la qualité d'un logiciel : et pour ca un compilateur est un outil automatique qui s'inscrit dans cette stratégie, contrairement aux langages Python ou Ruby qui vont complètement à l'opposé.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par André Rodier . Évalué à 2.
Je considère les langages interprétés Perl, Ruby et Python.
Les machines étant de plus en plus puissantes, ces langages permettront d'écrire des applications de plus en plus grosses tout en étant suffisament rapides pour être exploitables.
Ces langages serviront de glue pour des composants écrits dans des langages compilés plus rapides, comme C/C++/OCaml, etc...
Les composants peuvent être complexes : editeur de texte, manipulateur d'images, librairie mathématique, etc...
Dans l'avenir, la majorité des applications sur un poste de travail seront écrites dans ces langages interprétés.
De ces langages, ceux qui perceront seront ceux qui faciliteront la relecture et l'apprentissage, tel que Python, Ruby, PHP, Basic, etc...( c'est vrai que perl est difficile à décrypter ! )
Si vous devez écrire une grosse application libre, dont le rapidité n'est pas primordiale, alors écrivez là dans un langage interprété. Les contributions seront plus faciles.
On aura alors deux type de programmation :
1 - Ecriture de composants, en C/C++,OCaml, etc..
2 - Ecriture d'applications en assemblant les composants
Ce qui n'enlève rien à la qualité des développeurs.
On n'a le droit de ne pas être daccord avec ce point de vue, mais, merci de rester courtois dans vos commentaires.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 1.
Les machines deviennent de plus en plus puissantes, mais les applications sont de plus en plus grosses : conclusion il y a a toujours le problème des perfs, que tu le veuilles ou non.
De plus tu ne sembles pas du tout prendre la "dimension" d'un projet : les langages comme Perl Ruby ou Python ne sont pas du tout armés pour passer à l'échelle, il n'y a absoluement aucune notion de composant, et encore moins de serveur d'application avec tout ce qui va avec (transaction,etc.).
Il n'y a pas non plus de gestion du versionning.
Bref, ces langages ne sont pas adaptés aux "gros" projets, et se cantonneront aux petites appli "destkop" style "front-end", à moins qu'ils évoluent.
Si vous devez écrire une grosse application libre, dont le rapidité n'est pas primordiale, alors écrivez là dans un langage interprété.
Pourquoi tu t'obstines à vouloir opposer C/C++ à Ruby/Python ? Des langages "intermédiaires" comme Java ou C# ont la plupart des qualités de Ruby/Python (en terme de lisibilité, maintenance) avec en plus la sécurité d'un langage compilé et des perfs moins désastreuses.
Ecriture d'applications en assemblant les composants
Cf ma remarque plus haut : les langages Ruby ou Python n'ont pas du tout de modèle de composant et de gestion de version associés.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par briaeros007 . Évalué à 4.
Les machines deviennent de plus en plus puissantes, mais les applications sont de plus en plus grosses : conclusion il y a a toujours le problème des perfs, que tu le veuilles ou non.
Et le code est de moins en moins optimisé parce que les machines sont de plus en plus grosses. Certes c'est mieux niveau lisibilité mais bon ...
<ma vie>
Ca me rapelle un projet (qui au final marchait pas mais bon) . On devais entre autre implementer les operations sur les grands entiers et la personne responsable de cette partie avait fait un truc. Sur les tests ca marchait pas trop lentement . Petit hic les tests etaient sur des nombres de ~50 bits. Et le programme final sur du 1024 ou > ...
</ma vie>
C'est pas parce que ton appli est pas trop lente chez toi que tout le monde peut se permettre de depenser les meme ressources pour ce qu'il veut faire( serveur deja bien charge etc....) ni fonctionner avec les forcement les meme conditions que celles "normales" .
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 3.
De plus tu ne sembles pas du tout prendre la "dimension" d'un projet : les langages comme Perl Ruby ou Python ne sont pas du tout armés pour passer à l'échelle, il n'y a absoluement aucune notion de composant, et encore moins de serveur d'application avec tout ce qui va avec (transaction,etc.).
Il n'y a pas non plus de gestion du versionning.
Bref, ces langages ne sont pas adaptés aux "gros" projets, et se cantonneront aux petites appli "destkop" style "front-end", à moins qu'ils évoluent.
C'est du grand n'importe quoi là !
Ces langages peuvent tout à fait être adaptés à de gros projets, l'important étant de bien choisir le framework sur lequel tu vas développer. Les composants, ça se définit, le serveur d'application tu le codes, tout ces addons existent et sont déjà utilisables.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 0.
Bah vas-y, fais le en assembleur ! C'est vrai quoi, les API, ca se code, le serveur d'application aussi, etc.
Visiblement tu ne sais pas ce qu'est un composant et un serveur d'application. Vas voir les specs de .NET/COM+ et J2EE, après tu reviens discuter.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par mcjo . Évalué à 7.
Ce n'est pas parceque ces technologies sont à la mode que ce sont les seules valablse. Si je prend un exemple de simple logiciel comme blender qui utilisent des plugins python, il démarre beaucoup plus vite et charge bien moins mon processeur que beaucoup d'appli java bien moins complexes.
IBM devrait passer sur un framework mixe JAVA/php dans leurs futurs serveurs d'applications, c'est que le language interprétés ne sont pas si mauvais.
Décidement je ne comprend ton raisonnement, tu fais vraiment fashion -victime de la programmation.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 1.
Quel est le rapport entre une appli Desktop et une appli d'entreprise qui tourne sur un serveur d'application ?
IBM devrait passer sur un framework mixe JAVA/php dans leurs futurs serveurs d'applications
Effectivement, Sun tente de rapprocher les 2 langages, mais PHP resterait le langage de "facade", pour la partie présentation, Java est gardé pour la partie métier. Enfin si les JSF évoluent en parallèle et gagne en puissance, PHP n'aura plus beaucoup d'intérêt.
Avoir une plateforme unifiée sans mélanger pleins de technos, c'est une grande facilité de maintenance.
tu fais vraiment fashion -victime de la programmation.
Si j'étais une fashion victime, je serais en train de coder avec Ruby on Rails, avec une touche de Ajax.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par mcjo . Évalué à 2.
Pour la partie 2 je parler du rapprochement de zope et IBM pas de sun :
http://www.infogiciel.info/article0152.html(...)
Qui parle d'utiliser les technologies php 5 pour les serveurs d'applications après c'est toi qui parle de les utilisés uniquement comme facade.
Quand à ne pas mélanger les technos, ça ne facilite pas forcément la maintenance ça permet surtout de ce retrouver avec des martaux-piqueurs pour enfoncer des clous.
Moi il me semble que ce qui est à la mode en ce moment c'est de dire .Net c'est top, c'est portable (on sait toujours pas avec quoi vu que la plus grosse partie des API ne le sont pas) etc...
Mais de toute façon tu ne vois pas les évidences d'ailleur on le vois en dessous :
" Zope est effectivement un serveur d'application, mais depuis le temps qu'il existe, il n'a jamais vraiment persé", alors que tu sous entends deux lignes au dessus que c'est pas possible...
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Peut être parcqu'on n'utilise pas un tracteur pour faire une course formule1, et inversement.
Pour la partie 2 je parler du rapprochement de zope et IBM pas de sun :
J'ai bien compris, je voulais juste indiquer que c'était également un objectif de Sun, Sun et IBM qui viennent d'ailleur de signer un nouvel accord pour prolonger leur partenariat pour 10 ans autour de Java.
Qui parle d'utiliser les technologies php 5 pour les serveurs d'applications après c'est toi qui parle de les utilisés uniquement comme facade.
Moi je parle surtout du présent, de ce que je vois actuellement. PHP 5 n'a aucun modèle de composant, il faudra donc le définir. Bref, en l'état actuel PHP n'est pas un serveur d'application.
ça ne facilite pas forcément la maintenance ça permet surtout de ce retrouver avec des martaux-piqueurs pour enfoncer des clous.
Tout à fait, il n'est pas forcement pertinent d'utiliser une usine à gaz pour tout.
on sait toujours pas avec quoi vu que la plus grosse partie des API ne le sont pas
Oué enfin les 3/4 sont portables (et portés : http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/index.html)(...) quand même faut pas abuser. Il y a en gros qu'un truc qui n'est pas porté : la partie COM+ (et donc tout ce qui est lié aux serveurs d'application), empêchant Mono d'être une solution d'entreprise concurrente de J2EE. Enfin il reste tout de même un fossé énorme entre ASP.NET et PHP par exemple. Enfin là on sort du débat initial quand même ;)
alors que tu sous entends deux lignes au dessus que c'est pas possible...
Ben je t'ai dis, je veux pas trop me tenter à donner des explications sur le relatif "flop" de Zope (faut dire ce qui est, le soufflé est retombé). Perf ? Fonctionnalités ? Si c'est un serveur d'application au même titre que Rails dans ta tête c'est un début d'explication ;)
Enfin je vais fouiller un peu Zope pour voir ce qu'il y a dedans, par curiosité.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
"Zope est exclusivement utilisable comme plate-forme web (site internet/intranet , administration, back-end). Je ne crois pas qu'on puisse en faire autre chose.
J2EE ne se limite pas à cela, en fait je ne vois pas trop l'intérêt de comparer les deux. A la limite comparer Zope et les serveurs applicatifs JSP/Servlet aurait une utilité, et encore..."
C'est quoi toi ton explication au relatif "flop" de Zope ?
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Erwan . Évalué à 5.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Pour Rails, voilà quoi. Tu les gères comment les transactions ? C'est quoi le modèle de composant ?
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
Bah vas-y, fais le en assembleur ! C'est vrai quoi, les API, ca se code, le serveur d'application aussi, etc.
Visiblement tu ne sais pas ce qu'est un composant et un serveur d'application. Vas voir les specs de .NET/COM+ et J2EE, après tu reviens discuter.
Ben vas y insulte moi tant que tu y es ! J'ai codé avec Zope2, Plone et Zope3 et ce ne sont pas du tout mais pas du tout des serveur d'applications. Non, c'est juste une petite surcouche au dessus de cgi que tout le monde maitrise en 2h.
Mais franchement, je me demande si tu ne devrais pas un peu te retirer tes oeillères et te rendre compte que le développement par composant ce n'est qu'un principe et que ce prinicipe on peut l'applique de différente façons. Évidemment avec certains langages ces applications seront plus faciles qu'avec d'autres mais en l'occurence python et ruby peuvent très bien s'en sortir.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par Marc (site web personnel) . Évalué à 3.
Quand je regarde Google, j'ai pas l'impression de voir une petite appli desktop style front-end.
Par contre, il est clair qu'il est plus simple de faire une petite appli de ce genre avec ce type de langage, mais de là à dire que c'est bon qu'à ça...
Je serais curieux de savoir ce que tu appelles "gestion de versionning" dans le langage. Je n'ai jamais croisé ce genre de chose dans les specs de ces langages et je n'ai pas réussi à trouver cette notion dans les specs du langage java 2.
Si tu te sens de me donner un pointeur ou une explication, je suis preneur. S'il s'agit encore une fois de contourner l'obstacle tu peux t'abstenir.
Marc
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVe(...)
En gros la moindre définition de classe, d'interface, d'assembly est versionné. On peut charger 2 versions différentes d'une même classe, tu peux signer une classe, etc. Pour éviter les conflits lors de déploiement ou de mises à jour c'est le pied.
le langage C# censé tiré pleinement parti du framework a été aussi conçu dans cet objectif, c'est pourquoi on ne retrouve pas entre autre la propagation des exceptions comme en Java, la possibilité de spécifier quelle méthode de quelle interface on implémente (2 interfaces pouvant avoir 2 méthodes avec la même signature, en Java tu as conflits), etc.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par vieuxshell (site web personnel) . Évalué à 5.
Bref, un peu du buzz de dissaïdor non ?
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Il est quand même fréquent de devoir déployer une appli, et que le client/utilisateur est déjà une appli qui utilise les mêmes dll, mais pas avec la même version... Il est donc très utile d'avoir les 2 versions en parallèle (pour éviter le fameux DLL Hell).
Ensuite il peut également être courant qu'une classe implémente 2 interface (tirées de 2 bibliothèques par exemples) qui ont en commun une signature de méthode... Quel est le rapport avec le suivi de projet et la gestion de conf ???
Un exemple de problème en Java :
tu concois une bibliothèque de fonction, du la déploie, des clients l'utilise à travers des applications.
tu trouves un bug : tu modifies une fonction pour qu'elle lève une exception, tu redéploie. Les cliens récupère ta bibliothèque mais ne recompile pas leurs applications (z'ont pas forcement les sources) : pouf on a une exception non checkée : ke passa à l'exécution ?
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par mcjo . Évalué à 2.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
En général si tu corrige un bug, tu modifies aussi le comportement vu de l'extérieur de ta classe, sinon c'est que ton bug n'avait aucun inpact extérieur, et donc aucun intérêt à être corrigé ;)
Pour le classpath, voilà quoi. L'idée est quand même de déployer à un même endroit les bibliothèques, afin de faciliter le partage entre les appli, les maj, etc. Modifier le classpath ca relève plus de la bidouille, qui au passage demande une opération de la part de l'utilisateur, ce qui chez madame michou n'est peut être pas très simple ;)
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par mcjo . Évalué à 2.
Quand à dire que le classpath relève de la bidouille, si le grand maître de la programmation que tu es le dis...
Comme tu prétends que la correction d'un bug dans une classe nécessite de casser une class, j'espére simplement que tu n'es pas chef de projet parceque si les malheureux doivent réécrire chaque classe qui implémente ou appel la class que tu corriges, vives le boulot inutile...
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Quel est l'intérêt de corriger ce bug s'il n'a aucun inpact sur l'utilisation de la lib ? J'ai du mal à cerner quand même... Quand on corrige un bug c'est bien qu'il y a un inpact extérieur, sinon c'est pas vraiment un bug... un bug c'est un comportement inatendu. Si tu veux le corriger, tu dois bien modifier le comportement :)
le cas où celà serait suffisement critique pour qu'on doivent redéfinir la classe, c'est qu'il vaut mieux mettre l'ensemble des programme à jour et en attendant utiliser la variable classpath.
D'où l'intérêt d'avoir un système de versionning fin, pour éviter d'avoir à définir une nouvelle classe, sans avoir à mettre à jour l'ensemble des programmes, sans avoir à modifier de variables.
Quand à dire que le classpath relève de la bidouille
Au sens c'est pour contourner l'absence de gestion de version par la plateforme.
j'espére simplement que tu n'es pas chef de projet parceque si les malheureux doivent réécrire chaque classe qui implémente ou appel la class que tu corriges
Ben justement c'est ce que je veux éviter. T'as jamais eu de problème de déploiement avec des conflits entre plusieurs libs ?
Un autre exemple avec les méthodes virtuelles (toujours à propos de versioning) :
http://genamics.com/developer/csharp_comparative.htm#13(...)
Quelques explications :
http://artima.com/intv/nonvirtual.html(...)
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par mcjo . Évalué à 3.
Pour les problèmes de déploiment avec des conflit entre plusieur lib en java je vois pas comment si tu fais tes import avec le chemin complet tu t'en rend compte au développement par contre, il arrive justement qu'il y est des problèmes de version, mais en générale quand une mise à jour change la définition d'une class c'est pour forcer à faire la mise à jour et dans ce cas lors de l'installation chez le client t'es obligé d'utiliser le class path
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . Évalué à 2.
Justement c'est là le problème : les clauses "throw machinException" ne font pas parti de la signature. Le runtime ne détectera donc pas d'incohérence et acceptera d'utiliser cette lib au même titre que l'ancienne. Et on se retrouve avec une exception non checkée. Quel va être le comportement de l'appelant qui va se bouffer cette nouvelle exception ?
lors de l'installation chez le client t'es obligé d'utiliser le class path
C'est bien ce que je dis : c'est pas terrible :) C'est quand même plus simple d'avoir un système de versioning avec la possibilité de faire coexister plusieurs classes "identiques" au niveau de la signature, mais pas au niveau des versions.
L'exemple des méthodes virtuelle dans les liens que j'ai cité sont également un on bon exemple de choses "dangereuses" en Java lors de maj/déploiement/utilisation.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par mcjo . Évalué à 2.
Pour ce qui est des différentes version, celà ne change rien, sauf que beaucoup plus d'applications pourront continuer à utiliser des classes buggées et ceci en toute transparence pour l'utilisateur.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par kra . Évalué à 2.
regle numero 1 :
- "a priori ca passe" "ya pas de raison que ca marche pas" "je vois pas pourquoi ca marcherait pas" sont des expressions a bannir totalement dans le cadre d'un deployement d'une appli chez un client. Ou alors les comprendre comme "a priori, ca passe pas" "ya pas de raison que ca marche" "je vois pas pourquoi ca marcherait".
la loi de murphy est la seule constante en ce bas monde.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.