freem a écrit 5059 commentaires

En revanche, je le trouve pas si difficile que ça à parser (je n'ai touché du XML qu'en Python, donc peut-être que les autres langages s'en sortent moins bien, je ne sais guère).

Et ton parseur python, il vérifie la validité du document par rapport au DTD qui y est lié?
Ma question, elle revient à dire, est-ce que tu parses du XML standard, ou du XML allégé, comme la plupart des gens le font?

La raison, en gros:
endianness.

XML étant du texte ASCII allégé ( moins les caractères de contrôle, entres autres ), il est facile de déterminer l'endianness. Ajouter à ce point le fait qu'il soit possible de créer des fichiers pour vérifier l'intégrité des données ( DTD ) voire convertir à un sous-format différent, ainsi que le mécanisme de balises qui permets de vérifier un minimum d'intégrité sans le DTD, oui, ce format à des raisons d'être.

Mais, il s'agit d'un format ayant un rôle limité, et maintenant je suis à la limite d'avoir une réaction allergique quand on m'en parle, à force de le voir utilisé pour de la configuration ( apache, code::blocks, par exemple, mais je crois aussi que dbus s'en sert… sigh… ).

s/parfois/souvent

Du moins, souvent sur ma machine avec les logiciels que j'utilise. Pour la configuration.

Oui, parce qu'a mon avis, INI, c'est bien, c'est efficace… pour des config. C'est à dire des fichiers qu'il est agréable et utile de pouvoir modifier à la main, mais qui ont une volumétrie raisonnable.

Pour des fichiers de sauvegarde, je suis d'accord, ce n'est pas adapté. D'ailleurs, un format lisible par l'homme pour ce type d'utilisation ne me semble pas adapté non plus de façon générale. Les soucis étant que, les binaires, c'est pas versionnable, et en plus ça risque de péter en fonction de l'endianness.

Conclusion, j'utilise boost::serialization pour les sauvegardes de données, et boost::program_options pour la configuration ( ce qui me permets en plus de très aisément "configurer" mes outils en tapant la ligne de commande, et d'avoir un "--help" en 3 lignes de code. ).
Mais YAML n'est pas mal non plus :)

• La taille du fichier, on s'en fout pas mal, ça passe très très bien à la compression (c'est du texte très redondant)

Un fichier compressé, c'est un binaire. L'intérêt d'origine d'XML, c'est d'être utilisable sur un réseau sans trop en chier, chose que le texte ASCII ( sur 7 bits, donc ) fait très bien, contrairement au binaire.
Compresser un fichier XML, c'est un non-sens, parce qu'on perd l'un de ses intérêts principaux… mais tout le monde le fait, parce qu'XML c'est verbeux…
Dit autrement, compresser XML, c'est prouver qu'on à pas réfléchit avant d'utiliser d'XML.

• "Les devs ont la flemme d'écrire un parseur" -> "les devs ont l'intelligence de réutiliser des parseurs déja déboggués"

Ou alors, les devs se sont tapé l'écriture d'un parseur XML à la main et on la flemme d'en écrire un autre. Le fait que celui déjà écrit soit débogué est une assertion trompeuse, car les dev ne font pas tous ni toujours des tests unitaires couvrant à 100% leur code.

• La structure hiérarchique imposée par le xml permet de rationnaliser le stockage des données, à définir des noms de champs signifiants, etc.

Certes, mais XML est loin d'être le seul à définir des noms signifiants. En fait, INI le fait aussi. ( vendredi…)

Pour le reste, je te rejoins, oui, le problème c'est bien le dev qui choisit XML… ou plutôt le type qui écrit le cahier des charges du dev ( ça peut être le dev, mais pas toujours ).

Point sur lequel on est d'accord.

Le souci étant, que mettre d'accord des gens, ça prend du temps. Et la, on parle d'utilisateurs de vim, des "barbus" qui ont lutté contre "l'ennemi" emacs sur de nombre de forums, etc etc.
Bref, la moindre tentative d'uniformisation de vim risque d'aboutir à la naissance d'un nouveau standard, en plus d'être longue à mettre en place.

Ton commentaire était plutôt pertinent… jusqu'a cette ligne:

On ne juge pas sans preuve mais vous ne m'empêcherez pas de penser très fort que les grosses boites sont toujours les méchants de l'histoire…

