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.
