On Jan 27, 2009, at 5:37 PM, Michael G Schwern wrote:
Yes. Ant is a good idea if it weren't for the painfully cramped,
wordy and
inconvenient syntax.
To give you an idea, I once translated the Ant example into YAML.
Look at the
original here to refresh your memory:
http://ant.apache.org/manual/using.html#example
I certainly agree that that's a hell of a lot nicer to read than XML,
but YAML is so fragile that I think that it would be equally
unpopular. I hate hand-editing YAML for the same reason I hate hand-
editing XML. In fact, YAML is harder to edit by hand because of the
bizarro indentation rules.
That said, I remembered that James Duncan Davidson, the creator of
Ant, had at one time on his blog an entry about how, if he were to do
it all over again, he wouldn't use XML for the file format. I wrote to
him to ask about this (since in a deadly blog disaster he lost this
blog entry), specifically citing your YAML example and asking him if
it addressed the issues he had with XML in Ant, and he sent me this
reply (forwarded with permission):
I don't think it does. It addresses the complaint about all the
brackets and what not and is cleaner looking (though YAML fragile is
a concern), but it misses the other important thing. At some point,
every recipe really wants a conditional. More to the point, people
want to extend their recipes to do things other than a simple build.
And that way leads right into the need for a full language syntax.
Don't get me wrong, if one is trying to just keep to the basics like
I thought Ant should be in the first place—copy, compile, jar—simple
declarations will work. But user history has shown that an if/else
is wanted by most. Moreso, if somebody wants to do a small extension
to functionality, being able to do so right in the recipe is much
preferable to sorting out how to use the API of the build tool to
add an action.
FWIW, point 'em at Rake. It's much more the direction to emulate.
Rake tasks, FWIW, are written in Ruby.
The upshot of this is that I'm wondering what the reasoning is for
this approach. If I'm installing you Perl module, I'm going to be
running your Perl code anyway. So what difference does it make if the
installer script is written in Perl?
If the answer is that CPAN maintainers or testers need to not run the
Perl code, well, I'm wondering why we'd be solving such a problem for
a very small minority of users who can probably put the code in
question in a jail, anyway.
So what I'm asking is (and if I missed some other conversation about
this, apoligies!), what's the point of this? What problem are we
trying to solve?
Thanks,
David
