September 02, 2014
On 9/2/2014 5:33 AM, Kagamin wrote:
> On Friday, 29 August 2014 at 19:53:26 UTC, Nick Sabalausky wrote:
>>> True for XML too:
>>> 1. many editors already autocomplete it, no need to wonder, why nobody
>>> implemented it;
>>
>> Personally, I don't like that auto-insert stuff, it just trips me up.
>
> Didn't you argue for autoinserting? If you don't want it, you can turn
> it off (it's implemented).
>

I think it's great that it exists *for the people who DO like it*. I'm just not one of them. It conflicts with my automatic muscle memory and my deep-ingrained mental model of keyboard-based computer interaction. :/

>
> Your suggestion is a hack

It's no more of a hack than ANY modern editor feature.

Besides, that's not even an argument anyway, it's subjective bullshit.

I've pointed out over and over how this and other editor features effectively bring the two styles of closing tokens into parity (again, assuming one is ok with auto-insert, which many people are). Why are you so determined to completely ignore that argument?


> and less popular than XML.

That's even more nonsensical: You're not actually going to use popularly as an argument in a merit-oriented debate, are you?

"That's a flawed idea *because* it's not popular." See? Obviously doesn't work.


> Though, I don't see
> why create the problem with succinct language and then heroically solve
> it? (oh, wait, not yet)

Are you deliberately ignoring the part (which I've already pointed out) where this is obviously not limited to merely JSON alone, or even just data-formats, at all, but generally applicable to any language which uses a single same token to terminate all types of nested blocks?

If you're going to argue something, at least *attempt* to address the actual points that have been raised. Otherwise there's no point in discussing anything.


September 02, 2014
On Tuesday, 26 August 2014 at 09:43:21 UTC, Sönke Ludwig wrote:
> Am 26.08.2014 00:14, schrieb Idan Arye:
>> On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

What about enhancing the command-line interface of dub to reduce the need of editing the dub.json/dub.sdl file. For example:

dub depadd "name" "version"
dub depdel "name"
dub depmod "name" "newversion"

Configurations etc could be handled in the same way.

This way, for many use cases, editing the text file won't even be needed.

September 30, 2014
On 25/08/2014 17:40, 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/

My opinion on this subject had been a preference that we use an extension to JSON (something like lenient JSON, for example: http://developer.android.com/reference/android/util/JsonReader.html#setLenient%28boolean%29 )
I don't like SDL much (because it's not that well-known, is whitespace sensitive, and other reasons). But that's mostly a personal preference, SDL is not a bad choice either.

Still, when I read that ASON was being developed, as a possible alternative, it looked good, since ASON seemed similar to lenient-JSON. But then things took a turn to the worse. Nameless fields, because it makes the parsing application specific, is a bad idea. The data format should be universal, not application specific. The table feature is another thing I think is unnecessary, we should try to the keep the data format fairly simple (there's only a few things over plain JSON that I think are worth improving). But I think the real dealbreaker is being application specific. Given this, I would prefer even SDL to ASON.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
September 30, 2014
On 09/30/2014 08:15 AM, Bruno Medeiros wrote:
>
> I don't like SDL much (because it's not that well-known, is whitespace
> sensitive, and other reasons). But that's mostly a personal preference,
> SDL is not a bad choice either.
>

FWIW, the only "whitespace" sensitivity in SDL is just the fact that it's newline-terminated (with optional line-continuation). (Well, and the auto-unindending of string literals that use line-continuation.) That's really all there is. Again, just FWIW.

September 30, 2014
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/

So by ASON, do you mean:
http://www.americanteeth.org/libason/ason_spec.pdf ?  Weirdly
enough, this was published the same day you say you created ASON,
and yet my take on your ASON vs. this ASON is that they're very
different.
September 30, 2014
On Tuesday, 30 September 2014 at 22:41:15 UTC, Sean Kelly 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/
>
> So by ASON, do you mean:
> http://www.americanteeth.org/libason/ason_spec.pdf ?  Weirdly
> enough, this was published the same day you say you created ASON,
> and yet my take on your ASON vs. this ASON is that they're very
> different.

Oops, for some reason I thought this was a new thread...
2 3 4 5 6 7 8 9 10 11 12
Next ›   Last »