From: Paul Rubin on
Patrick Maupin <pmaupin(a)gmail.com> writes:
> - There is a preexisting file format suitable for my needs, so I
> should not invent another one.

There are in fact quite a few--json, yaml, .ini, xml, Python literals
(http://code.activestate.com/recipes/364469-safe-eval/), s-expressions,
actual Python code that the application can import, and so forth.

The problem isn't that you're trying to invent a useless file format per
se, but rather that in trying to get other people to learn it and use
it, you're also trying to appropriate a chunk of the user community's
scarce and precious brain cells without good justification. Newbie
designers are often lured into that and they're unfortunately (i.e. to
the community's detrimtent) often more successful than they really
should be.

Your one complaint about yaml is that it's slow to parse. Why do you
care about the parsing speed of a config file? If the existing
implementation is too slow, why not write a faster one instead of
designing yayaml? Even yaml is excessive in my view. "Yet another" was
an ok plan when Steve Johnson started the trope by writing Yacc 30 years
ago. These days, don't do yet another without very convincing reasons
for rejecting what is already there.
From: Patrick Maupin on
On Mar 1, 1:37 pm, Paul Rubin <no.em...(a)nospam.invalid> wrote:
> There are in fact quite a few--json, yaml, .ini, xml, Python literals
> (http://code.activestate.com/recipes/364469-safe-eval/), s-expressions,
> actual Python code that the application can import, and so forth.

Yes, I know about those.

> The problem isn't that you're trying to invent a useless file format per
> se, but rather that in trying to get other people to learn it and use
> it, you're also trying to appropriate a chunk of the user community's
> scarce and precious brain cells without good justification.  Newbie
> designers are often lured into that and they're unfortunately (i.e. to
> the community's detrimtent) often more successful than they really
> should be.

Can't disagree with the statement about newbie designers. On the flip
side, sometimes things wind up being defacto standards, simply because
nobody could be bothered to write a better one, and they have lots of
little niggling warts that also collectively take up a lot of time and
attention. There is obviously a good balance somewhere.

> Your one complaint about yaml is that it's slow to parse.  Why do you
> care about the parsing speed of a config file?  If the existing
> implementation is too slow, why not write a faster one instead of
> designing yayaml?  Even yaml is excessive in my view.  "Yet another" was
> an ok plan when Steve Johnson started the trope by writing Yacc 30 years
> ago.  These days, don't do yet another without very convincing reasons
> for rejecting what is already there.

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.

Regards,
Pat
From: Paul Rubin on
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. Just deal with the existing
thing's imperfections or make improvements to 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.

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.

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.
From: Patrick Maupin on
On Mar 1, 2:08 pm, Paul Rubin <no.em...(a)nospam.invalid> wrote:

> Yaml sucks, but seems to have gotten some traction regardless.

Yes, that's actually one of the reasons I want to do this. I've heard
that some of the YAML people want that in the standard library, and
IMHO that would be a huge mistake.

> 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.

But for my use-case, YAML is irretrievably broken. Sure, it looks
reasonably nice, but it increases regression runtime unacceptably.
Also, despite their current protestations that Yaml AIN'T markup
language, the syntax still belies its markup roots. I'm looking for a
configuration language, not a markup language.

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

Well, I've looked at the YAML parser and I can assure you that I will
not be contributing to that project.

> 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.

Well, there's no way I'm hitting three orders of magnitude, but I
don't think the bar is really that high. We will see.

> 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.

XML can certainly be made readable by humans. It's hard to make it
writeable by (average) humans just using a regular text editor, and
even though there are tons of structure editors, requiring non-
technical people to find one of those and start using it is a non-
starter in many cases. But I can't strongly disagree with the opinion
that YAML doesn't offer all that much over 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.

Well, I think that XML and YAML both overreach by trying to be all
things to all applications. So I'm aiming a lot lower than that. I
just want to make really good configuration files that are easy to
modify in a text editor.

None of the existing formats are suitable. I may be the only one who
feels that way. OTOH, if we never invented new things, then I
wouldn't be enjoying restructured text, and I'd be missing out on a
lot there...

Regards,
Pat
From: Paul Rubin on
Patrick Maupin <pmaupin(a)gmail.com> writes:
> But for my use-case, YAML is irretrievably broken. Sure, it looks
> reasonably nice, but it increases regression runtime unacceptably.

How big are the files that you want to parse with it? Sheesh.

> Well, I've looked at the YAML parser and I can assure you that I will
> not be contributing to that project.

So write a new one that parses the same syntax, but cleaner and faster.

> XML can certainly be made readable by humans. It's hard to make it
> writeable by (average) humans just using a regular text editor,

I do it all the time; it's a bit dreary but not difficult. And there is
absolutely no way to get anything done in this field anymore without
dealing with XML from time to time. So given that we all have some
experience using it, it's sensible to stick with it.

> None of the existing formats are suitable. I may be the only one who
> feels that way. OTOH, if we never invented new things, then I
> wouldn't be enjoying restructured text, and I'd be missing out on a
> lot there...

ReST is another abomination that should never have gotten off the
ground. It is one of the reasons I react so negatively to your
config format proposal. It just sounds like more of the same.