Il faut arrêter de blaguer, la, hein. Peut-être qu'il y à eu un défaut, mais, j'ai un mal fou à imaginer un régulateur de vitesse monter tout seul à 200km/h, si le contact est coupé.

Il y a eu un bug, c'est certain. Reste à savoir où il se plaçait: entre le tableau de bord et la chaise, ou dans l'électronique?

D'un autre côté, l'article ( je n'ai pas lu les sources, j'avoue ) n'indique pas qu'il y ait eu tromperie. Tel que c'est formulé, ça me fait plutôt penser à de la négligence des organisme officiels censé autoriser ou refuser la mise en marché ( euh, ok, la formulation est pas top ).
Pour moi, accepter si on manque d'info, c'est exactement comme configurer un firewall pour qu'il ne refuse que certains paquets, et laisse tout passer par défaut, alors qu'un firewall efficace doit tout rejeter par défaut, et avoir quelques règles qui indiquent quels paquets doivent finalement être acceptés.

Autrement dit, selon moi, de la façon dont est tourné le journal, la faute est partagée entre Toyota pour le code de merde, et la NTHSA, qui aurait du rejeter la bagnole sous prétexte de ne pas avoir eu assez d'informations pour juger, prétexte tout à fait valable selon moi.
Après tout, je ne trouve pas normal de livrer du code impactant sur la vie et la mort des gens, sans livrer de tests unitaires corrects. Dans un tel cas, vraiment, j'insiste lourdement, les 2 organisations sont coupables!

Mais bon, le jugement final n'est ici pas indiqué, et j'ai la flemme de lire les sources, donc peut-être que les jurés en sont arrivé à la même conclusion que moi. J'en doute, cependant…

Effectivement.
D'ailleurs c'est pour ça qu'il n'y a jamais eu de mort… attends… de quoi parle cet article, au fait?

Moui, enfin, C++ est quand même le plus lent à évoluer. Pour faire court, selon wikipedia, en 18 ans, Java à fait l'objet de 8 versions ( qui ne soient pas des bugfix ), python en à une tous les 2 ans, quand C++ en est à sa 2nde version standard, 3 si on compte la bugfix de 03.
Avec le w3c, il ne s'agit pas de standard, mais de recommandations, si ma mémoire est bonne. Recommandations qui ne sont respectées complètement par presque aucun site de ma connaissance. En pourcentage, ça doit donner de l'ordre du 5%, peut-être même moins! ( je pense être très optimiste avec mon 5%… )
Et il ne s'agit pas d'un langage de programmation, mais de description. Quand vim se configure, lui, avec un langage de programmation.

D'un autre côté, je peux comprendre, et accepter, que C++ soit plus long à standardiser.
Je ne voudrais pas que la quantité passe avant la qualité, franchement, donc qu'il ne fasse pas comme Oracle et son Java ou python ou les révisions mineures semblent empêcher d'interpréter des codes faits avec la rev mineure précédente ( lu je ne sais plus où sur ce dlfp ). Ca me va très bien comme ça.
Mais des MaJ plus petites, tout aussi propres et plus fréquentes, ça me ferait bien plaisir tout de même. Il n'empêche, le fait qu'ils en annoncent 1 pour cette année, n'implique pas que les délais seront tenus. Les procédures pour un standard ISO sont certainement nettement plus complexes que d'attendre l'approbation d'Oracle ou attendre qu'une équipe de dev open source accepte une contribution, cas de python. On parle d'un organisme de standardisation international reconnu par de nombreux pays, après tout.
Maintenant, en C++11, on peut toujours compiler du code qui date de 98, je ne suis pas sûr que ce soit le cas de la majorité des autres langages.
A part le langage de config de vim, j'imagine :)

Oui. En même temps, ils avaient prévu de sortir C++11 avant 2010, d'où le nom du draft: C++0x.
Ceux qui inventent des excuses diront qu'on parle d'hexadécimal, mais j'ose espérer que personne n'est dupe.

Entre prévoir et faire, il y a une grande différence.

Après, je suis d'accord: on parle de standard ISO, donc il faut faire les choses bien, ce qui peut prendre du temps. Mais bon, 13 ans ( standardisation en 98 selon wikipedia, bugfix en 03 ) pour une nouvelle version, en info, c'est long.
Mais bon, ça n'empêche pas ce langage d'être mon favori, vu qu'avec les fonctionnalités de base on peut faire déjà énormément, et au moins on a peu de choses qui deviennent obsolètes ( mais ça existe malgré tout, comme auto_ptr ).

Si linux n'était utilisé que par les programmeurs, android n'existerait pas.

Comme je le disais, le problème n'est pas le manque de fonctionnalités de vim, mais le fait que ces fonctionnalités ne sont pas présente à l'installation.

Pas moi qui l'ai dit, que vim manque de fonctionnalités :)

Enfin, si, mais je suis clairement persuadé qu'on peut le transformer en IDE complet… ce qui ne gommera pas ses défauts. Et pour les distrib de vim que tu cites, je ne les connaissais pas ( je n'y connais pas grand chose , il faut dire ), et je testerai. Sauf que… je doute qu'il y ait une intro simple à comprendre, ou qu'ils aient gommé les défauts de vim, dont la config complexe fait clairement partie. Selon moi, du moins.

Et quand on voit le temps que mets le comité C++ à se décider pour une nouvelle norme ( 8 ans pour C++11, si on considère la bugfix 03 comme une norme a part entière… que personne de mémoire n'a entièrement implémentée d'ailleurs ) je doute que ce soit une solution.
Qui plus est, comment trouver un système pour que ce que l'on utilise pas du standard ne coûte rien, comme en C++? ( ce qui n'est pas inclut ni demandé explicitement n'est pas utilisé en C++, donc pas payé. Exceptions, RTTI, ce genre de choses. On peut aussi les désactiver explicitement, mais en théorie ce n'est pas utile. J'ai bien dit théorie, hein? )

C'est sûr, c'est le genre de fonctionnalités qui me manquent personnellement, même sans les avoir essayées. J'ai pu voir des screen qui m'ont fait comprendre l'idée, rien de plus, mais… c'est séduisant tout de même.

Pour le coup, à part que ces layouts sont faits via lua, comment ça marche, en gros? Je me dis que quelque part, peut-être qu'avec des scripts exploitants les IPC d'i3… enfin, je ne sais pas, mais peut-être qu'il y aurait moyen de faire un truc qui sois moins pénible que refaire complètement le layout à chaque démarrage de la machine. Donc, comment qu'ils font, en face? ( parce que j'aime énormément l'idée du fichier de config simple, malgré tout… )

Je suppose qu'il est possible de créer un paquet dépendant de vim et des plug-in que tu souhaites, et les activant automatiquement.
C'est d'ailleurs exactement ce qu'eclipse fait, car sans plug-in cette usine à gaz ne fait juste rien.

Il faut juste trouvé un motivé qui ne craigne pas de récolter l'opprobe générale ( et ça part vite chez les barbus ;) ) en déterminant de façon totalement subjective et personnelle quels plug-ins liés à quelle configuration peuvent rendre vim aussi puissants qu'eclipse.

Sincèrement, si tu oses le faire je te soutien sans condition.

Ça, c'est génial! Merci beaucoup!!!

Oui, je sais, commentaire inutile, mais je tenais à te remercier.

Utile étant très subjectif…
J'avais à une époque ou je jouais beaucoup aux cartes Magic the gathering, créé un programme qui me permettait de calculer le nombre de terrains de chaque couleur que je devais mettre dans mon jeu pour optimiser mes chances de ne pas être handicapé par le fait de jouer plusieurs couleurs*.
Ca n'atteignait sûrement pas les 1000 lignes, considérant que la plupart du taf était faite via l'IHM, donc via une lib.

Je doute aussi que calc.exe ( proprio, certes, mais très utile ) fasse plus de quelques centaines de lignes, et pourtant, j'utilise souvent une calculette, peu importe mon OS. Celle de windows est mieux foutue que galculator sur certains aspects en plus.

J'ai aussi un script shell pour extraire les fichiers d'une archive jamendo dans une arborescence "artiste/album/*.???".

Ainsi qu'un outil pour générer une classe C++ en ligne de commande en fonction d'un nom que je lui passe, qui hérite automatiquement d'une liste de classes que je lui passe en paramètres ( fonctionnalité prévue: l'ajout automatique des prototypes des fonctions virtuelles des classes mères, avec le mot-clé override fournit gratos, entres autres ).

Je dois en citer d'autres, de petits utilitaires en dessous des 1000 lignes de code, ou tu as compris l'idée?
En fait, le mot est placé: utilitaire.

*: Ce qui me rappelle que le code source n'est pas "libre" ( surtout, pas diffusé ) mais j'avoue ne pas trop avoir imaginé qu'il puisse servir à quelqu'un… je dois encore l'avoir qui traîne sur un disque, je verrai p'tet pour le publier ce WE ^{^}

