On Sun, 2018-02-11 at 19:31 -0700, Jonathan M Davis via Digitalmars-d wrote:
> 
[…]
> On that note, I feel that I really should thank Sonke and those few
> that
> have helped him write dub. As much as I think that some aspects of
> dub need
> to be redesigned, at least they actually went and did something and
> managed
> to get it to take off enough that there are quite a few D libraries
> available using dub. So, while the solution may not be what we want,
> at
> least we have a solution.

Indeed.

And so inexorably an email thread fades into the distance and nothing gets done because nobody with an opinion writes code, they just write emails.

Your working on dxml is excellent proof of this. Once someone actually starts writing code things happen. It is after all how we ended up with Dub. Sonke et al. wrote code whilst everyone else just sounded off writing emails. Atila wrote code to solve his pain with Dub.

I am happy to write code rather than emails, well once ACCU 2018 is over anyway. But I am not going to do anything of this sort purely on my own, it is too big, it needs people supporting as well as one (or preferably more) doing. To date no-one other than me seems to have shown any intention of writing code in support of the professed pain with Dub.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 2018-02-09 08:54, Suliman wrote:
> I like D, but sometimes it's look like for me too complicated. Go have a
> lot of fans even it not simple, but primitive. But some D futures make
> it very hard to learning.
>
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
>
> Which language futures by your opinion make D harder?

1. Metaprogramming is a mess. Metaprogramming in D is split across many features: like templates, __traits, the "is" expression, .tupleof TypeInfo and probably others I have forgot.

2. The "is" expression. This is one of the most complicated features in D. I understand most of the examples in the spec [1], but then when you see how this feature is used in the wild, it's like: what!... how did you... that doesn't make sense.

3. Ranges only works with mutable arrays and don't work with tuples

4. "alias" parameters don't accept all values/types/symbols that "T..." does

5. Lambdas don't work, as far as I know, with alias or type parameters. That is, it's not possible to use a lambda to as a predicate to, for example, filter a tuple of types

These are all annoying issues when you work with metaprogramming resulting to add workarounds that makes the code unnecessary complicated.

[1] https://dlang.org/spec/expression.html#is_expression

-- 
/Jacob Carlborg

On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole wrote:
> On 11/02/2018 11:40 AM, Jonathan M Davis wrote:
>> On Sunday, February 11, 2018 11:26:30 rikki cattermole via Digitalmars-d
>> wrote:
>>> On 11/02/2018 11:18 AM, Russel Winder wrote:
>>>> Clearly though there is a problem with Dub as a build system for many
>>>> of it's users – or rather people who try and reject.
>>>
>>> Put simply, they expect far too much.
>>> Dub's scope is limited, lets not forget that.
>> 
>> The problem with that is that if dub is the way to build D projects in
>> general, then it needs to be able to do pretty much whatever you need to do
>> for pretty much any project - even if that involves backdoors. You need to
>> be able to do arbitrary stuff with your builds.
>> 
>> It's not as critical for applications so long as dub provides an easy way to
>> link in any libraries that it pulls in, but dub needs to be able to build
>> libraries no matter what crazy stuff you need to do, otherwise, those
>> libraries can't interact with the dub ecosystem, and dub is how D projects
>> in general pull in their dependencies.
>> 
>> So, for instance, if your D library has to build C or C++ code and link that
>> in as part of what it does, that needs to be possible with dub, even if dub
>> itself doesn't handling building code that isn't D. Also, if you need to
>> generate code as part of your build and then build those files, that needs
>> to be possible. And the way that dub is set up at this point, that sort of
>> stuff is rather difficult to do.
>> 
>> dub wouldn't have to be all that powerful if it were simply a handy build
>> tool for the average use case, but when it's tied in to package management
>> for D libraries and is the primary way that D projects pull in libraries, it
>> needs to be far more than a simple build tool. And right now, it's not far
>> enough away from being a simple build tool.
>> 
>> - Jonathan M Davis
>
> Dub can do everything that you have described.
> You are fully free to run cmake if you wish before the build.
I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub,  then a lot is possible. Those edge cases can be ironed out.

Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage.

At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains.


> Will it result in binaries that are decent? Probably not for most use cases.
Can you file a bug report on this?

>
> Its a hard problem to solve, I just wish people respected dub's scope more. Because it is very decently well scoped for its job already.
Same opinion here.

On 13/02/2018 10:45 AM, aberba wrote:
> On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole wrote:

snip

>> Will it result in binaries that are decent? Probably not for most use cases.
> Can you file a bug report on this?

Nah this should remain out of scope.
If binary (from e.g. cmake) exists, do not run cmake. Easy!

On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d wrote:
> 
[…]
> I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub,  then a lot is possible. Those edge cases can be ironed out.

I think there have been many actual complaints made in detail in this thread.

There is always a reason to replace, because you can build on what has gone before and do better. CMake is part of the problem.

> Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage.

No problem, and I guess you'll be happy to carry on using Dub after something new and better appears. In the case of Maven → Gradle, many people still use Maven even though it is provably inferior to Gradle simply because they cannot be bothered to change.

> At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains.
[…]

Why should Dub remain the one true way? Just because it was the first doesn't mean it is the best.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 13/02/2018 11:11 AM, Russel Winder wrote:
> On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d wrote:
>>
> […]
>> I wish complaints about Dub would include exactly what was
>> impossible with it. There's no reason to throw dub away and start
>> something new. If one can run cmake before build in dub,  then a
>> lot is possible. Those edge cases can be ironed out.
> 
> I think there have been many actual complaints made in detail in this
> thread.
> 
> There is always a reason to replace, because you can build on what has
> gone before and do better. CMake is part of the problem.
> 
>> Dub fulfills all my use cases so I don't complain. Those here
>> with not much issue with dub will also not complain. And that
>> does not make it a minority opinion without stats to prove dub
>> usage.
> 
> No problem, and I guess you'll be happy to carry on using Dub after
> something new and better appears. In the case of Maven → Gradle, many
> people still use Maven even though it is provably inferior to Gradle
> simply because they cannot be bothered to change.
> 
>> At point, dub will likely remain the default package management
>> tool. The build functionality can be improved for those who deal
>> with such stuff often. Manpower is what remains.
> […]
> 
> Why should Dub remain the one true way? Just because it was the first
> doesn't mean it is the best.

It wasn't the first and it was the best in over a 10 year period.

On Tuesday, 13 February 2018 at 11:14:25 UTC, rikki cattermole wrote:
> On 13/02/2018 11:11 AM, Russel Winder wrote:
>> On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d wrote:
>>>
>> […]
>>> I wish complaints about Dub would include exactly what was
>>> impossible with it. There's no reason to throw dub away and start
>>> something new. If one can run cmake before build in dub,  then a
>>> lot is possible. Those edge cases can be ironed out.
>> 
>> I think there have been many actual complaints made in detail in this
>> thread.
>> 
>> There is always a reason to replace, because you can build on what has
>> gone before and do better. CMake is part of the problem.
>> 
>>> Dub fulfills all my use cases so I don't complain. Those here
>>> with not much issue with dub will also not complain. And that
>>> does not make it a minority opinion without stats to prove dub
>>> usage.
>> 
>> No problem, and I guess you'll be happy to carry on using Dub after
>> something new and better appears. In the case of Maven → Gradle, many
>> people still use Maven even though it is provably inferior to Gradle
>> simply because they cannot be bothered to change.
>> 
>>> At point, dub will likely remain the default package management
>>> tool. The build functionality can be improved for those who deal
>>> with such stuff often. Manpower is what remains.
>> […]
>> 
>> Why should Dub remain the one true way? Just because it was the first
>> doesn't mean it is the best.
>
> It wasn't the first and it was the best in over a 10 year period.

While I am really suffer from some painful behavior of dub, in my opinion it is a great tool and it would damage the D ecosystem to go away from dub. Companies already starting investing into this tool. In my case, without dub it would not be possible at all to use D at work.

The involved developers doing a great job.

Kind regards
André

On Tuesday, 13 February 2018 at 11:36:50 UTC, Andre Pany wrote:
> On Tuesday, 13 February 2018 at 11:14:25 UTC, rikki cattermole wrote:
>> On 13/02/2018 11:11 AM, Russel Winder wrote:
>>> On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d wrote:
>>>>
>>> […]
>>>> I wish complaints about Dub would include exactly what was
>>>> impossible with it. There's no reason to throw dub away and start
>>>> something new. If one can run cmake before build in dub,  then a
>>>> lot is possible. Those edge cases can be ironed out.
>>> 
>>> I think there have been many actual complaints made in detail in this
>>> thread.
>>> 
>>> There is always a reason to replace, because you can build on what has
>>> gone before and do better. CMake is part of the problem.
>>> 
>>>> Dub fulfills all my use cases so I don't complain. Those here
>>>> with not much issue with dub will also not complain. And that
>>>> does not make it a minority opinion without stats to prove dub
>>>> usage.
>>> 
>>> No problem, and I guess you'll be happy to carry on using Dub after
>>> something new and better appears. In the case of Maven → Gradle, many
>>> people still use Maven even though it is provably inferior to Gradle
>>> simply because they cannot be bothered to change.
>>> 
>>>> At point, dub will likely remain the default package management
>>>> tool. The build functionality can be improved for those who deal
>>>> with such stuff often. Manpower is what remains.
>>> […]
>>> 
>>> Why should Dub remain the one true way? Just because it was the first
>>> doesn't mean it is the best.
>>
>> It wasn't the first and it was the best in over a 10 year period.
>
> While I am really suffer from some painful behavior of dub, in my opinion it is a great tool and it would damage the D ecosystem to go away from dub. Companies already starting investing into this tool. In my case, without dub it would not be possible at all to use D at work.
>
> The involved developers doing a great job.
>
> Kind regards
> André

Well backward compatibility with dub could always be a possibility.

On Friday, 9 February 2018 at 19:19:03 UTC, H. S. Teoh wrote:
>> But none of these features are *necessary* to start coding in
> D. They are optional extras that are nice once you're comfortable with the language.  I got by fine for *years* without even using a single mixin, or knowing what 'inout' does, or use any attributes.
>
> It's like human language, there's a set of core words ("basic features") that you have to know to hold a conversation, but there's a vast vocabulary of more specialized words ("advanced features") to draw from when you need to be more precise or in special situations. You don't need to know the *entire* language to be functional in it. E.g., there's a vast body of scientific vocabulary that 90% of the general population (of native English speakers) has no idea about.  Yet they can live and function in society just fine.  But that vocabulary is there when you *do* need it.
>

That's true for writing your own code, but when you look at other code like the standard library and are trying to understand it - if it's written using a plethora of features, then you have to learn a plethora of features.

Ali G

On 2/10/2018 4:35 AM, Timon Gehr wrote:
> In summary, the issue is that there is only one 'inout' and therefore it is not properly lexically scoped. It is a bit like having a language where all variables are implicit function parameters and they all have the same, global, name. This sort of works fine until you want a function with two parameters or until you want to nest functions in a non-trivial way.

This needs to be filed on bugzilla. Shall I do it, or do you want to?