« 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...
« 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)
[^] # 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.
[^] # 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 ?