On 2013-02-17 10:24, Russel Winder wrote:
On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote:
I agree about the non-optimal syntax, but it comes down to nicer syntax
(where JSON at least is not _too_ bad) vs. standard format (familiarity,
data exchange, proven design and implementation). And while data
exchange could worked around with export/import functions, considering
that these files are usually just 4 to 20 lines long, I personally would
put less weight on the syntax issue than on the others.
BTW, I think YAML as a superset of JSON is also a good contender with
nice syntax features, but also much more complex.
Peter's point is more important than the above response indicates.
Using JSON (YAML, whatever) is a recipe for failure. The syntax is data
exchange facing, whereas writing and maintaining a build script (even if
it is only 4 lines long), is a human activity. Do not underestimate the
reaction "why do I have to write this data exchange format?" The rapid
demise of XML, Ant, Maven, etc. is testament to people awakening to the
fact that they were forced to use manually a language designed for
another purpose.
Where Gradle, and before it Gant, Buildr, etc., got it right was to use
an internal DSL mentality to ask what is a written form that has
affordance for the user that we can interpret in some way to deliver for
computation the data needed. Groovy provides the infrastructure for
Gradle, but people write Gradle scripts not Groovy. The build/packaging
system does the hard work, not the user.
The lesson from SBT is that by judicious cleverness, a trivially simple
internal DSL can be derived that does all the work using Scala. The only
downside to SBT scripts is the extra newline needed everywhere. Surely D
is better than Scala for this?
Unfortunately I don't think D is better than Scala. I would say that you
can do everything/most that Scala/Groovy can but not with as nice syntax
as Scala/Groovy.
So if D is to contribute to build and package management, it should be
looking to replace Make, CMake, SCons, Waf, Gradle. It should be able to
build D systems yes, and manage D packages, but also look to build C, C
++, Fortran, and interlink all of them. Clearly starting small is good:
a successful large system always evolves from a successful small system;
designed large systems always fail. (cf. Gall, Systemantics, 1975)
I don't think it necessarily needs to be able to build non-D projects.
I'm looking at Gradle now. The first example they show is this:
task hello {
doLast {
println 'Hello world!'
}
}
That translated to D would probably look something like this:
task("hello", {
doLast({
writeln("Hello World");
});
});
Which in my opinion is a lot uglier the the original Groovy code. A
couple of problems with D:
* Semicolons
* Parentheses when making function calls
* No block syntax. Not possible to pass a delegate after the regular
arguments
If all the energy around DUB and Orbit leads to the situation where D
cannot be used to create an internal DSL for describing build and
package/artefact management, then D has failed.
As I've said. I will change Orbit to use D for the DSL.
--
/Jacob Carlborg