Héhéhé, je n'ai pas dit mon dernier mot:
Pas bien de se laisser embrigader par les politiques commerciales et de favoriser ainsi la vente liée ( on est trolldi depuis 1H, ouf suis sauvé )

Merci bien, je me sentait désespéré à l'idée de devoir manipuler un langage non typé sans débogueur, j'allais même sûrement binder une combo de touches de vim pour insérer des print, vu que le taf m'obligera sûrement à toucher à ce langage… ( quoique le client avait l'air heureux quand j'ai dit que je préfère utiliser d'autres langages a titre perso… peut-être que… avec quelques TU pour assurer mon coup, il y a moyen de vendre une migration de langage sur ce code crado, histo et phpo… )

et « IDE » est un ensemble de fonctionnalités pas clairement défini, mais dont on peut être sur qu'il inclut « éditeur de texte ».

Faux.
Tu pars du principe que tout langage de dev n'est constitué que de caractères ascii, la, voire de caractères tout court.

Ce n'est pas le cas. Les logiciels permettant de créer des programmes pour des automates industriels ne sont pas nécessairement textuels. Je ne connais que peu ce type de techno ( en fait, que de nom ) mais mon frère à fait ce genre de choses en bts électrotechnique ( il me semble qu'il me parlait de graphset, ou un truc du genre ).

Ce qui est amusant, c'est que je te contredis pour apporter de l'eau à ton moulin: un IDE est loin d'être évident à définir précisément. Après tout, le logiciel qui lui permettait de créer ces diagrammes qui étaient le source d'un programmes, n'avaient rien à voir avec un éditeur de texte, et étaient pourtant ce que l'on appellerai des IDE.

Lors d'une formation de chef de projet ( merci le pseudo anonymat internet, je préfère ne pas en parler si on peut m'identifier, tellement ça m'emmerderait que ça arrive aux mauvaises oreilles ) j'ai aussi vu des outils générant des programmes sans une once de texte, à base de schémas ( gestion de process en entreprise, de flux, bref, des trucs chiants… mais ça marche ) .
Donc, il n'y a pas qu'en industrie, mais aussi en service. Vraiment, non, un IDE n'inclue pas nécessairement un éditeur de texte.
Ah, ne pas oublier de citer access, que tout le monde ici doit connaître et qui permet de créer une DB ainsi qu'une IHM sur cette DB sans taper de coder si on le souhaite.

Si je rappelle qu'il n'y a pas que les entreprises qui font du dev, je passe pour un abruti, je suis hors sujet, ou j'ai raison? ( notez que je suis plus habitué au 2 1ers qu'au 3ème, je pense même que j'aime ça :p )

Le rPI, c'est moderne ou pas?

Oui, c'est limite trollant, j'avoue, mais, pour me justifier, les gens confondent souvent moderne et ayant une valeur commerciale élevée.
Et moi, je me dis que vu qu'on pouvais dev il y a 20 ans, pourquoi ne le pourrait-on plus avec des machines de même puissance, maintenant?

Alors, bien entendu, je sais que, je cite Mr dupond ( et pas dupont ) "Les applications modernes ont besoin de machines modernes pour tourner!" sauf que la raison principale de cet état de fait, c'est qu'on ne sais plus faire autrement que faire des trucs lourds j'ai l'impression.
Allez, un exemple pour accompagner mon argument: combien d'utilisateurs de word utilisent des fonctionnalités coûteuses en terme de CPU qui n'existaient pas il y a, disons, 10 ans? En pourcentage estimé, hein, pas en chiffres bruts.
Moi, je gage qu'on est largement en dessous des 25%, autrement dit, que la puissance consommée par ce logiciel à l'heure actuelle pourrait être réduite drastiquement dans 75% des cas.
Et ça, je suis incapable d'estimer l'impact que ça aurait énergétiquement et économiquement parlant sur notre planète. Moins de gaspillage, c'est la seule chose dont je sois persuadé ( pas convaincu, je manque de preuves pour ça ).

Ca vaut pour toutes les suites bureautiques, d'ailleurs.

Et pour revenir au dev, et à des cas concrets, la machine sur laquelle j'ai le plus codé ces 3 dernières années est un netbook, 1Go de RAM, dual core dual thread cadencé à 1.5GHz. Je t'assure que sur cette machine, ça à un impact non négligeable. Et je ne vois pas pourquoi je devrais m'interdire de coder dessus sous prétexte qu'elle m'a coûté que 210€ il y a 4 ans.

PS: vu le smiley, j'imagine que c'était de l'humour ta réponse, mais je tenais malgré tout à saisir l'occasion pour exprimer mon ras-le-bol des bloatwares et l'énervement que m'a toujours causé les gens qui disent "ne vous occupez pas des perfs, le client rachètera du matos", genre de mots entendu de mes profs, il y a presque 10 ans… et qui m'enragent toujours autant… oups :)

Mais un outil spécialisé dans un langage particulier incluera probablement nombre d'automatismes particuliers à ce langages, de raccourcis pour ses idiotismes et que sais-je encore.
Dans le cas de C++, il serait même imaginable qu'un nouveau moteur d'autocomplétion spécialisé puisse être réellement efficace ( j'ai bien dit: nouveau ;) )

En soit ça ne me semble pas idiot, de spécialiser l'outil… jusqu'a ce que je me rappelle qu'en général, un développeur professionnel n'utilise pas qu'un seul langage, et que changer d'outil en fonction du langage est assez ennuyeux, voire pénible.

Ça dépend, est-ce que emacs inclue un éditeur de texte?

Permets-moi de t'avouer que tes distinctions sont, à mon humble avis, simplistes.

Un éditeur de texte, on lui demande juste de créer, lire, et modifier un série de caractères sur un disque dur.
D'afficher de la coloration syntaxique ou une liste de suggestions, à mon sens ce ne sont pas des choses qui ont trait à l'édition de texte, mais à l'édition de code, chose très différente.
Après tout, un éditeur de texte ne sert pas qu'a créer du code, il y a aussi les todolist, les readme, etc.

Pour prendre un exemple "théoriquement concret", imagines un éditeur de texte qui fonctionne sur le même principe que mpd/mpc/ncmpc, c'est à dire un démon ( mpd ) qui à le contrôle total sur le texte ( 1 démon, 1 fichier, pour prendre un truc simple ), et des clients, qui communiquent avec le démon. Ces clients pourraient très bien s'interfacer à un autre outil qui aurait, lui, le rôle de soumettre des suggestions ( auto-complétion ) et laisser la coloration syntaxique à leur IHM.
Comment pourrais-tu dans un tel cas classer cet éditeur de texte théorique dans une de tes cases? Il est capable de traiter plusieurs langages, puisqu'il ne s'agit que de texte, donc il est généraliste. Pourtant, il n'inclue pas lui-même de système de plug-in et encore moins de coloration syntaxique, choses qui ne seraient gérées que par les clients voire d'autres outils.

Ensuite, la notion d'IDE est, elle aussi, délicate à définir. Selon le langage, on ne compile pas forcément ( interprété ), ne débug pas forcément ( je ne sais pas si ça existe, un débuggueur php par exemple? ), n'utilise pas forcément de diagrammes ( pour du code LaTeX je doute qu'on puisse faire des diagrammes pour représenter le code par exemple ) etc.
J'ai aussi connu des IDE qui n'ont pas la notion de contexte, de projet ( turboC par exemple, que j'ai longtemps préféré a devcpp ou un truc du genre parce que c'était justement moins prise de tête pour compiler/debugguer avec, pas besoin de s'emmerder à créer un projet pour un code de 500 lignes… ).
Alors qu'un simple éditeur de texte, dans un environnement configuré correctement, offrira à son utilisateur ( probablement aguerris aux twm et lignes de commandes ) autant de facilité qu'un IDE.
Du coup, quelle différence entre IDE et "DE" spécialisé pour le dev?

Les seules choses qui permettent à mon avis de différencier un outil qui permets de gérer son code d'un autre, c'est:
_ à quel point il est efficace par défaut. Caractéristique des IDE, ils sont très efficaces out-of-the-box. Par contre, quand on commence a vouloir un truc plus à son goût, ça commence à bloquer comparé à la config totale de son environnement de bureau à coups de scripts et d'outils respectant la philosophie UNIX.
_ à quel point il pèse sur les performances de la machine. Genre, on ne peut pas comparé eclipse ou visual studio avec vim+i3+lxterminal+bash.

Ceci dit, je te remercie parce que j'ai bon espoir de lire des choses très intéressantes en réaction à ton billet :)

Pas bien d'utiliser VS sans licence !