The DUB package manager

[Russel Winder]

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?

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)

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.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130217/1c918d8c/attachment.pgp>