The DUB package manager

[Jacob Carlborg]

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