oui mais le jeu c'est pas tellement de savoir qui peut remonter le plus d'erreurs possibles et que la syntaxe soit peu ambigüe pour le compilateur
il faut surtout que les erreurs qu'ils remontent soient claires et la syntaxe peu surprenantes pour le bipède
et puis il faut que tout l'éco-système derrière comprenne ça;
Par exemple là grâce à stackoverflow, j'ai fini par comprendre ce qui se passait
Le truc intolérable pour l'ordinateur que j'avais fait, c'était, rendez-vous compte, de mettre des commentaires dans un json.
Bon json, je savais grosso-modo que c'était des objets javascripts avec quelques restrictions de bon sens pour que ça s'échange mieux avec les autres langages (j'avais lu JavaScript, The Good Parts) mais ça m'était sorti de l'esprit que les commentaires c'était hors de question... vu que dans mon cas c'était à mon avis pertinent.
Oui mais effectivement, le designer de json, moins bête ou du moins instruit par la bêtise de ceux qui ont conçu xml, avait réfléchi à ça :
Comments were removed from JSON by design.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't."
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
En y réfléchissant, il avait raison de faire ça.
Autoriser les commentaires aurait été pire que de les interdire.
N'empêche que j'ai perdu énormément de temps sur ce problème ridicule
Et pas que moi, il suffit de voir le score considérable de la question sur stackoverflow, et le nombre de réponses ayant un score élevé
QUESTION : Score 895 : Can I comment a JSON file? If so, how?
Score 515: I don't believe you can have an actual comment. (...)
Score 216: No, comments in JSON are not allowed, see RFC et json.org (..)
Score 126 : It's not allowed because people would do bad things, but it useful if you know what you do. So I just released JSON.minify() which strips out comments and whitespace from a block of JSON and makes it valid JSON that can be parsed. (...) See my very long blog post here http://blog.getify.com/json-comments/
Score 70: I've found a little hack that allows you to place comments in a JSON file that will not affect the parsing, or alter the data being represented in any way.
Score 50 : Comments were removed from JSON by design. (j'en parle au-dessus)
Et d'autres encore.
En tout cas ça montre qu'il y a un réel problème d'utilisabilité là...
Auquel pourtant le designer avait très bien pensé, mais pas jusqu'au bout...
Qu'est-ce qu'il aurait du faire de plus en fait ?
Une page ad-hoc sur le site officiel de json expliquant pourquoi envoyer des données via json serait une idée horrible
Un paragraphe indiquant qu'un truc comme jsonminify par contre serait bienvenu et qu'il peut lister sur une page à part les logiciels bien fait qui font ça
Une note à l'intention des gens qui font les parseurs de json pour leur dire que interdire les commentaires, qui sont naturels quand on connait le javascript, va surprendre un tas de gens qui utilisent json sans connaitre tous les tenants aboutissant. Et donc, qu'il faut qu'ils fassent un message d'erreur explicite renvoyant vers la page de son site
Bref, beaucoup de tremblement d'ailes de papillons qui évitent qu'un tremblement de terre ne se déclenche à tout instant à des centaines de kilomètres de là.
D'où ma question : pour penser à tous ces petits détails extrèmement importants, ne vaut-il pas mieux commencer sur une base minimaliste comme Go l'a fait, quitte à rajouter ensuite les choses qui manquent vraiment ?
[^] # Re: Go vs C++ (et Rust ?) : Minimalisme versus sophistication
Posté par jean-michel.bertrou.eu . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 0. Dernière modification le 13 octobre 2013 à 14:05.
oui mais le jeu c'est pas tellement de savoir qui peut remonter le plus d'erreurs possibles et que la syntaxe soit peu ambigüe pour le compilateur
il faut surtout que les erreurs qu'ils remontent soient claires et la syntaxe peu surprenantes pour le bipède
et puis il faut que tout l'éco-système derrière comprenne ça;
Par exemple là grâce à stackoverflow, j'ai fini par comprendre ce qui se passait
Le truc intolérable pour l'ordinateur que j'avais fait, c'était, rendez-vous compte, de mettre des commentaires dans un json.
Bon json, je savais grosso-modo que c'était des objets javascripts avec quelques restrictions de bon sens pour que ça s'échange mieux avec les autres langages (j'avais lu JavaScript, The Good Parts) mais ça m'était sorti de l'esprit que les commentaires c'était hors de question... vu que dans mon cas c'était à mon avis pertinent.
Oui mais effectivement, le designer de json, moins bête ou du moins instruit par la bêtise de ceux qui ont conçu xml, avait réfléchi à ça :
Comments were removed from JSON by design.
"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't."
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
Public statement by Douglas Crockford on G+
http://stackoverflow.com/questions/244777/can-i-comment-a-json-file
En y réfléchissant, il avait raison de faire ça.
Autoriser les commentaires aurait été pire que de les interdire.
N'empêche que j'ai perdu énormément de temps sur ce problème ridicule
Et pas que moi, il suffit de voir le score considérable de la question sur stackoverflow, et le nombre de réponses ayant un score élevé
QUESTION : Score 895 : Can I comment a JSON file? If so, how?
Score 515: I don't believe you can have an actual comment. (...)
Score 216: No, comments in JSON are not allowed, see RFC et json.org (..)
Score 126 : It's not allowed because people would do bad things, but it useful if you know what you do. So I just released JSON.minify() which strips out comments and whitespace from a block of JSON and makes it valid JSON that can be parsed. (...) See my very long blog post here http://blog.getify.com/json-comments/
Score 70: I've found a little hack that allows you to place comments in a JSON file that will not affect the parsing, or alter the data being represented in any way.
Score 50 : Comments were removed from JSON by design. (j'en parle au-dessus)
Et d'autres encore.
En tout cas ça montre qu'il y a un réel problème d'utilisabilité là...
Auquel pourtant le designer avait très bien pensé, mais pas jusqu'au bout...
Qu'est-ce qu'il aurait du faire de plus en fait ?
Bref, beaucoup de tremblement d'ailes de papillons qui évitent qu'un tremblement de terre ne se déclenche à tout instant à des centaines de kilomètres de là.
D'où ma question : pour penser à tous ces petits détails extrèmement importants, ne vaut-il pas mieux commencer sur une base minimaliste comme Go l'a fait, quitte à rajouter ensuite les choses qui manquent vraiment ?