On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
> On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:

> The fact that it's backwards compatible with JSON would be useful for avoiding breaking existing dub packages, and it does

That's not a tragedy. For a while, dub could maintain the ability to read, even write the JSON format, and even to read .json and write .sdl, de facto converting.

Am 26.08.2014 15:37, schrieb eles:
> On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
>> On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:
>
>> The fact that it's backwards compatible with JSON would be useful for
>> avoiding breaking existing dub packages, and it does
>
> That's not a tragedy. For a while, dub could maintain the ability to
> read, even write the JSON format, and even to read .json and write .sdl,
> de facto converting.

It will *always* continue to support JSON. There are absolutely no plans to remove support. The plan is just to support an additional alternative format that is better suited for human editors.

Am 26.08.2014 15:37, schrieb Kagamin:
> On Tuesday, 26 August 2014 at 13:28:28 UTC, Kagamin wrote:
>> On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
>>> The fact that it's backwards compatible with JSON would be useful for
>>> avoiding breaking existing dub packages, and it does sound like it's
>>> a better format, but the fact that it's just been created for this
>>> makes me leery.
>>
>> Well, formats are created if existing formats are suboptimal. JSON is
>> not a general-purpose format, it was designed to be locked on
>> javascript parsers.
>
> If we want a popular markup language at some expense to save people from
> learning new language, it should be XML - it's more popular, than
> anything else.

XML may pass the popularity test, but utterly fails at providing a more concise and usable experience. As far as I'm concerned, it's about finding the most "usable" language among those that are *decently* popular.

On Tue, 2014-08-26 at 15:55 +0200, Sönke Ludwig via Digitalmars-d wrote:
> Am 26.08.2014 15:37, schrieb Kagamin:
> > On Tuesday, 26 August 2014 at 13:28:28 UTC, Kagamin wrote:
> >> On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
> >>> The fact that it's backwards compatible with JSON would be useful for avoiding breaking existing dub packages, and it does sound like it's a better format, but the fact that it's just been created for this makes me leery.
> >>
> >> Well, formats are created if existing formats are suboptimal. JSON is not a general-purpose format, it was designed to be locked on javascript parsers.
> >
> > If we want a popular markup language at some expense to save people from learning new language, it should be XML - it's more popular, than anything else.
> 
> XML may pass the popularity test, but utterly fails at providing a more concise and usable experience. As far as I'm concerned, it's about finding the most "usable" language among those that are *decently* popular.

XML has clearly failed as a build specification language. I offer you Ant and Maven as evidence for the persecution of people who inflict XML as a user written file format.

Clearly I am biased, but I like internal DSLs on dynamic languages for build specification.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

> Clearly I am biased, but I like internal DSLs on dynamic languages for
> build specification.

What are DSLs?  Link?

Jonathan Marler:

> What are DSLs?  Link?

http://en.wikipedia.org/wiki/Domain-specific_language

Bye,
bearophile

On Tue, 2014-08-26 at 17:25 +0000, Jonathan Marler via Digitalmars-d wrote:
> > Clearly I am biased, but I like internal DSLs on dynamic
> > languages for
> > build specification.
> 
> What are DSLs?  Link?

Technically it is a Domain Specific Language, but the whole thing is really complicated since anyone who writes any functions or classes is creating a DSL – it is really just the notion of creating abstraction: tokens forming a language of discourse.

Internal vs external DSL: internal means a language constructed using the symbols of the base language and not requiring a compiler, cf. Boost.Spirit, anything written in a dynamic language. External DSL are those requiring some form of compilation, cf. Make. Basically internal DSL scripts are executed whereas external DSL scripts must be parsed.

In the context, Python can support an internal DSL for build, cf. SCons, Waf. Groovy can support an internal DSL for build, cf. Gant, Gradle.

http://en.wikipedia.org/wiki/Domain-specific_language is not entirely wrong ;-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:
> Am 26.08.2014 15:37, schrieb eles:
>> On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
>>> On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:
>>

> additional alternative format

SDL or D

>
>
>  I agree. Those would be the points with most impacts. However, the
>> outcome would be quite far away from standard JSON, so we would really be talking about something like ASON or SDL already.
>>
>
> There are some beginnings like this one:
>
> http://json5.org/
>

Here's another, that supports tables: https://github.com/krisnye/ion

Unfortunately there doesn't seem to be any decently popular winner of the 'extended JSON' language, apparently most are fine with just adding comments.  YAML might be a choice, but I find it diverges a bit too far (and I'm not a fan of significant whitespace).

On Tuesday, 26 August 2014 at 18:35:55 UTC, Jeremy Powers via Digitalmars-d wrote:
>>
>>
>>  I agree. Those would be the points with most impacts. However, the
>>> outcome would be quite far away from standard JSON, so we would really be
>>> talking about something like ASON or SDL already.
>>>
>>
>> There are some beginnings like this one:
>>
>> http://json5.org/
>>
>
> Here's another, that supports tables:
> https://github.com/krisnye/ion
>
> Unfortunately there doesn't seem to be any decently popular winner of the
> 'extended JSON' language, apparently most are fine with just adding
> comments.  YAML might be a choice, but I find it diverges a bit too far
> (and I'm not a fan of significant whitespace).

Well, ion already has that in its name: "indented object notation" :-(

Basic YAML is not so bad (apart from significant whitespace, which I also dislike), but the full specification is surprisingly complicated (properties, tags, lots of different ways to format text...). Even though it wouldn't be utilized in most cases, these features would still need to be supported.

SDL is preferable IMO.