On Mon, 10 Feb 2014 19:58:04 -0800, Daniel Murphy
<yebbliesnos...@gmail.com> wrote:
"Adam Wilson" wrote in message
news:op.xa21zpux707...@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
