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