Plus de la moitie des specs de freedsktop ont ete proposees par KDE, discutees puis adoptees. Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
> M'enfin, Gnome a fait au moins cinq fois plus de propositions.
Je m'eleve en faux contre cette proposition. Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Une grande partie du travail de freedesktop, c'est de proposer des specifications, avec si possible une ou plusieurs implementaitons. Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client.
> Pour prendre un exemple chaud, Gnome fait un serveur multimédia. C'est Gstreamer,
C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants. C'est sur que si tu comptes comme ca, Gnome a beaucoup de projets.
Gstreamer n'assure pas la compabilite binaire ni source entre version. C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire. Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien (note que c'est le comportement a l'heure actuelle).
La solution, c'est de construire une couche d'isolation qui pourra fonctionner par exemple avec les diverses versions de gstreamer et aussi avec d'autres serveurs son, et qui elle sera stable. C'est phonon. Une api pour fournir des services sons aux applications KDE sans que celles-ci aient besoin de savoir si le serveur son installe est arts, esd, gstreamer v1, gstreamer v2, gstreamer v3, nmm ou autres.
Phonon en est encore a la phase experimental. Deja quand on voit comment il est mal recu, je vois mal comment on pourrait le pousser. J'espere pour ma part qu'il suivra le chemin de DCOP, c'est a dire qu'on realisera qu'il resoud un reel probleme et apporte qqch d'util, et qu'a partir de la, soit on adaptera phonon pour etre independant de KDE, soit on redeveloppera un wrapper de serveur son utilisable par tous les projets.
As tu envisage que au moment ou j'ai ecrit ce journal, Gnome n'etait pas liste dans la page web ? J'aurai du faire un screenshot, puisque ma parole est mise en doute si facilement.
Et puis excuse moi, je n'avais pas realise que les gens qui lisent linuxfr etaient des managers presses.
<<
- le site a eu un légé problème technique rendant les statistiques de gnome invisible mais ca ne t'empêche pas de pondre un roman pour ... rien ;
>>
Ben, qu'un projet aussi important que Gnome disparaisse d'un moteur de verification de vulnerabilites et ce justement aux alentours d'une release, ca demande un minimum d'investigation, tu ne trouves pas ? KDE aurait disparu, je me serai pose les memes questions. Sauf que sur KDE, je sais ou trouver les reponses, alors que sur Gnome, je demande.
<<
- tu n'as rien a dire de concret dans ta croisade contre gnome, par contre tu le fais savoir de façon hautement ridicule.
>>
De fait, en ce moment, Gnome fait des trucs vraiment pas mal. Je n'ai pas essaye depuis longtemp mais la presentation d'un Gnomeux a la derniere linuxexpo m'avait plutot laisse sur le cul. Apres, les qualites d'un desktop ne se voient pas que a la premiere utilisation mais sur la duree.
Sinon, contrairement a ce que certains pensent, j'aime plutot bien le projet Gnome. Ce qui m'agace, ce sont ceux qui le defendent aveuglement, sans reconnatire ses faiblesses [1]. Par exemple quand je lis comme hier soir que KDE ne fait rien sur freedesktop alors que c'est totalement faux (et il suffit de lire les archives de freedesktop pour s'en convaincre), ca me herisse.
J'essaye a ma facon de retablir la verite historique. Et je ne me contente pas d'avoir une opinion sorti de mon trou du cul. J"ai ecrit des programmes en Gtk, j'ai compare des programmes Gtk et Qt, j'ai suivi de plus ou moins loin l'activite de certains projets Gnome, j'ai lu le tutorial bonobo de meme que celui de kpart pour faire la comparaison, j'ai discute avec des gens bien informes sur des problemes precis comme les problemes des bindings.
[1] Note que ne pas reconnaitres ses propres faiblesses, c'est perdre une occasion de les corriger.
<< Il y a toujours des phases où on bossent dans son coin. Surtout à l'initialisation d'un projet et jusqu'en phase alpha voire beta. Tant que tu n'as rien de concret a proposer, c'est comme ça. >>
C'est tout a fait vrai. Mais pour une implementation. Pour une specification qui se veut commune a plusieurs bureaux en revanche, la concertation est fondamentale. Et Tango est justement un projet avec un but d'unification des icones pour plusieurs bureaux.
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
<<
Nobody said that Xfce will ship the Tango icon theme. Brain just said
that he wants to "join as Xfce representative". We'll discuss that issue
when the time arrives (which don't seem to be anytime soon).
>>
<< KDE ne fout pratiquement pour freedesktop >>
Je suis decu vraiment de voir qu'il y a des gens qui pensent encore cela. KDE est extremement implique dans freedesktop : propositions sur les specifications, feedback sur des implementations, organisations de conferences, etc etc.
Tu noteras des messages de Waldo Bastian, Aaron Seigo et Lubos Lunak. Il y a beaucoup plus de developpeurs KDE que cela qui lisent freedkestop mais ils n'ont pas toujours quelque chose a dire.
Tu peux noter le travail extremement actif de Waldo Bastian sur la stabilisations d'un certain nombre de specifications, en ce moment la spec qui decrit les fichiers .desktop
On peut aussi noter que KDE a adopte une technologie freedesktop, alors meme que la meme techno existait deja chez KDE et que celle de freedesktop n'apportait aucune fonctionnalite specifique sinon une meilleure interoperabilite. Tout le monde a compris que je parle de DBUS.
<<
Contrairement à ce que tu disais, il ne suffit pas d'être sur freedesktop pour être un standard. Au-dessus tu annonçais déjà que Tango est un standard uniquement car Tango était sur freedesktop et que TU disait que c'était un standard pour tous les desktop. Tango va peut-être mourir prochainement, je n'en sais rien.
Le rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.
>>
C'est fort parce que tu reussis a etre tout a fait d'accord avec ce que je pense tout en etant persuade que je pense le contraire. Relis mon post calmement et peut-etre que ce sera plus clair. Peut-etre me suis-je mal exprime ?. J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.
Freedesktop est au contraire un endroit de concertation et j'ai cite de nombreuses specs freedesktop sur lesquelles la concertation a eu lieu et a donne des resultats interessants.
Tango n'a pas suivi ce processus fondamental de concertation et a cause de cela, restera un projet dedie a Gnome. Le coeur de Tango en lui-meme me parait tout a fait interessant mais la partie "je suis un standard pour tous les desktops" revendiquees par les auteurs (cf le mail que je cite plus haut) ne deviendra jamais une realite.
<<
Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.
>>
Quand tu as plus de 500 vulnerabilites, ca commence a etre beaucoup de travail d'arriver a 0. Il me semble me souvenir que Gnome partait de loin au debut. Et maintenant, personne ne peut plus me contredire (gniark gniark gniark).
C'est la rentree, je recommence mon entrainement intensif.
Plus serieusement, personne ne sait pourquoi Gnome est sorti ? Ca m'etonne quand meme. J'espere vraiment qu'aucune des raisons que j'avance n'est veridique !!
C'etait sympa en plus, on pouvait comparer le nombre de lignes de Gnome et de KDE. Ca ouvrait la voie a plein de nouveaux trolls.
Je ne suis pas trop d'accord avec toi. Il y a certains developpeurs dans Gnome qui ont une attitude vis a vis de KDE qu'on peut qualifier de detestable mais beaucoup ont une attitude tres constructive. Il suffit d'ignorer les geneurs et d'avancer avec les gens qui veulent avancer.
Dbus n'a pas ete impose a KDE. Dbus a des avantages sur DCOP : pas de dependance a X, pas de dependance a Qt. Il aurait ete possible de re-ecrire DCOP pour en faire le DBUS actuel mais le fait est que personne ne l'a fait. Comme souvent en logiciel libre, c'est celui qui fait le travail qui decide et personne n'a fait le travail pour DCOP.
Globalement, DBUS est une belle histoire. Il faut savoir avancer en mettant de cote son NIH syndrome. DBUS a un gros avantage par raport a DCOP: il est reconnu au sein de Gnome. Ca veut dire que dans le mesure ou KDE ne perd pas en fonctionnalite vis a vis de DCOP, c'est une victoire pour le desktop linux : on va pouvoir resoudre plein de probleme pa DBUS et permettre aux deux bureaux majeurs d'en profiter : notification de material branche, baterie faible, etc etc.
La seule chose qui m'agace, c'est les enthousiastes de Gnome qui s'extasient sur les possibilites de DBUS et presentent cela comme une revolution lancee par Gnome alors meme que la plupart desdites fonctionnalites sont presentes depuis 6 ans dans KDE.
Un petit mot sur tango. Le but est louable, mais la methode est completement a l'inverse de la facon dont doit se developper une specification qui pretend etre adoptee par plusieurs bureaux.
En gros, une equipe consistituee principalement de developpeurs de Gnome s'est montee, a developpe tango sans aucune concertation avec des autres desktop et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau devaient adopter. C'est vraiment l'oppose des buts et du principe de freedesktop.
Il y a un certain nombre de raison pour KDE de ne pas adopter tango. Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande, donc ils n'ont pas leur mot a dire sur le "standard". Ensuite, Gnome et KDE ont un style d'icone qui est different. Tango utilise le style Gnome qui ne s'integre pas du tout dans l'historique de KDE. Enfin, KDE a son propre style d'icone tres complet et n'a pas besoin de Tango.
Je pense que le projet en soi est interressant mais pas pour plusieurs desktops.
A contrario, on peut citer un certain nombre de specifications de freedesktop qui ont ete developpees en _cooperation_ avec les differents bureaux, et qui sont un succes :
- placement des icones sur le systeme de fichier
- organistion des themes sur le systeme de fichier
- contenu des fichiers .desktop
- utilisation de dbus
- notification dans la barre des taches
- applets dans la barre des taches
A noter que tango n'est pas le seul projet a avoir fonctionner comme cela. On note regulierement sur la mailing list freedesktop des gens qui arrivent avec des specifications qu'ils veulent pousser pour que tout le monde les adopte, alors qu'ils n'ont pas fait le travail necessaire de concertation, verification de l'historique, interet pour les differents bureaux, etc etc. Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.
Tango est un tout petit peu different de cette situation puisque c'est une specification deja adoptee au sein de Gnome. Je trouve l'attitude du projet d'autant plus surprenante car il y a des gens dans la communaute Gnome qui savent comment fonctionne l'adoption d'une specification au sein de freedesktop (et qui ont meme fonde freedesktop).
Dans le meme ordre d'idee, cairo (moteur de rendu 2D) ne sera pas adopte par KDE/Qt car Qt possede son propre moteur 2D.
L'appel pour akademy 2007 est en cours, il suffit qu'un des organisateurs "postule" pour proposer d'utiliser les RMLL.
Sinon, plusieurs developpeurs de Gnome sont invites a akademy, de meme que des developpeurs KDE sont invites au Guadec. Donc les discussions ont bien lieu.
> Les layouts par défaut sont soit trop limités, soit trop complexes à utiliser (GridBa gLayout, Grrr). Mais rien ne t'empêche de développer ton propre layout
Rien ne m'empeche non plus de developper un toolkit graphique complet pour remplacer Qt, Gtk, Swing en une seule fois. Sauf que je prefere me concentrer sur la logique de mon application et que je trouve que ce travail revient plutot au developpeur du toolkit graphique.
Le fait que les layouts soient mal geres veut dire que le programmeur va passer beaucoup de temps a resoudre un probleme qui n'a rien a voir avec l'application qu'il developpe alors qu'il pourrait etre en train de corriger des bugs ou ajouter des fonctionnalites.
Je ne connais pas swing, mais dire dans la meme phrase que les layouts sous swings sont pourris mais que swing c'est bien me parait un peu tire par les cheveux.
Une application graphique, c'est avant tout un ensemble de briques graphiques a organiser. Et de nos jours, on a les parametres suivants qui sont variables :
- les traductions peuvent allonger ou racourcir les dialogues en permanence
- les gens ont des resolutions d'affichage hautement variable : entre le commercial avec son portable 12 pouces et le geek avec son 3500 x 4600, il faut s'adapter.
Donc les layouts sont quand meme un element important de la conception graphique de nos jours.
Pour l'instant, je trouve le discours des defenseurs de swing plutot desagreable. En gros, soit le programmeur est assez intelligent pour comprendre comment swing marche, soit il ferait mieux de retourner a son visual basic. Ca me fait penser aux defenseurs des MFCs qui disent que les MFCs sont simples et faciles a utiliser, mais qu'il faut 5 ans pour apprendre a bien s'en servir.
Trolltech a propose une approche de la programmation graphique qui est facile. Ce n'est pas une tare d'etre facile a utiliser, et ce n'est pas parce que Microsoft a fait rimer facilite et simplicite avec truc crade et inutilisable en gros deploiement que c'est une loi immuable.
Qt possede a mon sens l'avantage d'etre agreable a utiliser par des experts et par des debutants. Les debutants sont contents d'arriver rapidement a des resultats et les experts ne se sentent pas contraints par le framework mais peuvent au contraire laisser libre cours a leur creativite.
Pour revenir a l'histoire des layout, sous Qt, on peut par exemple laisser un expert en ergonomie travailler sur l'interface avec Qt Designer pendant que le programmeur travaille sur la logique, et cela sans se perturber l'un l'autre. La gestion des layouts est donc accessible a des non-techos.
Dans toutes les applications graphiques sur lesquelles j'ai travaille avec Qt, ce qui m'a le plus plu, c'est que comme la partie graphique est simple a mettre en place, on peut vraiment se concentrer sur la logique de l'application.
Il y a d'autres forks relativement reussis :
- XEmacs : l'original et le fork cohabitent plus ou moins bien encore
- gcc : la fork a remplace l'original au bout d'un moment. Si je me souviens bien, c'etait sur des histoires de support de l'objet a un moment ou RMS preferait que gcc ne fasse que du C.
Par contre, il y a des millards de forks rates. C'est _difficile_ de faire vivre un projet et nombreux sont les naifs qui pensent y arriver tout seul.
icescream a ete developpe par un gourou KDE (Stephan Kulow) et marche super bien. Pas une seule reuninon KDE ou les developpeurs ne commencent pas par deployer du icescream partout. Je suis surpris de ne pas le voir cite.
Petite copie de la partie interessante :
============================================
I use distcc, why should I change?
If you're sitting alone home and use your partner's computer to speed up your compilation and both these machines run the same Linux version, you're fine with distcc (as 95% of the users reading this chapter will be, I'm sure). But there are several situations, where distcc isn't the best choice:
* you're changing compiler versions often and still want to speed up your compilation (see the ICECC_VERSION support)
* you got some neat PPC laptop and want to use your wife's computer that only runs intel (see the cross compiler section)
* you don't know what machines will be on-line at compile time.
* most important: you're sitting in a office with several co-workers that do not like if you overload their workstations when they play doom (distcc doesn't have a scheduler)
* you like nice compile monitors :)
============================================
Je ne sais pas pour vous, mais la mise a disposition gratuite d'un service autrefoir payent, ce que ca m'insipre, c'est que le service payant n'a pas marche et qu'ils essaient de relancer la machine.
Ca fait longtemp qu'on entend plus parler du mandrake club, est-ce que ca tourne toujours ?
La news, c'est pour dire que beagle est capable d'analyser les messages et les contacts de thunderbird ?
Baleze, vraiment vraiment. Les messages sont au format mbox, qui est plus que trivial a analyser (je bourre tous les messages en texte dans un fichier), surtout quand on a fait le format maildir auparavant (un message par fichier texte dans un repertoire). Et les contacts sont au format vcard (du texte encore). Donc en fait, beagle est maintenant capable d'analyser des fichiers textes. Moi, ca m'impressionne :-)
Bon, plaisanterie a part, c'est sympa de voir ce projet avancer et j'imagine qu'il y a plus que l'indexation de fichier texte dans l'integration thunderbird. Mais ca ne ressort pas trop dans la news.
En fait, ce serait pas plus simple d'utilier Qt Designer avec une bonne transformation XSLT ? Ou bien carrement de faire un gtk-uic qui transforme la description xml de Qt Designer en implemntaion Gtk ? 99% des widgets Qt sont presents sous Gtk donc ca devrait pas etre si difficile.
Qt Designer est en GPL, ce serait pas difficile de le faire evoluer pour supporter du Gtk. Il fait deja l'import des fichiers glade de la version precedente :-)
Sans oublier la fonctionnalite de base qui manque cruellement a Sunbird: popup 1/4 heure avant le debut de la reunion, ou insertion dans l'agenda quasi automatique depuis le client mail. Ou encore possibilite pour des externes (secretaire, collegue) de te caser une reunion dans ton agenda, etc etc.
Pour ma boite, je cherchais un client windows libre quelconque mais fonctionnel (== pas une interface web) pour fonctionner avec un serveur libre quelconque sous Linux. La conclusion a ete que le plus fonctionnel etait probablement outlook avec un truc genre kolab. Plutot deprimant. Le probleme notamment, c'est que charger oulook + thunderbird en memoire, c'est vraiment du gachis de resources. Vivement kontact sous windows.
En fait, la conclusion de notre analyse a surtout ete qu'on manquait cruellement de standard en matiere de gestion d'agenda. Il y a bien les trucs genre iCal mais c'est pour formatter les inforamations sur un rendez-vous, pas pour definir la facon de se connecter a un serveur.
Tant qu'on aura pas un "Calendaring Transfer Protocol", les developpements auront du mal a se se focaliser sur un client de bonne qualite et on restera avec des solutions dispersees et de qualite moyenne voire pitoyables.
Justement parce que les fonctionnalites sont equivalentes, ce n'est pas possible d'envisager une convergence. Ca voudrait dire que l'un des deux projets doit abandonner son moteur, ce qui est inenvisageable. Je ne vois pas Gtk se mettre a dependre de Qt et je ne vois pas Trolltech adopter une technologie externe alors qu'elle a tant investi sur X et Qt.
A noter que ce n'est pas un probleme, Qt et Gtk coexistent depuis des annees sans problemes. Un minimum de diversite, quand il rime avec qualite a du bon.
Et pour ceux qui poseraient la question "quand est-ce que KDE va l'utiliser ?" ou "si Qt l'utilisait aussi, ce serait top", je vous informe que Qt possede un moteur de rendu qui fait exactement la meme chose que Cairo, mais qui s'appelle Arthur. Export SVG, rendu sur OpenGl, export PDF via backend d'impression, etc etc.
Je me demande toujours pourquoi les gens font un tel blocage sur l'allemand. La grammaire complete est au final plus simple que la grammaire anglaise, ou que la grammaire francaise. Tous les mots se prononcent comme ils s'ecrivent contrairement au francais qui rajoute des lettre en plus, ou a l'anglais qui a une difficulte de prononciation assez incroyable.
Juste pour rire, prononcez les deux phrases suivantes :
- I read it and I cut it
- I read it and I cut it
L'une est au passe, l'autre au present, meme si ca ne se voit pas. Dans celle qui est au passe, "read" se prononce comme dans "mer" et au present comme dans "riz".
Apres ca, on veut nous faire croire que l'anglais est simple. L'anglais n'a qu'une qualite indeniable, c'est qu'il est concis. Il ne sait battre que par le chinois.
Pour la tele, si tu es abonne au cable, tu as un certain nombre de chaines qui diffusent en anglais ou francais, avec choix des sous-titres en anglais ou en francais. Pour ma part, j'aime bien jimmy et comedie, qui diffusent en plus a l'occasion des series de tres bonne qualite (celles qui m'ont plu : six feet under, queer as folk, the shield, star trek enterprise, six sexy).
<<
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
>>
Une partie du gain vient du fait que le CLR peut detecter des organisations de code qu'il peut optimiser a la volee au moment de l'execution, ce que ne peut pas du tout faire le C.
Guido Van Rossum et tous les gens qui bossent sur python dpeuis 10 ans ne sont pas des machots donc je doute que le code C de python soit "mal optimise".
<<
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi
>>
Donc en fait, ta defense du C est une attaque des programmeurs. "Vous ne savez pas coder, sinon, ca marcherait mieux". C'est plutot minable comme argumentaire.
Sur des tres gros programmes en C, tu es souvent conduit a utiliser par exemple des pointeurs en (void *) car tu dois stocker plusieurs types de donnees dans un pointeur. L'absence de notion de dictionnaire, d'heritage, les notions de tableaux tres limitees, l'absence de notion d'interface font que beaucoup de paradigmes indispensables de programmation sont fait completement a l'insu du compilateur, qui du coup a un champ tres limite pour comprendre les intentions du programmeur et optimiser le code en fonction.
L'utilisation d'un (void *) est le plus flagrant mais tous les parametres jouent ensemble. Un dictionnaire a 3 elements est plus facile a optimiser avec une recherche lineaire, un dictionnaire avec 500 elements est plus facile a optimser avec une table de hashage. C'est une decision que le compilateur pourait prendre plutot que le programmeur.
L'absence de ramasse-miette fait aussi que les programmes en C demandent plus de travail au programmeur. Le ramassage des miettes (== desalllocation des ressources inutilisees) est aussi quelque chose que le compilateur peut faire mieux que le programmeur si on lui passe les bonnes information.
<<
La grammaire du C est complexe ? :o Pourquoi ?
>>
Au hasard et en survol :
- pas de distinction entre un tableau et un pointeur
- un melange entre la declaration de type et le nom de la variable :
<type de la variable> <nom de la variable> <info supplementaire facultative sur le type de la varible>
int a[30];
- le pre-processeur qui peut rendre la grammaire du texte decrivant le code completement irreguliere.
- l'absence de taille predefinies pour les types de bases.
<<
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
>>
Pour les plus simples :
- passage d'arguments par void *
- passage de tableaux par pointeur, on perd toute l'information sur la notion de tableau (de toute facon, le C n'est stocke aucune, mais c'est bien la une de ses limitations)
- bidouilles a coup de struct et de pointeurs de fonctions pour faire des interfaces
- pas de liste, pas de dictionnaire donc plein d'optimisations a la portee du compilateur qui sont perdues
<<
Et les outils ne font pas obligatoirement faire de meilleur code ;).
>>
T'as vraiment des arguments a 3 francs. T'as deja reflechi au sujet avant d'ecrire un truc pareil ?
Bien sur que la qualite des outils permettent d'ecrire du code de meilleur qualite et de le faire evoluer de meilleure facon.
Un outil de refactoring en java te permet de faire facilement evoluer ton code par exemple. La meme operation en C oblige a faire un gros grep dans les sources et a faire de modifs a la main, super penible donc rarement fait dans la pratique, donc code qui devient vite immaintenable.
Des que tu fais du C++, tu t'apercois que gdb n'as acces qu'a une partie limitee des objets, et que donc le debuggage est super penible, tu en reviens au printf, ce qui est long et penible.
Des outils comme la programmation oriente aspect permettent d'explorer des nouveaux concepts de programmation, plus en rapport avec les besoins de certains projets.
En java, il est possible de debugger a distance un programme java qui s'execute. Par exemple, je peux debugger une javacard depuis mon PC, poser des points d'arrets, inspecter les variables, etc. C'est difficile et lourd a faire avec du code embarque en C, tu es souvent oblige de developper un simulateur complet de ta plate-forme cible.
Des outils d'analyses de code peuvent te permettre de mieux comprendre un code existant. Ces outils sont limites dans leur comprehension du code C a cause des limitations de la grammaire du C (je commence a me repeter la).
<<
Les outils n'ont rien à voir avec la simplicité du langage...
>>
Je n'ai pas parle de simplicite mais d'expressivite. Si ton langage transcrit bien ce que tu veux faire, les outils peuvent t'aider beaucoup. Si ce n'est pas le cas, les outils ne peuvent rien pour toi.
Le cas d'erlang est frappant. Je ne connais pas le langage, mais je suis persuade que si tu informes le compilateur des morceaux de code qui doivent s'executer en parallele ou non, tu obtiens un truc bien plus propre que avec des mutex dans tous les sens, des sections critiques et des forks a tout va. Dans un cas, le compilateur peut t'aider et distributer pour toi l'execution du code sur plusieurs threads/processeurs/machines, dans l'autre, c'est toi pauvre programmeur, qui va essayer de le faire. Tu vas passer ton temps a re-inventer la roue.
[^] # Re: Vous devez entrer un sujet
Posté par Philippe F (site web personnel) . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 6.
[^] # Re: Tango : bof
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 7.
Plus de la moitie des specs de freedsktop ont ete proposees par KDE, discutees puis adoptees. Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
> M'enfin, Gnome a fait au moins cinq fois plus de propositions.
Je m'eleve en faux contre cette proposition. Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Une grande partie du travail de freedesktop, c'est de proposer des specifications, avec si possible une ou plusieurs implementaitons. Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client.
> Pour prendre un exemple chaud, Gnome fait un serveur multimédia. C'est Gstreamer,
C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants. C'est sur que si tu comptes comme ca, Gnome a beaucoup de projets.
Gstreamer n'assure pas la compabilite binaire ni source entre version. C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire. Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien (note que c'est le comportement a l'heure actuelle).
La solution, c'est de construire une couche d'isolation qui pourra fonctionner par exemple avec les diverses versions de gstreamer et aussi avec d'autres serveurs son, et qui elle sera stable. C'est phonon. Une api pour fournir des services sons aux applications KDE sans que celles-ci aient besoin de savoir si le serveur son installe est arts, esd, gstreamer v1, gstreamer v2, gstreamer v3, nmm ou autres.
Phonon en est encore a la phase experimental. Deja quand on voit comment il est mal recu, je vois mal comment on pourrait le pousser. J'espere pour ma part qu'il suivra le chemin de DCOP, c'est a dire qu'on realisera qu'il resoud un reel probleme et apporte qqch d'util, et qu'a partir de la, soit on adaptera phonon pour etre independant de KDE, soit on redeveloppera un wrapper de serveur son utilisable par tous les projets.
[^] # Re: Toujours aussi objectif...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome sorti de coverity scan ?. Évalué à 2.
Et puis excuse moi, je n'avais pas realise que les gens qui lisent linuxfr etaient des managers presses.
<<
- le site a eu un légé problème technique rendant les statistiques de gnome invisible mais ca ne t'empêche pas de pondre un roman pour ... rien ;
>>
Ben, qu'un projet aussi important que Gnome disparaisse d'un moteur de verification de vulnerabilites et ce justement aux alentours d'une release, ca demande un minimum d'investigation, tu ne trouves pas ? KDE aurait disparu, je me serai pose les memes questions. Sauf que sur KDE, je sais ou trouver les reponses, alors que sur Gnome, je demande.
<<
- tu n'as rien a dire de concret dans ta croisade contre gnome, par contre tu le fais savoir de façon hautement ridicule.
>>
De fait, en ce moment, Gnome fait des trucs vraiment pas mal. Je n'ai pas essaye depuis longtemp mais la presentation d'un Gnomeux a la derniere linuxexpo m'avait plutot laisse sur le cul. Apres, les qualites d'un desktop ne se voient pas que a la premiere utilisation mais sur la duree.
Sinon, contrairement a ce que certains pensent, j'aime plutot bien le projet Gnome. Ce qui m'agace, ce sont ceux qui le defendent aveuglement, sans reconnatire ses faiblesses [1]. Par exemple quand je lis comme hier soir que KDE ne fait rien sur freedesktop alors que c'est totalement faux (et il suffit de lire les archives de freedesktop pour s'en convaincre), ca me herisse.
J'essaye a ma facon de retablir la verite historique. Et je ne me contente pas d'avoir une opinion sorti de mon trou du cul. J"ai ecrit des programmes en Gtk, j'ai compare des programmes Gtk et Qt, j'ai suivi de plus ou moins loin l'activite de certains projets Gnome, j'ai lu le tutorial bonobo de meme que celui de kpart pour faire la comparaison, j'ai discute avec des gens bien informes sur des problemes precis comme les problemes des bindings.
[1] Note que ne pas reconnaitres ses propres faiblesses, c'est perdre une occasion de les corriger.
[^] # Re: Tango : bof
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 3.
C'est tout a fait vrai. Mais pour une implementation. Pour une specification qui se veut commune a plusieurs bureaux en revanche, la concertation est fondamentale. Et Tango est justement un projet avec un but d'unification des icones pour plusieurs bureaux.
cf par exemple :
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
<<
The purpose
of the Tango project is not only the icon theme. The purpose is to work
towards unifying the visual aspects of all the desktops.
>>
<< Il y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars". >>
Ah oui ? Au contraire, les gens de KDE par exemple ont dit "c'est ininteressant pour KDE, on n'adoptera jamais votre truc mais continuez les gars".
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
Concernant XFCE :
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
<<
Nobody said that Xfce will ship the Tango icon theme. Brain just said
that he wants to "join as Xfce representative". We'll discuss that issue
when the time arrives (which don't seem to be anytime soon).
>>
<< KDE ne fout pratiquement pour freedesktop >>
Je suis decu vraiment de voir qu'il y a des gens qui pensent encore cela. KDE est extremement implique dans freedesktop : propositions sur les specifications, feedback sur des implementations, organisations de conferences, etc etc.
Par exemple si on prend les archives du mois d'aout 2006 :
http://lists.freedesktop.org/archives/xdg/2006-August/author(...)
Tu noteras des messages de Waldo Bastian, Aaron Seigo et Lubos Lunak. Il y a beaucoup plus de developpeurs KDE que cela qui lisent freedkestop mais ils n'ont pas toujours quelque chose a dire.
Tu peux noter le travail extremement actif de Waldo Bastian sur la stabilisations d'un certain nombre de specifications, en ce moment la spec qui decrit les fichiers .desktop
On peut aussi noter que KDE a adopte une technologie freedesktop, alors meme que la meme techno existait deja chez KDE et que celle de freedesktop n'apportait aucune fonctionnalite specifique sinon une meilleure interoperabilite. Tout le monde a compris que je parle de DBUS.
<<
Contrairement à ce que tu disais, il ne suffit pas d'être sur freedesktop pour être un standard. Au-dessus tu annonçais déjà que Tango est un standard uniquement car Tango était sur freedesktop et que TU disait que c'était un standard pour tous les desktop. Tango va peut-être mourir prochainement, je n'en sais rien.
Le rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.
>>
C'est fort parce que tu reussis a etre tout a fait d'accord avec ce que je pense tout en etant persuade que je pense le contraire. Relis mon post calmement et peut-etre que ce sera plus clair. Peut-etre me suis-je mal exprime ?. J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.
Freedesktop est au contraire un endroit de concertation et j'ai cite de nombreuses specs freedesktop sur lesquelles la concertation a eu lieu et a donne des resultats interessants.
Tango n'a pas suivi ce processus fondamental de concertation et a cause de cela, restera un projet dedie a Gnome. Le coeur de Tango en lui-meme me parait tout a fait interessant mais la partie "je suis un standard pour tous les desktops" revendiquees par les auteurs (cf le mail que je cite plus haut) ne deviendra jamais une realite.
<<
Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.
>>
Comme DCOP ?
[^] # Re: Attention à ne pas confondre.
Posté par Philippe F (site web personnel) . En réponse au journal Gnome sorti de coverity scan ?. Évalué à 1.
[^] # Re: Toujours aussi objectif...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome sorti de coverity scan ?. Évalué à 2.
Plus serieusement, personne ne sait pourquoi Gnome est sorti ? Ca m'etonne quand meme. J'espere vraiment qu'aucune des raisons que j'avance n'est veridique !!
C'etait sympa en plus, on pouvait comparer le nombre de lignes de Gnome et de KDE. Ca ouvrait la voie a plein de nouveaux trolls.
[^] # Re: Tango : bof
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 10.
Dbus n'a pas ete impose a KDE. Dbus a des avantages sur DCOP : pas de dependance a X, pas de dependance a Qt. Il aurait ete possible de re-ecrire DCOP pour en faire le DBUS actuel mais le fait est que personne ne l'a fait. Comme souvent en logiciel libre, c'est celui qui fait le travail qui decide et personne n'a fait le travail pour DCOP.
Globalement, DBUS est une belle histoire. Il faut savoir avancer en mettant de cote son NIH syndrome. DBUS a un gros avantage par raport a DCOP: il est reconnu au sein de Gnome. Ca veut dire que dans le mesure ou KDE ne perd pas en fonctionnalite vis a vis de DCOP, c'est une victoire pour le desktop linux : on va pouvoir resoudre plein de probleme pa DBUS et permettre aux deux bureaux majeurs d'en profiter : notification de material branche, baterie faible, etc etc.
La seule chose qui m'agace, c'est les enthousiastes de Gnome qui s'extasient sur les possibilites de DBUS et presentent cela comme une revolution lancee par Gnome alors meme que la plupart desdites fonctionnalites sont presentes depuis 6 ans dans KDE.
# Tango : bof
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 8.
En gros, une equipe consistituee principalement de developpeurs de Gnome s'est montee, a developpe tango sans aucune concertation avec des autres desktop et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau devaient adopter. C'est vraiment l'oppose des buts et du principe de freedesktop.
Il y a un certain nombre de raison pour KDE de ne pas adopter tango. Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande, donc ils n'ont pas leur mot a dire sur le "standard". Ensuite, Gnome et KDE ont un style d'icone qui est different. Tango utilise le style Gnome qui ne s'integre pas du tout dans l'historique de KDE. Enfin, KDE a son propre style d'icone tres complet et n'a pas besoin de Tango.
Je pense que le projet en soi est interressant mais pas pour plusieurs desktops.
A contrario, on peut citer un certain nombre de specifications de freedesktop qui ont ete developpees en _cooperation_ avec les differents bureaux, et qui sont un succes :
- placement des icones sur le systeme de fichier
- organistion des themes sur le systeme de fichier
- contenu des fichiers .desktop
- utilisation de dbus
- notification dans la barre des taches
- applets dans la barre des taches
A noter que tango n'est pas le seul projet a avoir fonctionner comme cela. On note regulierement sur la mailing list freedesktop des gens qui arrivent avec des specifications qu'ils veulent pousser pour que tout le monde les adopte, alors qu'ils n'ont pas fait le travail necessaire de concertation, verification de l'historique, interet pour les differents bureaux, etc etc. Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.
Tango est un tout petit peu different de cette situation puisque c'est une specification deja adoptee au sein de Gnome. Je trouve l'attitude du projet d'autant plus surprenante car il y a des gens dans la communaute Gnome qui savent comment fonctionne l'adoption d'une specification au sein de freedesktop (et qui ont meme fonde freedesktop).
Dans le meme ordre d'idee, cairo (moteur de rendu 2D) ne sera pas adopte par KDE/Qt car Qt possede son propre moteur 2D.
[^] # Re: Utiliser les RMLL
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE aKademy 2006 du 23 au 30 septembre à Dublin. Évalué à 6.
Sinon, plusieurs developpeurs de Gnome sont invites a akademy, de meme que des developpeurs KDE sont invites au Guadec. Donc les discussions ont bien lieu.
[^] # Re: toolkit graphique = troll ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech publie les avancées de Qt pour Java. Évalué à 3.
Rien ne m'empeche non plus de developper un toolkit graphique complet pour remplacer Qt, Gtk, Swing en une seule fois. Sauf que je prefere me concentrer sur la logique de mon application et que je trouve que ce travail revient plutot au developpeur du toolkit graphique.
Le fait que les layouts soient mal geres veut dire que le programmeur va passer beaucoup de temps a resoudre un probleme qui n'a rien a voir avec l'application qu'il developpe alors qu'il pourrait etre en train de corriger des bugs ou ajouter des fonctionnalites.
[^] # Re: toolkit graphique = troll ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech publie les avancées de Qt pour Java. Évalué à 6.
Une application graphique, c'est avant tout un ensemble de briques graphiques a organiser. Et de nos jours, on a les parametres suivants qui sont variables :
- les traductions peuvent allonger ou racourcir les dialogues en permanence
- les gens ont des resolutions d'affichage hautement variable : entre le commercial avec son portable 12 pouces et le geek avec son 3500 x 4600, il faut s'adapter.
Donc les layouts sont quand meme un element important de la conception graphique de nos jours.
Pour l'instant, je trouve le discours des defenseurs de swing plutot desagreable. En gros, soit le programmeur est assez intelligent pour comprendre comment swing marche, soit il ferait mieux de retourner a son visual basic. Ca me fait penser aux defenseurs des MFCs qui disent que les MFCs sont simples et faciles a utiliser, mais qu'il faut 5 ans pour apprendre a bien s'en servir.
Trolltech a propose une approche de la programmation graphique qui est facile. Ce n'est pas une tare d'etre facile a utiliser, et ce n'est pas parce que Microsoft a fait rimer facilite et simplicite avec truc crade et inutilisable en gros deploiement que c'est une loi immuable.
Qt possede a mon sens l'avantage d'etre agreable a utiliser par des experts et par des debutants. Les debutants sont contents d'arriver rapidement a des resultats et les experts ne se sentent pas contraints par le framework mais peuvent au contraire laisser libre cours a leur creativite.
Pour revenir a l'histoire des layout, sous Qt, on peut par exemple laisser un expert en ergonomie travailler sur l'interface avec Qt Designer pendant que le programmeur travaille sur la logique, et cela sans se perturber l'un l'autre. La gestion des layouts est donc accessible a des non-techos.
Dans toutes les applications graphiques sur lesquelles j'ai travaille avec Qt, ce qui m'a le plus plu, c'est que comme la partie graphique est simple a mettre en place, on peut vraiment se concentrer sur la logique de l'application.
[^] # Re: Super !
Posté par Philippe F (site web personnel) . En réponse à la dépêche cdrkit : Debian forke cdrtools. Évalué à 2.
- XEmacs : l'original et le fork cohabitent plus ou moins bien encore
- gcc : la fork a remplace l'original au bout d'un moment. Si je me souviens bien, c'etait sur des histoires de support de l'objet a un moment ou RMS preferait que gcc ne fasse que du C.
Par contre, il y a des millards de forks rates. C'est _difficile_ de faire vivre un projet et nombreux sont les naifs qui pensent y arriver tout seul.
[^] # Re: autre alternative: icecream
Posté par Philippe F (site web personnel) . En réponse à la dépêche Compilation distribuée avec distcc / dmucs. Évalué à 2.
La page web: http://en.opensuse.org/Icecream
(l'url du commentaire plus haut a une parenthese en trop)
Petite copie de la partie interessante :
============================================
I use distcc, why should I change?
If you're sitting alone home and use your partner's computer to speed up your compilation and both these machines run the same Linux version, you're fine with distcc (as 95% of the users reading this chapter will be, I'm sure). But there are several situations, where distcc isn't the best choice:
* you're changing compiler versions often and still want to speed up your compilation (see the ICECC_VERSION support)
* you got some neat PPC laptop and want to use your wife's computer that only runs intel (see the cross compiler section)
* you don't know what machines will be on-line at compile time.
* most important: you're sitting in a office with several co-workers that do not like if you overload their workstations when they play doom (distcc doesn't have a scheduler)
* you like nice compile monitors :)
============================================
# Linspire, un succes ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linspire offre Freespire et son service en ligne. Évalué à 1.
Ca fait longtemp qu'on entend plus parler du mandrake club, est-ce que ca tourne toujours ?
# Hum
Posté par Philippe F (site web personnel) . En réponse à la dépêche Beagle 0.2.8 : prise en charge de Thunderbird. Évalué à 7.
Baleze, vraiment vraiment. Les messages sont au format mbox, qui est plus que trivial a analyser (je bourre tous les messages en texte dans un fichier), surtout quand on a fait le format maildir auparavant (un message par fichier texte dans un repertoire). Et les contacts sont au format vcard (du texte encore). Donc en fait, beagle est maintenant capable d'analyser des fichiers textes. Moi, ca m'impressionne :-)
Bon, plaisanterie a part, c'est sympa de voir ce projet avancer et j'imagine qu'il y a plus que l'indexation de fichier texte dans l'integration thunderbird. Mais ca ne ressort pas trop dans la news.
[^] # Re: Tasks
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trois médailles pour la France aux Olympiades Internationales d'Informatique. Évalué à 2.
http://www.topcoder.com/tc
[^] # Re: à tester
Posté par Philippe F (site web personnel) . En réponse à la dépêche Glade 3 : l'échappée belle. Évalué à 0.
Qt Designer est en GPL, ce serait pas difficile de le faire evoluer pour supporter du Gtk. Il fait deja l'import des fichiers glade de la version precedente :-)
[^] # Re: Toujours le même problème
Posté par Philippe F (site web personnel) . En réponse à la dépêche Agenda partagé : des solutions. Évalué à 5.
Pour ma boite, je cherchais un client windows libre quelconque mais fonctionnel (== pas une interface web) pour fonctionner avec un serveur libre quelconque sous Linux. La conclusion a ete que le plus fonctionnel etait probablement outlook avec un truc genre kolab. Plutot deprimant. Le probleme notamment, c'est que charger oulook + thunderbird en memoire, c'est vraiment du gachis de resources. Vivement kontact sous windows.
En fait, la conclusion de notre analyse a surtout ete qu'on manquait cruellement de standard en matiere de gestion d'agenda. Il y a bien les trucs genre iCal mais c'est pour formatter les inforamations sur un rendez-vous, pas pour definir la facon de se connecter a un serveur.
Tant qu'on aura pas un "Calendaring Transfer Protocol", les developpements auront du mal a se se focaliser sur un client de bonne qualite et on restera avec des solutions dispersees et de qualite moyenne voire pitoyables.
[^] # Re: GNUstep
Posté par Philippe F (site web personnel) . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 2.
A noter que ce n'est pas un probleme, Qt et Gtk coexistent depuis des annees sans problemes. Un minimum de diversite, quand il rime avec qualite a du bon.
Pour dbus, on note son arrivee dans Qt 4.2 :
http://doc.trolltech.com/4.2/qtdbus.html
[^] # Re: GNUstep
Posté par Philippe F (site web personnel) . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 3.
[^] # Re: Licence
Posté par Philippe F (site web personnel) . En réponse à la dépêche PyQt v4 et Python 2.5 beta 1. Évalué à 6.
[^] # Re: Bientot sur commodore 64 ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche XMoto 0.1.16 est sorti !. Évalué à 3.
[^] # Re: Bogue...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 5.
Juste pour rire, prononcez les deux phrases suivantes :
- I read it and I cut it
- I read it and I cut it
L'une est au passe, l'autre au present, meme si ca ne se voit pas. Dans celle qui est au passe, "read" se prononce comme dans "mer" et au present comme dans "riz".
Apres ca, on veut nous faire croire que l'anglais est simple. L'anglais n'a qu'une qualite indeniable, c'est qu'il est concis. Il ne sait battre que par le chinois.
[^] # Re: Bogue...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 2.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 10.
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
>>
Une partie du gain vient du fait que le CLR peut detecter des organisations de code qu'il peut optimiser a la volee au moment de l'execution, ce que ne peut pas du tout faire le C.
Guido Van Rossum et tous les gens qui bossent sur python dpeuis 10 ans ne sont pas des machots donc je doute que le code C de python soit "mal optimise".
<<
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi
>>
Donc en fait, ta defense du C est une attaque des programmeurs. "Vous ne savez pas coder, sinon, ca marcherait mieux". C'est plutot minable comme argumentaire.
Sur des tres gros programmes en C, tu es souvent conduit a utiliser par exemple des pointeurs en (void *) car tu dois stocker plusieurs types de donnees dans un pointeur. L'absence de notion de dictionnaire, d'heritage, les notions de tableaux tres limitees, l'absence de notion d'interface font que beaucoup de paradigmes indispensables de programmation sont fait completement a l'insu du compilateur, qui du coup a un champ tres limite pour comprendre les intentions du programmeur et optimiser le code en fonction.
L'utilisation d'un (void *) est le plus flagrant mais tous les parametres jouent ensemble. Un dictionnaire a 3 elements est plus facile a optimiser avec une recherche lineaire, un dictionnaire avec 500 elements est plus facile a optimser avec une table de hashage. C'est une decision que le compilateur pourait prendre plutot que le programmeur.
L'absence de ramasse-miette fait aussi que les programmes en C demandent plus de travail au programmeur. Le ramassage des miettes (== desalllocation des ressources inutilisees) est aussi quelque chose que le compilateur peut faire mieux que le programmeur si on lui passe les bonnes information.
<<
La grammaire du C est complexe ? :o Pourquoi ?
>>
Au hasard et en survol :
- pas de distinction entre un tableau et un pointeur
- un melange entre la declaration de type et le nom de la variable :
<type de la variable> <nom de la variable> <info supplementaire facultative sur le type de la varible>
int a[30];
- le pre-processeur qui peut rendre la grammaire du texte decrivant le code completement irreguliere.
- l'absence de taille predefinies pour les types de bases.
<<
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
>>
Pour les plus simples :
- passage d'arguments par void *
- passage de tableaux par pointeur, on perd toute l'information sur la notion de tableau (de toute facon, le C n'est stocke aucune, mais c'est bien la une de ses limitations)
- bidouilles a coup de struct et de pointeurs de fonctions pour faire des interfaces
- pas de liste, pas de dictionnaire donc plein d'optimisations a la portee du compilateur qui sont perdues
<<
Et les outils ne font pas obligatoirement faire de meilleur code ;).
>>
T'as vraiment des arguments a 3 francs. T'as deja reflechi au sujet avant d'ecrire un truc pareil ?
Bien sur que la qualite des outils permettent d'ecrire du code de meilleur qualite et de le faire evoluer de meilleure facon.
Un outil de refactoring en java te permet de faire facilement evoluer ton code par exemple. La meme operation en C oblige a faire un gros grep dans les sources et a faire de modifs a la main, super penible donc rarement fait dans la pratique, donc code qui devient vite immaintenable.
Des que tu fais du C++, tu t'apercois que gdb n'as acces qu'a une partie limitee des objets, et que donc le debuggage est super penible, tu en reviens au printf, ce qui est long et penible.
Des outils comme la programmation oriente aspect permettent d'explorer des nouveaux concepts de programmation, plus en rapport avec les besoins de certains projets.
En java, il est possible de debugger a distance un programme java qui s'execute. Par exemple, je peux debugger une javacard depuis mon PC, poser des points d'arrets, inspecter les variables, etc. C'est difficile et lourd a faire avec du code embarque en C, tu es souvent oblige de developper un simulateur complet de ta plate-forme cible.
Des outils d'analyses de code peuvent te permettre de mieux comprendre un code existant. Ces outils sont limites dans leur comprehension du code C a cause des limitations de la grammaire du C (je commence a me repeter la).
<<
Les outils n'ont rien à voir avec la simplicité du langage...
>>
Je n'ai pas parle de simplicite mais d'expressivite. Si ton langage transcrit bien ce que tu veux faire, les outils peuvent t'aider beaucoup. Si ce n'est pas le cas, les outils ne peuvent rien pour toi.
Le cas d'erlang est frappant. Je ne connais pas le langage, mais je suis persuade que si tu informes le compilateur des morceaux de code qui doivent s'executer en parallele ou non, tu obtiens un truc bien plus propre que avec des mutex dans tous les sens, des sections critiques et des forks a tout va. Dans un cas, le compilateur peut t'aider et distributer pour toi l'execution du code sur plusieurs threads/processeurs/machines, dans l'autre, c'est toi pauvre programmeur, qui va essayer de le faire. Tu vas passer ton temps a re-inventer la roue.