From: Patrick Maupin on
On Mar 2, 11:59 am, Terry Reedy <tjre...(a)udel.edu> wrote:

> To me, comparing object notation with programming language is not
> helpful to the OP's purpose.

Yes, I agree, it was a distraction. I fell into the trap of
responding to the ludicrous claim that "if X is a superset of Y, then
X cannot possibly look better than Y" (a claim made by multiple people
all thinking it was clever) by showing that Y has other supersets that
do in fact look better than Y. In doing this, I made the mistake of
choosing a superset of an analogue to Y, rather than to Y itself.
When called out on it, I showed that, in fact, the actual X that IS a
superset of Y can be used in a way that looks better. However, you
are right that JSON is such a small subset of JS that it's really
pretty ridiculous to even compare them, but that still makes the point
that the original argument I was trying to refute is completely
specious. In retrospect, though, I should have chosen a better way to
make that point, because I let myself get caught up in making and then
defending a flippant statement that I don't really care about one way
or the other.

> His main claim is that JSON can be usefully
> extended but that YAML is too much, so that perhaps he, with help, can
> find a 'sweet spot' in between.

An excellent summary of my position.

Thanks,
Pat
From: Steven D'Aprano on
On Tue, 02 Mar 2010 11:30:32 -0800, Patrick Maupin wrote:

> On Mar 2, 11:59 am, Terry Reedy <tjre...(a)udel.edu> wrote:
>
>> To me, comparing object notation with programming language is not
>> helpful to the OP's purpose.
>
> Yes, I agree, it was a distraction. I fell into the trap of responding
> to the ludicrous claim that "if X is a superset of Y, then X cannot
> possibly look better than Y" (a claim made by multiple people all
> thinking it was clever) by showing that Y has other supersets that do in
> fact look better than Y.

It's not ludicrous.

You claim that:

(1) JSON is too hard to edit;

(2) RSON is a superset of JSON (the PEP even explicitly says "All valid
UTF-8 encoded JSON files are also valid RSON files");

(3) which implies that all JSON files are valid RSON files.

If you reject the logical conclusion that RSON must therefore also be too
hard to edit, then perhaps JSON isn't too hard to edit either.

You seem to be taking the position that if you start with a config file
config.json, it is "too hard to edit", but then by renaming it to
config.rson it magically becomes easier to edit. That *is* ludicrous.

Perhaps what you mean to say is that JSON *can be* (not is) too hard to
edit, and RSON *can be* too hard to edit too, but RSON has additional
benefits, including being easier to edit *sometimes*.

So far you have done (in my opinion) a really poor job of explaining what
those benefits are. You've bad-mouthed existing config formats, then
tried to convince us that RSON is almost exactly the same as one of those
formats apart from a couple of trivial changes of spelling (True for
true, etc.).

In my opinion, if you're going to get any traction with RSON, you need to
demonstrate some examples of where JSON actually is hard to write, and
show how RSON makes it easier. It's not good enough showing badly written
JSON, it has to be examples that can't be written less badly given the
constraints of JSON.


--
Steven
From: Paul Rubin on
Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes:
> (3) which implies that all JSON files are valid RSON files.
>
> If you reject the logical conclusion that RSON must therefore also be too
> hard to edit, then perhaps JSON isn't too hard to edit either.

I would say that JSON is hard to edit because, among other things, it
has no comment syntax. It's quite difficult to maintain a hand-edited
JSON file, or figure out what to edit into it, if it can't have any
comments in it describing what it's doing. JSON is a serialization
format for machine to machine communication, not intended for hand
editing. Simply adding a comment syntax to JSON would go a long way
towards making it easier to edit.
From: Patrick Maupin on
On Mar 2, 5:36 pm, Steven D'Aprano <st...(a)REMOVE-THIS-
cybersource.com.au> wrote:
> You seem to be taking the position that if you start with a config file
> config.json, it is "too hard to edit", but then by renaming it to
> config.rson it magically becomes easier to edit. That *is* ludicrous.

No, but that seems to be the position you keep trying to ascribe to
me: "Wait a minute... if JSON is too hard to edit, and RSON is a
*superset* of JSON, that means by definition every JSON file is also a
valid RSON file. Since JSON is too hard to manually edit, so is
RSON."

> Perhaps what you mean to say is that JSON *can be* (not is) too hard to
> edit, and RSON *can be* too hard to edit too, but RSON has additional
> benefits, including being easier to edit *sometimes*.

I have said as much, in multiple prior postings on this thread, if you
care to look.

> So far you have done (in my opinion) a really poor job of explaining what
> those benefits are.

That's certainly a valid complaint, and I can certainly believe that's
true (and I'm going to be working on the doc some more), but instead
of making this complaint, you made the (still silly IMO) assertion
that a superset has to be as unreadable as the base set.

> You've bad-mouthed existing config formats, then
> tried to convince us that RSON is almost exactly the same as one of those formats apart from a couple of trivial changes of spelling (True for true, etc.).

This is conflating two different issues. In a lame attempt to show
the silliness of the argument that the superset must be as bad as the
subset, I was trying to explain that, if you make a very few changes,
Python is a superset of JSON. However, my lame attempt at this was
obviously as poorly thought out as some of the rest of my words,
because it started an additional discussion that wasn't really germane
to the real issues about configuration files.

> In my opinion, if you're going to get any traction with RSON, you need to
> demonstrate some examples of where JSON actually is hard to write, and
> show how RSON makes it easier. It's not good enough showing badly written
> JSON, it has to be examples that can't be written less badly given the
> constraints of JSON.

Agreed, and I will be working on that.

Best regards,
Pat
From: Alf P. Steinbach on
* Patrick Maupin:
> On Mar 2, 5:36 pm, Steven D'Aprano <st...(a)REMOVE-THIS-
> cybersource.com.au> wrote:
>> You seem to be taking the position that if you start with a config file
>> config.json, it is "too hard to edit", but then by renaming it to
>> config.rson it magically becomes easier to edit. That *is* ludicrous.
>
> No, but that seems to be the position you keep trying to ascribe to
> me: "Wait a minute... if JSON is too hard to edit, and RSON is a
> *superset* of JSON, that means by definition every JSON file is also a
> valid RSON file. Since JSON is too hard to manually edit, so is
> RSON."

Just a heads-up: IME it's next to impossible (maybe actually impossible) to
convince Steven that your position is not the one he ascribes to you. At least
not without an extremely lengthy debate veering off on multiple similar tangents
plus some that one would never dream of. So I'd give up on that.

Anyway, I agree with the sentiments expressed by many in this thread that what's
important is the established "eco-culture", not the editability.

Thus, even though XML isn't all that editable it's what I'd choose by default
for rich configuration information, regardless of whether some simpler to edit
alternative existed. Simply because there are so many XML tools out there, and
people know about XML. It's like MS-DOS once became popular in spite of being
extremely technically imperfect for its purpose, and then Windows... :-)


Cheers,

- Alf