One more question - an untapped audience.
Adam Wilson
flyboynw at gmail.com
Mon Feb 10 23:06:51 PST 2014
On Mon, 10 Feb 2014 22:07:50 -0800, Daniel Murphy
<yebbliesnospam at gmail.com> wrote:
>> "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.
>
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
More information about the Digitalmars-d
mailing list