En l'occurrence il ne s'agit pas d'importer un mot ici, mais de prendre un faux-ami (donc qui existe aussi dans notre langue) et de lui donner un sens qu'il n'a pas. Ce qui me gêne surtout, c'est que l'on change le sens de mots existant déjà dans notre langue plus par ignorance (des alternatives existant déjà dans ladite langue, entre autres) que par "choix".
« Bof, ton fabriquant de cartes, il les vends aussi que je sache (à des grossistes bien sûr), il ne les donne pas je pense.. »
Dans un système commercial, nous sommes tous vendeurs et acheteurs de quelque chose (sauf le client final, bien sûr). Sauf que lorsqu'on parle d'un fabriquant, ça a un sens précis. Lorsqu'on parle d'un vendeur, ça a un sens précis aussi, lorsqu'il est employé en tant que nom commun. Le "vendeur" est justement là pour vendre au client final. Le fabriquant non.
Je te renvoie à 1984 : pourquoi avoir des mots antonymiques ? On a "mauvais" et "bon". Il suffit de garder "bon" et de rajouter des préfixes et des suffixes :
"bon", "inbon"/"pabon", et pour le mélioratif utiliser "plusbon", "doubleplusbon"... C'est vrai quoi, qu'est-ce qu'on s'en fiche, d'avoir une langue française riche, certes, mais précise aussi ? A quoi ça sert ?
Mis à part ECMAScript, qui est normalisé, je ne vois pas trop de choses autres que des standards niveau Web... Donc comme "standard != norme", même si c'est nul de la part MS de ne pas respecter ce dernier, ils n'ont aucune obligation de le faire.
Euh, si OpenXML devient une norme ISO, je ne vois pas où serait le problème. Si ça devient une norme, MS ne pourra pas la modifier comme bon leur semblera, et l'on pourra l'utiliser dans les logiciels libres.
PS : comme il a été dit précédemment : standard != norme...
« Elle n'était précédemment disponible que pour les vendeurs de cartes, sous licence propriétaire. »
(c'est moi qui souligne)
Merci d'arrêter l'anglicisme "vendeur" (issu de "vendor"), et de remplacer par "fabriquant". C'est une manie qui devient de plus en plus courante, et à chaque fois j'ai l'impression que je vais avoir le monsieur de chez Darty qui va me filer une carte WiFi, ce qui est tout de même assez troublant ...
C'est très variable en fonction du matériel à piloter. En fait, si tu possèdes les specifications du matériel, ça peut être extrêmement rapide, étant donné que (et en supposant que les specs décrivent fidèlement le comportement du matériel bien sûr) tu possèdes à peu près toutes les informations nécessaires pour lier ledit matériel au système.
Par contre, si pour une "bête" carte réseau ethernet (sans fonctions de crypto intégrée en dur ou autres) la rédaction d'un pilote est rapide , autant pour une carte vidéo qui comporte énormément de circuits différents et spécialisés, ça risque de prendre plus de temps - notemment à cause du temps pris par des tests sérieux. Combien, je ne sais pas. :-)
« Pourquoi HP sponsorise ou a sponsorisé par donation des projets comme Debian, Samba, Jabber, Apache, Gentoo, Gnome, NetBSD et FreeBSD, et pas OpenBSD ? »
Sans doute parce que Linux a une visibilité bien plus grande qu'OpenBSD, que la base de développeurs pour le système est, elle aussi, bien plus grande, etc.
Franchement, il serait plus simple de laisser le dév desdits drivers aux gens qui ont le plus l'habitude de bosser sur les systèmes précités... Sans parler du fait que certains aiment développer des drivers (si si), ou tout un tas d'autres trucs. :-)
« Personne n'a sérieusement réfuté les chiffres autrement qu'en disant : les chiffres sont US donc biaisés, oui mais comment ? Imaginons que c'est vrai, on parle d'un facteur 10 à 20 quand même. »
Je me répète : ta façon de rédiger tes posts n'a rien à voir avec leur contenu. Je ne sais pas qui a tort ou raison. Ce que je sais, c'est que ce que tu affirmes ne m'est pas inconnu, et j'ai donc tendance à accorder du crédit à ce que tu dis. Sauf qu'avec ta façon condescendate et méprisante de répondre, tu en deviens désagréable.
Soit dit en passant, lorsque tu cites, merci de citer avec un minimum de contexte autour. Lorsque je dis que « à partir des années 90, l'avantage d'être informatisé commençait à se dessiner clairement. », le contexte est "je crois me souvenir qu'on m'avait dit dans mes cours que ..." Bref, tu cites comme si j'affirmais, alors que justement dans la suite de mon message précédent, je te propose de confirmer auprès de mes anciens profs.
« On notera que l'informatisation sans réorganisation et vice versa entraînent une perte de productivité. L'informatique apporte à elle seule aucun de gain de productivité. »
Quoi ? Tu veux dire qu'une technologie utilisée « brutalement », sans adapter un système à son fonctionnement ne fonctionne pas bien, voire rend les choses plus difficiles à réaliser ? Quelle surprise !
L'informatique est une technologie extrêmement récente, il me semble évident qu'il faut attendre un minimum de temps pour que son utilisation devienne non seulement aisée, mais efficace.
« La chose que je dit par rapport aux diplômes en informatique, c'est qu'à priori il n'est pas évident l'en prenant au hasard des gens diplomés dans cette discipline (sur une population ayant au moins deux ans de pratiques), on ait forcément des informaticiens *siginificativement* meilleurs professionellement parlant qu'en prenant n'importe qui »
Je ne suis pas d'accord. Enfin, plus exactement, je pense que cela dépend totalement du domaine en informatique où tu te places.
Si l'on parle d'administration système, je suis parfaitement d'accord, et d'une manière générale, dès qu'il s'agit d'informatique en tant qu'outil de gestion d'un système d'information, tu as parfaitement raison : on n'a pas besoin de faire des études poussées (et même, si l'on peut se permettre de se procurer les bons ouvrages, on a juste besoin d'un ordinateur à disposition et de beaucoup de patience).
Sauf que l'informatique n'est pas que de gestion. Il existe énormément de domaines (pas forcément très théoriques a priori) où le besoin d'avoir été formé dans des sciences fondamentales est extrêmement important :
- l'informatique embarquée ;
- les outils de modélisation de tous poils (simulateurs, émulateurs, logiciels de PAO/DAO/Machin-AO)
- les jeux vidéo (oui oui)
- les outils de traitement multimédia en règle générale
- etc.
Tous ces domaines (et bien d'autres encore) nécessitent de comprendre d'un point de vue scientifique ce qu'on programme. Alors bien sûr, il faut quelqu'un "au-dessus" pour superviser le tout, c'est évident. Il est aussi évident qu'il faut bien organiser la communication entre les différents développeurs, et autres personnes impliquées dans le projet, mais franchement, dans une entreprise, n'est-ce pas - justement - une évidence ? :-)
Une "simple" formation ne suffit pas pour cela. La formation en master/école d'ingénieur/etc permet de s'armer un peu mieux pour ce genre de choses, car en cinq ans, on a le temps d'aborder bien plus de sujets, et surtout, on a le temps d'approfondir. Franchement, mis à part les ingénieurs de recherche et les chercheurs eux-mêmes, tu connais beaucoup de gens qui continuent de se former sur des sciences "fondamentales" ou très théoriques ? Pourtant, c'est vital dans certains domaines. Donc puisque généralement, on ne revient plus en arrière pour se former dans les nouvelles théories en maths, physique, etc., autant bien se former dès le début, une fois pour toutes. Au moins il en restera quelque chose vingt ans (au moins une tournure d'esprit plutôt scientifique).
Un exemple très bête : un ancien collègue, très productif au demeurant, s'était mis au Java lors de la programmation d'une grosse application pour une grosse boite. Il connaissait bien le langage C, et avait déjà fait à plusieurs reprises des projets en C++ (enfin, de ce que j'ai compris).
Bien. Sauf qu'il continuait à programmer en Java comme on le ferait en C. Bien sûr, il se servait un minimum des mécanismes objet, mais il faisait ses exceptions "à la main", réinventait le goto dans un langage qui interdit son usage ... Bref, l'horreur pour qui a un minimum de connaissances en programmation orientée objet. Par contre comme architecte logiciel, chapeau, ça se voyait qu'il avait de l'expérience dans le domaine. Il était juste incapable de s'adapter à des techniques plus modernes (honnêtement, il avait 20 ans de retard concernant le génie logiciel "terre à terre", immédiat).
Voilà un ingénieur, de formation plus électronicienne qu'informaticienne (et pour cause, à l'époque, peu d'écoles proposaient une vraie formation en informatique), qui a fini par accuser les frameworks utilisés de ne pas permettre de maintenir correctement l'application en question - alors qu'en fait, c'était plus la méconnaissance des design patterns, et des frameworks en eux-mêmes qui avaient conduit à une usine à gaz difficilement maintenable. Alors oui, cette personne, si on lui donnait une formation continue, pourrait sans doute se mettre à jour concernant la POO.
Mais quand je vois le mal qu'on déjà certains étudiants lorsqu'on passe de la programmation procédurale à la programmation objet en IUT, alors qu'on ne parle même pas des "vrais" aspects théoriques et mathématiques qui se cachent derrière, permets-moi de douter de la capacité de tout un chacun à réaliser n'importe quel projet informatique. Une formation longue permet, selon moi, de rendre sa cervelle plus "flexible". Bien sûr, il existe tout un tas de gens qui sont déjà dans ce cas, sans diplôme, avec un diplôme bac +2/+3, etc., mais ils sont (bizarrement ? :-) ) beaucoup moins nombreux que ceux qui font quatre ou cinq ans d'études...
« Mon ton vous semble probablement suffisant, parce que je n'accorde aucun crédit à vos titres, et que ce que vous écrivez n'est pas argumenté. Les "on dit que", "tout le monde sait/fait" ne sont pas des arguments sauf au comptoir d'un bar. »
Non, ta façon d'écrire pue le mépris. Un grand diplômé qui prendrait le même ton recevrait le même accueil : tu es d'une condescendance crasse, à la limite de traiter à peu près tout le monde ici comme si l'on était des imbéciles.
Je connais en partie les ouvrages que tu cites (« Code Complete » est effectivement un excellent bouquin, et « The mythical man-month » aussi). Mais les agiter sous le nez des gens en disant "vous voyez, j'ai raison, vous avez tort, bande de minables" (oui, je sais, tu n'as traité personne de minable, mais parfois, les phrases sont elliptiques...), forcément, ça n'aide pas à soutenir ta thèse.
[moinssage]
« Par ailleurs, les responsables du master et de sa comm, et les partenaires industriels lisant le forum, il est assez rationnel qu'ils n'aient pas envie d'avoir de mauvais commentaires sur leur diplômes et leur initiative qui apparaissent sur le web, »
Si tu penses vraiment ça, c'est que tu es parano. Et un parfait imbécile (ça y est, je l'ai dit), ou alors très très malade.
Je ne vois pas en quoi les dires d'une seule personne, qui plus est en minorité concernant son opinion (puisqu'elle est plus ou moins toute seule contre tous) risquerait de faire du tort aux enseignants qui essaient de monter leur master.
Et cela n'a rien à voir avec qui a tort ou raison.
Bref.
En IUT nous avons parlé du fait que l'informatisation des entreprises n'était pas nécessairement un bienfait pour elles. Sauf que dans mon souvenir, mes profs d'éco/gestion/organisation nous disaient que justement, si jusque dans les années 80 c'était plutôt discutable, à partir des années 90, l'avantage d'être informatisé commençait à se dessiner clairement. Je n'ai aucune référence sur le sujet en question, mais je peux toujours recontacter mes anciens profs d'IUT si ça t'intéresse.
Concernant la formation : bien sûr, on peut "tout" apprendre dans les livres. Mais on oublie un truc : à ce train-là, on peut apprendre à peu près tout le savoir "scolaire" dans les livres. Ce qui est intéressant dans une formation, quelle qu'elle soit, c'est le fait que les enseignants qui y officient puissent permettre d'opérer des raccourcis, et d'épargner justement tout un tas de lectures (au moins dans un premier temps) à leurs élèves. En plus, une formation offre l'énorme avantage que contrairement aux livres, les profs répondent aux questions, eux.
En IUT génie info [de gestion], il est accordé une place aussi importante à l'étude du génie logiciel qu'à l'algorithmique/programmation et les cours de système en cumulé. Ce n'est pas pour rien : l'informatique de gestion nécessite effectivement une analyse et une planification toutes différentes d'autres projets informatiques.
Sauf que par exemple, en IUT génie électrique et informatique industrielle, on y fait aussi de l'informatique. D'un autre genre, certes, mais de l'informatique quand même. Le genre d'informatique qu'on retrouve dans les systèmes embarqués. Et là, il faut un autre genre d'informaticien. Je ne parle même pas des machins de technologie de pointe.
Tu peux cracher tant que tu veux sur les diplômes, mais quelqu'un ayant réussi à avoir un bac +5 dans le domaine de l'informatique répond à au moins l'un de ces deux critères :
1) Il a en fait un parcours plutôt "management", et a fait un à deux ans d'informatique pour pouvoir se spécialiser un peu ;
2) Il a fait de l'informatique à un certain niveau, et a un niveau de culture générale en sciences a priori suffisant pour pouvoir comprendre comment trouver et mettre en oeuvre des solutions techniques diverses et variées.
J'ai fait un IUT, puis une école d'ingénieur. Je te promets que la formation, aussi limitée puisse-t-elle paraître, permet à quelqu'un de motivé de réussir à faire de bien belles choses. Et là où c'est miraculeux, c'est que même quelqu'un qui n'est pas forcément passionné par l'informatique peut quand même en faire son métier car on lui a donné de bonnes méthodes pour réaliser un projet informatique ! (si si). A lui de les appliquer ensuite, bien sûr.
Qu'est-ce que tu appelles une "structure arborescente non-réentrante" ? Parce que le XML, par l'intermédiaire des ref-id, permet d'obtenir non seulement un arbre ordonné et étiqueté, mais aussi un graphe (donc avec des cycles, et tout).
« Il semble d'ailleurs que ce soit une erreur fréquente (notamment propagée par les médias...) »
Mouais. C'est surtout qu'il est bien plus naturel à l'oral de mettre un subjonctif derrière « après que ». D'ailleurs, je crois que c'est déjà déclaré comme toléré (sinon, ça ne saurait tarder).
« Je dis que la syntaxe des attributs n'est pas un arbre XML donc on perds la recursivité. »
Et je réponds à nouveau que si tu cherches la récursivité, tu utilises des noeuds (donc des balises). D'un point de vue temps de définition, c'est à peu près équivalent (avec une DTD).
«
> Il faut comprendre justement comment les langages de navigation
> dans les arbres XML et les langages de requêtes sur XML infèrent
> les types.
Il doit manquer des mots ;-)
»
Euh non. :-)
En gros, un langage qui navigue dans un arbre XML, ou bien un langage qui effectue des requêtes dessus (et qui donc en fait, est bien obligé de naviguer dedans ;-) ) se doit d'être un minimum intelligent, sinon il va être assez inefficace :
- s'il considère le doc XML comme un fichier texte, il va juste se baser sur la notion de « bien formé » (une balise ouvrante possède un équivalent fermant) et à la limite, autant utiliser de bonnes vieilles regexps pour chercher l'info qui nous manque (bonjour le mal de crâne).
- sinon, il faut inférer le type de retour concernant la requête de navigation ou d'interrogation de ton doc en règle générale :
si on possède un schéma XML ou une DTD, ça signifie entre autres être capable de prédire (au moins en partie) si une partie du code de la requête examinée ne donnerait pas un résultat qui serait toujours faux (par exemple, demander de trouver une balise qui ne se trouve *jamais* dans une autre), et donc couper certaines branches de la recherche, histoire de gagner du temps. On évalue aussi le type "retour" que la requête devrait renvoyer, lorsqu'il s'agit d'une requête qui effectue des transformations sur un document XML.
Par exemple, on récupère l'ensemble des "//a/b" dans une variable $x et à chaque fois qu'on le trouve, on renvoie "<c>$x</c>". S'il se trouve que <c> ne contient *jamais* les balises contenues dans <b>, alors on peut d'ores et déjà invalider la requête. Le problème survient quand seulement une partie des balises contenues dans <c> se retrouvent dans <b> : là il faut analyser la réponse de la requête (évaluer son type), et comparer avec ce qui est attendu (le type de retour prévu).
«
> genre en XPath, si tu cherches /a//c[@d="untruc"],
Génial !
C'est pile ce que je critique. Le lien entre XPath et XML ?
»
Plus loin, tu te demandes en quoi XPath est spécifique à XML (exemple LISPien à l'appui)
Ma réponse est vraiment toute bête :
XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML fondamentalement. Un document XML, c'est un ensemble d'arbres ordonnés et étiquetés. Que sa représentation textuelle soit faite sous forme de balises ouvrantes et fermantes plutôt que sous formes de commandes TeXiennes (\etiquette{...}) ou LISPiennes ( (etiquette '(...)), ou ... on s'en fiche un peu.
NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas récursifs non plus, et qui - surprise ! - sont non ordonnés :
\documentclass[a4paper,12pt]{report}
Dès que tu as des [...], tu as un ensemble de mots-clef (donc non ordonnés, puisqu'il s'agit d'un ensemble).
Concernant le peu de ressemblance entre la syntaxe XPath et XML, c'est vrai. D'ailleurs XML Schema a été créé pour avoir un système de définition de types XML qui soit fait en XML, et pas avec un langage tiers (pas comme les DTD quoi). En pratique, un schéma XML un tant soit peu complexe est très chiant à lire pour un humain, alors qu'une DTD c'est déjà vachement plus simple (le problème c'est que c'est moins puissant, et donc lorsqu'on veut réaliser certaines choses, XML Schema est le seul recours).
Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les langages de transformation de XML ne ressemblent pas trop à du XML. Par exemple, XQuery utilise une syntaxe FLWR : for / let / where / order by . Et après ? XML est fait pour être lu par des machines. Par contre, les programmes qui manipulent les documents XML (pour rechercher, récupérer, transformer tout ou partie de ceux-ci) doivent être compréhensibles pour l'humain.
D'ailleurs, XSL/T, ça a beau être super puissant, c'est tellement chiant à utiliser que dès que je peux éviter ben... j'évite :-)
« Je suis assez d'accord pour dire que les attributs sont une aberration. Ils étaient logique en HTML : l'attribut représente la mise en forme, le reste est du texte.
Mais avec XML on a perdu cette sémantique, »
Euh non. Contrairement à ce que vous semblez pensez tous les deux, les attributs sont typés. Ce ne sont pas de vulgaires chaînes de caractères (avec les DTD c'est pas facile à voir, je le reconnais, mais avec les schémas XML ça crève les yeux, puisqu'on peut leur affecter un type). De toute manière, il faut comprendre justement comment les langages de navigation dans les arbres XML et les langages de requêtes sur XML infèrent les types.
Si j'ai un noeud [a] qui contient un attribut @b, un bon langage de requête pourra inférer un certain type (a,b) (en simplifiant à l'extrême), et retrouvera ses petits tout en faisant quand même des optimisations - genre en XPath, si tu cherches /a//c[@d="untruc"], alors qu'on sait que le noeud [c] ne comporte pas d'attribut @d, on peut directement « défausser » la requête et même la considérer comme fausse.
Faut pas croire, les gens qui ont élaboré XML (et ceux qui continuent de bosser dessus) sont loin d'être bêtes.
« "Les optimisations ne sont plus liées à une syntaxe, mais à la sémantique du code... C'est justement bien plus profond !" »
Je ne sais pas si c'est une spécialité de l'INRIA ou bien de la recherche dans les langages de programmation en général, mais j'ai l'impression que pas mal de langages issus de labos de recherche « remontent » les traitements au niveau sémantique ... Je pense entre autres à CDuce (http://www.cduce.org), un langage fonctionnel et généraliste à la ML qui a été créé pour traiter efficacement les transformations de documents XML. Là aussi, on a passé certains pans du langage au niveau sémantique (notamment le sous-typage qui est classiquement utilisé au niveau syntaxique, est « remonté » au niveau sémantique - et c'est le compilateur qui trouve tout seul comme un grand quel est le type d'une fonction donnée).
l'attribut href est une simple chaine, pas un arbre xml. »
Euh oui, mais là on VEUT que ce soit une chaîne ;-) (prendre mon exemple de date à contre-pied aurait sans doute été plus heureux, je trouve). Je ne vois pas trop où est le problème en fait. Qu'on parle XQuery ou XSL/T, on utilise XPath pour naviguer dans l'arbre XML. Je vois les attributs d'un noeud - pardon, d'une balise ;-) - comme étant des données propres à celle-ci. Exactement de la même manière que je peux avoir dans un arbre en C une structure noeud du genre
const unsigned int N = 100; /* arité */
typedef struct Noeud_
{
char *etiquette; /* type de noeud */
void *donnee; /* données spécifiques au noeud */
struct Noeud_ *noeuds[N]; /* fils du noeud */
} Noeud;
Dans ce cas, je peux créer un arbre N-aire, et dont les données sont parfaitement « génériques » : il suffit d'allouer assez de mémoire pour y faire tenir tous les « attributs » que je veux. :-)
Je ne vois pas ce qu'il y a de gênant avec ce genre de structures de données, en fait.
Ici, il faut définir pour chaque balise une fonction particulière (puisqu'en LISP, une parenthèse ouvrante indique que le terme qui suit est une fonction). C'est particulièrement lourd, tu ne trouves pas ? Même en faisant des setq de partout, ça risque d'être un vrai casse-tête.
De plus, lorsque tu dis
« Bilan, les atributs sont gérés comme des arbres et leur valeur peut aussi être un arbre, donc bien plus typé qu'une chaine. »
En disant ça, tu ne fais que répéter ce que j'ai dit : si les attributs ne te plaisent pas, tu n'es pas obligé de les utiliser, et tu as tout à fait le droit de n'utiliser que des balises - car ce que tu proposes de faire en LISP revient exactement à ça. Si on a défini la notion d'attribut en-dehors des balises classiques, il y a quand même une raison. Et étant donné que tu définis lesdits attributs dans ta DTD ou ton schéma, tu ne perds absolument pas d'information de type.
Le gros problème d'XML en ce moment, selon moi, c'est que beaucoup d'outils existent, mais que les gens ne les utilisent pas forcément (je radote avec les histoires de DTD et de schémas XML ;-) ). Ou alors ils utilisent XML parce que ça fait bien, mais sans réel besoin : j'ai envie de flinguer à peu près tous les programmeurs qui utilisent XML pour faire des fichiers de config, par exemple. Si dans certains cas ça peut parfaitement se justifier (par exemple un fichier de config Apache en XML, ça ne changerait pas tellement du fichier de config original), dans la plupart des cas, une bête association clef-valeur(s) (éventuellement séparées par des virgules) est largement suffisante.
Là où XML devient intéressant, à mon avis, c'est lorsqu'on commence à traiter de gros volumes de données (et où on doit donc vraiment prendre en compte les types pour optimiser les recherches). Sinon, *bof*.
« Le XML est à la mode mais il a aussi ses défauts. »
Jusque là, je suis tout à fait d'accord. :-)
« Très verbeux, "chiant" à deboguer à la main... »
Euh oui, mais n'oublie pas un truc que tu as dit en tout premier, en haut de ton post : « Le XML est conçu pour la machine » !
« Il souffre surtout à mon avis d'une erreur de conception au niveau des attributs. En effet, il perds l'aspect récursif du LISP a ce niveau là, les attributs étant des chaines de textes entre "" et non du XML »
Là-dessus, je ne suis pas d'accord. Premièrement, si vraiment tu tiens à ne pas utiliser les attributs, tu n'as qu'à définir une balise « vide », dire quelle autre balise peut l'utiliser, et c'est fini (exemple pour XHTML : <br/>).
Deuxièmement, il faut voir les documents XML comme des arbres, dont les noeuds peuvent posséder, en plus de leurs enfants et de l'étiquette qui les identifie, une séquence de données supplémentaires : les attributs. Là où un document XML est un arbre ordonné, les attributs ont l'avantage de plutôt représenter un « ensemble » de données (non ordonnées, donc). Suivant l'usage dont tu as besoin, ça peut être très pratique. Par exemple, je trouve bien plus utile d'avoir une balise « vide » <date/>, avec comme obligation de comporter au moins un attribut « année » et comme attributs optionnels « mois » et « jour », que de définir la même balise comme étant composée de trois autres balises :
<!ELEMENT date (annee, mois?, jour?)>
De toute manière, on se fiche un peu de l'ordre dans lequel ils apparaissent, non ?
Si tu as besoin de l'aspect récursif des types XML, tu utilises les balises ; sinon, tu as le choix entre attributs et balises suivant que tu désires sous-typer ou pas ta structure de données.
« Bilan, il y a tout un tas d'API pour contourner ce problème de conception, »
Euh, tu dis que les API sont là pour contourner le fait que les attributs existent ? Ca me semble un peu irréel comme remarque, ça ! :-)
A moins d'utiliser les ID-REFs dans tes schémas XML, les documents XML sont strictement des arbres. Pas de risque de cycle, rien. Il y a tout plein de problèmes qui risquent de se poser pour faire l'analyse de docs XML, mais certainement pas les attributs !
« Le plus grave, c'est qu'on en a pris pour 20 ou 30 ans et que ca va nous faire chie... »
Meuh non. Premièrement, définir une DTD c'est chiant, mais ça n'a rien d'impossible (et c'est surtout ça le problème avec XML je trouve : le fait que les gens ne prennent pas la peine de définir correctement des DTD ou des schémas XML). Ensuite, il existe des outils pour exporter une DTD en schéma XML (car les DTD ont certaines limitations, mais sont, en contrepartie, relativement lisibles, comparées aux schémas XML).
Enfin, pour ceux qui l'ignoreraient, il existe un langage de requête, XQuery, qui possède déjà quelques implémentations, et qui a le gros avantage de prendre en compte le fait qu'un document XML est typé, et donc ne fait pas de recherche stupide lorsqu'il peut l'éviter.
Le XML est là en partie pour permettre de modéliser des choses qui le sont difficilement avec des systèmes de gestion de bases de données classiques (notamment relationnelles), ou bien au prix de certaines contorsions ou d'occupation excessive de la mémoire.
« Je ne suis pas programmeur et fanatique de LISP mais avec une syntaxe bien plus simple et récusive, tu refais tout XML en propre. »
Bof. Les données semi-structurées, ça fait un bout de temps que ça existe, sauf qu'avant, chacun avait son modèle dans son coin. Ce qu'apporte XML, c'est un compromis entre différents acteurs du monde industriel (Microsoft, Sun, etc.) et scientifiques (universités, INRIA, etc). Comme tous les compromis, il n'est pas parfait, car chacun voulait que « sa » killer-feature se retrouve dans le langage. Mais franchement, on n'en est qu'au début de l'exploitation d'XML. Laissez encore cinq ans aux différents acteurs pour élaborer des méthodes d'interrogation efficaces de XML, et on en reparlera.
« Un arbre, un tri, je cherche à me souvenir quand j'ai eu à m'intérresser à ça, ouhla ça fait loin.. »
Mmmmh. Je m'en sers tous les jours en faisant des "cd ..", "cd /usr/share/doc", etc. Ah oui, et si tu manipules du XML, avec des requêtes XPath, ça peut être pas mal de comprendre comment fonctionne la structure d'un arbre. Ca peut aussi éclairer ta lanterne sur le fait qu'utiliser l'opérateur "//" doit être mûrement réfléchi.
« Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof. »
Idem pour les arbres (d'où ma référence à la glibc). Mais relis mieux ce que j'ai dit ensuite : le problème est de savoir utiliser les bons outils, et donc, connaître les forces et les faiblesses des structures de données manipulées.
« La plupart du temps quand on programme, cela tient plus de la recette de cuisine »
Euh. Tu te rends compte que ce que tu dis finalement, c'est « Puisque j'y arrive de cette manière, pourquoi j'essaierai d'apprendre à le faire d'une autre manière, aussi pratique soit-elle au final ? »
La programmation fonctionnelle est extrêmement puissante, permet de faire des programmes assez concis, et faciles à comprendre. Après, il est possible de faire de même en prog itérative, bien sûr. Mais il s'agit dans les deux cas d'outils à utiliser en fonction des besoins. Faire une IA en C est bien plus difficile que faire la même chose en LISP. Faire un programme sûr est bien plus facile avec un langage comme Java (qui est sûr du point de vue des types) qu'avec un langage de type C ou FORTRAN.
Dans tous les cas, la prog fonctionnelle n'est certainement pas plus compliquée à apprendre dans l'absolu que la prog itérative. D'ailleurs, si tu prends un langage comme Perl, il permet de faire les deux (en faisant une ou deux contorsions, c'est vrai).
1) Ouvre n'importe quel bouquin de niveau licence/maîtrise pour faire de l'algo.
2) Choisis les chapitres concernant les graphes et les arbres plus particulièrement.
3) Prends un algo au hasard.
4) Surprise ! L'algo est récursif. Et c'est carrément « naturel » de penser ainsi, soit dit en passant. L'alternative itérative est beaucoup moins facile à imaginer.
5) Réessaie avec le chapitre sur les tris efficaces (pire cas ou cas moyen). Retourner en 4 pour la conclusion.
Il faut évidemment nuancer tout ça : si l'algo en question est récursif terminal, il existe une version équivalente itérative, et on peut même s'amuser à automatiser la transformation (certains compilateurs le font dans les cas assez simples).
Par contre, une chose est certaine : autant l'approche récursive est tout à fait naturelle dans certaines structures de données (les structures ... récursives, tiens donc !), autant, pour un langage comme le C, la récursivité peut faire très mal (surtout si elle n'est pas terminale).
Moralité : il faut des mecs super balaises en algo/prog C pour élaborer des algos itératifs pour gérer les cas (cf. la glibc, par ex), sinon il y a risque de faire exploser la pile des variables automatiques.
Corollaire : les programmeurs « moyens » utilisent des structures de données comme on le leur a dit, sans vraiment leur expliquer comment elles fonctionnent, et du coup bousillent totalement les perfs d'un programme. Par exemple, ils ont l'habitude d'utiliser des listes d'éléments (en Java, C#, que sais-je), et n'ont jamais entendu parler des arbres rouge-noir (pourtant implémentés en tant que TreeMap en Java par ex). Résultat : ils vont se faire chier à faire des sortes de « tri par insertion » sur une liste, plutôt que d'utiliser une structure spécifiquement élaborée pour ce genre de cas.
Maintenant, un langage fonctionnel a beau avoir une approche plus « mathématique » de la programmation (pour la forme), je pense avoir eu autant de mal au début à comprendre comment faire des boucles for/while/do-while en Perl/C qu'à faire des récursions en LISP pour la première fois. Non, pire. Ca avait été plus dur, car comme on m'avait relativement bien formé à C, on n'avait cessé de me répéter : « la récursivité, c'est le Mal » (à cause du passage des paramètres par valeur, etc). Donc j'étais bien endoctriné.
Euh, je suis fervent défenseur de LaTeX et tout, mais faut arrêter de dire n'importe quoi hein.
« On ne s'attardera pas non plus sur l'incapacité de Word de gérer les références aux figures, sections et tuttti quanti quand vous en insérez de nouvelles. Pitoyable. »
Euh, sans parler des plantages qui effectivement surviennent de temps à autres, lorsque j'ai vu des gens se servir de MS-Word, avec une vraie formation derrière, j'ai jamais vu de problème de génération de tables des matières, etc. . Ils lançaient la regénération automatique des différentes tables, et ça fonctionnait.
Comme je l'ai dit plus bas, c'est surtout la promesse débile qu'on a pas besoin de se coltiner de manuel avec MS-Word (au contraire de LaTeX, ou LyX) qui est stupide. On a toujours besoin d'apprendre à se servir d'un outil si l'on veut être performant avec. Et dans le cas de MS-Word, le temps qu'on passe à examiner les différentes boites de dialogue est extrêmement important (là où - au moins pour LaTeX - on le passe à piger les rudiments du langage - et 2 heures suffisent pour comprendre comment faire la même chose que MS-Word avec 2 h de cliquage intensif).
Sinon, MS-Word permet aussi de récupérer les fichiers perdus lors de crashes.
« je tenais à attaquer le mythe selon lequel "latex fait toute la mise en page seul" »
C'est pourtant en grande partie le cas.
Généralement, je précise les en-têtes, les marges, simple/double colone, le titre, etc., dans le préembule, et ensuite, roulez jeunesse.
Ensuite, c'est évident qu'utiliser ViM / Emacs pour éditer du LaTeX permet d'aller super vite, vu que tout un tas de balises apparaissent automagiquement quand on connaît les bons raccourcis...
N'empêche : sous MS-Word/OOWriter, il faut maîtriser les styles pour arriver à faire à peu près ce que LaTeX permet de faire. Ensuite, c'est vrai, quand on est un gourou MS-Word/OOWriter ou un gourou LaTeX, on a généralement passé un certain temps sur le logiciel en question, on sait faire tout plein de trucs, et le résultat est plutôt bon dans les deux cas. Sauf que par la force des choses LaTeX « oblige » à apprendre un peu comment structurer son document, alors que les logiciels de traitement de texte incitent au départ à tout essayer ... et prendre de mauvaises habitudes...
[^] # Re: [HS] Mais j'en ai un peu marre ....
Posté par lasher . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 10.
[^] # Re: [HS] Mais j'en ai un peu marre ....
Posté par lasher . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 9.
Dans un système commercial, nous sommes tous vendeurs et acheteurs de quelque chose (sauf le client final, bien sûr). Sauf que lorsqu'on parle d'un fabriquant, ça a un sens précis. Lorsqu'on parle d'un vendeur, ça a un sens précis aussi, lorsqu'il est employé en tant que nom commun. Le "vendeur" est justement là pour vendre au client final. Le fabriquant non.
Je te renvoie à 1984 : pourquoi avoir des mots antonymiques ? On a "mauvais" et "bon". Il suffit de garder "bon" et de rajouter des préfixes et des suffixes :
"bon", "inbon"/"pabon", et pour le mélioratif utiliser "plusbon", "doubleplusbon"... C'est vrai quoi, qu'est-ce qu'on s'en fiche, d'avoir une langue française riche, certes, mais précise aussi ? A quoi ça sert ?
[^] # Re: sans vouloir faire l'oiseau de mauvaise augure...
Posté par lasher . En réponse à la dépêche Le format OpenDocument approuvé par l'ISO. Évalué à 2.
[^] # Re: Vers une meilleure intéropérabilité ?
Posté par lasher . En réponse à la dépêche Le format OpenDocument approuvé par l'ISO. Évalué à 3.
PS : comme il a été dit précédemment : standard != norme...
# [HS] Mais j'en ai un peu marre ....
Posté par lasher . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 10.
(c'est moi qui souligne)
Merci d'arrêter l'anglicisme "vendeur" (issu de "vendor"), et de remplacer par "fabriquant". C'est une manie qui devient de plus en plus courante, et à chaque fois j'ai l'impression que je vais avoir le monsieur de chez Darty qui va me filer une carte WiFi, ce qui est tout de même assez troublant ...
[^] # Re: Linux
Posté par lasher . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 5.
Par contre, si pour une "bête" carte réseau ethernet (sans fonctions de crypto intégrée en dur ou autres) la rédaction d'un pilote est rapide , autant pour une carte vidéo qui comporte énormément de circuits différents et spécialisés, ça risque de prendre plus de temps - notemment à cause du temps pris par des tests sérieux. Combien, je ne sais pas. :-)
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par lasher . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 2.
Sans doute parce que Linux a une visibilité bien plus grande qu'OpenBSD, que la base de développeurs pour le système est, elle aussi, bien plus grande, etc.
[^] # Re: Linux
Posté par lasher . En réponse à la dépêche Sortie d'OpenBSD 3.9. Évalué à 8.
Voyons voir ...
Driver Solaris, driver Linux, driver {DragonFly,Free,Net,Open}BSD, driver QNX, driver ...
Franchement, il serait plus simple de laisser le dév desdits drivers aux gens qui ont le plus l'habitude de bosser sur les systèmes précités... Sans parler du fait que certains aiment développer des drivers (si si), ou tout un tas d'autres trucs. :-)
[^] # Re: Bac +5 ? c'est idiot
Posté par lasher . En réponse à la dépêche Un Master en Ingénierie du Logiciel Libre. Évalué à 4.
Je me répète : ta façon de rédiger tes posts n'a rien à voir avec leur contenu. Je ne sais pas qui a tort ou raison. Ce que je sais, c'est que ce que tu affirmes ne m'est pas inconnu, et j'ai donc tendance à accorder du crédit à ce que tu dis. Sauf qu'avec ta façon condescendate et méprisante de répondre, tu en deviens désagréable.
Soit dit en passant, lorsque tu cites, merci de citer avec un minimum de contexte autour. Lorsque je dis que « à partir des années 90, l'avantage d'être informatisé commençait à se dessiner clairement. », le contexte est "je crois me souvenir qu'on m'avait dit dans mes cours que ..." Bref, tu cites comme si j'affirmais, alors que justement dans la suite de mon message précédent, je te propose de confirmer auprès de mes anciens profs.
« On notera que l'informatisation sans réorganisation et vice versa entraînent une perte de productivité. L'informatique apporte à elle seule aucun de gain de productivité. »
Quoi ? Tu veux dire qu'une technologie utilisée « brutalement », sans adapter un système à son fonctionnement ne fonctionne pas bien, voire rend les choses plus difficiles à réaliser ? Quelle surprise !
L'informatique est une technologie extrêmement récente, il me semble évident qu'il faut attendre un minimum de temps pour que son utilisation devienne non seulement aisée, mais efficace.
« La chose que je dit par rapport aux diplômes en informatique, c'est qu'à priori il n'est pas évident l'en prenant au hasard des gens diplomés dans cette discipline (sur une population ayant au moins deux ans de pratiques), on ait forcément des informaticiens *siginificativement* meilleurs professionellement parlant qu'en prenant n'importe qui »
Je ne suis pas d'accord. Enfin, plus exactement, je pense que cela dépend totalement du domaine en informatique où tu te places.
Si l'on parle d'administration système, je suis parfaitement d'accord, et d'une manière générale, dès qu'il s'agit d'informatique en tant qu'outil de gestion d'un système d'information, tu as parfaitement raison : on n'a pas besoin de faire des études poussées (et même, si l'on peut se permettre de se procurer les bons ouvrages, on a juste besoin d'un ordinateur à disposition et de beaucoup de patience).
Sauf que l'informatique n'est pas que de gestion. Il existe énormément de domaines (pas forcément très théoriques a priori) où le besoin d'avoir été formé dans des sciences fondamentales est extrêmement important :
- l'informatique embarquée ;
- les outils de modélisation de tous poils (simulateurs, émulateurs, logiciels de PAO/DAO/Machin-AO)
- les jeux vidéo (oui oui)
- les outils de traitement multimédia en règle générale
- etc.
Tous ces domaines (et bien d'autres encore) nécessitent de comprendre d'un point de vue scientifique ce qu'on programme. Alors bien sûr, il faut quelqu'un "au-dessus" pour superviser le tout, c'est évident. Il est aussi évident qu'il faut bien organiser la communication entre les différents développeurs, et autres personnes impliquées dans le projet, mais franchement, dans une entreprise, n'est-ce pas - justement - une évidence ? :-)
Une "simple" formation ne suffit pas pour cela. La formation en master/école d'ingénieur/etc permet de s'armer un peu mieux pour ce genre de choses, car en cinq ans, on a le temps d'aborder bien plus de sujets, et surtout, on a le temps d'approfondir. Franchement, mis à part les ingénieurs de recherche et les chercheurs eux-mêmes, tu connais beaucoup de gens qui continuent de se former sur des sciences "fondamentales" ou très théoriques ? Pourtant, c'est vital dans certains domaines. Donc puisque généralement, on ne revient plus en arrière pour se former dans les nouvelles théories en maths, physique, etc., autant bien se former dès le début, une fois pour toutes. Au moins il en restera quelque chose vingt ans (au moins une tournure d'esprit plutôt scientifique).
Un exemple très bête : un ancien collègue, très productif au demeurant, s'était mis au Java lors de la programmation d'une grosse application pour une grosse boite. Il connaissait bien le langage C, et avait déjà fait à plusieurs reprises des projets en C++ (enfin, de ce que j'ai compris).
Bien. Sauf qu'il continuait à programmer en Java comme on le ferait en C. Bien sûr, il se servait un minimum des mécanismes objet, mais il faisait ses exceptions "à la main", réinventait le goto dans un langage qui interdit son usage ... Bref, l'horreur pour qui a un minimum de connaissances en programmation orientée objet. Par contre comme architecte logiciel, chapeau, ça se voyait qu'il avait de l'expérience dans le domaine. Il était juste incapable de s'adapter à des techniques plus modernes (honnêtement, il avait 20 ans de retard concernant le génie logiciel "terre à terre", immédiat).
Voilà un ingénieur, de formation plus électronicienne qu'informaticienne (et pour cause, à l'époque, peu d'écoles proposaient une vraie formation en informatique), qui a fini par accuser les frameworks utilisés de ne pas permettre de maintenir correctement l'application en question - alors qu'en fait, c'était plus la méconnaissance des design patterns, et des frameworks en eux-mêmes qui avaient conduit à une usine à gaz difficilement maintenable. Alors oui, cette personne, si on lui donnait une formation continue, pourrait sans doute se mettre à jour concernant la POO.
Mais quand je vois le mal qu'on déjà certains étudiants lorsqu'on passe de la programmation procédurale à la programmation objet en IUT, alors qu'on ne parle même pas des "vrais" aspects théoriques et mathématiques qui se cachent derrière, permets-moi de douter de la capacité de tout un chacun à réaliser n'importe quel projet informatique. Une formation longue permet, selon moi, de rendre sa cervelle plus "flexible". Bien sûr, il existe tout un tas de gens qui sont déjà dans ce cas, sans diplôme, avec un diplôme bac +2/+3, etc., mais ils sont (bizarrement ? :-) ) beaucoup moins nombreux que ceux qui font quatre ou cinq ans d'études...
[^] # Re: Bac +5 ? c'est idiot
Posté par lasher . En réponse à la dépêche Un Master en Ingénierie du Logiciel Libre. Évalué à 5.
Non, ta façon d'écrire pue le mépris. Un grand diplômé qui prendrait le même ton recevrait le même accueil : tu es d'une condescendance crasse, à la limite de traiter à peu près tout le monde ici comme si l'on était des imbéciles.
Je connais en partie les ouvrages que tu cites (« Code Complete » est effectivement un excellent bouquin, et « The mythical man-month » aussi). Mais les agiter sous le nez des gens en disant "vous voyez, j'ai raison, vous avez tort, bande de minables" (oui, je sais, tu n'as traité personne de minable, mais parfois, les phrases sont elliptiques...), forcément, ça n'aide pas à soutenir ta thèse.
[moinssage]
« Par ailleurs, les responsables du master et de sa comm, et les partenaires industriels lisant le forum, il est assez rationnel qu'ils n'aient pas envie d'avoir de mauvais commentaires sur leur diplômes et leur initiative qui apparaissent sur le web, »
Si tu penses vraiment ça, c'est que tu es parano. Et un parfait imbécile (ça y est, je l'ai dit), ou alors très très malade.
Je ne vois pas en quoi les dires d'une seule personne, qui plus est en minorité concernant son opinion (puisqu'elle est plus ou moins toute seule contre tous) risquerait de faire du tort aux enseignants qui essaient de monter leur master.
Et cela n'a rien à voir avec qui a tort ou raison.
Bref.
En IUT nous avons parlé du fait que l'informatisation des entreprises n'était pas nécessairement un bienfait pour elles. Sauf que dans mon souvenir, mes profs d'éco/gestion/organisation nous disaient que justement, si jusque dans les années 80 c'était plutôt discutable, à partir des années 90, l'avantage d'être informatisé commençait à se dessiner clairement. Je n'ai aucune référence sur le sujet en question, mais je peux toujours recontacter mes anciens profs d'IUT si ça t'intéresse.
Concernant la formation : bien sûr, on peut "tout" apprendre dans les livres. Mais on oublie un truc : à ce train-là, on peut apprendre à peu près tout le savoir "scolaire" dans les livres. Ce qui est intéressant dans une formation, quelle qu'elle soit, c'est le fait que les enseignants qui y officient puissent permettre d'opérer des raccourcis, et d'épargner justement tout un tas de lectures (au moins dans un premier temps) à leurs élèves. En plus, une formation offre l'énorme avantage que contrairement aux livres, les profs répondent aux questions, eux.
En IUT génie info [de gestion], il est accordé une place aussi importante à l'étude du génie logiciel qu'à l'algorithmique/programmation et les cours de système en cumulé. Ce n'est pas pour rien : l'informatique de gestion nécessite effectivement une analyse et une planification toutes différentes d'autres projets informatiques.
Sauf que par exemple, en IUT génie électrique et informatique industrielle, on y fait aussi de l'informatique. D'un autre genre, certes, mais de l'informatique quand même. Le genre d'informatique qu'on retrouve dans les systèmes embarqués. Et là, il faut un autre genre d'informaticien. Je ne parle même pas des machins de technologie de pointe.
Tu peux cracher tant que tu veux sur les diplômes, mais quelqu'un ayant réussi à avoir un bac +5 dans le domaine de l'informatique répond à au moins l'un de ces deux critères :
1) Il a en fait un parcours plutôt "management", et a fait un à deux ans d'informatique pour pouvoir se spécialiser un peu ;
2) Il a fait de l'informatique à un certain niveau, et a un niveau de culture générale en sciences a priori suffisant pour pouvoir comprendre comment trouver et mettre en oeuvre des solutions techniques diverses et variées.
J'ai fait un IUT, puis une école d'ingénieur. Je te promets que la formation, aussi limitée puisse-t-elle paraître, permet à quelqu'un de motivé de réussir à faire de bien belles choses. Et là où c'est miraculeux, c'est que même quelqu'un qui n'est pas forcément passionné par l'informatique peut quand même en faire son métier car on lui a donné de bonnes méthodes pour réaliser un projet informatique ! (si si). A lui de les appliquer ensuite, bien sûr.
[^] # Re: /proc
Posté par lasher . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 3.
[^] # Re: Euh..
Posté par lasher . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 5.
[^] # Re: Comme dirait mon prof...
Posté par lasher . En réponse au journal Le laptop du MIT est indécent .... Évalué à 2.
http://www.langue-fr.net/index/A/apres-que.htm
[^] # Re: Comme dirait mon prof...
Posté par lasher . En réponse au journal Le laptop du MIT est indécent .... Évalué à 2.
Mouais. C'est surtout qu'il est bien plus naturel à l'oral de mettre un subjonctif derrière « après que ». D'ailleurs, je crois que c'est déjà déclaré comme toléré (sinon, ça ne saurait tarder).
[^] # Re: Mandriva plus
Posté par lasher . En réponse à la dépêche Mandriva licencie 18 personnes dont Gaël Duval. Évalué à 4.
tu places le binaire dans /opt (par exemple), tu tapes
sudo ./j2sdk-15blablabla
et puis ben, après c'est pas difficile, tu cliques :-)
Ah oui quand même, il ne faut pas oublier de rajouter /opt/j2sdk.../bin
à ton PATH.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par lasher . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
Et je réponds à nouveau que si tu cherches la récursivité, tu utilises des noeuds (donc des balises). D'un point de vue temps de définition, c'est à peu près équivalent (avec une DTD).
«
> Il faut comprendre justement comment les langages de navigation
> dans les arbres XML et les langages de requêtes sur XML infèrent
> les types.
Il doit manquer des mots ;-)
»
Euh non. :-)
En gros, un langage qui navigue dans un arbre XML, ou bien un langage qui effectue des requêtes dessus (et qui donc en fait, est bien obligé de naviguer dedans ;-) ) se doit d'être un minimum intelligent, sinon il va être assez inefficace :
- s'il considère le doc XML comme un fichier texte, il va juste se baser sur la notion de « bien formé » (une balise ouvrante possède un équivalent fermant) et à la limite, autant utiliser de bonnes vieilles regexps pour chercher l'info qui nous manque (bonjour le mal de crâne).
- sinon, il faut inférer le type de retour concernant la requête de navigation ou d'interrogation de ton doc en règle générale :
si on possède un schéma XML ou une DTD, ça signifie entre autres être capable de prédire (au moins en partie) si une partie du code de la requête examinée ne donnerait pas un résultat qui serait toujours faux (par exemple, demander de trouver une balise qui ne se trouve *jamais* dans une autre), et donc couper certaines branches de la recherche, histoire de gagner du temps. On évalue aussi le type "retour" que la requête devrait renvoyer, lorsqu'il s'agit d'une requête qui effectue des transformations sur un document XML.
Par exemple, on récupère l'ensemble des "//a/b" dans une variable $x et à chaque fois qu'on le trouve, on renvoie "<c>$x</c>". S'il se trouve que <c> ne contient *jamais* les balises contenues dans <b>, alors on peut d'ores et déjà invalider la requête. Le problème survient quand seulement une partie des balises contenues dans <c> se retrouvent dans <b> : là il faut analyser la réponse de la requête (évaluer son type), et comparer avec ce qui est attendu (le type de retour prévu).
«
> genre en XPath, si tu cherches /a//c[@d="untruc"],
Génial !
C'est pile ce que je critique. Le lien entre XPath et XML ?
»
Plus loin, tu te demandes en quoi XPath est spécifique à XML (exemple LISPien à l'appui)
Ma réponse est vraiment toute bête :
XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML fondamentalement. Un document XML, c'est un ensemble d'arbres ordonnés et étiquetés. Que sa représentation textuelle soit faite sous forme de balises ouvrantes et fermantes plutôt que sous formes de commandes TeXiennes (\etiquette{...}) ou LISPiennes ( (etiquette '(...)), ou ... on s'en fiche un peu.
NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas récursifs non plus, et qui - surprise ! - sont non ordonnés :
\documentclass[a4paper,12pt]{report}
Dès que tu as des [...], tu as un ensemble de mots-clef (donc non ordonnés, puisqu'il s'agit d'un ensemble).
Concernant le peu de ressemblance entre la syntaxe XPath et XML, c'est vrai. D'ailleurs XML Schema a été créé pour avoir un système de définition de types XML qui soit fait en XML, et pas avec un langage tiers (pas comme les DTD quoi). En pratique, un schéma XML un tant soit peu complexe est très chiant à lire pour un humain, alors qu'une DTD c'est déjà vachement plus simple (le problème c'est que c'est moins puissant, et donc lorsqu'on veut réaliser certaines choses, XML Schema est le seul recours).
Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les langages de transformation de XML ne ressemblent pas trop à du XML. Par exemple, XQuery utilise une syntaxe FLWR : for / let / where / order by . Et après ? XML est fait pour être lu par des machines. Par contre, les programmes qui manipulent les documents XML (pour rechercher, récupérer, transformer tout ou partie de ceux-ci) doivent être compréhensibles pour l'humain.
D'ailleurs, XSL/T, ça a beau être super puissant, c'est tellement chiant à utiliser que dès que je peux éviter ben... j'évite :-)
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par lasher . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
Mais avec XML on a perdu cette sémantique, »
Euh non. Contrairement à ce que vous semblez pensez tous les deux, les attributs sont typés. Ce ne sont pas de vulgaires chaînes de caractères (avec les DTD c'est pas facile à voir, je le reconnais, mais avec les schémas XML ça crève les yeux, puisqu'on peut leur affecter un type). De toute manière, il faut comprendre justement comment les langages de navigation dans les arbres XML et les langages de requêtes sur XML infèrent les types.
Si j'ai un noeud [a] qui contient un attribut @b, un bon langage de requête pourra inférer un certain type (a,b) (en simplifiant à l'extrême), et retrouvera ses petits tout en faisant quand même des optimisations - genre en XPath, si tu cherches /a//c[@d="untruc"], alors qu'on sait que le noeud [c] ne comporte pas d'attribut @d, on peut directement « défausser » la requête et même la considérer comme fausse.
Faut pas croire, les gens qui ont élaboré XML (et ceux qui continuent de bosser dessus) sont loin d'être bêtes.
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par lasher . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Je ne sais pas si c'est une spécialité de l'INRIA ou bien de la recherche dans les langages de programmation en général, mais j'ai l'impression que pas mal de langages issus de labos de recherche « remontent » les traitements au niveau sémantique ... Je pense entre autres à CDuce (http://www.cduce.org), un langage fonctionnel et généraliste à la ML qui a été créé pour traiter efficacement les transformations de documents XML. Là aussi, on a passé certains pans du langage au niveau sémantique (notamment le sous-typage qui est classiquement utilisé au niveau syntaxique, est « remonté » au niveau sémantique - et c'est le compilateur qui trouve tout seul comme un grand quel est le type d'une fonction donnée).
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par lasher . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 4.
<a href="http://debian.org">debian</a>
l'attribut href est une simple chaine, pas un arbre xml. »
Euh oui, mais là on VEUT que ce soit une chaîne ;-) (prendre mon exemple de date à contre-pied aurait sans doute été plus heureux, je trouve). Je ne vois pas trop où est le problème en fait. Qu'on parle XQuery ou XSL/T, on utilise XPath pour naviguer dans l'arbre XML. Je vois les attributs d'un noeud - pardon, d'une balise ;-) - comme étant des données propres à celle-ci. Exactement de la même manière que je peux avoir dans un arbre en C une structure noeud du genre
const unsigned int N = 100; /* arité */
typedef struct Noeud_
{
char *etiquette; /* type de noeud */
void *donnee; /* données spécifiques au noeud */
struct Noeud_ *noeuds[N]; /* fils du noeud */
} Noeud;
Dans ce cas, je peux créer un arbre N-aire, et dont les données sont parfaitement « génériques » : il suffit d'allouer assez de mémoire pour y faire tenir tous les « attributs » que je veux. :-)
Je ne vois pas ce qu'il y a de gênant avec ce genre de structures de données, en fait.
Reprenons ton exemple en LISP :
« (a (href "http://debian.org") "debian") »
Ici, il faut définir pour chaque balise une fonction particulière (puisqu'en LISP, une parenthèse ouvrante indique que le terme qui suit est une fonction). C'est particulièrement lourd, tu ne trouves pas ? Même en faisant des setq de partout, ça risque d'être un vrai casse-tête.
De plus, lorsque tu dis
« Bilan, les atributs sont gérés comme des arbres et leur valeur peut aussi être un arbre, donc bien plus typé qu'une chaine. »
En disant ça, tu ne fais que répéter ce que j'ai dit : si les attributs ne te plaisent pas, tu n'es pas obligé de les utiliser, et tu as tout à fait le droit de n'utiliser que des balises - car ce que tu proposes de faire en LISP revient exactement à ça. Si on a défini la notion d'attribut en-dehors des balises classiques, il y a quand même une raison. Et étant donné que tu définis lesdits attributs dans ta DTD ou ton schéma, tu ne perds absolument pas d'information de type.
Le gros problème d'XML en ce moment, selon moi, c'est que beaucoup d'outils existent, mais que les gens ne les utilisent pas forcément (je radote avec les histoires de DTD et de schémas XML ;-) ). Ou alors ils utilisent XML parce que ça fait bien, mais sans réel besoin : j'ai envie de flinguer à peu près tous les programmeurs qui utilisent XML pour faire des fichiers de config, par exemple. Si dans certains cas ça peut parfaitement se justifier (par exemple un fichier de config Apache en XML, ça ne changerait pas tellement du fichier de config original), dans la plupart des cas, une bête association clef-valeur(s) (éventuellement séparées par des virgules) est largement suffisante.
Là où XML devient intéressant, à mon avis, c'est lorsqu'on commence à traiter de gros volumes de données (et où on doit donc vraiment prendre en compte les types pour optimiser les recherches). Sinon, *bof*.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par lasher . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
Jusque là, je suis tout à fait d'accord. :-)
« Très verbeux, "chiant" à deboguer à la main... »
Euh oui, mais n'oublie pas un truc que tu as dit en tout premier, en haut de ton post : « Le XML est conçu pour la machine » !
« Il souffre surtout à mon avis d'une erreur de conception au niveau des attributs. En effet, il perds l'aspect récursif du LISP a ce niveau là, les attributs étant des chaines de textes entre "" et non du XML »
Là-dessus, je ne suis pas d'accord. Premièrement, si vraiment tu tiens à ne pas utiliser les attributs, tu n'as qu'à définir une balise « vide », dire quelle autre balise peut l'utiliser, et c'est fini (exemple pour XHTML : <br/>).
Deuxièmement, il faut voir les documents XML comme des arbres, dont les noeuds peuvent posséder, en plus de leurs enfants et de l'étiquette qui les identifie, une séquence de données supplémentaires : les attributs. Là où un document XML est un arbre ordonné, les attributs ont l'avantage de plutôt représenter un « ensemble » de données (non ordonnées, donc). Suivant l'usage dont tu as besoin, ça peut être très pratique. Par exemple, je trouve bien plus utile d'avoir une balise « vide » <date/>, avec comme obligation de comporter au moins un attribut « année » et comme attributs optionnels « mois » et « jour », que de définir la même balise comme étant composée de trois autres balises :
<!ELEMENT date (annee, mois?, jour?)>
De toute manière, on se fiche un peu de l'ordre dans lequel ils apparaissent, non ?
Si tu as besoin de l'aspect récursif des types XML, tu utilises les balises ; sinon, tu as le choix entre attributs et balises suivant que tu désires sous-typer ou pas ta structure de données.
« Bilan, il y a tout un tas d'API pour contourner ce problème de conception, »
Euh, tu dis que les API sont là pour contourner le fait que les attributs existent ? Ca me semble un peu irréel comme remarque, ça ! :-)
A moins d'utiliser les ID-REFs dans tes schémas XML, les documents XML sont strictement des arbres. Pas de risque de cycle, rien. Il y a tout plein de problèmes qui risquent de se poser pour faire l'analyse de docs XML, mais certainement pas les attributs !
« Le plus grave, c'est qu'on en a pris pour 20 ou 30 ans et que ca va nous faire chie... »
Meuh non. Premièrement, définir une DTD c'est chiant, mais ça n'a rien d'impossible (et c'est surtout ça le problème avec XML je trouve : le fait que les gens ne prennent pas la peine de définir correctement des DTD ou des schémas XML). Ensuite, il existe des outils pour exporter une DTD en schéma XML (car les DTD ont certaines limitations, mais sont, en contrepartie, relativement lisibles, comparées aux schémas XML).
Enfin, pour ceux qui l'ignoreraient, il existe un langage de requête, XQuery, qui possède déjà quelques implémentations, et qui a le gros avantage de prendre en compte le fait qu'un document XML est typé, et donc ne fait pas de recherche stupide lorsqu'il peut l'éviter.
Le XML est là en partie pour permettre de modéliser des choses qui le sont difficilement avec des systèmes de gestion de bases de données classiques (notamment relationnelles), ou bien au prix de certaines contorsions ou d'occupation excessive de la mémoire.
« Je ne suis pas programmeur et fanatique de LISP mais avec une syntaxe bien plus simple et récusive, tu refais tout XML en propre. »
Bof. Les données semi-structurées, ça fait un bout de temps que ça existe, sauf qu'avant, chacun avait son modèle dans son coin. Ce qu'apporte XML, c'est un compromis entre différents acteurs du monde industriel (Microsoft, Sun, etc.) et scientifiques (universités, INRIA, etc). Comme tous les compromis, il n'est pas parfait, car chacun voulait que « sa » killer-feature se retrouve dans le langage. Mais franchement, on n'en est qu'au début de l'exploitation d'XML. Laissez encore cinq ans aux différents acteurs pour élaborer des méthodes d'interrogation efficaces de XML, et on en reparlera.
[^] # Re: bof
Posté par lasher . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 7.
Mmmmh. Je m'en sers tous les jours en faisant des "cd ..", "cd /usr/share/doc", etc. Ah oui, et si tu manipules du XML, avec des requêtes XPath, ça peut être pas mal de comprendre comment fonctionne la structure d'un arbre. Ca peut aussi éclairer ta lanterne sur le fait qu'utiliser l'opérateur "//" doit être mûrement réfléchi.
« Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof. »
Idem pour les arbres (d'où ma référence à la glibc). Mais relis mieux ce que j'ai dit ensuite : le problème est de savoir utiliser les bons outils, et donc, connaître les forces et les faiblesses des structures de données manipulées.
« La plupart du temps quand on programme, cela tient plus de la recette de cuisine »
Euh. Tu te rends compte que ce que tu dis finalement, c'est « Puisque j'y arrive de cette manière, pourquoi j'essaierai d'apprendre à le faire d'une autre manière, aussi pratique soit-elle au final ? »
La programmation fonctionnelle est extrêmement puissante, permet de faire des programmes assez concis, et faciles à comprendre. Après, il est possible de faire de même en prog itérative, bien sûr. Mais il s'agit dans les deux cas d'outils à utiliser en fonction des besoins. Faire une IA en C est bien plus difficile que faire la même chose en LISP. Faire un programme sûr est bien plus facile avec un langage comme Java (qui est sûr du point de vue des types) qu'avec un langage de type C ou FORTRAN.
Dans tous les cas, la prog fonctionnelle n'est certainement pas plus compliquée à apprendre dans l'absolu que la prog itérative. D'ailleurs, si tu prends un langage comme Perl, il permet de faire les deux (en faisant une ou deux contorsions, c'est vrai).
[^] # Re: bof
Posté par lasher . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
1) Ouvre n'importe quel bouquin de niveau licence/maîtrise pour faire de l'algo.
2) Choisis les chapitres concernant les graphes et les arbres plus particulièrement.
3) Prends un algo au hasard.
4) Surprise ! L'algo est récursif. Et c'est carrément « naturel » de penser ainsi, soit dit en passant. L'alternative itérative est beaucoup moins facile à imaginer.
5) Réessaie avec le chapitre sur les tris efficaces (pire cas ou cas moyen). Retourner en 4 pour la conclusion.
Il faut évidemment nuancer tout ça : si l'algo en question est récursif terminal, il existe une version équivalente itérative, et on peut même s'amuser à automatiser la transformation (certains compilateurs le font dans les cas assez simples).
Par contre, une chose est certaine : autant l'approche récursive est tout à fait naturelle dans certaines structures de données (les structures ... récursives, tiens donc !), autant, pour un langage comme le C, la récursivité peut faire très mal (surtout si elle n'est pas terminale).
Moralité : il faut des mecs super balaises en algo/prog C pour élaborer des algos itératifs pour gérer les cas (cf. la glibc, par ex), sinon il y a risque de faire exploser la pile des variables automatiques.
Corollaire : les programmeurs « moyens » utilisent des structures de données comme on le leur a dit, sans vraiment leur expliquer comment elles fonctionnent, et du coup bousillent totalement les perfs d'un programme. Par exemple, ils ont l'habitude d'utiliser des listes d'éléments (en Java, C#, que sais-je), et n'ont jamais entendu parler des arbres rouge-noir (pourtant implémentés en tant que TreeMap en Java par ex). Résultat : ils vont se faire chier à faire des sortes de « tri par insertion » sur une liste, plutôt que d'utiliser une structure spécifiquement élaborée pour ce genre de cas.
Maintenant, un langage fonctionnel a beau avoir une approche plus « mathématique » de la programmation (pour la forme), je pense avoir eu autant de mal au début à comprendre comment faire des boucles for/while/do-while en Perl/C qu'à faire des récursions en LISP pour la première fois. Non, pire. Ca avait été plus dur, car comme on m'avait relativement bien formé à C, on n'avait cessé de me répéter : « la récursivité, c'est le Mal » (à cause du passage des paramètres par valeur, etc). Donc j'étais bien endoctriné.
[^] # Re: documentation et limites
Posté par lasher . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 6.
« On ne s'attardera pas non plus sur l'incapacité de Word de gérer les références aux figures, sections et tuttti quanti quand vous en insérez de nouvelles. Pitoyable. »
Euh, sans parler des plantages qui effectivement surviennent de temps à autres, lorsque j'ai vu des gens se servir de MS-Word, avec une vraie formation derrière, j'ai jamais vu de problème de génération de tables des matières, etc. . Ils lançaient la regénération automatique des différentes tables, et ça fonctionnait.
Comme je l'ai dit plus bas, c'est surtout la promesse débile qu'on a pas besoin de se coltiner de manuel avec MS-Word (au contraire de LaTeX, ou LyX) qui est stupide. On a toujours besoin d'apprendre à se servir d'un outil si l'on veut être performant avec. Et dans le cas de MS-Word, le temps qu'on passe à examiner les différentes boites de dialogue est extrêmement important (là où - au moins pour LaTeX - on le passe à piger les rudiments du langage - et 2 heures suffisent pour comprendre comment faire la même chose que MS-Word avec 2 h de cliquage intensif).
Sinon, MS-Word permet aussi de récupérer les fichiers perdus lors de crashes.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par lasher . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
C'est pourtant en grande partie le cas.
Généralement, je précise les en-têtes, les marges, simple/double colone, le titre, etc., dans le préembule, et ensuite, roulez jeunesse.
Ensuite, c'est évident qu'utiliser ViM / Emacs pour éditer du LaTeX permet d'aller super vite, vu que tout un tas de balises apparaissent automagiquement quand on connaît les bons raccourcis...
N'empêche : sous MS-Word/OOWriter, il faut maîtriser les styles pour arriver à faire à peu près ce que LaTeX permet de faire. Ensuite, c'est vrai, quand on est un gourou MS-Word/OOWriter ou un gourou LaTeX, on a généralement passé un certain temps sur le logiciel en question, on sait faire tout plein de trucs, et le résultat est plutôt bon dans les deux cas. Sauf que par la force des choses LaTeX « oblige » à apprendre un peu comment structurer son document, alors que les logiciels de traitement de texte incitent au départ à tout essayer ... et prendre de mauvaises habitudes...
[^] # Re: Mieux que le C
Posté par lasher . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.