"Adam Wilson"  wrote in message news:op.xa21zpux707hn8@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.

> 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. 

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

> "Adam Wilson"  wrote in message news:op.xa21zpux707hn8@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

On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:

> 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.
>

You're greatly underestimating just how easy dub makes developing with D. I'm by no means a Linux dev. My life has been lived on Windows. But I use dub exclusively now and would love to see it packaged with DMD and become the de facto way to get D libraries. If Phobos were to be broken into a set of dub packages, even better.

Setting up a package.json for a new project is extremely easy. Once it's done you can copy it around for future projects with minor changes. Compilation, in its simplest form, then becomes:

dub build

And all the libraries you need are automatically pulled down. Then they are available for any other projects that need them. It doesn't get any easier than that.

Plus, once all of the D IDEs get support for it worked out, you then have one universal project configuration tool. No more need to provide build scripts, make files, Visual Studio solutions, MonoD projects, or whatever else. No matter your choice of text editor/IDE, one configuration file rules them all.

Ultimately, this would make it much, much easier to get started with D. So far, my experience in using dub with Derelict has suggested this to be true. I still get people asking for help with using Derelict 3 without dub, often because they don't know how to configure the import path or the linker in their IDE, or don't understand what it even means (and, apparently, have failed to read any documentation on the subject). I've gotten *zero* compile/link issues about building with dub. Maybe that just means the newbies aren't using dub, or that they aren't reporting their problems to me, but I suspect it's because dub is easy.

On Mon, 10 Feb 2014 21:03:28 -0800, Mike Parker <aldacron@gmail.com> wrote:

> On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:
>
>> 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.
>>
>
> You're greatly underestimating just how easy dub makes developing with D. I'm by no means a Linux dev. My life has been lived on Windows. But I use dub exclusively now and would love to see it packaged with DMD and become the de facto way to get D libraries. If Phobos were to be broken into a set of dub packages, even better.
>
> Setting up a package.json for a new project is extremely easy. Once it's done you can copy it around for future projects with minor changes. Compilation, in its simplest form, then becomes:
>
> dub build
>
> And all the libraries you need are automatically pulled down. Then they are available for any other projects that need them. It doesn't get any easier than that.
>
> Plus, once all of the D IDEs get support for it worked out, you then have one universal project configuration tool. No more need to provide build scripts, make files, Visual Studio solutions, MonoD projects, or whatever else. No matter your choice of text editor/IDE, one configuration file rules them all.
>
> Ultimately, this would make it much, much easier to get started with D. So far, my experience in using dub with Derelict has suggested this to be true. I still get people asking for help with using Derelict 3 without dub, often because they don't know how to configure the import path or the linker in their IDE, or don't understand what it even means (and, apparently, have failed to read any documentation on the subject). I've gotten *zero* compile/link issues about building with dub. Maybe that just means the newbies aren't using dub, or that they aren't reporting their problems to me, but I suspect it's because dub is easy.

Well, I can be wrong. I fully admit to not having any experience with it. But that doesn't answer my other problem. :-)

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

> "Adam Wilson"  wrote in message news:op.xa3n27el707hn8@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.

> 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. 

On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:

[snip]

> 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.
>

I disagree to some extent. I don't want to see Phobos, the core stdlib get bigger. But I do want to see the official module list grow.

I'd love to have opt-in officially endorsed, D-dev reviewed and supported modules for things like sqlite/db access, xml, gui, gfx, SciD etc. etc. Whether via dub or tarball, I'm easy.

I dislike package managers but DUB is simple to use and works reasonably well. If it were adopted as "the" package system for official D modules I would have no problem.

A dub GUI would be an interesting side project...I might have to have a hack at that. Anyone else working on one?

Cheers,
ed

On Mon, 10 Feb 2014 22:07:50 -0800, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

>> "Adam Wilson"  wrote in message news:op.xa3n27el707hn8@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

On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:
>
> 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.

Well if you only need some output to the console then sure, you don't necessarily need DUB.
A fresh programmer can still download VisualD and create a project since that will seem simpler at first.

But DUB does make life a lot easier. Not needing to care about import/source paths is a huge gain. Being able to discover new libraries and integrate them in seconds is a lot better than what it was before using a package manager.

The C++ way of providing zillions build systems is frankly a real impediment to code sharing.

On Tuesday, 11 February 2014 at 05:03:29 UTC, Mike Parker wrote:
>
> You're greatly underestimating just how easy dub makes developing with D.

I have to say that dub is a great tool. I remember the times when I had to copy files to /usr/bin/ etc. and would still wonder why the compiler complained. I started using dub a few months ago (when I started a vibe.d project) and it helps me a lot. I moved the project to a new machine, just ran $ dub and it compiled and ran, out of the box.

Back to the original point, i.e. what's important for newbies (some of it has already been said):

1. ease of use:
    download, install, type away.
2. tutorials:
    a. show how things work in D, the most common cases first (e.g. string handling, (assoc) arrays, saving to file, useful real world examples)
    b. show how things should be done correctly (there's nothing worse than having to figure out yourself and then refactor your code, because nobody told you how to do it correctly or in an optimized way).
    c. the newbie should be able to get going and be productive without an in depth understanding of the philosophy behind every language feature. That comes later, more or less automatically.
3. documentation:
    More examples. The Cocoa API reference is very good in this respect. It shows trivial things like opening a file dialog. Trivial but it's good to have something you can just copy for starters, without having to figure out what else to import and all that kind of stuff that only holds you up.

I cannot say anything about IDE support, because I haven't used D+IDE yet. But some analyzing tools would be nice, e.g. "variable declaration is shadowing global variable", "unused import".

The most important thing for newbies, either new to the language or new to programming, is "instant gratification". If it compiles and works, people are more likely to be enthusiastic about it. Give them useful examples and use cases and they will begin to see how useful programming is and start thinking about applications, however trivial they may be, they can write themselves for their own personal use (a little clock, a calculator for VAT ...) In this way they will start to think as both developer and user, add features, go ever deeper into programming. Creating useful things, that's what it's all about, isn't it?

On Monday, 10 February 2014 at 19:03:22 UTC, Tofu Ninja wrote:

> I am only 20 and am still in university so I feel like I can answer this with at least my own experiences. Personally I think D would capture the attention of more young people if it was simply easier to use. The first "real" language I really got into was C#(about 5-6 years ago) and I think the main

You hijacked my topic and converted it into the usual arguments about lack of infrastructure for D.

I'm talking about guys and girls who don't have a computer, let alone C#. They just have a cheap smart phone that maybe they succeeded in getting rooted. So is your answer that they should just use Java?

And yes, the C# library is excellent, but D is a better language, and is easy to use. Get out of the wood and see the trees!

I'm at the other end of my life, with a long view of history. We should do our bit to help to bring civilization and reason (back) to the world, not just tell people 'use C#'.

A more relevant criticism would be that people who only know say Swahili won't be able to find out about and use D anyway - Java either. Sadly my Swahili is not up to it.

Sorry, but you asked for it ;=)

Steve