Je suis étonné de m'apercevoir que dans ce groupe, qui a fait de la
polémique et de la mauvaise foi un art de vivre, aucune discussion
concernant systemd n'a été explicitement lancée.
Il est grand temps d'y remédier.
- Systemd est-il oui ou non un mal nécessaire ?
Question subsidiaire :
- Pottering est-il un agent double ou un escroc ?
Merci d'affutez vos partis pris et de sortir vos meilleurs arguments.
À vos mouches, prêts, partez !
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
++++++++++++++ Live long and prosper ++++++++++++++
Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :
Il existe des formats de description de données nettement moins lourdingues, néanmoins. Par exemple : http://en.wikipedia.org/wiki/JSON
Moins lourdingue, faut voir. En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, perso ça me gonfle.
Passe au qwerty/dvorak ? Un ralentissement au début, mais quelle facilité pour coder.
Ordinateur portable, fainéantise, toussa.
YAML avec son identation structurée me semble par contre une bonne alternative.
Connaissait pas, mais cool. Le seul cas oú tu gagnes réellement de place est pour les chaines de caractères. L'indentation bouffant certainement pas mal de place.
Je ne connaissais pas non plus mais j'aime bien. C'est mon coté pythoneux qui parle.
Pour le reste je suppose (à vérifier donc) qu'il est possible de choisir la taille de l'indentation. Et puis quand tu en es au 42ème niveau d'indentation ça fait peut-être au moins 32 niveaux qu'il fallait penser à une autre solution, non ?
Mais pourquoi ne pas passer sur des encodages plus réduit ou compresser ?
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 quelques lignes d'XML ne me dérangent pas plus que ça.
À vrai dire je dois modifier mon menu quelque chose comme 2 ou 3 fois par an. Pour le peu que je m'en sert de toutes façons...
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) ++++++++++++++ Live long and prosper ++++++++++++++
Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :
Il existe des formats de description de données nettement moins
lourdingues, néanmoins. Par exemple :
http://en.wikipedia.org/wiki/JSON
Moins lourdingue, faut voir.
En AZERTY, les accolades, les crochets et les guillemets dans tous les
sens c'est vite chiant à taper et vite source d'erreur. Enfin, perso ça
me gonfle.
Passe au qwerty/dvorak ? Un ralentissement au début, mais quelle
facilité pour coder.
Ordinateur portable, fainéantise, toussa.
YAML avec son identation structurée me semble par contre une bonne
alternative.
Connaissait pas, mais cool. Le seul cas oú tu gagnes réellement de place
est pour les chaines de caractères. L'indentation bouffant certainement
pas mal de place.
Je ne connaissais pas non plus mais j'aime bien. C'est mon coté
pythoneux qui parle.
Pour le reste je suppose (à vérifier donc) qu'il est possible de choisir
la taille de l'indentation. Et puis quand tu en es au 42ème niveau
d'indentation ça fait peut-être au moins 32 niveaux qu'il fallait penser
à une autre solution, non ?
Mais pourquoi ne pas passer sur des encodages plus réduit ou compresser ?
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 quelques
lignes d'XML ne me dérangent pas plus que ça.
À vrai dire je dois modifier mon menu quelque chose comme 2 ou 3 fois
par an. Pour le peu que je m'en sert de toutes façons...
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
++++++++++++++ Live long and prosper ++++++++++++++
Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :
Il existe des formats de description de données nettement moins lourdingues, néanmoins. Par exemple : http://en.wikipedia.org/wiki/JSON
Moins lourdingue, faut voir. En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, perso ça me gonfle.
Passe au qwerty/dvorak ? Un ralentissement au début, mais quelle facilité pour coder.
Ordinateur portable, fainéantise, toussa.
YAML avec son identation structurée me semble par contre une bonne alternative.
Connaissait pas, mais cool. Le seul cas oú tu gagnes réellement de place est pour les chaines de caractères. L'indentation bouffant certainement pas mal de place.
Je ne connaissais pas non plus mais j'aime bien. C'est mon coté pythoneux qui parle.
Pour le reste je suppose (à vérifier donc) qu'il est possible de choisir la taille de l'indentation. Et puis quand tu en es au 42ème niveau d'indentation ça fait peut-être au moins 32 niveaux qu'il fallait penser à une autre solution, non ?
Mais pourquoi ne pas passer sur des encodages plus réduit ou compresser ?
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 quelques lignes d'XML ne me dérangent pas plus que ça.
À vrai dire je dois modifier mon menu quelque chose comme 2 ou 3 fois par an. Pour le peu que je m'en sert de toutes façons...
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) ++++++++++++++ Live long and prosper ++++++++++++++
Moreira David
Doug713705 writes:
Le 19-12-2013, Moreira David nous expliquait dans fr.comp.os.linux.debats :
Moins lourdingue, faut voir. En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, per so ça me gonfle.
Moins lourdingue, faut voir.
En AZERTY, les accolades, les crochets et les guillemets dans tous les
sens c'est vite chiant à taper et vite source d'erreur. Enfin, per so ça
me gonfle.
Moins lourdingue, faut voir. En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, per so ça me gonfle.
-- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! David Moreira () perso: / 6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F
Nicolas George
Doug713705 , dans le message , a écrit :
En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, perso ça me gonfle.
Tu as le droit d'utiliser un éditeur décent et d'indenter le JSON, hein.
YAML avec son identation structurée me semble par contre une bonne alternative.
La sensibilité à l'espacement est une calamité.
Doug713705 , dans le message <hls9oaxqho.ln2@actarus.bourzy.lan>, a
écrit :
En AZERTY, les accolades, les crochets et les guillemets dans tous les
sens c'est vite chiant à taper et vite source d'erreur. Enfin, perso ça
me gonfle.
Tu as le droit d'utiliser un éditeur décent et d'indenter le JSON, hein.
YAML avec son identation structurée me semble par contre une bonne
alternative.
En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, perso ça me gonfle.
Tu as le droit d'utiliser un éditeur décent et d'indenter le JSON, hein.
YAML avec son identation structurée me semble par contre une bonne alternative.
En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, pers o ça me gonfle.
En AZERTY, les accolades, les crochets et les guillemets dans tous les
sens c'est vite chiant à taper et vite source d'erreur. Enfin, pers o ça
me gonfle.
En AZERTY, les accolades, les crochets et les guillemets dans tous les sens c'est vite chiant à taper et vite source d'erreur. Enfin, pers o ça me gonfle.
-- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! David Moreira () perso: / 6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F
Nicolas George
Moreira David , dans le message , 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 aberration, pour plein de raisons.
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 aberration, pour plein
de raisons.
Oui, il faut indenter son code pour le rendre lisible. Mais donner un sens sémantique à l'espacement est, je le maintiens, une aberration, pour plein de raisons.
Si tu as d'autres raisons, je veux bien les entendres.
-- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! David Moreira () perso: / 6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F
Nicolas George
Moreira David , dans le message , a écrit :
Aberration pour toi. Je ne vois pas le problème d'avoir des scopes limités par des espaces.
Déjà, sur le principe : la structure d'un document est son élément le plus important, c'est absurde de la faire reposer sur le caractère le moins visible.
Ensuite, sur les aspects pratiques.
Comme tu le mentionnes, les tabulations. Certains éditeurs vont automatiquement remplacer huit espaces par une tabulation dans certaines circonstances. Tu peux les blâmer tant que tu veux, dire qu'ils ont tort, le fait est qu'ils existent, c'est un comportement fréquent. La sensibilité à l'espacement est donc une propriété fragile : une différence automatique et invisible peut casser la structure du document.
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.
D'une manière générale, il vaut largement mieux utiliser une syntaxe avec des délimiteurs explicites bien conçus _et_ s'astreindre à une présentation lisible.
Moreira David , dans le message <871u18vocm.fsf@od.vash2593.com>, a
écrit :
Aberration pour toi. Je ne vois pas le problème d'avoir des scopes
limités par des espaces.
Déjà, sur le principe : la structure d'un document est son élément le plus
important, c'est absurde de la faire reposer sur le caractère le moins
visible.
Ensuite, sur les aspects pratiques.
Comme tu le mentionnes, les tabulations. Certains éditeurs vont
automatiquement remplacer huit espaces par une tabulation dans certaines
circonstances. Tu peux les blâmer tant que tu veux, dire qu'ils ont tort, le
fait est qu'ils existent, c'est un comportement fréquent. La sensibilité à
l'espacement est donc une propriété fragile : une différence automatique et
invisible peut casser la structure du document.
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.
D'une manière générale, il vaut largement mieux utiliser une syntaxe avec
des délimiteurs explicites bien conçus _et_ s'astreindre à une présentation
lisible.
Aberration pour toi. Je ne vois pas le problème d'avoir des scopes limités par des espaces.
Déjà, sur le principe : la structure d'un document est son élément le plus important, c'est absurde de la faire reposer sur le caractère le moins visible.
Ensuite, sur les aspects pratiques.
Comme tu le mentionnes, les tabulations. Certains éditeurs vont automatiquement remplacer huit espaces par une tabulation dans certaines circonstances. Tu peux les blâmer tant que tu veux, dire qu'ils ont tort, le fait est qu'ils existent, c'est un comportement fréquent. La sensibilité à l'espacement est donc une propriété fragile : une différence automatique et invisible peut casser la structure du document.
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.
D'une manière générale, il vaut largement mieux utiliser une syntaxe avec des délimiteurs explicites bien conçus _et_ s'astreindre à une présentation lisible.
-- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! David Moreira () perso: / 6629 55A7 6AF3 45F4 E27D 9C1F DFB3 057C 93A2 EC9F
Nicolas George
Moreira David , dans le message , 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 modifieront ton fichier utiliseront.
Le langage est donc bien définis.
Encore heureux !
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î ?
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.
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 modifieront ton
fichier utiliseront.
Le langage est donc bien définis.
Encore heureux !
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î ?
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.
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 modifieront ton fichier utiliseront.
Le langage est donc bien définis.
Encore heureux !
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î ?
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.
Tonton Th
On 2013-12-19, Nicolas George <nicolas$ wrote:
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.
On 2013-12-19, Nicolas George <nicolas$george@salle-s.org> wrote:
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.
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.
