From: Erik Max Francis on
Patrick Maupin wrote:
> 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."

Huh? That's the argument being used against you, not the argument being
ascribed to you. You're getting confused about something, somewhere.

--
Erik Max Francis && max(a)alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
I wonder if heaven got a ghetto
-- Tupac Shakur
From: Patrick Maupin on
On Mar 2, 9:20 pm, Erik Max Francis <m...(a)alcyone.com> wrote:
> Patrick Maupin wrote:
> > 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."
>
> Huh?  That's the argument being used against you, not the argument being
> ascribed to you.  You're getting confused about something, somewhere.
>
> --
> Erik Max Francis && m...(a)alcyone.com &&http://www.alcyone.com/max/
>   San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
>    I wonder if heaven got a ghetto
>     -- Tupac Shakur

Yes, it is very confusing. Steven used that purported argument
against me, and then since I disagreed with it, it apparently meant
that I was arguing that changing the file extension type (which I've
never even proposed or discussed, btw) from json to rson somehow
magically makes a preexisting file all better. I have a headache now,
and it will only get worse, so that's really all I have left to say
about this issue.

Best regards,
Pat
From: Steven D'Aprano on
On Tue, 02 Mar 2010 19:35:20 -0800, Patrick Maupin wrote:

> Yes, it is very confusing. Steven used that purported argument against
> me, and then since I disagreed with it, it apparently meant that I was
> arguing that changing the file extension type (which I've never even
> proposed or discussed, btw) from json to rson

My argument is *figurative*, not literal.


> somehow magically makes a preexisting file all better.

You might not have intended that ludicrous conclusion, but it was implied
by some of your posts, particularly the early ones. Of course I don't
think that you *actually* believe the conclusion.

I believe that, whatever the real or imagined benefit of RSON over JSON,
in this thread you have attempted to over-sell RSON while giving
relatively little justification for it.

I wish you every success in your project, but think that it is off-topic
for a Python discussion group.




--
Steven
From: Erik Max Francis on
Patrick Maupin wrote:
> On Mar 2, 9:20 pm, Erik Max Francis <m...(a)alcyone.com> wrote:
>> Patrick Maupin wrote:
>>> 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."
>> Huh? That's the argument being used against you, not the argument being
>> ascribed to you. You're getting confused about something, somewhere.
>
> Yes, it is very confusing. Steven used that purported argument
> against me, and then since I disagreed with it, it apparently meant
> that I was arguing that changing the file extension type (which I've
> never even proposed or discussed, btw) from json to rson somehow
> magically makes a preexisting file all better.

No, that was not the point he was making. You should reread more
carefully (and be aware of sarcasm).

--
Erik Max Francis && max(a)alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
Perfect situations must go wrong
-- Florence, _Chess_
From: mk on
Paul Rubin wrote:
> Patrick Maupin <pmaupin(a)gmail.com> writes:
>> One of my complaints. If you had read the document you would have
>> seen others. I actually have several complaints about YAML, but I
>> tried to write a cogent summary.

> Yaml sucks, but seems to have gotten some traction regardless.
> Therefore the Python principle of "there should be one and only one
> obvious way to do it" says: don't try to replace the existing thing if
> your new thing is only slightly better.

With all due respect, Paul, and with thanks for all the help you've
given me, I have to disagree here: this is a really, really complicated
matter and I think there is a case even for making things slightly better.

I think this is a matter of "investment period", so to speak: is it
short or long? In short term, it absolutely makes no sense to produce
even slight improvement.

But in the long run it will almost certainly pay off to switch to smth
even somewhat better implementation (say, imaginary "20%" if you get my
drift): suppose we stay with sucky format for 10 years. Wouldn't it make
sense to implement a new one and be "in red" in terms of effort expended
versus saved for 3 years, but then be "in black" for the following 7 years?

> Just deal with the existing
> thing's imperfections or make improvements to it.

OK, but how? How would you make up e.g. for JSON's lack of comments?
Producing accompanying ".json-comment" format and writing libraries that
parse the comments and interleave them with JSON file for producing
human-readable commented output?

I think the effort required by all parties, both developers and users,
before they produced smth like this and learned to use this widely and
comprehensively, for this manner of improvement would be so high that it
would be actually cheaper to dump the thing and develop smth new that
has built-in support for comments.

If you mean some other method of improving existing things like formats,
well let's hear it; but I for one don't see any worth doing to
significant extent really, other than dumping the thing or producing
next, improved version at least.

Improvement: other than making basic tools like parsing libraries
editors, what improvements can you realistically make? And such
improvements in and of themselves are not very expensive: my GPL
Notepad++ has syntax highlighting for YAML (on top of gazillion other
languages), and there are parsing libraries for it. So where's this
terrible cost to it?

OTOH, if YAML produces net benefit for as few as, say, 200 people in
real world, the effort to make it has been well worth it.

> If you can make a
> really powerful case that your new thing is 1000x better than the old
> thing, that's different, but I don't think we're seeing that here.

Perhaps in ideal world we would be able to develop smth good or at least
decent without long series of abominations preceding it.

But I don't think we live in such world and I don't think it's possible
to produce a decent format (or language) without decades of having to
deal with abominations first. We learn as we go along, there's no way
but to produce whatever works best at the moment, learning from it,
dumping it and then doing smth better. I don't think e.g. Python could
be produced without C, COBOL and Fortran preceding it: it's important
not only to know how to do it, but also how (and why) not to do it, and
learning that can't be done without producing some sort of abomination.

I'd argue that abominations are inevitable price of progress and evolution.

> Also, XML is used for pretty much everything in the Java world. It
> sucks too, but it is highly standardized, it observably gets the job
> done, there are tons of structure editors for it, etc. Frankly
> I'd rather have stayed with it than deal with Yaml.

http://myarch.com/why-xml-is-bad-for-humans

http://www.ibm.com/developerworks/xml/library/x-sbxml.html

Such reasons alone are enough to consider dumping XML for smth better.

Today I had to hand-edit XML config files for two programs (no other
option). The files were rather large, complicated and doing it frankly
sucked.

I also have to maintain a few applications that internally use XML as
data format: while they are tolerable, they still leave smth to be
desired, as those applications are really slow for larger datasets,
their users systematically make errors (like forgetting to attach DTD
before editing), and working across various versions of Windows is still
not perfect.

If somebody out there invents smth that is better than XML "only" by
half, I'm all for it.

> There are too many of these damn formats. We should ban all but one of
> them (I don't much care which one). And making even more of them is not
> the answer.

I think this is a situation of "beware of what you wish for". Suppose
those alternative formats disappeared and you'd have no tools, however
imperfect, to use them: I think that in many, many contexts deficiencies
of "the" format would be so painful that most developers would just
write their own "private" ones, and everyone would be even worse off
than they are now.

I wouldn't worry too much about "stretching scarce resources thin"
either: abominations completely unfit to live waste little in the way of
resources, and we learn a deal off them too.

There are demonstrable benefits to this too: I for one am happy that
ReST is available for me and I don't have to learn a behemoth such as
DocBook to write documentation.

(imaginary dialog:

Paul: "eat your greens and learn your DocBook!"

Me: "but I don't like it and there's too much of it..."

;-)

OK me off the soapbox.

Regards,
mk