On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
> On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
> > Why not YAML? It's cleaner than JSON and is very widely known.
> 
> YAML is just plain evil. It doesn't ignore whitespace.
[...]

It's funny. I used to think Python is evil for the same reason, but after having played with it a little (mostly in SCons build scripts, though, not full-fledged Python programs), I've come to actually like it. It *is* rather refreshing to _not_ have those cascading '}'s trailing every function body, taking up precious screen real estate. And reindenting code doesn't require tedious checking to make sure those {'s and }'s still line up as they ought.

I'd say that it's an acquired taste, at least for me. :)

But I've never used YAML, so I can't say whether or not I'd like it.

One thing I find lacking in these purported configuration file formats, is the lack of built-in facility for cascading, and formatting long values nicely.  In my own personal projects, I use a format that allows cascading, in which the program first loads a base configuration, which is then selectively overridden by subsequent configuration files specified by the user, command-line arguments, or direct user input, of which there can be arbitrarily many overlays. This is especially useful in programs where you run many times, each time with mostly the same settings as the previous time, just slightly tweaked. Instead of retyping (or copy-n-pasting, or scroll history + edit) 50 different settings each time, you put them into files containing 5-10 settings each (in fact, one file for each variant of the same 5-10 settings, if you're so inclined), and freely combine them in various ways, plus specify a few on-the-fly settings on the command-line, say.

As for long values, I've always disliked the fact that almost all formats provide a way to wrap them across multiple lines, but almost none of them let you indent the result nicely without also changing the value.  This is important for complex configuration formats that have nested groups of settings. In my format, the syntax is specifically catered for this use case, for example:

	# This is a comment
	value1 = "This is a very long value \
	         \split across multiple \
	         \lines."
	value2 = "A short value"

	module1 {
		# These values are in a nested scope, so they are
		# distinct from the settings above.
		value1 = "This is another long \
		         \value split across \
		         \multiple lines."
		value2 = "This is a value \
		         \with an embedded \   # a long value
		         \comment!"
	}

The \'s at the end of the line begin a continuation escape sequence that spans until the first \ on the following line, thus allowing arbitrary indentation. The resulting value is a concatenation of the stuff before the first \ and after the second \. You can even place a comment in between them, for documentation purposes.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL

Am 11.09.2013 20:04, schrieb H. S. Teoh:
> On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
>> On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
>>> Why not YAML? It's cleaner than JSON and is very widely known.
>>
>> YAML is just plain evil. It doesn't ignore whitespace.
> [...]
>
> It's funny. I used to think Python is evil for the same reason, ...

Haskell and F# are just as evil. :)

On Wednesday, September 11, 2013 20:12:40 Paulo Pinto wrote:
> Am 11.09.2013 20:04, schrieb H. S. Teoh:
> > On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
> >> On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
> >>> Why not YAML? It's cleaner than JSON and is very widely known.
> >> 
> >> YAML is just plain evil. It doesn't ignore whitespace.
> > 
> > [...]
> > 
> > It's funny. I used to think Python is evil for the same reason, ...
> 
> Haskell and F# are just as evil. :)

At least with haskell, it's generally far more straightforward due to Haskell's function nature, and you _can_ choose to use braces and semicolons if you want to.

- Jonathan M Davis

On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:
> On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
> > On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
> > > Why not YAML? It's cleaner than JSON and is very widely known.
> > 
> > YAML is just plain evil. It doesn't ignore whitespace.
> 
> [...]
> 
> It's funny. I used to think Python is evil for the same reason,

Well, I hate that about python too, but what I _really_ hate about python is that it's dynamic. It shouldn't be possible to do things like change the type of a variable based on whether an if condition was true or not (or change the type of a variable at all for that matter). I use python at work when I need to use a scripting language, because it's the best option that I have there, but otherwise, I'd just use D.

> But I've never used YAML, so I can't say whether or not I'd like it.

JSON is a subset of YAML 1.2, so they're very similar. Probably the most obvious differences are that you don't need as many quotes in YAML, and whitespace matters. I've had to deal with it some at work, and I hope to never have to deal with it elsewhere.

- Jonathan M Davis

On Tuesday, September 10, 2013 13:48:58 Andrei Alexandrescu wrote:
> We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project.
> 
> We're considering making dub the official package manager for D. What do you all think?

I don't know if it's quite ready for that or not, but I've started using it for most of my stuff. It feels kind of limited to me, and I'm inclined to think that it will need more advanced build configuration abilities in the future (it essentially does what rdmd does, whereas some projects will need something more along the lines of full-on make capabilities), but for basic stuff, it works just fine.

Certainly, I have no problem with aiming for dub becoming the official package manager, and if we think that it's ready for that now and that whatever shortcomings it currently has can be sorted out later, then I have no problem with it becoming the official package manager now.

- Jonathan M Davis

On 2013-09-11 14:29, Dicebot wrote:

> Because it is current D reality. Package that do not get updated to
> latest front-end version are used only if there is absolutely no other
> choice. Amount of inconvenience it causes to the user of the package is
> tremendous.

I don't understand the inconvenience. Just have multiple compilers installed. It's not rocket science.

-- 
/Jacob Carlborg

On 2013-09-11 17:09, Dicebot wrote:

> Those should be provided as sources and built by dub too. Distributing
> binary packages requires both package signing and reasonable web of
> trust - something that is not easy to "just implement" from scratch.
> Otherwise any single malicious package may ruin reputation of the whole
> system.

I have no problems with the packages being distributed as source. That makes a lot of things easier. But it should compile and install it when it's downloaded. Currently it only clones the repository. Not giving much more than a plain "git clone".

-- 
/Jacob Carlborg

On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:
> On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:
> > On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
> > > On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
> > > > Why not YAML? It's cleaner than JSON and is very widely known.
> > > 
> > > YAML is just plain evil. It doesn't ignore whitespace.
> > 
> > [...]
> > 
> > It's funny. I used to think Python is evil for the same reason,
> 
> Well, I hate that about python too, but what I _really_ hate about python is that it's dynamic. It shouldn't be possible to do things like change the type of a variable based on whether an if condition was true or not (or change the type of a variable at all for that matter).

Yeah, this is something oft touted as being 'convenient' and 'easy', but then in production code, you find yourself writing type checks anyway just to make sure what's passed in is what you expect. (And things blow up in horrible ways when some stray code passes in something with the wrong type.) Which defeats the purpose of having a dynamic language in the first place.


> I use python at work when I need to use a scripting language, because it's the best option that I have there, but otherwise, I'd just use D.

Well, that's why we're here, right? :) If I were fully happy with Python, or whatever else it is out there, I wouldn't be here in the first place.


