This is why I don't use D.

Everlast Everlast at For.Ever
Thu Sep 6 16:32:09 UTC 2018


On Thursday, 6 September 2018 at 15:28:56 UTC, Patrick Schluter 
wrote:
> On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
>> On Wednesday, 5 September 2018 at 12:32:33 UTC, Andre Pany 
>> wrote:
>>> On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast 
>>> wrote:
>>>> [...]
>>>
>>> You showed as a painful issue in our eco system which we can 
>>> work on, thank you.
>>>
>>> You do not need to work on this but do you have a proposal 
>>> for a solution? What would you help (ranking according to 
>>> last update, ...)
>>>
>>> Kind regards
>>> Andre
>>
>>
>> The problem is that all projects should be maintained. The 
>> issue, besides the tooling which can only reduce the problem 
>> to manageable levels, is that projects go stale over time.
>>
>> This is obvious! You say though "But we can't maintain every 
>> package, it is too much work"... and that is the problem, not 
>> that it is too much work but there are too many packages. This 
>> is the result of allowing everyone to build their own kitchen 
>> sink instead of having some type of common base types.
>>
>> It's sort of like most things now... say cell phone 
>> batteries... everyone makes a different one to their liking 
>> and so it is a big mess to find replacements after a few years.
>>
>>
>> See, suppose if there were only one package... and everyone 
>> maintained it. Then as people leave other people will come in 
>> in a continual basis and the package will always be maintained 
>> as long as people are using it.
>>
>> This is why D needs organization, which it has none. It needs 
>> structure so things work and last and it isn't a continual 
>> fight.
>>
>> It's like if someone doesn't take care of their car. 
>> Eventually it starts to break down and when they do shitty 
>> fixes it only buys them a little time before it breaks down 
>> again and again.
>>
>> The issue isn't the fixes nor the car but how they use the car 
>> and not maintain it properly. That is, it is their mindsets. 
>> Since D seems to be full of people with very little 
>> understanding how how to build a proper foundation for 
>> organization, D has little chance of surviving. As the car 
>> breaks down more and more it is just a matter of time before 
>> it ends up in the junk heap. It was a great car while it 
>> lasted though...
>
> That's what I have said elsewhere in the thread. Checking the 
> maintainer of a package, if there's no feedback, put the 
> package out of the main list and put it in a purgatory where it 
> can get stale for itself. If a new maintainer appears for a 
> specific package, it can be reinstated in the approved list 
> when it works again.
> What annoys people is not that there are broken packages in the 
> list, but that there is no way to know beforehand if one is 
> choosing a reliable package or a hobby experiment gone wrong. 
> This uncertainty is grating imo.

The problem is that google isn't going to help. Most people find 
packages by searching google in some way and then follow that 
rabbit hole. It would be impossible to know then until it's too 
late.

But things such as your suggestions can mitigate the problem. 
Dub, for example, could have a list of reliable packages built 
in(or could have a master list) that can automatically inform the 
user about these issues... rather than the user having to look up 
on a web page.

The more the compilers and tools do for us the easier our life 
becomes. The more complex things get the more time it takes. 
Since most things tend towards complexity it means things should 
be designed well from the get go before they become mainstream so 
messes like this do not happen.


More information about the Digitalmars-d mailing list