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.
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.
Mais pourquoi ne pas passer sur des encodages plus réduit ou compresser ?
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.
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.
Mais pourquoi ne pas passer sur des encodages plus réduit ou compresser ?
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.
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.
Mais pourquoi ne pas passer sur des encodages plus réduit ou compresser ?
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, per so ça
me gonfle.
Passe au qwerty/dvorak ? Un ralentissement au début, mais quel le
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éellemen t de place
est pour les chaines de caractères. L'indentation bouffant certaine ment
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 d e 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 falla it penser
à une autre solution, non ?
Mais pourquoi ne pas passer sur des encodages plus réduit ou compre sser ?
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 foi s
par an. Pour le peu que je m'en sert de toutes façons...
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, per so ça
me gonfle.
Passe au qwerty/dvorak ? Un ralentissement au début, mais quel le
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éellemen t de place
est pour les chaines de caractères. L'indentation bouffant certaine ment
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 d e 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 falla it penser
à une autre solution, non ?
Mais pourquoi ne pas passer sur des encodages plus réduit ou compre sser ?
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 foi s
par an. Pour le peu que je m'en sert de toutes façons...
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, per so ça
me gonfle.
Passe au qwerty/dvorak ? Un ralentissement au début, mais quel le
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éellemen t de place
est pour les chaines de caractères. L'indentation bouffant certaine ment
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 d e 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 falla it penser
à une autre solution, non ?
Mais pourquoi ne pas passer sur des encodages plus réduit ou compre sser ?
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 foi s
par an. Pour le peu que je m'en sert de toutes façons...
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.
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.
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.
YAML avec son identation structurée me semble par contre une bonne
alternative.
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, pers o ça
me gonfle.
Tu as le droit d'utiliser un éditeur décent et d'indenter le JS ON,
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, pers o ça
me gonfle.
Tu as le droit d'utiliser un éditeur décent et d'indenter le JS ON,
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 , 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, pers o ça
me gonfle.
Tu as le droit d'utiliser un éditeur décent et d'indenter le JS ON,
hein.
YAML avec son identation structurée me semble par contre une bonne
alternative.
La sensibilité à l'espacement est une calamité.
Un mininmum de rigeur fait toujours plaisir.
Un mininmum de rigeur fait toujours plaisir.
Un mininmum de rigeur fait toujours plaisir.
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.
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.
Aberration pour toi. Je ne vois pas le problème d'avoir des scopes
limités par des espaces.
Aberration pour toi. Je ne vois pas le problème d'avoir des scopes
limités par des espaces.
Aberration pour toi. Je ne vois pas le problème d'avoir des scopes
limités par des espaces.
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 moi ns
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 sensibi lité Ã
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écessa ire si on veut une
valeur qui commence par un espace ou qui contient des retours à la l igne.
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 u ne 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 moi ns
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 sensibi lité Ã
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écessa ire si on veut une
valeur qui commence par un espace ou qui contient des retours à la l igne.
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 u ne syntaxe avec
des délimiteurs explicites bien conçus _et_ s'astreindre à une présentation
lisible.
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 moi ns
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 sensibi lité Ã
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écessa ire si on veut une
valeur qui commence par un espace ou qui contient des retours à la l igne.
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 u ne syntaxe avec
des délimiteurs explicites bien conçus _et_ s'astreindre à une présentation
lisible.
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.
Le langage est donc bien définis.
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.
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.
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.
Le langage est donc bien définis.
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.
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.
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.
Le langage est donc bien définis.
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.
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.
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î ?
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î ?
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î ?