On Wednesday, 27 August 2014 at 12:44:00 UTC, eles wrote:
> On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote:
>> On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:
>
>> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
>> - Antoine de Saint-Exupery
>
> Why to not use a classic?
>
> "Within C++, there is a much smaller and cleaner language struggling to get out."
>
> He meant, of course, D. We knew it all along.

This is why dforums needs a like button:)

On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler wrote:
> IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain.  I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue.

I'm not necessarily arguing that Json is great or flexible. I'm arguing, well maybe arguing is a strong word, i'm positing that something more complicated than Json isn't really needed at this time.

I understand the argument that it would be nice for human-friendly constructs to be present in the dub file but is this really a problem dub is facing at the minute? Are lots of devs venting their spleens over not being able to include comments, heredoc strings and such in dub files? The dub registry is gaining traction lets not throw an obstacle in the road now.

Also inventing a Frankenstein format that is both a superset of Json and SDL just sounds horrible and just sounds wrong. It's just too much. Your effort would be better directed to something which is an immediate problem. Not re-inventing this particular wheel.

Sonke has said Json will always be an option in dub. Which is fantastic because now that dub has reached an official level as the de-facto package manager we need to embrace stability and stop this needless change which has been plaguing D forever.

I honestly think Ason should be abandoned as an unneeded solution looking for a problem and something more stable and recognised like Yaml or XML, etc. implemented in future *if needed* and actually if requested by dub's users.

On Wednesday, 27 August 2014 at 15:27:25 UTC, Gary Willoughby wrote:
> On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler wrote:
>> IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain.  I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue.
>
> I'm not necessarily arguing that Json is great or flexible. I'm arguing, well maybe arguing is a strong word, i'm positing that something more complicated than Json isn't really needed at this time.
>
> I understand the argument that it would be nice for human-friendly constructs to be present in the dub file but is this really a problem dub is facing at the minute?

Yes. dub is most definitely facing this problem at this minute.

> Are lots of devs venting their spleens over not being able to include comments, heredoc strings and such in dub files? The dub registry is gaining traction lets not throw an obstacle in the road now.

heredoc's is a new one, but comments/nesting/trailing commas/unquoted strings, yes, most assuredly yes. Have you not been reading people's concerns about JSON? How could you say that people aren't complaining?

>
> Also inventing a Frankenstein format that is both a superset of Json and SDL just sounds horrible and just sounds wrong. It's just too much. Your effort would be better directed to something which is an immediate problem. Not re-inventing this particular wheel.

I most definitely wouldn't call ASON a "Frankenstein" format.  I didn't design ASON to be a superset of SDL, that's just how it worked out.  Just like YAML happens to be a superset of JSON.  Instead of saying it "sounds horrible and just sounds wrong", why don't you look at the language spec and say what is wrong about it.  It's fine if you think we shouldn't use a new language but even if no one ever uses it, it's helpful to know what features people think are good/bad so we can all learn something.

>
> Sonke has said Json will always be an option in dub. Which is fantastic because now that dub has reached an official level as the de-facto package manager we need to embrace stability and stop this needless change which has been plaguing D forever.

Yes, JSON will always be used to represent the package format on the back-end.  So it makes sense to allow users to use it on the front-end if they wish.  And again, adding a new format isn't a "needless change", why do you think so many people have such strong opinions about what format to use.  You seem to be one of the only ones that thinks adding a new format (or using "lenient JSON") is a bad thing.

>
> I honestly think Ason should be abandoned as an unneeded solution looking for a problem and something more stable and recognised like Yaml or XML, etc. implemented in future *if needed* and actually if requested by dub's users.

You seem to be stuck on the idea that I think DUB should use ASON. I created this thread so I could learn from other people what they think about this format and others.  Even though you haven't added anything helpful, after reading other people's posts I'm now leaning more towards SDl.  My biggest complaint is that it might be confusing for people to go between the SDL version and the JSON version.  However, Sonke thinks that he can make a much more friendly package format with SDL's extra features like tag values/attributes.

