One more question - an untapped audience.

[Adam Wilson]

On Mon, 10 Feb 2014 19:58:04 -0800, Daniel Murphy  
<yebbliesnospam at gmail.com> wrote:

> "Adam Wilson"  wrote in message  
> news:op.xa21zpux707hn8 at invictus.hra.local...
> Building a new IDE won't solve this problem. Here we need to focus on
>> building better tools for D, turning DMD itself into a library or  
>> Compiler-as-a-Service in the current lingo, since libraries are now  
>> "services". D needs to make great strides in tooling to be relevant, we  
>> need first-class debugging, and they need to support more than the  
>> terminal. We need D as library, we need better IDE integrations.
>
> I don't know if you've been following recent activity on the compiler,  
> but we are finally making progress in this direction.  One of the things  
> on my todo list (after the switch to D is complete) is to start making  
> the lexer/parser usable outside the compiler.
>

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.

>> We need a  broader standard library. We need more bindings for
>> existing libraries. We need more new libraries (like the Aurora library
>> I am working on).
>
> I'm starting to think phobos should not exist in its current form, and  
> it should just be a set of 'officially blessed' dub packages that meet  
> certain usefulness, API, performance and stability criteria.

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.

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.

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.

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.

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.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator