<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Therefore, I think the main critera we should be looking at here, for any of the possibilities, isn't "Does this language have flaws?" but rather "Is this language *good enough* to be supported by DUB as a JSON alternative?"<br>
</div>
</blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The 'alternative' bit is the kicker.  Personally, I don't believe DUB can succeed at having multiple supported config languages - one or the other will win out over time, and users will diverge.  So no language would meet that bar (in my opinion).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Mostly we are talking about JSON+stuff as an additional language... so can it be reframed as 'additional features you can use in your dub config file, that aren't strict JSON'?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Framing things this way, you could (for example) switch DUB entirely over to ASON, and avoid the 'switching to a new language' arguments.  DUB takes JSON, DUB also accepts not-strictly-JSON syntax like comments, etc.</div>
<div class="gmail_extra"><br></div></div>