Re: [Json] Human JSON (Hjson)

[Peter Cordell <[e-mail]>]

On 26/05/2016 16:15, Carsten Bormann wrote:
> Peter Cordell wrote:
>> For me JSON is too simple, and YAML is too complex.  I've tried to get
>> into YAML a couple of times, but it seems to have multiple ways to do
>> the same things, so I end up getting confused.
>
> I think it would be a great academic subject to study *where* people
> stumble that try to pick up something like YAML.  Can you relate your
> experience in some more detail (off-list if that helps)?
>

I'll do one round on-list in the hope that it's helpful for some 
possible future work:

- The specification is long!

- Having two forms - block style and flow style - doubles the confusion

- As a C family programmer, the block format doesn't 'speak' to me,
   (whereas the JSON format does)

- I haven't done YAML for the other reasons, but I imagine getting the
   indentation right with lists started by '-' is annoyingly fiddly.
   Hence I'm put off going down that path before even trying it.

- Perl-esq levels of non-intuitive magical characters

- There looks to be things like namespacing which for most things I
   probably won't need.  Alas, because they are there, at some point
   some bright spark will use them, which means I will have to support
   them.  So though I could look at things like that as 'optional' at
   some point they probably won't be, in much the same way that if you
   attempt to use a simplified XML processor, at some point it will bite
   you!


>> It clearly fails at at
>> least one level to be human friendly.  Why JSON doesn't have comments
>> eludes me.  JavaScript does, so missing that bit in the subsetting was a
>> big drop off IMO.
>
> JSON was meant as an interchange format between programs, which don't
> need comments to talk to each other.  (Also, if you do need to include
> commentary material, you way want to process this together with the
> other data, so you just add it as fields to your structure, keeping your
> data model simple.)
> [Just trying to relate the rationale as I have heard it expressed many
> times.  Doesn't apply that much to config files, of course.]

While I understand that rationale, when you have a text based format 
that can be consumed by services I still think it was naive to not 
anticipate that people would want to create their own hand edited 
versions, perhaps for test purposes, and squirt them into services to 
see what happens.   From there, config files are a small step.  Indeed, 
it's also naive to not expect a successful 'thing' to be used beyond the 
scope it was originally intended for.

But that's all water under the bridge, and there's little point crying 
over it, other than to perhaps note that "anything that can be edited in 
an editor will be edited in an editor, and anything that will be edited 
in an editor should allow comments" ;-)

Pete.