Paul Rubin wrote:
Patrick Maupin <pmau...@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
--
http://mail.python.org/mailman/listinfo/python-list
