On 8/27/14, 5:25 AM, Gary Willoughby wrote:
> On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:
>> I just had an "epiphany".  I believe that if I added attributes to
>> ASON, it would be a true superset of SDL.  Meaning any SDL file would
>> also be a valid ASON file.  What kind of monster did I create!  I
>> accidently created a language that serves as both a superset of JSON
>> and SDL?  I didn't think that would be possible, expecially with such
>> a little amount of extensions to JSON.
>
> Perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away.
> - Antoine de Saint-Exupery

Then perfection in personal finance is easy to achieve :o). -- Andrei

On Wednesday, 27 August 2014 at 19:30:35 UTC, Nick Sabalausky wrote:
> 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.)

You just acknowledged succinct languages don't scale, and the only way to make them scale is to turn them into syntactical equivalent of XML with closing tags. And even then more verbose than XML itself. So what's a difference from XML if good config language still must have XML syntax?

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

The editors show only what's written and written is JSON, not JSON++.

On 8/28/2014 5:29 AM, Kagamin wrote:
> On Wednesday, 27 August 2014 at 19:30:35 UTC, Nick Sabalausky wrote:
>> 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.)
>
> You just acknowledged succinct languages don't scale,

No, I've only acknowledged that they don't exhibit *perfect* scaling. They certainly still scale. And they can scale even better with a little editor help.

> and the only way
> to make them scale is to turn them into syntactical equivalent of XML
> with closing tags. And even then more verbose than XML itself. So what's
> a difference from XML if good config language still must have XML syntax?
>

The differences (off the top of my head, there may be more):

- Nobody has to actually write the closing
- Nobody had to keep the opening/closing in sync
- The closing takes up zero bytes
- Nobody has to actually look at the closing if they want to reduce the visual clutter: Ie, viewing it is an optional thing.

>> I don't know why no editors ever do that.
>
> The editors show only what's written and written is JSON, not JSON++.

My editor shows all sorts of stuff that ain't written. Line numbers, 80-col mark, visible whitespace/EOLs, indent guides, a horizontal line to denote folded code sections, etc. You're not going to split hairs and claim those are fundamentally/meaningfully different from what I'm suggesting are you?

On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky wrote:
> On 8/28/2014 5:29 AM, Kagamin wrote:
>> and the only way
>> to make them scale is to turn them into syntactical equivalent of XML
>> with closing tags. And even then more verbose than XML itself. So what's
>> a difference from XML if good config language still must have XML syntax?
>>
>
> The differences (off the top of my head, there may be more):
>
> - Nobody has to actually write the closing
> - Nobody had to keep the opening/closing in sync
> - The closing takes up zero bytes
> - Nobody has to actually look at the closing if they want to reduce the visual clutter: Ie, viewing it is an optional thing.

So it has no advantage over using a grammar-based XML editor, just less flexible and more clumsy… Sounds like the wrong trade-off.

(tags don't take much space when the file is compressed)

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/

Wait, SDL is not Simple DirectMedia Layer ?

You broke my hope.

On Wed, 27 Aug 2014 16:57:52 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> D and its tools are crying out for stability right now.
there is D1. stable as a doornail.

On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

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


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).

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

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.

On Friday, 29 August 2014 at 02:10:47 UTC, Jeremy Powers via Digitalmars-d wrote:
> On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> 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?"
>>
>
>
> 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).

I can totally see JSON format being used mostly by the tools and new one written by actual developers - everyone gets its niche.

On 8/28/2014 9:57 PM, Poyeyo 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/
>>
>
> Wait, SDL is not Simple DirectMedia Layer ?
>
> You broke my hope.

Yea, that unfortunate little naming conflict is why I named my parser for it SDLang-D instead of SDL-D.

On 8/28/2014 5:07 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky wrote:
>> On 8/28/2014 5:29 AM, Kagamin wrote:
>>> and the only way
>>> to make them scale is to turn them into syntactical equivalent of XML
>>> with closing tags. And even then more verbose than XML itself. So what's
>>> a difference from XML if good config language still must have XML
>>> syntax?
>>>
>>
>> The differences (off the top of my head, there may be more):
>>
>> - Nobody has to actually write the closing
>> - Nobody had to keep the opening/closing in sync
>> - The closing takes up zero bytes
>> - Nobody has to actually look at the closing if they want to reduce
>> the visual clutter: Ie, viewing it is an optional thing.
>
> So it has no advantage over using a grammar-based XML editor, just less
> flexible and more clumsy… Sounds like the wrong trade-off.
>

I could easily turn that around and say a grammar-based XML editor has no advantage over my suggestion. I certainly don't see what's "less flexible" about it. And I find some of the tricks that grammar-based XML editors do to be clumsy and in-my-way (specifically when they automagically insert text I didn't type).

*Without* any editor support, JSON-style and XML-style both have pro/con tradeoffs. I prefer the JSON-style tradeoffs.

*With* an ideal level of editor support, JSON-style and XML-style can pretty much reach feature parity.

I still hate dealing with XML though ;)

> (tags don't take much space when the file is compressed)
>

If it really needs to be compressed, then the format may be too verbose anyway. It doesn't really strike me as passing the "less clumsy" criteria either. Ehh, but I'm a fan of binary for interchange anyway, so whatever ;)