> Euh non. Contrairement à ce que vous semblez pensez tous les
> deux, les attributs sont typés
Je dis que la syntaxe des attributs n'est pas un arbre XML donc on perds la recursivité. Si tu penses que c'est bien, tant mieux pour toi. Personnellement, je trouve cela dommageable. Tant qu'on m'en a pas démontrer le contraire, je persiste à penser que c'est une erreur de conception.
> 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 ;-)
J'ai fait pas mal de sites web basés sur XML avec une bonne séparation forme fond avec AxKit. Bref, je ne suis pas complètement nul même si je ne suis pas spécialiste.
> 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 ? Syntaxe complètement différentes... Tu pourrais tout a fais appliquer XPath sur tout autre chose que le XML. Le XPath est une API de recherche dans un arbre. Ca marcherait tout aussi sur ma structure a base de parenthèse basé sur du LISP !
> Faut pas croire, les gens qui ont élaboré XML (et ceux qui
> continuent de bosser dessus) sont loin d'être bêtes.
Je n'ai jamais dis que c'etait des idiots. Une bonne partie de ces personnes venaient du SGML qui comme usine a gas est pas mal aussi ;-) Avec des raisonnements pareil, les choses n'evoluent pas.
Je reste persuadé que Knuth a été bien plus génial avec son TeX.
Je reprend ton exemple XPath avec une syntaxe LISP
En Eiffel, le concept objet est poussé a l'extrème. On le voit par exemple dans la proposition pour faire du parallélisme SCOOP (toujours aucune implémentation...).
En Sather, les concepteurs ont essayé d'orthogonaliser au maximun les concepts afin de les rendre le plus possible indépendant (concept d'orthogonalisation, si tu déplaces sur un axe, tu restes immobile sur un autre).
Donc, le concept d'héritage est divisé en deux : héritage d'interface et héritage de code. L'héritage d'interface suis le principe classique de la programmation objet lorsqu'une classe hérite d'une autre. Cependant, en Sather, elle n'hérite d'aucun code ! Il faut écrire explicitement l'héritage de code via le mot clef "include". Du coup, cela résoud très proprement les problèmes d'héritage multiple (au niveau des appels de méthodes, notament de même nom), a vrai dire, cela parait tellement simple qu'il n'y a plus de problèmes.
L'arbre des classe est très simple et permet le "supertyping". On peux créer une classe et dire que des classes déjà implémenté hérite de celle-ci !! C'est absolument génial pour étendre une librairie toute faite ou en corrigé des manques (inévitables).
Au niveau du parallélisme, les concepts en jeu sont a 100 lieu de SCOOP mais ca marche (enfin, ca marchait) et c'est clair à comprendre et a utiliser. Il y a même une extension "cluster" ou tu peux rajouter à toute instruction la chaine '@numerodunoeud" ou tu impose le noeud du cluster. Ca marche même sur les structures de donnée comme un tableau dont les éléments seraient physiquement imposés par le programmeur sur les différents noeuds du cluster.
Pour faire des boucles "loop do done", il y a un concept d'iterateur basé sur la notion de coroutine. Grace a ce concept, on évite l'usine a gas de la double structure de classe pour les conteneurs de données. L'arbre des classes n'en ai que plus simple. Grace a ce concept d'itérateur indépendant de le notion de classe et d'objet mais de même niveau que la notion de méthode, on divise par deux le nombre de classe (j'exagère) et on simplifie énormément les implémentations, laissant le compilateur optimisé le code ;-)
Bref, le langage a quelques defauts mais comme l'équipe qui l'avait développé faisait du calcul parrallèle, ils ont privilégié la simplicité et l'efficacité. Au final, on a un langage efficasse qui est un cousin d'Eiffel mais particulièrement attachant.
> Ici, il faut définir pour chaque balise une fonction particulière
Non, j'ai écris avec une syntaxe LISP mais si mes souvenirs sont bons, il faut mettre une apostrophe devant (scheme) pour dire que c'est une struture de données.
'(a (href "http://debian.org") "debian")
Bref, je ne parle pas de fonction LISP mais de structure de donnees LISP.
> 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,
Je ne dis pas que je n'aime pas les attributs, je dis que la syntaxe n'est pas bonne. Dans mon exemple, l'attribut est en second, le contenu en troisième. Il y a bien une différence sémantique entre les attributs et le contenu.
Je me demande pourquoi se limiter a des attributs de type chaine ? Avec une vrai structure bien pensée, le contenu est un arbre et l'attribut peux aussi etre un arbre, donc une structure complexe, chose non possible aujourd'hui avec le XML au niveau des attributs.
Par exemple, la chaine href ici, tu dis que c'est une chaine. Mais en pratique, c'est une URL. On pourrait donc très bien la valider sous une forme d'URL dans le schéma en séparant le protocole (http), le serveur (debian.org) , le dossier (/)... En XML, si tu veux faire cela, tu es obligé de passer par le contenu car via les attributs, la structure de données est trop faible.
> 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
La, je te plussoie a 100%. D'abord pour les fichiers de config, le YAML est souvent très bien. J'avoue que je déteste me tapper un XML pour configurer un logiciel.
l'attribut href est une simple chaine, pas un arbre xml. Du coup, pour injecter un truc dedans via un moteur, xslt par exemple, on a tout un tas de truc pour transformer un bout d'arbre xml en attribut et reciproquement.
Je reprend la meme chose avec un syntaxe LISP (dont je ne suis pas fanatique)
(a (href "http://debian.org") "debian")
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. les atributs sont en seconde position et les valeurs en troisième. Le modèle est bien plus simple.
La structure d'arbre du XML a été cassé au niveau des attributs. C'est dommage, car une partie de récursivité est par la même perdus et donc pour s'en sortir, les API sont plus complexes.
Tout cela n'est que reflexion personnelle. Je ne me fait aucune illusion. Ce n'est pas ces quelques lignes qui vont modifier la trajectoire du XML. Je lui souhaite bonne chance.
> Le nommage des packages n'est pas basé sur le DNS, c'est un
> conseil de Sun de nommer ses packages en utilisant un nom de
> domaine qu'on possède afin de limiter au maximum les collisions
C'est ca que je reproche. Lorsque j'ai vu ca la première fois il y a ... au début de java, je me suis dis, les autres sont des idiots, cette idée est géniale.
Et bien non. Cela cloisonne les projets. En pratique, les personnes mettent effectivement le domaine dns à l'envers. On a un espace de nom qui ne veut rien dire avec des org.machin.toto...
Si tu regardes un peu du coté du CPAN, on ne perds pas son temps dans des org.machin.toto, on va directement au but et toutes les personnes du monde se partagent le MEME espace de nom. Et ca marche FORMIDABLEMENT bien. Il n'y a AUNCUNE collision !
Pourquoi, parce qu'il y a un CPAN ou tout le code de tous les modules écrit et voulant être mutualisé se trouve.
Bref, le systeme d'un seul espace de nom pousse a la mutualisation du code. Celui qui ne veut pas mutualisé peut avoir un jour un risque de collusion, tant pis pour lui (en java, c'est la meme chose pour ce point la).
Comme le code n'est pas centralisé en java, si tu veux prendre des packages d'un autre esapce de nom org.truc.titi par exemple, qu'est ce qui t'assures que ce bout de code sera encore valable dans six mois ? Bilan, tu recopies voire tu remet tout dans ton espace de nom.
Dernier point, comme chacun travaille dans son espace, si tu travaille sur un module qui fait du ping et un autre qui fait du telnet, tu peux avoir un
Comme machin et truc son dans deux esapce de nom différent, il est certain qu'il n'y a pas d'homogénéité dans la philosophie des modules ping et telnet. Au niveau du code, c'est aussi pas super explicites. On ferait un
import net.ping
import net.telnet
Ce serait quand meme bien mieux.
Ensuite, se tapper les org.machin... a chaque fois est pénible, du coup on voit souvent dans les sources des
import org.machine.*
Et ca, ca devrait être interdit par le langage. Surtout que si il y a plusieurs import de ce type et que les API sont étendues, le code peux ne plus compiler !
Un des problèmes des langages objets et que cela devient lourd parfois de faire des choses très simple. Par exemple écrire sur la sortie standard. Sans ce * dans les import en java, c'est très lourd. C'est là ou Sather a une solution GENIALE. Il y a deux classes à la racine : IN et OUT, et il y a un raccourci pour faire appel a la méthode create (ou new du C++), il suffit de mettre un # devant la classe. Donc
#OUT == OUT.create
Avec ca, écrire sur la sortie standard en pur objet tout en restant humain se fait par la seule ligne
#OUT + "hello world !\n"
On instancie la classe OUT, on appelle la méthode + sur cet objet et c'est tout !
> package : accessible uniquement depuis les instances des
> classes du même package
Désolé de mon ignorance sur ce point là. Un package est'il extensible ? Est'il lié à la notion d'espace de nom.
Mon idée est la suivante. Je veux une classe interne a mon espace de nom. En effet, elle n'a aucun intérêt a être public et je veux pouvoir modifier son API.
Mais si une autre personne étend mon espace de nom en rajoutant des classes, il a bien sur le droit d'y avoir accès puisqu'il travaille sur le même thème. Cependant, dans le contrat social implicite, il sais qu'il doit suivre la philosophie de l'espace de nom et s'adapter au changement des API interne à l'espace.
En fait, le choix de l'espace de nom, de faire un CPAN... ont plus un impact sociologoique que technique. En inscrivant dès le départ ce choix dans le langage, on inscrit le projet dans un mouvement communautaire et plutôt lié au libre. Après, la sauce marche ou ne marche pas. Dans un cadre de type INRIA, c'est intéressant de mettre ce type de base car cela évite que des pontes au dessus ai des vues plus monétaires des choses. Une fois la dynamique lancée, ils sont coincés (c'est comme ca qu'un copain a pu sauver son projet libre qui marche relativement bien et que l'université voulait récupérer a son profit).
> il y a correspondance entre chemin et nom de package. Par
> exemple la Classe org.linuxfr.Main sera dans le fichier
> org/linuxfr/Main.java
Heureusement, il faudrait être fou pour proposer un autre système... bien qu'en ada avec gnat, on a le choix de pouvoir mettre des tirets à la place des slash et donc de tout avoir à plat dans le même dossier.
> Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl
> ou en Java.
En Perl, il n'y a pas d'import. D'ailleurs, les import sont un truc pourri. Le seul intérêt est d'éviter d'écrire le chemin complet lorsqu'on instancie un objet. Mais le code peux ne plus compilé un jour si on fait un import * come en java ou en python.
En Perl, on fait des use ou des require. Je suis d'accord que c'est parfois un peu chiant et que cela pourrait être évité.
Cependant, le use charge le code dans la phrase de pré-compilation alors que le require ne charge le code qu'au moment de l'éxecution. La librairie n'est alors pas chargé au démarrage. Dans le cadre de gros programme ayant plein de fonctionalité, le fait de charger les modules qu'en fonction des besoins et au dernier moment est très intéressant.
De toute manière, si Lisaac veut concurrencer le C, il faudra bien qu'il supporte la compilation modulaire (des librairies et pas que des executables) et qu'il puisse charger du code dynamiquement. Imagine un peu si le code d'Apache n'était pas modulaire...
Je le sais bien d'ou mon smiley ;-) D'un autre coté, c'est sur des trucs énorme que le langage progresse...
D'ailleurs on voit bien l'intérêt de l'espace de nom. Tout ce qui concerne spécifiquement le CLAN serait sous l'espace de nom 'CLAN::'.
Très bien ta réponse sur les sections. Faut vraiment que je regarde plus du coté des langages à prototypes. En fait, j'ai évoquer ce problème d'appel à d'autres classes car je trouve que les langages classiques que je connais n'offrent pas de bonne solution de ce coté là.
> NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il
> y a des chances, mais il faudrait que ce ne soit pas obligatoire).
La structure de l'espace de nom ne doit surtout pas suivre l'arbre d'héritage ! Cela ne veut pas dire que les sous classes doivent être dans un autre espace de nom, bien évidement. Par contre, il y a dans un espace de nom, un ensemble de 'module' ayant un rapport commun pour faire un certain type de composant/application. Par exemple, il y a sous l'espace de nom 'Apache::' de Perl tous les modules lié au serveur web apache.
Bref, l'espace de nom est une structure 'sociale' décidé par l'homme et non par le langage. Le langage doit laisser l'homme très libre sur celui-ci.
Je ne sais pas en quoi est programmé l'original (le CTAN de TeX) mais le CPAN de Perl est bien sur programmé en Perl ;-) D'ailleurs, pour faire celui du javascript (JSAN), ils prennent aussi du Perl car si mes souvenirs sont bons, il y a des choses que le javascript ne peux pas faire.
Bref, le CPAN étant encore très actif au niveau de son développement, j'irais plutôt regarder du coté du perl que du php. Il doit y avoir plein de bout de code a récupérer.
Sinon, c'est un beau projet que de le faire en Lisaac lui-même, histoire de montrer la souplesse de celui-ci ;-)
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
Reflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
L'expérience du CPAN de perl a montré que le classement fait par les développeurs est généralement très pertinent et a une très bonne durée de vie.
A vrai dire, je ne maitrise pas super bien les iterateurs de ruby donc je me suis peut être trop avancé...
Les itérateurs de Sather sont défnis comme les autres fonctions mais leur parametres peuvent avoir en plus des attributs in, out, inout l'attribut 'once' qui veut dire evalué qu'a la première execution. Bien sur, l'objet sur lequel est appellé l'itérateur à l'attribut once.
Ensuite, on ne peux les utiliser QUE dans une boucle 'loop' du langage. On peux donc en mettre plusieurs dans la même boucle et les itérateurs vivent leur vie chacun de leur coté mais en parallèle. On n'a donc pas une boucle par itérateur.
Tu peux aussi reconfigurer ton clavier pour mettre l'antisalsh '\' a la place de la livre ou du mu ;-) A ce moment la, ca devient plus facile que la paire <>.
> Ils sont encore échaudé par OCaml qui ne décolle toujours pas.
Il faut dire que l'INRIA est incapable de mettre en place un CPAN, et c'est pas la première fois que j'en parle ici.
Idem pour Lissac, si vous voulez que ca marche, prévoir de suite deux choses :
- un compilateur LIBRE (pas comme scilab)
- un CPAN dès l'origine avec le même fonctionnement que l'original. Le premier servis s'accapare l'espace de nom (l'espace de nom est global a tous les utilisateurs). Surtout ne pas faire l'erreur de java avec des espaces de nom basé sur les domaines DNS. Le système perl a montré que c'est un système qui fédère les différentes communautés alors que le système java les cloisonne.
Remarque : pour Scilab, l'INRIA fait la même erreur que pour OCaml. C'est à se demander s'ils ont vraiment envie que leurs technologies soient réellement utilisées ?
C'était et c'est toujours la grande force d'ada avec la compilation séparé prévu dès la conception.
Je suis d'accord avec toi. L'analyse globale du code, c'est bien mais si cela supprime le chargement dynamique de librairie, c'est plutôt une regression dans 99% des cas. Sans cette fonctionalité, pas de greffons ;-(
Pour l'aspect multi-thread, encore une fois, l'ada l'a a l'origine ! C'est pareil ici, il faut un modèle permettant de faire du parallèlisme simple dans le langage. Surtout que les microporcesseurs mulit-core arrivent et que c'est clairement le futur proche.
L'INRIA a pas mal travailer sur Eiffel, personnellement, je lui préfère Sather (et pSather). Sather ressemble a Eiffel mais a choisis la voie de l'orthogonalisation des concepts plutôt que celui de la fusion. Bilan, je le trouve bien plus propre et simple. Un truc super en Sather sont les iterateurs, sorte de coroutine, qui renvoi la double structure des conteneurs du C++ au moyen age, la structure de boucle d'Eiffel dans la catégorie des usines à gaz... Les itérateurs de Sather sont bien plus puissant que ceux de ruby, leur implémentation n'est pas si difficile /a priori/ et leur utilisation élimine des centaines de bogues des programmes.
Une autre caractérisque qui manque a beaucoup de langage est la reflexibilté. La reflexibité permet, entre autre, le transfert des objets d'une machine à une autre.
> Enfin, je trouve que la syntaxe est à ch.. un peu désuette, pour le
> coup je préfèrerais quelque chose un peu style xml dans l'esprit.
L'édition du xml à la main est horrible. Fait un peu de docbook pour t'amuser. Revenir ensuite au jeu d'instruction de LaTeX est un vrai bonheur.
Pour ce qui est des touches au clavier, l'antislash est très chiant sur un clavier azerty mais si tu regardes le clavier qwerty des anciennes stations graphiques, la touche est directement accessible. Bref, le choix de \ est un peu malheureux pour les francais mais à l'époque, ce n'etait pas prévisible.
Si tu regardes MS/Windows, il ont aussi ce choix du \ comme séparateur de dossier contrairement au / d'UNIX. Sur un XP, ton login et logname\DOMAINE ! Un partage à distance \\SERVER\partage... Bref, le clavier francais est peut etre a revoir. Qui utilise encore le symbole de la livre anglaise, ou le mu grecque (honntétement, on s'en fout !) ?
Encore une fois, en TeX, tu peux tout modifier. D'ailleurs, la lettre & a aussi une signification en mode 'tabular', le $ introduit le mode math... Si tu fais du texinfo, tu peux voir que le caractère choisis pour commencer une commande est le @ et non le \.
L'idée géniale dans TeX est ce choix d'avoir une lettre spéciale pour commencer une commande. Bien moins lourd que les <> du xml. Comme c'est un moteur orienté pour les documents, le postulat de base est qu'il a moins de commande que de textes. Il faut donc privilégier le texte.
Bref, s'il y avait eu autant d'énergie mis sur l'API LaTeX et le moteur TeX que sur le XML, on aurait autre chose aujourd'hui ;-)
Le XML est conçu pour la machine alors que le TeX est conçu pour l'homme ;-)
A partir de là, il y a quelques problème historique avec le jeu d'instruction LaTeX pour vraiment séparé la forme du contenu mais comme c'est un langage de programmation, c'est reprogrammable aussi ;-) (il y a aussi des cas, rares, ou on est obligé d'intervenir sur la forme et sur le fond pour avoir un résultat propre au niveau des certaines équations -- je ne sais pas s'il est possible de faire un moteur de rendu d'équations qui ne se plante jamais)
Le XML est à la mode mais il a aussi ses défauts. Très verbeux, "chiant" à deboguer à la main... 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.
Bilan, il y a tout un tas d'API pour contourner ce problème de conception, mais ca devient lourds... Le plus grave, c'est qu'on en a pris pour 20 ou 30 ans et que ca va nous faire chie...
Pour courronner le tout, les API annexes de type XPath n'ont rien a voir avec le XML. C'est de la notation pointée de gauche à droite... Bref, c'est vraiment un fatras de techno mal fichu.
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. Si c'est pour avoir un langage orienté machine et non orinté pour l'homme, je préfère encore me tapper ces fichues parenthèses ;-)
> Le jour ou je pourais utiliser Latex sans écrire une ligne de code et
> sans saisir une seule commande, ou je trouverai des menu pour
> insérer, éditer les propriétés des objets et autres "facilité"
> indispensables à l'édition d'un document ;
On parle pas mal de facilité, de documentation dans ce débat. Personnellement, je trouve plus simple de dire
\chapter{Le titre de mon chapitre}
,fonction il est vrai très difficile a retenir, que d'apprendre les menus dans MS/Word ou je vais pouvoir avoir la même chose.
J'irais même plus loin. Le langage tex est globalement très proche des mots clef anglais (comme beaucoup de langage), retenir une trentaine de mot clef n'est pas difficile pour une personne. Maintenant, ferme les yeux et manipule ton MS/Word, tu verras que tu connais par coeur bien plus que 30 mots clefs.
Bref, les interfaces graphiques te font croire que c'est simple et que tu n'as rien a apprendre mais ton inconscient apprends finalement bien plus de trucs avec toutes ces boites de dialogues (je te rassure, j'utilise aussi des interfaces graphiques).
C'est comme le clavier, on passe son temps a le regarder alors qu'on le connait par coeur. On effacerait la signification des touches que ce serait bien plus efficasse pour 99% des gens, le temps d'adaptation étant de moins de 15 jours.
Pour ce qui est de la simplicité MS/Wors - LaTeX, si je compare l'épaisseurs des livres que l'on trouve par exemple dans une FNAC, je me dis que LaTeX doit être bien plus simple ;-)
> le jour ou je pourais à l'écran avoir un appercu "proche" de celui à
> l'impression me permettant de véritablement travailler sur mon texte
> et non pas simplement le saisir, alors je reconsidèrerait
> éventuellement ma position.
Justement, avec LaTeX, ce que tu vois à l'écran est exactement ce que tu aura sur ton papier ! C'est justement pas un truc "proche" à la MS/Office (qui n'a jamais ralé sur les object flotant de MS/Word qui foute une merde pas possible ;-)
Si mes souvenirs sont bons, le moteur TeX calcule tout en entier (très efficasse, surtout il y a 20 ans) et l'unité de base est le nanométre... Bref, on a de la marge avant que les imprimantes arrivent a cette précision ;-)
> Je reste convaincu que LATEX est un outil d'un autre age.
J'ai fait un post un peu plus haut pour parler de la paramétrisation dans un document LaTeX, notament au niveau des variables mathématiques.
Globalement, si tu as 6 formules par pages, avec quelques bonnes formules (indices en haut, en bas...), comment est tu sur que les formules soient justes ?
Tu as beau te relire, comme tu connais ton document par coeur, tu n'est pas capable de bien détecter les erreurs. Et c'est pas un correcteur orthographique ou grammatical qui va t'aider. Et pourtant, c'est plus important que les formules soit justes plutôt qu'il y ai une faute ici ou la de francais (évidement, il faut pas non plus avoir 10 fautes par lignes).
Ma solution, paramétrer toutes les variables utilisées $x$ -> $\sx$ et de temps en temps, lors d'une relecture, changer la définition d'une variable de base par une autre lettre ayant une forme très différente.
C'est la méthode qui m'a permit d'écrire rapidement il y a 10 ans un document de 250 pages ayant des milliers de formules et ou je n'ai pas détecter plus de 5 erreurs depuis dedans (comme je n'avais pas accès à une imprimante, j'avais tout fait à l'écran à l'époque).
> Ceux qui utilisaient LaTeX, je les plains, parce que pour vérifier leurs
> équations, il fallait compiler et poireauter (et très souvent compiler 2
> fois de suite...). Mais avec LyX, les équations sont visibles de suite.
> Un vrai confort. Pas besoin d'apprendre des tonnes de commandes
> obscures.
Le problème est que la vrai puissance de TeX (et LaTeX) vient que c'est un vrai langage de programmation, ou par défaut, les commandes commencent par une lettre spéciale (contrairement aux langages de programmation classique).
Or, il n'est pas facile de faire une interface graphique pour un langage... C'est pas infaisable, cf. labview.
Dès que tu as pas mal d'équation, la grande force de LaTeX est de pouvoir faire des macros pour paramétrer ton texte. Par exemple, un vecteur peut être représenté avec une flêche (France) ou en gras (USA). Si tu as paramétré cela dans un fichier macro.tex que tu importe en début de document, un simple changement dans ce fichier te modifie toutes les flêches en caractères gras.
Idem si tu t'amuses avec des formules qui ont des indices en haut et en bas... Si tu as des tenseurs...
Une autre utilisation des macros que j'ai pas mal pratiqué sur les gros document est la suivante. Disons que j'ai une variable x que j'utilise un peu partout. Je n'utilise jamais directement x sous la forme $x$ mais via la macro $\sx$, le vecteur associé est défini par $\vx$ et le tenseur $\tx$...
Un simple changement dans ma définition de \sx modifie complètement toutes les variables x de mon document par une autre lettre, par exemple la lettre grecque Xi
\newcommand{\sx}{\Xi}
Intérêt ?
Lorsque tu as en moyenne dix formules par pages, le nombre d'erreur de frappe dans les formules est très élévé. Le simple fait de modifier l'apparence des variables, surtout principales, permet de voir de suite les formules fausses. On sais bien qu'il est très difficile de se relire lorsque l'on connait le document par coeur.
Du coup, j'ai jamais pu vraiment utiliser LyX car à partir du moment où tu paramètres toutes tes variables, la plus value avec un vrai éditeur de texte n'est pas évidente. Pour le texte au kilomètre, je 'ai pas vraiement besoin d'avoir un affichage pseudo WYSIWYG.
cygwin est une implémentation de la norme POSIX sur Windows. C'est aussi une "distribution" si on compte tous les logiciels qui vont avec. cygwin est un peu le pendant de wine sous les UNIX, wine étant une implémentation de l'API win32.
colinux permet de faire tourner un noyau linux. Ce n'est pas juste une API. Dans ton colinux, tu es dans une sorte de machine virtuelle. Alors qu'avec cygwin, tu partage complétement l'environnement avec windows.
> Est-il indispensable que rsync soit installé sur le serveur ?
OUI
Avec l'option --backup d'rsync, tu fait une sauvegarde locale et tu n'envoi que les nouveautes par ftp. Par contre, il y a quelques essais a faire avant que ca marche ;-)
Je n'ai essayé qu'une seule fois sous Linux et ca avait marché. A vrai dire, sous un UNIX, ca n'a pas un intéret fou a moins de faire du propriétaire, ce qui n'est pas mon cas ;-)
A vrai dire, plus un langage a de possibilités et un nombre titanesque de module, plus il y a de chance de trouver un cas ou cela ne marche pas... Par ailleurs, il est vrai que Perl n'avait pas été conçu à l'époque pour ca.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
> deux, les attributs sont typés
Je dis que la syntaxe des attributs n'est pas un arbre XML donc on perds la recursivité. Si tu penses que c'est bien, tant mieux pour toi. Personnellement, je trouve cela dommageable. Tant qu'on m'en a pas démontrer le contraire, je persiste à penser que c'est une erreur de conception.
> 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 ;-)
J'ai fait pas mal de sites web basés sur XML avec une bonne séparation forme fond avec AxKit. Bref, je ne suis pas complètement nul même si je ne suis pas spécialiste.
> 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 ? Syntaxe complètement différentes... Tu pourrais tout a fais appliquer XPath sur tout autre chose que le XML. Le XPath est une API de recherche dans un arbre. Ca marcherait tout aussi sur ma structure a base de parenthèse basé sur du LISP !
> Faut pas croire, les gens qui ont élaboré XML (et ceux qui
> continuent de bosser dessus) sont loin d'être bêtes.
Je n'ai jamais dis que c'etait des idiots. Une bonne partie de ces personnes venaient du SGML qui comme usine a gas est pas mal aussi ;-) Avec des raisonnements pareil, les choses n'evoluent pas.
Je reste persuadé que Knuth a été bien plus génial avec son TeX.
Je reprend ton exemple XPath avec une syntaxe LISP
(search-xpath /a//c[@d="untruc"] '(mon-arbre-xml-ecrit-en-lisp) )
Vu comme ca, c'est sur que XPath ne s'intègre pas du tout avec un autre langage que le XML ;-)
[^] # Re: J'espère....
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
En Eiffel, le concept objet est poussé a l'extrème. On le voit par exemple dans la proposition pour faire du parallélisme SCOOP (toujours aucune implémentation...).
En Sather, les concepteurs ont essayé d'orthogonaliser au maximun les concepts afin de les rendre le plus possible indépendant (concept d'orthogonalisation, si tu déplaces sur un axe, tu restes immobile sur un autre).
Donc, le concept d'héritage est divisé en deux : héritage d'interface et héritage de code. L'héritage d'interface suis le principe classique de la programmation objet lorsqu'une classe hérite d'une autre. Cependant, en Sather, elle n'hérite d'aucun code ! Il faut écrire explicitement l'héritage de code via le mot clef "include". Du coup, cela résoud très proprement les problèmes d'héritage multiple (au niveau des appels de méthodes, notament de même nom), a vrai dire, cela parait tellement simple qu'il n'y a plus de problèmes.
L'arbre des classe est très simple et permet le "supertyping". On peux créer une classe et dire que des classes déjà implémenté hérite de celle-ci !! C'est absolument génial pour étendre une librairie toute faite ou en corrigé des manques (inévitables).
Au niveau du parallélisme, les concepts en jeu sont a 100 lieu de SCOOP mais ca marche (enfin, ca marchait) et c'est clair à comprendre et a utiliser. Il y a même une extension "cluster" ou tu peux rajouter à toute instruction la chaine '@numerodunoeud" ou tu impose le noeud du cluster. Ca marche même sur les structures de donnée comme un tableau dont les éléments seraient physiquement imposés par le programmeur sur les différents noeuds du cluster.
Pour faire des boucles "loop do done", il y a un concept d'iterateur basé sur la notion de coroutine. Grace a ce concept, on évite l'usine a gas de la double structure de classe pour les conteneurs de données. L'arbre des classes n'en ai que plus simple. Grace a ce concept d'itérateur indépendant de le notion de classe et d'objet mais de même niveau que la notion de méthode, on divise par deux le nombre de classe (j'exagère) et on simplifie énormément les implémentations, laissant le compilateur optimisé le code ;-)
Bref, le langage a quelques defauts mais comme l'équipe qui l'avait développé faisait du calcul parrallèle, ils ont privilégié la simplicité et l'efficacité. Au final, on a un langage efficasse qui est un cousin d'Eiffel mais particulièrement attachant.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
Non, j'ai écris avec une syntaxe LISP mais si mes souvenirs sont bons, il faut mettre une apostrophe devant (scheme) pour dire que c'est une struture de données.
'(a (href "http://debian.org") "debian")
Bref, je ne parle pas de fonction LISP mais de structure de donnees LISP.
> 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,
Je ne dis pas que je n'aime pas les attributs, je dis que la syntaxe n'est pas bonne. Dans mon exemple, l'attribut est en second, le contenu en troisième. Il y a bien une différence sémantique entre les attributs et le contenu.
Je me demande pourquoi se limiter a des attributs de type chaine ? Avec une vrai structure bien pensée, le contenu est un arbre et l'attribut peux aussi etre un arbre, donc une structure complexe, chose non possible aujourd'hui avec le XML au niveau des attributs.
Par exemple, la chaine href ici, tu dis que c'est une chaine. Mais en pratique, c'est une URL. On pourrait donc très bien la valider sous une forme d'URL dans le schéma en séparant le protocole (http), le serveur (debian.org) , le dossier (/)... En XML, si tu veux faire cela, tu es obligé de passer par le contenu car via les attributs, la structure de données est trop faible.
'(a (href ((proto "http") (server "debian.org") (path "/")) "debian")
> 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
La, je te plussoie a 100%. D'abord pour les fichiers de config, le YAML est souvent très bien. J'avoue que je déteste me tapper un XML pour configurer un logiciel.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 3.
Un exemple très simple
<a href="http://debian.org">debian</a>
l'attribut href est une simple chaine, pas un arbre xml. Du coup, pour injecter un truc dedans via un moteur, xslt par exemple, on a tout un tas de truc pour transformer un bout d'arbre xml en attribut et reciproquement.
Je reprend la meme chose avec un syntaxe LISP (dont je ne suis pas fanatique)
(a (href "http://debian.org") "debian")
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. les atributs sont en seconde position et les valeurs en troisième. Le modèle est bien plus simple.
La structure d'arbre du XML a été cassé au niveau des attributs. C'est dommage, car une partie de récursivité est par la même perdus et donc pour s'en sortir, les API sont plus complexes.
Tout cela n'est que reflexion personnelle. Je ne me fait aucune illusion. Ce n'est pas ces quelques lignes qui vont modifier la trajectoire du XML. Je lui souhaite bonne chance.
[^] # Re: bonjour
Posté par Sytoka Modon (site web personnel) . En réponse au journal Workflow photo numérique. Évalué à 4.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
> conseil de Sun de nommer ses packages en utilisant un nom de
> domaine qu'on possède afin de limiter au maximum les collisions
C'est ca que je reproche. Lorsque j'ai vu ca la première fois il y a ... au début de java, je me suis dis, les autres sont des idiots, cette idée est géniale.
Et bien non. Cela cloisonne les projets. En pratique, les personnes mettent effectivement le domaine dns à l'envers. On a un espace de nom qui ne veut rien dire avec des org.machin.toto...
Si tu regardes un peu du coté du CPAN, on ne perds pas son temps dans des org.machin.toto, on va directement au but et toutes les personnes du monde se partagent le MEME espace de nom. Et ca marche FORMIDABLEMENT bien. Il n'y a AUNCUNE collision !
Pourquoi, parce qu'il y a un CPAN ou tout le code de tous les modules écrit et voulant être mutualisé se trouve.
Bref, le systeme d'un seul espace de nom pousse a la mutualisation du code. Celui qui ne veut pas mutualisé peut avoir un jour un risque de collusion, tant pis pour lui (en java, c'est la meme chose pour ce point la).
Comme le code n'est pas centralisé en java, si tu veux prendre des packages d'un autre esapce de nom org.truc.titi par exemple, qu'est ce qui t'assures que ce bout de code sera encore valable dans six mois ? Bilan, tu recopies voire tu remet tout dans ton espace de nom.
Dernier point, comme chacun travaille dans son espace, si tu travaille sur un module qui fait du ping et un autre qui fait du telnet, tu peux avoir un
import org.machine.net.ping
import org.truc.net.telnet
Comme machin et truc son dans deux esapce de nom différent, il est certain qu'il n'y a pas d'homogénéité dans la philosophie des modules ping et telnet. Au niveau du code, c'est aussi pas super explicites. On ferait un
import net.ping
import net.telnet
Ce serait quand meme bien mieux.
Ensuite, se tapper les org.machin... a chaque fois est pénible, du coup on voit souvent dans les sources des
import org.machine.*
Et ca, ca devrait être interdit par le langage. Surtout que si il y a plusieurs import de ce type et que les API sont étendues, le code peux ne plus compiler !
Un des problèmes des langages objets et que cela devient lourd parfois de faire des choses très simple. Par exemple écrire sur la sortie standard. Sans ce * dans les import en java, c'est très lourd. C'est là ou Sather a une solution GENIALE. Il y a deux classes à la racine : IN et OUT, et il y a un raccourci pour faire appel a la méthode create (ou new du C++), il suffit de mettre un # devant la classe. Donc
#OUT == OUT.create
Avec ca, écrire sur la sortie standard en pur objet tout en restant humain se fait par la seule ligne
#OUT + "hello world !\n"
On instancie la classe OUT, on appelle la méthode + sur cet objet et c'est tout !
> package : accessible uniquement depuis les instances des
> classes du même package
Désolé de mon ignorance sur ce point là. Un package est'il extensible ? Est'il lié à la notion d'espace de nom.
Mon idée est la suivante. Je veux une classe interne a mon espace de nom. En effet, elle n'a aucun intérêt a être public et je veux pouvoir modifier son API.
Mais si une autre personne étend mon espace de nom en rajoutant des classes, il a bien sur le droit d'y avoir accès puisqu'il travaille sur le même thème. Cependant, dans le contrat social implicite, il sais qu'il doit suivre la philosophie de l'espace de nom et s'adapter au changement des API interne à l'espace.
En fait, le choix de l'espace de nom, de faire un CPAN... ont plus un impact sociologoique que technique. En inscrivant dès le départ ce choix dans le langage, on inscrit le projet dans un mouvement communautaire et plutôt lié au libre. Après, la sauce marche ou ne marche pas. Dans un cadre de type INRIA, c'est intéressant de mettre ce type de base car cela évite que des pontes au dessus ai des vues plus monétaires des choses. Une fois la dynamique lancée, ils sont coincés (c'est comme ca qu'un copain a pu sauver son projet libre qui marche relativement bien et que l'université voulait récupérer a son profit).
> il y a correspondance entre chemin et nom de package. Par
> exemple la Classe org.linuxfr.Main sera dans le fichier
> org/linuxfr/Main.java
Heureusement, il faudrait être fou pour proposer un autre système... bien qu'en ada avec gnat, on a le choix de pouvoir mettre des tirets à la place des slash et donc de tout avoir à plat dans le même dossier.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
> ou en Java.
En Perl, il n'y a pas d'import. D'ailleurs, les import sont un truc pourri. Le seul intérêt est d'éviter d'écrire le chemin complet lorsqu'on instancie un objet. Mais le code peux ne plus compilé un jour si on fait un import * come en java ou en python.
En Perl, on fait des use ou des require. Je suis d'accord que c'est parfois un peu chiant et que cela pourrait être évité.
Cependant, le use charge le code dans la phrase de pré-compilation alors que le require ne charge le code qu'au moment de l'éxecution. La librairie n'est alors pas chargé au démarrage. Dans le cadre de gros programme ayant plein de fonctionalité, le fait de charger les modules qu'en fonction des besoins et au dernier moment est très intéressant.
De toute manière, si Lisaac veut concurrencer le C, il faudra bien qu'il supporte la compilation modulaire (des librairies et pas que des executables) et qu'il puisse charger du code dynamiquement. Imagine un peu si le code d'Apache n'était pas modulaire...
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
Je le sais bien d'ou mon smiley ;-) D'un autre coté, c'est sur des trucs énorme que le langage progresse...
D'ailleurs on voit bien l'intérêt de l'espace de nom. Tout ce qui concerne spécifiquement le CLAN serait sous l'espace de nom 'CLAN::'.
Très bien ta réponse sur les sections. Faut vraiment que je regarde plus du coté des langages à prototypes. En fait, j'ai évoquer ce problème d'appel à d'autres classes car je trouve que les langages classiques que je connais n'offrent pas de bonne solution de ce coté là.
> NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il
> y a des chances, mais il faudrait que ce ne soit pas obligatoire).
La structure de l'espace de nom ne doit surtout pas suivre l'arbre d'héritage ! Cela ne veut pas dire que les sous classes doivent être dans un autre espace de nom, bien évidement. Par contre, il y a dans un espace de nom, un ensemble de 'module' ayant un rapport commun pour faire un certain type de composant/application. Par exemple, il y a sous l'espace de nom 'Apache::' de Perl tous les modules lié au serveur web apache.
Bref, l'espace de nom est une structure 'sociale' décidé par l'homme et non par le langage. Le langage doit laisser l'homme très libre sur celui-ci.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 5.
http://www.openjsan.org/
Bref, le CPAN étant encore très actif au niveau de son développement, j'irais plutôt regarder du coté du perl que du php. Il doit y avoir plein de bout de code a récupérer.
Sinon, c'est un beau projet que de le faire en Lisaac lui-même, histoire de montrer la souplesse de celui-ci ;-)
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
Reflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
L'expérience du CPAN de perl a montré que le classement fait par les développeurs est généralement très pertinent et a une très bonne durée de vie.
[^] # Re: Itérateurs et ruby
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Les itérateurs de Sather sont défnis comme les autres fonctions mais leur parametres peuvent avoir en plus des attributs in, out, inout l'attribut 'once' qui veut dire evalué qu'a la première execution. Bien sur, l'objet sur lequel est appellé l'itérateur à l'attribut once.
Ensuite, on ne peux les utiliser QUE dans une boucle 'loop' du langage. On peux donc en mettre plusieurs dans la même boucle et les itérateurs vivent leur vie chacun de leur coté mais en parallèle. On n'a donc pas une boucle par itérateur.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 8.
Il faut dire que l'INRIA est incapable de mettre en place un CPAN, et c'est pas la première fois que j'en parle ici.
Idem pour Lissac, si vous voulez que ca marche, prévoir de suite deux choses :
- un compilateur LIBRE (pas comme scilab)
- un CPAN dès l'origine avec le même fonctionnement que l'original. Le premier servis s'accapare l'espace de nom (l'espace de nom est global a tous les utilisateurs). Surtout ne pas faire l'erreur de java avec des espaces de nom basé sur les domaines DNS. Le système perl a montré que c'est un système qui fédère les différentes communautés alors que le système java les cloisonne.
Remarque : pour Scilab, l'INRIA fait la même erreur que pour OCaml. C'est à se demander s'ils ont vraiment envie que leurs technologies soient réellement utilisées ?
[^] # Re: J'espère....
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Je suis d'accord avec toi. L'analyse globale du code, c'est bien mais si cela supprime le chargement dynamique de librairie, c'est plutôt une regression dans 99% des cas. Sans cette fonctionalité, pas de greffons ;-(
Pour l'aspect multi-thread, encore une fois, l'ada l'a a l'origine ! C'est pareil ici, il faut un modèle permettant de faire du parallèlisme simple dans le langage. Surtout que les microporcesseurs mulit-core arrivent et que c'est clairement le futur proche.
L'INRIA a pas mal travailer sur Eiffel, personnellement, je lui préfère Sather (et pSather). Sather ressemble a Eiffel mais a choisis la voie de l'orthogonalisation des concepts plutôt que celui de la fusion. Bilan, je le trouve bien plus propre et simple. Un truc super en Sather sont les iterateurs, sorte de coroutine, qui renvoi la double structure des conteneurs du C++ au moyen age, la structure de boucle d'Eiffel dans la catégorie des usines à gaz... Les itérateurs de Sather sont bien plus puissant que ceux de ruby, leur implémentation n'est pas si difficile /a priori/ et leur utilisation élimine des centaines de bogues des programmes.
Une autre caractérisque qui manque a beaucoup de langage est la reflexibilté. La reflexibité permet, entre autre, le transfert des objets d'une machine à une autre.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 5.
> coup je préfèrerais quelque chose un peu style xml dans l'esprit.
L'édition du xml à la main est horrible. Fait un peu de docbook pour t'amuser. Revenir ensuite au jeu d'instruction de LaTeX est un vrai bonheur.
Pour ce qui est des touches au clavier, l'antislash est très chiant sur un clavier azerty mais si tu regardes le clavier qwerty des anciennes stations graphiques, la touche est directement accessible. Bref, le choix de \ est un peu malheureux pour les francais mais à l'époque, ce n'etait pas prévisible.
Si tu regardes MS/Windows, il ont aussi ce choix du \ comme séparateur de dossier contrairement au / d'UNIX. Sur un XP, ton login et logname\DOMAINE ! Un partage à distance \\SERVER\partage... Bref, le clavier francais est peut etre a revoir. Qui utilise encore le symbole de la livre anglaise, ou le mu grecque (honntétement, on s'en fout !) ?
Encore une fois, en TeX, tu peux tout modifier. D'ailleurs, la lettre & a aussi une signification en mode 'tabular', le $ introduit le mode math... Si tu fais du texinfo, tu peux voir que le caractère choisis pour commencer une commande est le @ et non le \.
L'idée géniale dans TeX est ce choix d'avoir une lettre spéciale pour commencer une commande. Bien moins lourd que les <> du xml. Comme c'est un moteur orienté pour les documents, le postulat de base est qu'il a moins de commande que de textes. Il faut donc privilégier le texte.
Bref, s'il y avait eu autant d'énergie mis sur l'API LaTeX et le moteur TeX que sur le XML, on aurait autre chose aujourd'hui ;-)
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 5.
A partir de là, il y a quelques problème historique avec le jeu d'instruction LaTeX pour vraiment séparé la forme du contenu mais comme c'est un langage de programmation, c'est reprogrammable aussi ;-) (il y a aussi des cas, rares, ou on est obligé d'intervenir sur la forme et sur le fond pour avoir un résultat propre au niveau des certaines équations -- je ne sais pas s'il est possible de faire un moteur de rendu d'équations qui ne se plante jamais)
Le XML est à la mode mais il a aussi ses défauts. Très verbeux, "chiant" à deboguer à la main... 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.
Bilan, il y a tout un tas d'API pour contourner ce problème de conception, mais ca devient lourds... Le plus grave, c'est qu'on en a pris pour 20 ou 30 ans et que ca va nous faire chie...
Pour courronner le tout, les API annexes de type XPath n'ont rien a voir avec le XML. C'est de la notation pointée de gauche à droite... Bref, c'est vraiment un fatras de techno mal fichu.
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. Si c'est pour avoir un langage orienté machine et non orinté pour l'homme, je préfère encore me tapper ces fichues parenthèses ;-)
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
> sans saisir une seule commande, ou je trouverai des menu pour
> insérer, éditer les propriétés des objets et autres "facilité"
> indispensables à l'édition d'un document ;
On parle pas mal de facilité, de documentation dans ce débat. Personnellement, je trouve plus simple de dire
\chapter{Le titre de mon chapitre}
,fonction il est vrai très difficile a retenir, que d'apprendre les menus dans MS/Word ou je vais pouvoir avoir la même chose.
J'irais même plus loin. Le langage tex est globalement très proche des mots clef anglais (comme beaucoup de langage), retenir une trentaine de mot clef n'est pas difficile pour une personne. Maintenant, ferme les yeux et manipule ton MS/Word, tu verras que tu connais par coeur bien plus que 30 mots clefs.
Bref, les interfaces graphiques te font croire que c'est simple et que tu n'as rien a apprendre mais ton inconscient apprends finalement bien plus de trucs avec toutes ces boites de dialogues (je te rassure, j'utilise aussi des interfaces graphiques).
C'est comme le clavier, on passe son temps a le regarder alors qu'on le connait par coeur. On effacerait la signification des touches que ce serait bien plus efficasse pour 99% des gens, le temps d'adaptation étant de moins de 15 jours.
Pour ce qui est de la simplicité MS/Wors - LaTeX, si je compare l'épaisseurs des livres que l'on trouve par exemple dans une FNAC, je me dis que LaTeX doit être bien plus simple ;-)
> le jour ou je pourais à l'écran avoir un appercu "proche" de celui à
> l'impression me permettant de véritablement travailler sur mon texte
> et non pas simplement le saisir, alors je reconsidèrerait
> éventuellement ma position.
Justement, avec LaTeX, ce que tu vois à l'écran est exactement ce que tu aura sur ton papier ! C'est justement pas un truc "proche" à la MS/Office (qui n'a jamais ralé sur les object flotant de MS/Word qui foute une merde pas possible ;-)
Si mes souvenirs sont bons, le moteur TeX calcule tout en entier (très efficasse, surtout il y a 20 ans) et l'unité de base est le nanométre... Bref, on a de la marge avant que les imprimantes arrivent a cette précision ;-)
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 2.
J'ai fait un post un peu plus haut pour parler de la paramétrisation dans un document LaTeX, notament au niveau des variables mathématiques.
Globalement, si tu as 6 formules par pages, avec quelques bonnes formules (indices en haut, en bas...), comment est tu sur que les formules soient justes ?
Tu as beau te relire, comme tu connais ton document par coeur, tu n'est pas capable de bien détecter les erreurs. Et c'est pas un correcteur orthographique ou grammatical qui va t'aider. Et pourtant, c'est plus important que les formules soit justes plutôt qu'il y ai une faute ici ou la de francais (évidement, il faut pas non plus avoir 10 fautes par lignes).
Ma solution, paramétrer toutes les variables utilisées $x$ -> $\sx$ et de temps en temps, lors d'une relecture, changer la définition d'une variable de base par une autre lettre ayant une forme très différente.
C'est la méthode qui m'a permit d'écrire rapidement il y a 10 ans un document de 250 pages ayant des milliers de formules et ou je n'ai pas détecter plus de 5 erreurs depuis dedans (comme je n'avais pas accès à une imprimante, j'avais tout fait à l'écran à l'époque).
[^] # Re: documentation et limites
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 8.
> équations, il fallait compiler et poireauter (et très souvent compiler 2
> fois de suite...). Mais avec LyX, les équations sont visibles de suite.
> Un vrai confort. Pas besoin d'apprendre des tonnes de commandes
> obscures.
Le problème est que la vrai puissance de TeX (et LaTeX) vient que c'est un vrai langage de programmation, ou par défaut, les commandes commencent par une lettre spéciale (contrairement aux langages de programmation classique).
Or, il n'est pas facile de faire une interface graphique pour un langage... C'est pas infaisable, cf. labview.
Dès que tu as pas mal d'équation, la grande force de LaTeX est de pouvoir faire des macros pour paramétrer ton texte. Par exemple, un vecteur peut être représenté avec une flêche (France) ou en gras (USA). Si tu as paramétré cela dans un fichier macro.tex que tu importe en début de document, un simple changement dans ce fichier te modifie toutes les flêches en caractères gras.
Idem si tu t'amuses avec des formules qui ont des indices en haut et en bas... Si tu as des tenseurs...
Une autre utilisation des macros que j'ai pas mal pratiqué sur les gros document est la suivante. Disons que j'ai une variable x que j'utilise un peu partout. Je n'utilise jamais directement x sous la forme $x$ mais via la macro $\sx$, le vecteur associé est défini par $\vx$ et le tenseur $\tx$...
Un simple changement dans ma définition de \sx modifie complètement toutes les variables x de mon document par une autre lettre, par exemple la lettre grecque Xi
\newcommand{\sx}{\Xi}
Intérêt ?
Lorsque tu as en moyenne dix formules par pages, le nombre d'erreur de frappe dans les formules est très élévé. Le simple fait de modifier l'apparence des variables, surtout principales, permet de voir de suite les formules fausses. On sais bien qu'il est très difficile de se relire lorsque l'on connait le document par coeur.
Du coup, j'ai jamais pu vraiment utiliser LyX car à partir du moment où tu paramètres toutes tes variables, la plus value avec un vrai éditeur de texte n'est pas évidente. Pour le texte au kilomètre, je 'ai pas vraiement besoin d'avoir un affichage pseudo WYSIWYG.
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 4.
Par exemple, sur SELinux, je prefererais que debian choissise par défaut RSBAC.
http://www.rsbac.org/
[^] # Re: QALQ
Posté par Sytoka Modon (site web personnel) . En réponse au journal Colinux nouvelle version 0.6.3. Évalué à 8.
colinux permet de faire tourner un noyau linux. Ce n'est pas juste une API. Dans ton colinux, tu es dans une sorte de machine virtuelle. Alors qu'avec cygwin, tu partage complétement l'environnement avec windows.
[^] # Re: rsync sur serveur
Posté par Sytoka Modon (site web personnel) . En réponse au message Sauvegarde : rsync ?. Évalué à 4.
Après, c'est à toi d'utiliser l'outil dans l'environnement qu'il te faut et si cela s'avère génial, de le faire partager a d'autres.
# rsync sur serveur
Posté par Sytoka Modon (site web personnel) . En réponse au message Sauvegarde : rsync ?. Évalué à 4.
OUI
Avec l'option --backup d'rsync, tu fait une sauvegarde locale et tu n'envoi que les nouveautes par ftp. Par contre, il y a quelques essais a faire avant que ca marche ;-)
[^] # Re: Perl
Posté par Sytoka Modon (site web personnel) . En réponse au message nouveau language à apprendre. Évalué à 2.
A vrai dire, plus un langage a de possibilités et un nombre titanesque de module, plus il y a de chance de trouver un cas ou cela ne marche pas... Par ailleurs, il est vrai que Perl n'avait pas été conçu à l'époque pour ca.
# resolvconf
Posté par Sytoka Modon (site web personnel) . En réponse au message resolvconf -a. Évalué à 2.
iface eth0 inet static
address 192.168.0.123
netmask 255.255.255.0
gateway 192.168.0.1
dns-search nicedomain.org
dns-nameservers 195.238.2.21 195.238.2.22
Ensuite, on relance le reseau ?