> > But I've never used YAML, so I can't say whether or not I'd like it.
> 
> JSON is a subset of YAML 1.2, so they're very similar. Probably the most obvious differences are that you don't need as many quotes in YAML, and whitespace matters. I've had to deal with it some at work, and I hope to never have to deal with it elsewhere.
[...]

Wait, how can JSON be a subset of YAML if whitespace in YAML is significant, but it isn't in JSON?


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

On Wednesday, 11 September 2013 at 20:05:18 UTC, Jacob Carlborg wrote:
> On 2013-09-11 14:29, Dicebot wrote:
>
>> Because it is current D reality. Package that do not get updated to
>> latest front-end version are used only if there is absolutely no other
>> choice. Amount of inconvenience it causes to the user of the package is
>> tremendous.
>
> I don't understand the inconvenience. Just have multiple compilers installed. It's not rocket science.

Different front-end versions are not guaranteed to be ABI compatible. You always need to use same compiler version within one application and using library that is not updated to latest version forces you to use that old version in your own code too.

On Wed, Sep 11, 2013 at 10:07:02PM +0200, Jacob Carlborg wrote:
> On 2013-09-11 17:09, Dicebot wrote:
> 
> >Those should be provided as sources and built by dub too. Distributing binary packages requires both package signing and reasonable web of trust - something that is not easy to "just implement" from scratch.  Otherwise any single malicious package may ruin reputation of the whole system.

The same can be said of malicious source code. Just because it wasn't precompiled for you doesn't mean you're going to read through every line to ensure there are no malicious bits before compiling and using it. Using the package at all -- regardless of whether it's source or binary -- implies a certain level of trust already.


> I have no problems with the packages being distributed as source. That makes a lot of things easier. But it should compile and install it when it's downloaded. Currently it only clones the repository. Not giving much more than a plain "git clone".
[...]

How would it know which compiler(s) to use to compile the packages? What if you have multiple compilers / development environments with incompatible ABIs?


T

-- 
I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller