Draft PEP on RSON configuration file format

[mk]

Paul Rubin wrote:
> Patrick Maupin <pmaupin at 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