On Wednesday, 27 August 2014 at 15:57:41 UTC, Jonathan Marler wrote:
> Even though you haven't added anything helpful...

If you don't want input, don't publicly ask for it. Just because my input is not what you would deem helpful because it contradicts your view does not mean it's of no value. I always argue from a standpoint of zero change regarding anything to do with D and always will do.

D and its tools are crying out for stability right now. Change for change sake has seriously hurt D in the past.

> Yes. dub is most definitely facing this problem at this minute.

Where? in this *one* thread?

On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky wrote:
> On 8/25/2014 6:14 PM, Idan Arye wrote:
>> On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:
>>> Hello everyone,
>>>
>>> I've been working on SDL support for DUB and wanted to get some
>>> people's opinions on whether we should really use SDL.  I've posted my
>>> thoughts here:
>>> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
>>>
>>
>> You said that "The standard way to read a dub package description is to
>> use the output of "dub describe", not to parse dub.json directly", but
>> what about tools that *write* to dub.json?
>
> ...They *continue* writing to dub.json just as before?
>
> I don't see the problem. "dub describe" isn't going to magically start failing just because it was a machine that wrote to dub.json instead of a human.
>
> You did catch the part where people keep saying that support for JSON is *not going anywhere*, right?
>
> > Currently, if an IDE wants to
>> use DUB behind the scenes as it's build system it can parse dub.json and
>> modify it as it wishes, and that should even work if someone modified
>> dub.json by hand. But what if someone modifies dub.json by hand and adds
>> ASON stuff to it?
>
> Again, use "dub describe" to read the data, then write to "dub.{whatever}".
>
> > I think we need a command like `dub normalize` that'll
>
> "dub describe"
>
>> convert the dub.json file into a pure JSON file
>
> "dub describe"
>
> >that has exactly the
>> same data, so IDEs could call it before loading dub.json.
>>
>
> I don't see the problem.

`dub describe` does not give you a normalized version of "dub.json". It gives you something else:

$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined - expected string.

Sure, the data to build a new "dub.json" is in there - after all, all the data DUB can provide is in there. But that's the problem - *all* the data DUB can provide is in there. That includes data from downloaded dependencies, system data, (possibly) local configuration data and anything can be added in the future. That's the point of `dub describe` - query for anything DUB can tell you and let the user pick what they need.

Even if the result of `dub describe` were valid for "dub.json", you wouldn't want to put all that data in the project's build-file! You want to be able to put "dub.json" under source control and for that it must only contain information about the project - not about the specific configuration of the machine of the last developer who happened to run `dub describe` and overwrite "dub.json".

`dub describe` is perfect for automated tools that want to query DUB, but it's not a solution for tools that need to modify it.

On 8/27/2014 2:38 PM, Idan Arye wrote:
> On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky wrote:
>> On 8/25/2014 6:14 PM, Idan Arye wrote:
>>> On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:
>>>> Hello everyone,
>>>>
>>>> I've been working on SDL support for DUB and wanted to get some
>>>> people's opinions on whether we should really use SDL.  I've posted my
>>>> thoughts here:
>>>> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
>>>>
>>>>
>>>
>>> You said that "The standard way to read a dub package description is to
>>> use the output of "dub describe", not to parse dub.json directly", but
>>> what about tools that *write* to dub.json?
>>
>> ...They *continue* writing to dub.json just as before?
>>
>> I don't see the problem. "dub describe" isn't going to magically start
>> failing just because it was a machine that wrote to dub.json instead
>> of a human.
>>
>> You did catch the part where people keep saying that support for JSON
>> is *not going anywhere*, right?
>>
>> > Currently, if an IDE wants to
>>> use DUB behind the scenes as it's build system it can parse dub.json and
>>> modify it as it wishes, and that should even work if someone modified
>>> dub.json by hand. But what if someone modifies dub.json by hand and adds
>>> ASON stuff to it?
>>
>> Again, use "dub describe" to read the data, then write to
>> "dub.{whatever}".
>>
>> > I think we need a command like `dub normalize` that'll
>>
>> "dub describe"
>>
>>> convert the dub.json file into a pure JSON file
>>
>> "dub describe"
>>
>> >that has exactly the
>>> same data, so IDEs could call it before loading dub.json.
>>>
>>
>> I don't see the problem.
>
> `dub describe` does not give you a normalized version of "dub.json". It
> gives you something else:
>
> $ dub init
> Successfully created an empty project in '/tmp/dub-test'.
> $ dub describe > dub.json.new
> $ mv dub.json.new dub.json
> $ dub describe
> Error executing command describe: Got .name of type undefined - expected
> string.
>

Ok, I see now. Yea, that could be improved. Luckily it shouldn't be a difficult feature to add, though.

> `dub describe` is perfect for automated tools that want to query DUB,
> but it's not a solution for tools that need to modify it.

Well, it would probably work, it just wouldn't be an ideal solution. But again, that "dub normalize" you suggest (or "dub describe --normalize" or something) should do the trick. So it doesn't appear to be a deal-breaker for supporting another language, it's just an additional TODO for dub.

On Wednesday, 27 August 2014 at 19:06:29 UTC, Nick Sabalausky wrote:
> On 8/27/2014 2:38 PM, Idan Arye wrote:
>> On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky wrote:
>>> On 8/25/2014 6:14 PM, Idan Arye wrote:
>>>> On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:
>>>>> Hello everyone,
>>>>>
>>>>> I've been working on SDL support for DUB and wanted to get some
>>>>> people's opinions on whether we should really use SDL.  I've posted my
>>>>> thoughts here:
>>>>> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
>>>>>
>>>>>
>>>>
>>>> You said that "The standard way to read a dub package description is to
>>>> use the output of "dub describe", not to parse dub.json directly", but
>>>> what about tools that *write* to dub.json?
>>>
>>> ...They *continue* writing to dub.json just as before?
>>>
>>> I don't see the problem. "dub describe" isn't going to magically start
>>> failing just because it was a machine that wrote to dub.json instead
>>> of a human.
>>>
>>> You did catch the part where people keep saying that support for JSON
>>> is *not going anywhere*, right?
>>>
>>> > Currently, if an IDE wants to
>>>> use DUB behind the scenes as it's build system it can parse dub.json and
>>>> modify it as it wishes, and that should even work if someone modified
>>>> dub.json by hand. But what if someone modifies dub.json by hand and adds
>>>> ASON stuff to it?
>>>
>>> Again, use "dub describe" to read the data, then write to
>>> "dub.{whatever}".
>>>
>>> > I think we need a command like `dub normalize` that'll
>>>
>>> "dub describe"
>>>
>>>> convert the dub.json file into a pure JSON file
>>>
>>> "dub describe"
>>>
>>> >that has exactly the
>>>> same data, so IDEs could call it before loading dub.json.
>>>>
>>>
>>> I don't see the problem.
>>
>> `dub describe` does not give you a normalized version of "dub.json". It
>> gives you something else:
>>
>> $ dub init
>> Successfully created an empty project in '/tmp/dub-test'.
>> $ dub describe > dub.json.new
>> $ mv dub.json.new dub.json
>> $ dub describe
>> Error executing command describe: Got .name of type undefined - expected
>> string.
>>
>
> Ok, I see now. Yea, that could be improved. Luckily it shouldn't be a difficult feature to add, though.
>
>> `dub describe` is perfect for automated tools that want to query DUB,
>> but it's not a solution for tools that need to modify it.
>
> Well, it would probably work, it just wouldn't be an ideal solution. But again, that "dub normalize" you suggest (or "dub describe --normalize" or something) should do the trick. So it doesn't appear to be a deal-breaker for supporting another language, it's just an additional TODO for dub.

