One more question - an untapped audience.

[Daniel Murphy]

> "Adam Wilson"  wrote in message 
> news:op.xa3n27el707hn8 at invictus.hra.local...

> To be honest I haven't been following it closely as I've been buried in 
> work projects and Aurora. It would be awesome if that came sometime later 
> this year. We badly need those capabilities, and I imagine that hacking on 
> the compiler itself will get much easier when it's converted to D.

No guarantees.

> I don't know if I can express how strongly I disagree with that sentiment. 
> I don't use dub, I don't really want to use dub, and I am virtually 
> certain that the whole concept of using dub is a going to make newbie 
> acceptance much more difficult. D is supposed to make life easier, not 
> harder.

As Mike Parker said, that doesn't match my experience, and it seems to work 
for python/ruby/etc

> DUB is great if you're an experienced linux dev. But for somebody just 
> getting started, especially those coming from other languages with 
> standard libraries (aka, all of them) the idea of having to use a package 
> manager to do anything is completely backwards. We need to be reducing our 
> project setup times, not increasing them by making people download the 
> same 10 packages for every project they start. People want to download a 
> language and start writing code. Not faff about with getting the right 
> package configuration just to write some output to the console.

The situation you describe sounds bad, but I'm not sure that's the situation 
with dub.  Obviously I don't want us to move to a worse situation.

> It is also very helpful to have a standardized set of capabilities that I 
> can rely on existing at a minimum in all configurations. This is critical 
> in a code-generation context when you are building code for an unknown 
> environment where the only certain capabilities you have are the stdlib 
> and any libraries you provide. And yes, I have a code generation project 
> planned for D later this year that is very important to my company. 
> Killing the standard library would effectively cancel that project and end 
> my involvement in D, as we can't convert to D without this code-gen 
> project. I make this point not to try to hold D hostage to myself, D 
> should never be held hostage by the needs of any one entity, but that 
> having a stdlib available by default is extremely useful in certain cases 
> and by removing it you make those cases exponentially more difficult if 
> not impossible to achieve.

I don't understand this at all.  We wouldn't stop shipping phobos with the 
compiler, it would just be in the format of a dub repo/several dub repos 
instead of it's own thing.

> If anything Phobos needs to get bigger and increase the coverage standard 
> available functionality. We can talk about improvements to reduce module 
> dependencies, and improve layout, design, and code quality, but none of 
> those are sufficient reasons in my mind to through out the idea of a 
> stdlib altogether.

Maybe I should have said it differently.  I don't want to throw out the 
_concept_ of phobos, just normalize it a little with the concept of 
third-party packages.  Phobos would still be officially supported, 
regression tested, code reviewed etc

My hope is that this would improve the quality and quantity of phobos, 
because third-party modules meeting the high standards could be moved into 
phobos, and unmaintained or obsolete modules could be moved out without 
horrific breakage.

> The only way I could accept that is if D integrated DUB directly into it's 
> source code and downloaded and installed packages silently in the 
> background when one of the imports matches a DUB package import. But I 
> don't see that happening anytime soon.

I can certainly imagine a world where `rdmd proj.d` will automagically fetch 
dub packages for you.