On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
> [...]

Also on YN: https://news.ycombinator.com/item?id=13217529

On 12/20/2016 12:48 PM, Benjiro wrote:
> Actually, i did not vent any anger until this morning when i noticed the wiseass response. All the points i wrote yesterday are items that actually bother a lot more people. But those same people who complain about it, always get shutdown with that typical: Do it yourself response / Improve the standard library / ...

Can you list specific list of actions/events you would have wanted to see as a result of your post? Literally "person X does Y". Trying to write it down is very likely to make obvious why no other reaction than one you have got is possible.

On 12/20/2016 2:46 AM, bachmeier wrote:
> Dub's documentation is simply atrocious *and it's the
> official package manager*. Throw around things terms like "you can use Git
> submodules for that" as if it's a trivial thing. But I'm not going to say more.
> I realized a while back that this community is incapable of understanding what
> is wrong with Dub's documentation.

We do accept pull requests, though.

Heck, just pick *one* thing that grinds your gears, like the quotation above, and fix it.

On Tuesday, 20 December 2016 at 11:00:02 UTC, Walter Bright wrote:
> On 12/20/2016 2:46 AM, bachmeier wrote:
>> Dub's documentation is simply atrocious *and it's the
>> official package manager*. Throw around things terms like "you can use Git
>> submodules for that" as if it's a trivial thing. But I'm not going to say more.
>> I realized a while back that this community is incapable of understanding what
>> is wrong with Dub's documentation.
>
> We do accept pull requests, though.
>
> Heck, just pick *one* thing that grinds your gears, like the quotation above, and fix it.

But I don't use Dub or Git submodules. I use R's package manager, which is both well-documented and does not require the user to write a configuration file to use the package. Of course that is not an option for very many D users.

I guess the bigger problem is that Dub is allowed to be the official package manager even though nobody bothered to write real documentation. In other communities, contributions have to meet standards for both code and documentation.

On Tuesday, 20 December 2016 at 10:46:28 UTC, bachmeier wrote:
> On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
>> Documentation:
>> --------------
>
> I realized a while back that this community is incapable of understanding what is wrong with Dub's documentation.

Michael Parker is working on that from last I heard.

On 12/20/2016 3:12 AM, bachmeier wrote:
>> Heck, just pick *one* thing that grinds your gears, like the quotation above,
>> and fix it.
>
> But I don't use Dub or Git submodules. I use R's package manager, which is both
> well-documented and does not require the user to write a configuration file to
> use the package. Of course that is not an option for very many D users.
>
> I guess the bigger problem is that Dub is allowed to be the official package
> manager even though nobody bothered to write real documentation. In other
> communities, contributions have to meet standards for both code and documentation.

If you don't want to fix anything, ok. But you can still file bugzilla issues for things that you find.

On 12/19/16 11:38 PM, Jerry wrote:
>> https://issues.dlang.org/show_bug.cgi?id=16991
>
> Another issue onto the list of thousands, to collect dust for the next
> few years til someone decides they want to use their personal time to
> fix it.

That's changing because we're starting to have permanent collaborators. I've kindly asked Razvan, one of our scholarship students, to take a look. Generally they will be focused on larger projects but fixing trivial bugs is a simple background activity.

> Just to highlight another problem, there's a lot of trivial to
> fix issues. Just maintenance really, like that one you posted. But there
> is no one going through fixing them. Well that one might end up getting
> fixed cause of the extra exposure.

I've just added the "trivial" keyword. If any concrete bug comes to mind please ascribe the keyword to it.


Thanks,

Andrei

On 12/20/16 3:41 AM, Benjiro wrote:
> [snip]

Thanks for the rant. Though it was pretty awesome, I too feel the focus was missing in the sense that I'm unclear on what steps we can take to alleviate your pain points. Do you want more or less in the language and the standard library? Do you want me to get on things like editor integration I have no expertise in? What would be Cliff's notes of this post?

> Maybe you want to freaking ask the authors of for instants std.database
> etc why they feel unwilling to add it to the standard library git.

Erik Smith has been on board with adding his work to the standard library from day one, and he has our full support. He gave a talk at DConf. As sadly it sometimes happens with volunteers, time is a precious commodity for us all and volunteer projects are the first to be dropped in a crunch. Framing this politically is not quite helpful.

Are you thinking of a different database package?


Thanks,

Andrei

On Tuesday, 20 December 2016 at 12:43:38 UTC, Andrei Alexandrescu wrote:
> On 12/20/16 3:41 AM, Benjiro wrote:
>> [snip]
>
> Thanks for the rant. Though it was pretty awesome, I too feel the focus was missing in the sense that I'm unclear on what steps we can take to alleviate your pain points. Do you want more or less in the language and the standard library? Do you want me to get on things like editor integration I have no expertise in?

Hi,

As a long time D observer and someone who tried to use D earlier this year, I hope following is constructive.

D's reason for existence
------------------------

I think the landscape of programming languages has changed somewhat in recent years - we have new languages like Go, Swift, Rust, and even an existing language like C# is becoming cross platform. It seems that D started out as better C++ but C++ is also evolving and taking many of the ideas from D.

So I think that D has to have a clear charter similar to say the charter for C (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm).

And this needs to clarify how D is different from its competition and which use cases it is best for.

Is it better C?
Is it better C++?
Is it better some other language?

Project Management
---------------------

It is a bit painful to watch how D's development is managed. In my view, the whole of the D team (including volunteers) need to be very narrowly focussed on very small set of defined priorities.

Secondly the goal has to be a measurable delivery within strict timescales.

It seems that too many avenues are being chased while there are too few people to handle the workload. Why not have a much more restricted scope and focus everyone on that. And when this is achieved move to the next scope.

It is also important to keep the scope small and achievable in a short time (3-6 months).

Real world needs
-----------------

As a potential user of D, here are the things I looked at:

1) Can I successfully build my project?

2) Can I expose my D modules as reusable C ABI compatible shared libraries for use in a heterogenous environment?

3) Can I debug my programs easily?

4) Is there an IDE I can use for development?

5) Is the performance going to match C or C++?

6) Will the third party libraries I need to use work with D?

Note that in all of above, language features and D libraries did not count! In production usage being able to deliver counts most. D fell short in these areas compared to a combination of C++ and C#.

Final thoughts
--------------

I wish I could help, as I really like D as a language. But unfortunately I have to focus on getting my own work done (survival reasons), and I chose to use C++ and C# for my project (after giving up the idea of using D).

I could potentially help in project management in my spare time ... but feel that it needs a mind set change in the D team ... and I fear this is unlikely.

Apologies for being one of those who offers advice but no action.


Regards
Dibyendu

On Tuesday, 20 December 2016 at 11:17:19 UTC, Guillaume Piolat wrote:

> Michael Parker is working on that from last I heard.

Yes, he is, though slowly. I can give it more priority after the New Year.