A. Pagaltzis wrote:
> YAML is a gigantic pile of suck. If it corresponded to the
> feature set of JSON, it would be fine, but good grief, take
> your complexity fetish and stick it somewhere unmentionable.
>
> As it is, I'll have JSON instead please, thankyouverymuch.
But JSON is YAML. :) JSON even removed comments to make that true.
And JSON has all that distracting mandatory quoting and braces that makes the
eyes bleed. Blech. I don't want to have to write that.
{
"targets" : {
"compile" : {
"descripton" : "compile the source",
"actions" : [
{
"javac" : {
"srcdir" : "${src}",
"destdir" : "${build}"
}
}
],
"depends" : "init"
},
"dist" : {
"actions" : [
{
"mkdir" : {
"dir" : "${dist}/lib/"
}
},
{
"jar" : {
"jarfile" : "${dist}/lib/MyProject-${DSTAMP}.jar",
"basedir" : "${build}"
}
}
],
"description" : "generate the distribution",
"depends" : "compile"
},
"clean" : {
"actions" : {
"delete" : [
{
"dir" : "${build}"
},
{
"dir" : "${dist}"
}
]
},
"description" : "clean up"
},
"init" : {
"actions" : [
"tstamp",
{
"mkdir" : {
"dir" : "${build}"
}
}
]
}
},
"name" : "MyProject",
"default" : "dist",
"description" : "simple example build file",
"basedir" : ".",
"properties" : {
"src" : {
"location" : "src/"
},
"dist" : {
"location" : "dist/"
},
"build" : {
"location" : "build/"
}
}
}
Anyhow, they translate trivially which means YAML vs JSON formatting wars are
moot.
$ cat `which yaml2json`
#!/usr/bin/perl -w
use strict;
use YAML ();
use JSON ();
my $json = JSON->new(pretty => 1, indent => 4);
print $json->objToJson(YAML::Load(join "", <>));
$ cat `which json2yaml`
#!/usr/bin/perl -w
use strict;
use YAML;
use JSON;
print YAML::Dump( jsonToObj( join "", <> ) );
>> Oh, you want to actually DO something with it? Here, bolt on
>> this GIGANTIC PILE of standard libraries^W^Hs. Don't forget to
>> write an XML Schema so you can know what all those tags mean,
>> or maybe you get a DTD we haven't worked that bit out yet. And
>> don't forget your XSLT so you can translate this stuff. And CSS
>> so you can make it easy on the eye. And XPath so you can search
>> it. And XQuery because you might be braindead enough to try to
>> use this as a database. And XForms to allow users to change
>> your XML. And...
>
> Yes, I'm sure you can come up with a way to express an XHTML
> document in YAML that would be 200x more readable and positively
> trivial to process. You and every other genius ranting about XML.
No, I would not, because that's not what YAML is for (and HTML is it's own
writhing pile of hate and its redesign I wouldn't touch with any length pole).
It's designed for a specific, yet common and otherwise unfulfilled, purpose.
YAML is a data serialization language for dynamic languages that's human and
machine readable. It's core data types are designed to map easily to and from
the way dynamic languages and humans think. Scalars, lists and pairs.
Name: ____________
Address: ____________
Phone Number: ____________
Last Three Employers:
____________________________
____________________________
____________________________
It's not a magical Try To Bolt Everything On And Suck At Most Of Them format.
But people shove XML into that role all the time, that's what it's being sold
as, the ONE tool for data modeling. Just encode it in XML and everyone will
be able to read it! Bullshit.
(X|SG)ML tries to model the whole universe as a big tree while the universe
itself rarely does that. This leads to all sorts of heavy-weight translation
issues mapping stuff to and from XML whether it's trying to take a real-world
concept from your head and encoding it as XML or trying to make a usable data
structure for your program out of an XML tree. Translation of concepts
increases costs and adds to the complexity of data transmission, exactly the
thing XML is supposed to prevent. It just pushes the cost from parsing the
data to mapping the concepts and that's hateful.
Trying to do EVERYTHING with one format is hateful. It's ok to have more than
one tool.
--
The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.
