On Wednesday, 11 March 2015 at 07:19:57 UTC, Vladimir Panteleev wrote:
> What is indubitably, actually, very important, and something I'm surprised you haven't pushed for since long ago, is making it EASY to get more things. Dub absolutely must be a part of D, and not today but one or more years ago. There is now a rift in this community, between people who use code.dlang.org and its packages, and those who do not.

And those of us who don't use dub are *not* going to magically
start using dub just because it is bundled with dmd. I don't use
dub because it doesn't benefit me in any way, and really only
gets in my way.

> Coming from a language with a package manager, and then trying to build a project with a dozen dependencies by manually cloning the repositories and making sure they are the correct version, is madness. A package manager encourages people to build many small reusable components, because the overhead of managing each component becomes very small, and this is something we really want.

And any package manager that only operates in source, demands
a central repository (that effectively just redirects to the
actual Git repos), and only works for one language is utterly
worthless for real world projects.

Not to mention, putting extra tools like dustmite and dub in dmd
will only ever benefit dmd users, not those of us who use ldc or
gdc.

Ignoring that for a moment, where does it stop? Do we include an
editor? [sarcasm] Why not? Every D developer needs to edit their
code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
and bundle that with dmd. [/sarcasm]

On 3/11/15 9:27 AM, Anon wrote:
> On Wednesday, 11 March 2015 at 07:19:57 UTC, Vladimir Panteleev wrote:
>> What is indubitably, actually, very important, and something I'm
>> surprised you haven't pushed for since long ago, is making it EASY to
>> get more things. Dub absolutely must be a part of D, and not today but
>> one or more years ago. There is now a rift in this community, between
>> people who use code.dlang.org and its packages, and those who do not.
>
> And those of us who don't use dub are *not* going to magically
> start using dub just because it is bundled with dmd. I don't use
> dub because it doesn't benefit me in any way, and really only
> gets in my way.

That's fine. The thing about tooling is it can be ignored if found unnecessary. The trick is providing tooling that works well for a majority of users and that the other tools may assume they exist.

>> Coming from a language with a package manager, and then trying to
>> build a project with a dozen dependencies by manually cloning the
>> repositories and making sure they are the correct version, is madness.
>> A package manager encourages people to build many small reusable
>> components, because the overhead of managing each component becomes
>> very small, and this is something we really want.
>
> And any package manager that only operates in source, demands
> a central repository (that effectively just redirects to the
> actual Git repos), and only works for one language is utterly
> worthless for real world projects.
>
> Not to mention, putting extra tools like dustmite and dub in dmd
> will only ever benefit dmd users, not those of us who use ldc or
> gdc.

That's entirely reasonable. Each distribution has the freedom to bundle whichever tools it finds fit.

I would agree it would be bad if dustmite and dub were locked-in to only work with dmd. Is that the case?

> Ignoring that for a moment, where does it stop? Do we include an
> editor? [sarcasm] Why not? Every D developer needs to edit their
> code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
> and bundle that with dmd. [/sarcasm]

Probably "where does it stop" is a good question to ask later.


Andrei

On Wednesday, 11 March 2015 at 16:35:22 UTC, Andrei Alexandrescu wrote:
> On 3/11/15 9:27 AM, Anon wrote:
>> Not to mention, putting extra tools like dustmite and dub in dmd
>> will only ever benefit dmd users, not those of us who use ldc or
>> gdc.
>
> That's entirely reasonable. Each distribution has the freedom to bundle whichever tools it finds fit.

My point with that (that I forgot to actually type) was that I
feel there would be better mileage if D tools were packaged up
and provided apart from the compiler. Then the same tools set
can be used regardless of compiler choice, and (perhaps more
importantly) update independently of DFE updates. Some tools
are dependent on the compiler being used, and wouldn't work for
independent distribution, but for the others, it makes more
sense (to me anyway) to make that a separate download.
Of course, installers could be set up to also download that
zip if desired.

By way of example, I'd expect clang-format to be bundled with
clang, but I wouldn't expect (or want) valgrind to be bundled
with clang or gcc. I could however, see the value of a single
download that included valgrind and astyle.

> I would agree it would be bad if dustmite and dub were locked-in to only work with dmd. Is that the case?

Not to my knowledge, but binary releases for most dmd tools are
only available with dmd, which is not ideal. It also creates
a potential ambiguity, since dmd is not redistributable
without explicit permission from Walter, but most of the tools
included with dmd are. Separating the tools from the compiler
allows a very easy line to be drawn between what is and might
not be redistributable.

