Parlons de choses qui fachent

pehache <pehache.7@gmail.com> writes:

Le 19/12/2013 12:13, Moreira David a écrit :

Parce que ce n'est pas moi qui code le menu d'openbox est-il une
réponse acceptable ? :-) Je ne suis qu'utilisateur et perso quelqu es
lignes d'XML ne me dérangent pas plus que ça.

Ok, ce n'est pas pour transiter sur le réseau. Donc inutile de pens er à
la lourdeur de la chose à moins d'écrire à la main du xml /json/yaml par
paquet de méga octets.

La lourdeur c'est aussi, et surtout, à la lecture. La lecture d'un X ML
(donc sa modification) est tout sauf fluide.

J'admet que le Xml est lourd à lire, mais je parle également de j son et
de yaml.

--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
David Moreira ()
perso: vash2593@myopera.com /
6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F

Nicolas George <nicolas$george@salle-s.org> writes:

Moreira David , dans le message <87wqj0u4mo.fsf@od.vash2593.com>, a
écrit :

Ils n'on pas raison selon mon avis, c'est un fait. Après, tu as des
moyens de mettre en valeur ce type de caractère sur certains
editeurs. Emacs peut le faire, vim sans doute également.

Tu ne peux pas contrôler l'éditeur que tous les gens qui modifi eront ton
fichier utiliseront.

Le langage est donc bien définis.

Encore heureux !

Encore heureux oui. Mais quand on voit les absurditées amenées pa r les
ambiguité de python, ruby et le fait que le c++ soit contexte sensitif,
on ne peut que pleurer quand on doit implémenter un parser/compilateur.

Je vais me faire l'avocat du diable, mais l'ajout des accolades dans les
C-likes impliquent une moins bonne lisibilitté du langage par
l'insertion de caractère invisible.

Gnî ?

Bah oui, plus de caractères ⇒ plus d'informations ⇒ mo ins lisibles.

Certaines langues n'ont pas de ponctuations, ou on eu une ponctuation
que récemment. Ainsi, il semble que c'est un système viable à l'échelle
d'une langue naturelle.

On n'est pas en train de parler d'une langue naturelle.

Malheureusement pour toi, il y beaucoup de ressemblance entre un langage
de programmation et une langue naturelle :

- grammaire/syntaxe ;
- sémantique ;
- traduction/compilation ;
- Description d'une idée, d'une action.

Donc parler des langues naturelles, quand on parle de syntaxe des
langues de programmation n'est pas déconnant.

--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
David Moreira ()
perso: vash2593@myopera.com /
6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F

Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :

Nicolas George <nicolas$george@salle-s.org> writes:

D'autre part, contrairement à ce que certains prétendent, un mécanisme
d'échappement est toujours nécessaire. Ici, il est nécessaire si on veut une
valeur qui commence par un espace ou qui contient des retours à la ligne.
Pouvoir découper de longues lignes en blocs gérables peut aussi être utile.
La sensibilité à l'espacement rend tout ça plus malcommode.

En effet, commen en ruby, il faut sois échapper le caractère de retour à
la ligne (ce qui est horrible) soit faire en sorte que l'expression ne
soit pas finit : en mettant un opérateur en fin de ligne par exemple.

Sauf que dans le cas présent, pour yaml, il existe des opérateurs
spécifiant afin de dire que la chaine de caractère va tenir en plusieurs
lignes. Ainsi, on n'a pas l'ambigüité de Python ou de Ruby par exemple.

Python dispose également d'un tel opérateur permettant à un echaine de
tenir sur plusieurs ligne tout comme il permet de scinder les longues
lignes.

--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
++++++++++++++ Live long and prosper ++++++++++++++

Doug713705 <doug.letough@free.fr> writes:

Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :

Nicolas George <nicolas$george@salle-s.org> writes:

D'autre part, contrairement à ce que certains prétendent, un
mécanisme d'échappement est toujours nécessaire. Ici, il est
nécessaire si on veut une valeur qui commence par un espace ou qui
contient des retours à la ligne. Pouvoir découper de longues lignes
en blocs gérables peut aussi être utile. La sensibilité à
l'espacement rend tout ça plus malcommode.

En effet, commen en ruby, il faut sois échapper le caractère d e retour à
la ligne (ce qui est horrible) soit faire en sorte que l'expression ne
soit pas finit : en mettant un opérateur en fin de ligne par e xemple.

Sauf que dans le cas présent, pour yaml, il existe des opérate urs
spécifiant afin de dire que la chaine de caractère va tenir en plusieurs
lignes. Ainsi, on n'a pas l'ambigüité de Python ou de Ruby pa r exemple.

Python dispose également d'un tel opérateur permettant à u n echaine de
tenir sur plusieurs ligne tout comme il permet de scinder les longues
lignes.

Ceci est un exemple. Et échapper un retour à la ligne n'est pas s ain
pour les yeux. Comment vas-tu écrie « expr1 + expr2  » sur deux lignes en
python.

solution 1 :
expr1 +
expr2

solution 2 :
expr1
+ expr2

Why not both? Parce que Python ne fera même pas un warning pour la
deuxième solution (peut être un useless statement comme pour le c).

--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
David Moreira ()
perso: vash2593@myopera.com /
6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F

Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :

Ceci est un exemple. Et échapper un retour à la ligne n'est pas sain
pour les yeux. Comment vas-tu écrie « expr1 + expr2 » sur deux lignes en
python.

solution 1 :
expr1 +
expr2

solution 2 :
expr1
+ expr2

Why not both? Parce que Python ne fera même pas un warning pour la
deuxième solution (peut être un useless statement comme pour le c).

Ah ok, je vois de quoi tu parles.
Honnêtement je n'ai pas le niveau pour argumenter sur un tel sujet.

--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
++++++++++++++ Live long and prosper ++++++++++++++

Doug713705 <doug.letough@free.fr> writes:

Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :

Ceci est un exemple. Et échapper un retour à la ligne n'est pa s sain
pour les yeux. Comment vas-tu écrie « expr1 + expr2  » sur deux lignes en
python.

solution 1 :
expr1 +
expr2

solution 2 :
expr1
+ expr2

Why not both? Parce que Python ne fera même pas un warning pour la
deuxième solution (peut être un useless statement comme pour le c).

Ah ok, je vois de quoi tu parles.
Honnêtement je n'ai pas le niveau pour argumenter sur un tel sujet.

Tant que tu écris du code, tu devrais pouvoir le faire. Le problè me est
juste une question de style. Perso, je préfère la deuxième s olution, qui
est plus explicite, mais qui est ambigue dans les langages point
virgules less.

--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
David Moreira ()
perso: vash2593@myopera.com /
6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F

Le 20-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :

Doug713705 <doug.letough@free.fr> writes:

Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :

Ceci est un exemple. Et échapper un retour à la ligne n'est pas sain
pour les yeux. Comment vas-tu écrie « expr1 + expr2 » sur deux lignes en
python.

solution 1 :
expr1 +
expr2

solution 2 :
expr1
+ expr2

Why not both? Parce que Python ne fera même pas un warning pour la
deuxième solution (peut être un useless statement comme pour le c).

Ah ok, je vois de quoi tu parles.
Honnêtement je n'ai pas le niveau pour argumenter sur un tel sujet.

Tant que tu écris du code, tu devrais pouvoir le faire. Le problème est
juste une question de style. Perso, je préfère la deuxième solution, qui
est plus explicite, mais qui est ambigue dans les langages point
virgules less.

Je prefère également la deuxième solution et j'échappe le retour à la
ligne :

expr1
+ expr2

Ce n'est pas très heureux mais ce n'est pas gravissime.

--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
++++++++++++++ Live long and prosper ++++++++++++++

Doug713705 <doug.letough@free.fr> writes:

Le 20-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :

Doug713705 <doug.letough@free.fr> writes:

Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.deba ts :

Ceci est un exemple. Et échapper un retour à la ligne n'est pas sain
pour les yeux. Comment vas-tu écrie « expr1 + expr2  Â» sur deux lignes en
python.

solution 1 :
expr1 +
expr2

solution 2 :
expr1
+ expr2

Why not both? Parce que Python ne fera même pas un warning pour la
deuxième solution (peut être un useless statement comme pou r le c).

Ah ok, je vois de quoi tu parles.
Honnêtement je n'ai pas le niveau pour argumenter sur un tel sujet.

Tant que tu écris du code, tu devrais pouvoir le faire. Le problà ¨me est
juste une question de style. Perso, je préfère la deuxièm e solution, qui
est plus explicite, mais qui est ambigue dans les langages point
virgules less.

Je prefère également la deuxième solution et j'échapp e le retour à la
ligne :

expr1
+ expr2

Ce n'est pas très heureux mais ce n'est pas gravissime.

J'aime avoir un style plaisant quand j'écris du code et garder le me ̂me
pour l'ensemble du projet. Devoir rajouter un retour à la ligne é chapper
me derange un peu.

Au minimum, je pourrais écrire :

expr1
+ expr2

Mais ce n'est pas très facile à modifier (en C{,++}, c'est plus s imple,
car le mode le gère assez bien).
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
David Moreira ()
perso: vash2593@myopera.com /
6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F

Le 19 Dec 2013 15:34:55 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :

Moreira David , dans le message <8761qluhf1.fsf@od.vash2593.com>, a
écrit :
> Un mininmum de rigeur fait toujours plaisir.

Oui, il faut indenter son code pour le rendre lisible. Mais donner un
sens sémantique à l'espacement est, je le maintiens, une aberra tion,
pour plein de raisons.

Ça me rappelle une querelle du début des 70/80s. Le mythe veut qu 'une
espace ait crashé une sonde de la Nasa. C'était du Fortran non ? ;)