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...
« Il y a des évolutions dans le sens du... "sens", pardon pour la tournure malheureuse, plutôt que de la technicité. Le but n'est pas de faire des bêtes de calcul, mais des gens qui savent ce qu'ils calculent, et comment calculer. »
Et je trouve ça assez bête. :-)
Avant de comprendre comment mon ordinateur fonctionnait, je l'ai utilisé (sous MS-DOS au départ, sous MS-Windows ensuite, puis enfin avec un mix Linux/MS-Windows/*BSD). Je n'ai commencé à réellement comprendre son fonctionnement que par hasard, dans mes cours d'électronique en 1ère.
Le côté calculatoire des maths en primaire et au collège est à mon avis un mal nécessaire. Le sens de ces opérations n'est compris que bien plus tard, et pour être franc, on aura toujours besoin de calcul mental dans la vie de tous les jours, alors que comprendre comment on obtient Z à partir de N, et tutti quanti, je ne vois pas trop l'intérêt autre que la culture générale pour tous ceux qui font des études non scientifiques [1].
Pour « savoir calculer », il faut calculer beaucoup, ça doit être limite un réflexe. Le « comment » vient bien plus tard. Nous percevons, nous utilisons tout un tas d'outils dans la vie de tous les jours, mais nous ne savons pas nécessairement comment ils fonctionnent, n'est-ce pas ?
Je suis loin de sous-estimer la capacité de compréhension des élèves de primaire. Je pense que justement, on a trop tendance à les sous-estimer, on ramène tout vers le bas. Mais une chose est certaine : malgré mon niveau moyen en maths, ce qui a fait que j'ai toujours réussi à m'en sortir jusqu'au bac, ça a été de faire des exercices encore et encore pour m'enfoncer la théorie dans la tête (bon en fait ce n'est pas tout à fait vrai, mais on va simplifier). Et ce qui m'a permis de bien comprendre, plus que tout, c'est de savoir bien lire, et de connaître mes quatre opérations.
Pour moi la primaire doit permettre d'avoir des bases si solides avec les maths « concrètes » que lorsqu'on aborde des domaines plus abstraits, on peut toujours se reposer dessus (je parle jusqu'au lycée).
Une sorte d'approche « bottom-up », si tu veux.
Pour faire une analogie, je vois la différence entre ceux qui apprennent « comment programmer » en Java, directement à un certain niveau d'abstraction, et ceux qui ont appris « par le bas », par exemple en ayant d'abord reçu un cours d'architecture des ordinateurs, en même temps que des cours de C.
C'est ce qui s'est passé dans mon cas : contrairement à certains cours, nous n'avons commencé à toucher les pointeurs que deux mois après avoir commencé l'algo/prog en C. Pourquoi ? Pour laisser le temps au prof d'archi de nous en montrer assez concernant les registres, la mémoire, les adresses, ... Et bizarrement, une fois ceci fait, lorsqu'on nous a parlé de pointeurs, a priori rien n'a semblé bizarre. « Ben oui, c'est comme en archi, quoi ». Avant cela, nous avions recours à des artifices pour les chaînes de caractères, la notion d'allocation dynamique n'était pas connue... Mais ce n'était pas grave.
En maths c'est pareil : on peut cacher une partie de la complexité des objets manipulés, car l'important ce sont les bases. Il sera toujours temps d'entrer plus en détails, de faire plus d'abstractions plus tard.
[1] Oui, je sais qu'en primaire et au collège, on n'explique pas comment on obtient l'un à partir de l'autre, c'est juste un exemple. :-)
« Sinon, autant n'autoriser que les abaques dans les concours scientifiques... »
Mais justement, rappelle-toi un peu ce que tu faisais au collège, comme maths. Je ne sais pas quel est ton âge, mais il y a un peu plus de dix ans, je n'ai réellement fait explicitement d'équations qu'à partir de la Quatrième (il y avait une sorte d'introduction en fin de cinquième si je me souviens bien - sans parler des opérations à « trous »).
Ce qu'on nous fait faire au collège en maths est hautement calculatoire jusqu'en cinquième (il s'agit finalement d'apprendre les bons mécanismes), sauf dans le cas de la géométrie (même si là encore, on ne fait pas réellement de démonstration...).
Même arrivés en quatrième ou troisième, le programme devient plus abstrait, mais justement, ce sont les briques de base qui vont permettre de comprendre une bonne partie de la suite (les équations et la façon de rédiger une réponse à un problème les mettant en oeuvre, etc.) ; je me vois mal introduire une facilité de calcul ou de résolution d'équation alors qu'on est justement là pour apprendre comment résoudre ce genre de problème.
« Ils leur apprennent le calcul, ET à se servir d'un tableur. »
« Une calculatrice, un tableur, c'est un outil. De toute façon pour s'en servir faut connaitre les bases, deviner en voyant un résultat si on a pas fait une erreur de frappe... »
« Tant mieux si on apprend au plus tôt à se servir d'un ordinateur. »
Je te conseille fortement de lire le document que j'ai référencé plus haut, notamment la partie concernant l'enseignement de l'informatique au collège et au lycée. Franchement, autant je comprends l'intérêt d'apprendre aux élève à se servir d'un ordinateur, autant je ne suis pas convaincu que ça doive se faire sur le temps des cours de maths. Comme il est évident que nous ne sommes pas tous égaux devant l'outil ordinateur (entre ceux qui ont un ordinateur et ceux qui n'en ont pas, déjà, on peut voir une certaine inégalité), je ne dis pas qu'il faut absolument bannir l'apprentissage de son utilisation dans un cadre scolaire. Par contre, utiliser l'ordinateur en maths, au collège, je trouve ça très très dangereux. Au lycée aussi, d'ailleurs.
C'est assez marrant, lorsque j'étais au collège, il nous était interdit d'utiliser une calculatrice graphique. Même en Seconde, ça nous était interdit. Ce n'est qu'une fois arrivé en section scientifique qu'on m'a autorisé à l'utiliser. Et je trouve ça particulièrement sain : ici, la calculatrice nous a aidé pour comprendre le comportement de fonctions. Mais même comme ça, ça ne m'a pas dispensé de devoir tracer les courbes moi-même...
Honnêtement, vue la teneur des programmes de maths entre la 6è et la 2nde, je ne vois pas vraiment ce qui justifie l'utilisation d'un ordinateur pour calculer quoi que ce soit.
Pire : les gens qui font une prépa ou un DEUG MIAS, à ma connaissance, n'ont droit à rien de plus qu'une calculatrice graphique. Il y a bien une partie « informatique », mais il s'agit de « vraie » informatique théorique (avec Maple, Pascal, ou OCaml, par ex).
« De toutes façons, le tableur se prête très bien à cet usage. Ça apporte énormément aux élèves pour la compréhension des fonctions, le développement des procédures de calculs, la recherche par tatonnement. »
Il n'y a que moi que cette phrase fait tiquer ?
Le tâtonnement c'est bien, mais tant qu'on reste au niveau collège-lycée, j'estime que les maths ont un niveau encore assez bas pour que ce dernier se fasse à la main !
Je ne vois objectivement pas comment laisser une machine faire les calculs à ma place pourrait m'aider en quoi que ce soit pour de l'apprentissage. Surtout au collège ou au lycée.
Il est signé par de très grands mathématiciens (beaucoup, comme Laurent Lafforgue, ont obtenu la médaille Fields).
Le texte est éloquent, et même si je ne suis pas forcément d'accord avec tout ce qui y est dit, dans les grandes lignes, je le trouve extrêmement pertinent (et pas forcément si grandes que ça, les lignes).
Bref. Ca n'enlève rien à l'initiative louable de faire un manuel libre. C'est surtout que l'on ait décidé d'apprendre les maths aux élèves en leur faisant sauter l'étape « calculatoire » qui est extrêmement formatrice, qui me gêne - et ça, les rédacteurs du manuel n'y peuvent rien.
Même Fabius devient un ultra de gauche.
Fabius ? Un ultra de gauche ? Pardon ? Fabius est un opportuniste, qui a bien compris une chose : Jospin s'est planté en 2002 parce qu'il a dit tout haut ce que son gouvernement ("ancien" et "futur") savait déjà : ils n'allaient pas faire de politique économique de gauche. Et il y a perdu son électorat (sans parler de sa guéguerre débile contre Chirac).
Fabius surfe sur ce besoin d'avoir une gauche "vraiment à gauche", justement. Parce que c'est pas avec DSK qu'on peut dire qu'elle l'était, niveau économie.
Quand on voit que dans beaucoup de pays (USA, RU, Allemagne, Italie) ce qui est appelé "gauche" est plus proche de Bayrou voire Villepin que de Hollande ou Fabius...
Je te renvoie à ce que disait Rocard sur le sujet en décembre 2004, où justement il explique que non, au PS en France, ça fait un moment qu'on a accepté l'économie de marché, et qu'on n'est pas du tout en retard sur les autres partis "socialisant" européens.
Chose amusante : dans les autres pays du monde, droite=conservateurs, gauche=travaillistes/libéraux.
Euh, c'est pas parce que "libéral" en français (la langue) veut dire une certaine chose que ça doit forcément vouloir dire la même dans les autres langues (au hasard, aux USA). La notion de faux-ami n'a pas disparue du jour au lendemain, que je sache.
D'ailleurs, les journalistes français parlent bien de parti "démocrate" et "républicain" qd ils parlent des EU, c'est pas pour rien.
« Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer. »
Ben euh... Au moins la « threadification », le compilateur peut faire quelque chose...
« Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme. »
C'est dommage. Si un compilateur est capable, moyennant un léger surcoût à la compilation, d'extraire les instructions indépendantes, je ne vois pas pourquoi on ne pourrait pas en profiter pour paralléliser automatiquement le programme (création de pipelines logiciels, déroulage de boucles, déroulage/fusion, etc)
« Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P »
Euh, je n'utilise jamais -ansi, parce que de toute manière je serais obligé de définir certaines macros spécifiques à GCC, alors autant garder l'environnement de base. Mais je ne vois pas en quoi --pedantic est une option d'extrêmiste.
-Wall -W -pedantic
me semblent les options minimales pour qui veut faire un code un minimum correct (éventuellement avec l'option -std=c99 histoire de se mettre au goût du jour - mais bon, comme GCC n'implémente pas toutes les options de C99, ce sera du C99--).
« Que des tonnes de mongoliens adorateurs de \emph (dont je fais(ais) partie) continue le culte du cadavre, c'est normal. Ca peut meme durer 2000 ans. »
C'est marrant, quel que soit l'éditeur de texte choisi (dans ViM et Emacs c'est certain, et j'ai vu des plugins pour d'autres éditeurs aussi), il y a tout un tas de facilités qui existent pour justement éviter de taper \emph{} et autres {\tt } à la main. Au hasard, je tape SSS et paf! un joli \subsection{} apparaît dans ViM. C'est sûr, ça doit prendre environ 0,1 seconde de plus que de faire un ctrl-G dans OOo.
Maintenant, tu peux dire ce que tu veux sur Latex, que c'est pourri, que ça n'a plus d'avenir, etc. Le langage TeX et les macros LaTeX n'évoluent plus ? C'est possible (même si un jour ils finiront par le sortir, leur Latex 3 !)
J'espère à ce moment-là, que tu es aussi d'avis de rendre le langage C obsolète au profit de langages de type Ruby, OCaml, squeak, etc.. (j'ai fait exprès de mettre tout un tas de langages interprétés dans le lot, mais mettez n'importe quel langage compilé qui possède une vérification des types plus forte que celle de C - au hasard C++ - et c'est bon aussi). Sauf pour ce qui est du très bas niveau, bien sûr.
Parce que bon, C99 existe, c'est vrai, et certaines évolutions peuvent être considérées comme "majeures", mais sont pour beaucoup des ajouts récupérés depuis d'autres langages plus évolués. Et avant d'avoir une norme ISO 99, nous avons eu pendant près de 10 ans une norme 89, et pendant près de 20 ans auparavant, pas de norme du tout, avec des extensions spécifiques à un compilateur à tous les coins.
Qu'on soit bien d'accord, je ne dis pas que Latex est LE truc ultime pour tout. Mais l'exemple de Beamer (qui n'est finalement, rien d'autre qu'un jeu de macros au-dessus des macros Latex) permet de vraiment faire de belles présentations. Bon ben, entre une présentation OOo/PowerPoint et une présentation Beamer, j'ai choisi mon camp.
Dire que Latex n'évolue pas, alors qu'il existe tout un tas de packages qui permettent au contraire de ne pas avoir à se taper le Latex Companion de A à Z, je trouve ça assez fort.
[^] # 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.
[^] # Re: Surpris
Posté par lasher . En réponse à la dépêche Un manuel scolaire libre. Évalué à 2.
Et je trouve ça assez bête. :-)
Avant de comprendre comment mon ordinateur fonctionnait, je l'ai utilisé (sous MS-DOS au départ, sous MS-Windows ensuite, puis enfin avec un mix Linux/MS-Windows/*BSD). Je n'ai commencé à réellement comprendre son fonctionnement que par hasard, dans mes cours d'électronique en 1ère.
Le côté calculatoire des maths en primaire et au collège est à mon avis un mal nécessaire. Le sens de ces opérations n'est compris que bien plus tard, et pour être franc, on aura toujours besoin de calcul mental dans la vie de tous les jours, alors que comprendre comment on obtient Z à partir de N, et tutti quanti, je ne vois pas trop l'intérêt autre que la culture générale pour tous ceux qui font des études non scientifiques [1].
Pour « savoir calculer », il faut calculer beaucoup, ça doit être limite un réflexe. Le « comment » vient bien plus tard. Nous percevons, nous utilisons tout un tas d'outils dans la vie de tous les jours, mais nous ne savons pas nécessairement comment ils fonctionnent, n'est-ce pas ?
Je suis loin de sous-estimer la capacité de compréhension des élèves de primaire. Je pense que justement, on a trop tendance à les sous-estimer, on ramène tout vers le bas. Mais une chose est certaine : malgré mon niveau moyen en maths, ce qui a fait que j'ai toujours réussi à m'en sortir jusqu'au bac, ça a été de faire des exercices encore et encore pour m'enfoncer la théorie dans la tête (bon en fait ce n'est pas tout à fait vrai, mais on va simplifier). Et ce qui m'a permis de bien comprendre, plus que tout, c'est de savoir bien lire, et de connaître mes quatre opérations.
Pour moi la primaire doit permettre d'avoir des bases si solides avec les maths « concrètes » que lorsqu'on aborde des domaines plus abstraits, on peut toujours se reposer dessus (je parle jusqu'au lycée).
Une sorte d'approche « bottom-up », si tu veux.
Pour faire une analogie, je vois la différence entre ceux qui apprennent « comment programmer » en Java, directement à un certain niveau d'abstraction, et ceux qui ont appris « par le bas », par exemple en ayant d'abord reçu un cours d'architecture des ordinateurs, en même temps que des cours de C.
C'est ce qui s'est passé dans mon cas : contrairement à certains cours, nous n'avons commencé à toucher les pointeurs que deux mois après avoir commencé l'algo/prog en C. Pourquoi ? Pour laisser le temps au prof d'archi de nous en montrer assez concernant les registres, la mémoire, les adresses, ... Et bizarrement, une fois ceci fait, lorsqu'on nous a parlé de pointeurs, a priori rien n'a semblé bizarre. « Ben oui, c'est comme en archi, quoi ». Avant cela, nous avions recours à des artifices pour les chaînes de caractères, la notion d'allocation dynamique n'était pas connue... Mais ce n'était pas grave.
En maths c'est pareil : on peut cacher une partie de la complexité des objets manipulés, car l'important ce sont les bases. Il sera toujours temps d'entrer plus en détails, de faire plus d'abstractions plus tard.
[1] Oui, je sais qu'en primaire et au collège, on n'explique pas comment on obtient l'un à partir de l'autre, c'est juste un exemple. :-)
[^] # Re: Surpris
Posté par lasher . En réponse à la dépêche Un manuel scolaire libre. Évalué à 1.
Mais justement, rappelle-toi un peu ce que tu faisais au collège, comme maths. Je ne sais pas quel est ton âge, mais il y a un peu plus de dix ans, je n'ai réellement fait explicitement d'équations qu'à partir de la Quatrième (il y avait une sorte d'introduction en fin de cinquième si je me souviens bien - sans parler des opérations à « trous »).
Ce qu'on nous fait faire au collège en maths est hautement calculatoire jusqu'en cinquième (il s'agit finalement d'apprendre les bons mécanismes), sauf dans le cas de la géométrie (même si là encore, on ne fait pas réellement de démonstration...).
Même arrivés en quatrième ou troisième, le programme devient plus abstrait, mais justement, ce sont les briques de base qui vont permettre de comprendre une bonne partie de la suite (les équations et la façon de rédiger une réponse à un problème les mettant en oeuvre, etc.) ; je me vois mal introduire une facilité de calcul ou de résolution d'équation alors qu'on est justement là pour apprendre comment résoudre ce genre de problème.
[^] # Re: Surpris
Posté par lasher . En réponse à la dépêche Un manuel scolaire libre. Évalué à 3.
« Une calculatrice, un tableur, c'est un outil. De toute façon pour s'en servir faut connaitre les bases, deviner en voyant un résultat si on a pas fait une erreur de frappe... »
« Tant mieux si on apprend au plus tôt à se servir d'un ordinateur. »
Je te conseille fortement de lire le document que j'ai référencé plus haut, notamment la partie concernant l'enseignement de l'informatique au collège et au lycée. Franchement, autant je comprends l'intérêt d'apprendre aux élève à se servir d'un ordinateur, autant je ne suis pas convaincu que ça doive se faire sur le temps des cours de maths. Comme il est évident que nous ne sommes pas tous égaux devant l'outil ordinateur (entre ceux qui ont un ordinateur et ceux qui n'en ont pas, déjà, on peut voir une certaine inégalité), je ne dis pas qu'il faut absolument bannir l'apprentissage de son utilisation dans un cadre scolaire. Par contre, utiliser l'ordinateur en maths, au collège, je trouve ça très très dangereux. Au lycée aussi, d'ailleurs.
C'est assez marrant, lorsque j'étais au collège, il nous était interdit d'utiliser une calculatrice graphique. Même en Seconde, ça nous était interdit. Ce n'est qu'une fois arrivé en section scientifique qu'on m'a autorisé à l'utiliser. Et je trouve ça particulièrement sain : ici, la calculatrice nous a aidé pour comprendre le comportement de fonctions. Mais même comme ça, ça ne m'a pas dispensé de devoir tracer les courbes moi-même...
Honnêtement, vue la teneur des programmes de maths entre la 6è et la 2nde, je ne vois pas vraiment ce qui justifie l'utilisation d'un ordinateur pour calculer quoi que ce soit.
Pire : les gens qui font une prépa ou un DEUG MIAS, à ma connaissance, n'ont droit à rien de plus qu'une calculatrice graphique. Il y a bien une partie « informatique », mais il s'agit de « vraie » informatique théorique (avec Maple, Pascal, ou OCaml, par ex).
[^] # Re: Surpris
Posté par lasher . En réponse à la dépêche Un manuel scolaire libre. Évalué à 4.
Il n'y a que moi que cette phrase fait tiquer ?
Le tâtonnement c'est bien, mais tant qu'on reste au niveau collège-lycée, j'estime que les maths ont un niveau encore assez bas pour que ce dernier se fasse à la main !
Je ne vois objectivement pas comment laisser une machine faire les calculs à ma place pourrait m'aider en quoi que ce soit pour de l'apprentissage. Surtout au collège ou au lycée.
Je recommande vivement la lecture du présent ouvrage (collectif) :
http://www.ihes.fr/%7elafforgue/textes/SavoirsFondamentaux.p(...)
Il est signé par de très grands mathématiciens (beaucoup, comme Laurent Lafforgue, ont obtenu la médaille Fields).
Le texte est éloquent, et même si je ne suis pas forcément d'accord avec tout ce qui y est dit, dans les grandes lignes, je le trouve extrêmement pertinent (et pas forcément si grandes que ça, les lignes).
Bref. Ca n'enlève rien à l'initiative louable de faire un manuel libre. C'est surtout que l'on ait décidé d'apprendre les maths aux élèves en leur faisant sauter l'étape « calculatoire » qui est extrêmement formatrice, qui me gêne - et ça, les rédacteurs du manuel n'y peuvent rien.
[^] # Re: Bon
Posté par lasher . En réponse au journal Bayrou défendra le logiciel libre à l'Assemblé Nationale. Évalué à 10.
Fabius ? Un ultra de gauche ? Pardon ? Fabius est un opportuniste, qui a bien compris une chose : Jospin s'est planté en 2002 parce qu'il a dit tout haut ce que son gouvernement ("ancien" et "futur") savait déjà : ils n'allaient pas faire de politique économique de gauche. Et il y a perdu son électorat (sans parler de sa guéguerre débile contre Chirac).
Fabius surfe sur ce besoin d'avoir une gauche "vraiment à gauche", justement. Parce que c'est pas avec DSK qu'on peut dire qu'elle l'était, niveau économie.
Quand on voit que dans beaucoup de pays (USA, RU, Allemagne, Italie) ce qui est appelé "gauche" est plus proche de Bayrou voire Villepin que de Hollande ou Fabius...
Je te renvoie à ce que disait Rocard sur le sujet en décembre 2004, où justement il explique que non, au PS en France, ça fait un moment qu'on a accepté l'économie de marché, et qu'on n'est pas du tout en retard sur les autres partis "socialisant" européens.
cf. : http://www.diffusion.ens.fr/index.php?res=conf&idconf=49(...)
Chose amusante : dans les autres pays du monde, droite=conservateurs, gauche=travaillistes/libéraux.
Euh, c'est pas parce que "libéral" en français (la langue) veut dire une certaine chose que ça doit forcément vouloir dire la même dans les autres langues (au hasard, aux USA). La notion de faux-ami n'a pas disparue du jour au lendemain, que je sache.
D'ailleurs, les journalistes français parlent bien de parti "démocrate" et "républicain" qd ils parlent des EU, c'est pas pour rien.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par lasher . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 2.
Ben euh... Au moins la « threadification », le compilateur peut faire quelque chose...
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par lasher . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 4.
C'est dommage. Si un compilateur est capable, moyennant un léger surcoût à la compilation, d'extraire les instructions indépendantes, je ne vois pas pourquoi on ne pourrait pas en profiter pour paralléliser automatiquement le programme (création de pipelines logiciels, déroulage de boucles, déroulage/fusion, etc)
[^] # Re: Esperons que la qualité suivra
Posté par lasher . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 10.
Tu veux dire, mis à part les fonctions de 4000 lignes et les hacks qu'on retrouve dans tous les sens ?
[^] # Re: Esperons que la qualité suivra
Posté par lasher . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 7.
Euh, je n'utilise jamais -ansi, parce que de toute manière je serais obligé de définir certaines macros spécifiques à GCC, alors autant garder l'environnement de base. Mais je ne vois pas en quoi --pedantic est une option d'extrêmiste.
-Wall -W -pedantic
me semblent les options minimales pour qui veut faire un code un minimum correct (éventuellement avec l'option -std=c99 histoire de se mettre au goût du jour - mais bon, comme GCC n'implémente pas toutes les options de C99, ce sera du C99--).
[^] # Re: Hum
Posté par lasher . En réponse à la dépêche Disparition de M. Gilles KAHN, Président de l'INRIA, membre de l'Académie des Sciences. Évalué à 0.
C'est marrant, quel que soit l'éditeur de texte choisi (dans ViM et Emacs c'est certain, et j'ai vu des plugins pour d'autres éditeurs aussi), il y a tout un tas de facilités qui existent pour justement éviter de taper \emph{} et autres {\tt } à la main. Au hasard, je tape SSS et paf! un joli \subsection{} apparaît dans ViM. C'est sûr, ça doit prendre environ 0,1 seconde de plus que de faire un ctrl-G dans OOo.
Maintenant, tu peux dire ce que tu veux sur Latex, que c'est pourri, que ça n'a plus d'avenir, etc. Le langage TeX et les macros LaTeX n'évoluent plus ? C'est possible (même si un jour ils finiront par le sortir, leur Latex 3 !)
J'espère à ce moment-là, que tu es aussi d'avis de rendre le langage C obsolète au profit de langages de type Ruby, OCaml, squeak, etc.. (j'ai fait exprès de mettre tout un tas de langages interprétés dans le lot, mais mettez n'importe quel langage compilé qui possède une vérification des types plus forte que celle de C - au hasard C++ - et c'est bon aussi). Sauf pour ce qui est du très bas niveau, bien sûr.
Parce que bon, C99 existe, c'est vrai, et certaines évolutions peuvent être considérées comme "majeures", mais sont pour beaucoup des ajouts récupérés depuis d'autres langages plus évolués. Et avant d'avoir une norme ISO 99, nous avons eu pendant près de 10 ans une norme 89, et pendant près de 20 ans auparavant, pas de norme du tout, avec des extensions spécifiques à un compilateur à tous les coins.
Qu'on soit bien d'accord, je ne dis pas que Latex est LE truc ultime pour tout. Mais l'exemple de Beamer (qui n'est finalement, rien d'autre qu'un jeu de macros au-dessus des macros Latex) permet de vraiment faire de belles présentations. Bon ben, entre une présentation OOo/PowerPoint et une présentation Beamer, j'ai choisi mon camp.
Dire que Latex n'évolue pas, alors qu'il existe tout un tas de packages qui permettent au contraire de ne pas avoir à se taper le Latex Companion de A à Z, je trouve ça assez fort.