On Wednesday, 11 March 2015 at 08:57:14 UTC, Rikki Cattermole wrote:
> On 11/03/2015 9:00 p.m., Vladimir Panteleev wrote:
>> On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:
>>> It doesn't seem so to me. You find easy weaknesses in my vision and
>>> pump on them instead of working on making it stronger. That's the easy
>>> "but that business won't work, and here are the reasons why" approach.
>>> The harder part is finding ways to make it work by overcoming its
>>> weaknesses.
>>
>> Here is a counter-proposal:
>>
>> 1. Add Dub to D.
>>
>> 2. Add a "web development" link in the sidebar, which simply links to
>> vibed.org.
>>
>> 3. Add an example on the front page on how to create a simple web
>> server. It needs to list only main.d and package.json, and the dub
>> command line to build it. A package.json will be needed for non-trivial
>> things anyway, so might as well get that out of the way anyway.
>>
>> 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do
>> this by making forum.dlang.org connect to it via NNTP.
>>
>> I think this will achieve much of your goal without the drawbacks.
>
> I would like to add putting focus on getting libasync[0] phobos ready instead of the vibe.d direction.
>
> It might be a lot younger, but it is also have a lot smaller scope.
>
> Perhaps even a rewrite of std.socket to use it?
>
> It is a lot of work, but its probably a more manageable unit of work in the short term.
>
> [0] https://github.com/etcimon/libasync

+1
While vibe.d might be too big(?) for phobos, async sockets and file I/O would be awesome.

On Wednesday, 11 March 2015 at 05:43:17 UTC, Vladimir Panteleev wrote:
> Furthermore, Vibe is a library, with its own possibly-unstable API. Some projects may want to use an older version of Vibe with a newer version of the compiler. This is hypothetical, correct me if I'm wrong.
>
> I think your vision of including Vibe with D is misguided. Ripping out just the core of what is now an ecosystem may even be a faux pas. Including Vibe without Dub is certainly a mistake, because inter-component versioning relies on Dub. And if you have Dub, Vibe and its components (including any older versions of such) are, like I said, a command away.

Couldn't agree more.

On Wednesday, 11 March 2015 at 08:00:22 UTC, Vladimir Panteleev wrote:
> On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:
>> It doesn't seem so to me. You find easy weaknesses in my vision and pump on them instead of working on making it stronger. That's the easy "but that business won't work, and here are the reasons why" approach. The harder part is finding ways to make it work by overcoming its weaknesses.
>
> Here is a counter-proposal:
>
> 1. Add Dub to D.
>
> 2. Add a "web development" link in the sidebar, which simply links to vibed.org.
>
> 3. Add an example on the front page on how to create a simple web server. It needs to list only main.d and package.json, and the dub command line to build it. A package.json will be needed for non-trivial things anyway, so might as well get that out of the way anyway.
>
> 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do this by making forum.dlang.org connect to it via NNTP.
>
> I think this will achieve much of your goal without the drawbacks.

Excellent points and thank you so much for defending DUB and the ecosystem :)

On 2015-03-11 17:27, Anon wrote:

> Ignoring that for a moment, where does it stop? Do we include an
> editor? [sarcasm] Why not? Every D developer needs to edit their
> code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
> and bundle that with dmd. [/sarcasm]

I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's.

-- 
/Jacob Carlborg

On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote:
> On 2015-03-11 17:27, Anon wrote:
>
>> Ignoring that for a moment, where does it stop? Do we include an
>> editor? [sarcasm] Why not? Every D developer needs to edit their
>> code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
>> and bundle that with dmd. [/sarcasm]
>
> I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's.

That's an IDE that includes a compiler, not a compiler that includes an IDE. You aren't downloading cl, you're downloading VisualStudio. That you also get cl is an implementation detail. If Bruno wanted to release a build of Eclipse+DDT that came with a compiler, I'd have no problem with that.

On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote:
> On 2015-03-11 17:27, Anon wrote:
>
>> Ignoring that for a moment, where does it stop? Do we include an
>> editor? [sarcasm] Why not? Every D developer needs to edit their
>> code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
>> and bundle that with dmd. [/sarcasm]
>
> I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's.

The SDKs ship with Visual Studio, not the other way around. Both the Windows SDK and .NET Framework/SDK are separate products. The .NET Framework itself includes the .NET compiler, which Visual Studio uses, and the Windows SDK includes cl.exe which is the C/C++ compiler. Neither require Visual Studio.

It's good to have a single installer that includes everything you need to get started (dmd, dub, IDE / IDE plugin) like Visual Studio is (cl/csc, Nuget, VS), but the compiler itself should definitely not ship with an IDE.

On Wednesday, 11 March 2015 at 08:00:22 UTC, Vladimir Panteleev wrote:
> On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:
>> It doesn't seem so to me. You find easy weaknesses in my vision and pump on them instead of working on making it stronger. That's the easy "but that business won't work, and here are the reasons why" approach. The harder part is finding ways to make it work by overcoming its weaknesses.
>
> Here is a counter-proposal:
>
> 1. Add Dub to D.
>
> 2. Add a "web development" link in the sidebar, which simply links to vibed.org.
>
> 3. Add an example on the front page on how to create a simple web server. It needs to list only main.d and package.json, and the dub command line to build it. A package.json will be needed for non-trivial things anyway, so might as well get that out of the way anyway.
>
> 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do this by making forum.dlang.org connect to it via NNTP.
>
> I think this will achieve much of your goal without the drawbacks.

Thanks Vladimir, this is really how we should approach things IMO.