D needs to get its shit together!

[Mike Parker via Digitalmars-d]

On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote:

> 1. coff/omf. Requires use of windows and visual studio/C stuff 
> who's locations and versions change over the years. This can be 
> a major headache finding the right version. Mainly because the 
> error messages, when using the wrong version, do not suggest 
> that it is a versioning error.

This isn't as severe as you make it sound. If the latest version 
of VS doesn't work, the one before will. It's easy to prevent 
such issues in the future. Since we never know if a new version 
of VS will break things, this can be solved by one person who can 
monitor the beta releases of VS and submit PRs to the appropriate 
repositories if the paths change, or (as happened with VS 2015) 
the C runtime library changes, or some other breakage arises. 
Then DMD can get support for the new version before it's 
released. Could that person be you?


>
> 2. Managing different compilers: Not too bad but if you end up 
> with some problems here, then it gets multiplied by the factor 
> of the number of issues with each compiler. if LDC has an issue 
> with the x64 dlls and dmd with the x32 and they are always 
> looking in the same place because the versions are different 
> and wrong, then it becomes a issue with a "factor of 4" 
> problem. This can become even worse when you try cross 
> compiling and such.

What I've done in the past is to keep the latest DMD on the 
system path, then set up Command Prompt shortcuts initialized 
with a different batch file to set override it with paths to 
different compilers/versions. If DVM could get support for LDC 
and GDC, then you'd have everything in one convenient app.

>
> 3. Re-installation can be problematic. sci.ini is overwritten. 
> If you hand coded the paths to get everything to work, guess 
> what? Well, who cares? You have plenty of time to waste, right?

Backup the sc.ini file.

>
> 4. Reinstalling one thing can break something else. This 
> depends on how fragile the setup was at the start.

Like what?

>
> 5. I have over 1 billion files on my system, I use it for 
> around 20 different non-complementary subjects(graphics, music, 
> programming, etc). When everything is "competing for space" and 
> things are not set up to work together, one seemingly unrelated 
> program and effect every other one. (e.g., simply by adding to 
> the path variable and break things with error messages that are 
> meaningless to the real problem)
>
> Most ignorant people do not take those things in to account 
> because they oversimplify... and that usually causes problems 
> down the road for the rest of us.

So, what are you proposing here? Educate us. What are we supposed 
to take into account? I use my computer also for graphics, music, 
programming, document editing, all sorts of stuff. The only 
breakage I've ever had has usually been related to anti-virus 
software, though in the past there was an occasional issue with 
things like SecuRom. What exactly should the D community to in 
order to alleviate these major breakages you have on your system?

>
> As D becomes increasing popular, there are going to be more 
> variation in the system and the flaws in it will become larger 
> and larger.  It's best to start working on fixing those flaws 
> before they become too large to manage and weaken the whole 
> structure.

I would like to reiterate here what I mentioned earlier in this 
thread -- people in the D community are currently fixing flaws 
all the time. That we aren't fixing the flaws that particularly 
peeve you does not mean nothing is being done. I would also like 
to reiterate that if something is important enough to you, then 
you could do something about it besides coming to the forums and 
calling the rest of us ignorant. Write a DIP. File issues on 
Bugzilla. Submit pull requests. Take on responsibility for 
ensuring Visual Studio compatibility. Or do nothing, but please 
don't act as if we're all just sitting here twiddling our thumbs.