I don't like `dub describe --normalize` - it implies that the regular `dub describe` is in some non-normalize format and adding this flag will normalize the output. If you want to add normalization as a `dub describe` flag, I'd prefer something like `dub describe --buildfile-only`

On 8/27/2014 5:27 AM, Sönke Ludwig wrote:
> Am 27.08.2014 10:02, schrieb Kagamin:
>> On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:
>>> That's somewhat misleading.
>>>
>>> More accurately, SDL is newline-delimited (with backslash line
>>> continuation). That's pretty darn simple and has an age-old history.
>>> It's not like we're talking weird Python/JavaScript rules or anything
>>> here.
>>>
>>> The only thing that does trip people up is that the existence of { and
>>> } in the syntax makes people think "C-family and therefore freeform".
>>> And then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!"
>>> Well...or something vaguely sorta kinda like that ;)
>>
>> That's justified, because SDL fails to not surprise. Curly brace
>> syntaxes are not line-delimited not requires backslash line
>> continuations.

Yea, I'll grant it *is* somewhat of a blemish in SDL's design. But I don't think it's a critical one.

Besides, this thread's (dare I say "bikeshedded"?) quest for an ideal data language seems doomed from the start: If we try to avoid the less common ones, and avoid inventing our own (which I think we have good reason to avoid), then everything left *does* have imperfections.

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?"

>
> Like JavaScript for example?
>

Heh, there is that.


>>
>> What's wrong with XML? I work with it daily and see no problem. The less
>> syntax a language has, the worse it scales, and if it doesn't scale, its
>> adoption creates a technical debt. 100 lines with 3 levels of nesting
>> and JSON becomes hard to follow and TOML becomes simply unmanageable.
>
> The reason to search for an additional format is to make it more
> convenient and readable for human interaction. XML wouldn't structurally
> a bad choice, but is awful because of it's syntactical overhead.

That's a big one. *The* big one in my mind.

Additionally, despite XML's simplistic appearance, some of the details about it get disturbingly over-engineered. Heck, take a look at W3C's docs on it: for something that's *supposed* to be as simple as:

<tag1>
    <tag2 attr="value">blah</tag2>
    <tag3 />
</tag1>

For something that *appears* to be that simple, it's formal reality is horrifically complicated.

Besides, there's nothing stopping a good editor from taking this:

{
    "tag1" : {
        ...blah, blah, blah, blah...
        ...blah, blah, blah, blah...
        ...blah, blah, blah, blah...
        ...blah, blah, blah, blah...
    }
}

And adding helper visuals (not part of the actual document) to display it as this:

{
    "tag1" : {
        ...blah, blah, blah, blah...
        ...blah, blah, blah, blah...
        ...blah, blah, blah, blah...
        ...blah, blah, blah, blah...
    }  <i>"tag1"</i>
} <i>{root}</i>

(The <i></i> wouldn't be displayed, I just put them there to indicate the text inside would be visually distinguished so that the user finds it obvious it's not actually part of the document. Can't really emulate that in a NG post.)

I don't know why no editors ever do that.

On 8/27/2014 12:57 PM, Gary Willoughby wrote:
>
> D and its tools are crying out for stability right now. Change for
> change sake has seriously hurt D in the past.
>

It's also been a critical factor in it's success.

Double-edged sword, admittedly.

On 8/27/2014 3:26 PM, Idan Arye wrote:
>
> I don't like `dub describe --normalize` - it implies that the regular
> `dub describe` is in some non-normalize format and adding this flag will
> normalize the output. If you want to add normalization as a `dub
> describe` flag, I'd prefer something like `dub describe --buildfile-only`

Yea, that's better. I just meant "Maybe a flag for 'describe' rather than a separate dub command." and didn't feel like coming up with an alternative name. :)