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.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part