On Mon, 10 Feb 2014 22:07:50 -0800, Daniel Murphy
<yebbliesnos...@gmail.com> wrote:
"Adam Wilson" wrote in message
news:op.xa3n27el707...@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.
I suppose as long as it's available by default that's OK.
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.
That'd be quite good actually. :-) Although at this point I don't see much
advantage, either way.
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
