Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

On Wednesday, 13 January 2016 at 01:40:59 UTC, Mike Parker wrote:
> On Tuesday, 12 January 2016 at 21:08:30 UTC, Jason Jeffory 
> wrote:
>> (I should mention that I am exaggerating a bit, and some of 
>> the complaints about D are actually more directed to the 
>> programming community in general. D has the same fundamental 
>> issues though and it is just a matter of scale. Programming is 
>> way more fun when you are actually programming and getting the 
>> job done rather than fighting things that should work but 
>> don't. As programmers, we get used to that crap.. specially 
>> those that programmed in the 70's and 80's... but it doesn't 
>> mean it's ok. Specially when we know how to fix it. I really 
>> like the D language but the D tool chain should be more user 
>> friendly to work with on every level.)
>
> I think there's another side of this in that what is an issue 
> for one person isn't necessarily an issue for another. For 
> example, your difficulties with static linking... you aren't 
> the first person to have this problem, but I personally never 
> have. It all seems quite straight forward to me. I was annoyed 
> by the COFF/OMF issue when I first started using D, sure, and 
> that's what prompted me to start Derelict), but it's never been 
> a problem that prevented me from building my D projects.
>
> The way to solve this particular sort of problem is to have 
> more documentation, or tutorials, but that requires someone 
> with the time and motivation to write it. People who aren't 
> having that problem are going to be motivated to direct their 
> time and energy elsewhere. So I don't see this as an issue of 
> "getting used to" a bad situation, just one of varying opinions 
> about what part of the situation is bad.
>
> I'm going to make an effort toward improving the situation with 
> my learningd.org site. Linking with C libraries would be a good 
> topic for a tutorial to go there. There is also some movement 
> behind the scenes right now to create a comprehensive web site 
> for teaching all things D, but it's going to be after the next 
> DConf before any concrete effort is made in that direction.
>
> As for the toolchain... Until there is a dedicated team with a 
> clear goal-oriented task list and the management necessary to 
> keep development focused on those tasks, then development will 
> go in the direction that the core contributors feel they need 
> to direct their efforts. Anyone can champion a new cause in D's 
> development, and several have over the years. That's what has 
> driven the project forward. There have been many, many, many 
> discussions over the years about how unfriendly D is to new 
> users, or how difficult it is to get up and running with this 
> or that aspect of the toolchain. Most of them have resulted in 
> improvements. As a long time D user, I can tell you that you 
> kids have it much better than we did back in the day.
>
> So things will get easier with time. Pre-D experience is what 
> determines the degree of difficulty in getting started with D 
> right now. For example, programmers who are comfortable with 
> the command line, particularly when using C or C++, tend to 
> have few difficulties with the toolchain. I'm hoping that the 
> recent creation of the D Foundation will create opportunities 
> to make it easier for /anyone/ to hit the ground running with D.


Yes, but the world consists of many differnet programmers, and 
due the the interaction of different things, which is 
exponential, it is too complex to solve each persons problems on 
a one by one basis. What works for you works for you because you 
are you... not because you are me(not trying to make a Beatles 
song here).

e.g., if write your total system configuration in a list, and I 
write mine, then just about every element in the list interacts 
with every other element and creates new dependency problems. The 
amount of potential issues it the powerset of all the items.

e.g.,

ubuntu 14.3, dmd 2.062, glad opengl, etc...

windows, dmd 2.061, derelict opengl, etc...

Each item in your list has to interact with each other, and in 
each case it may or may not work well for you. But my list is 
totally different and you can't say "It works for me"... because 
it doesn't help me in any way.

dmd 2.061 may have a bug in the windows version and the derelict 
version that is not exhibited by the linux case.

Because the problem is so complex, the only way to make it work 
is that the elements themselves have to work well 
individually(basically because we can't code for every 
combination). This is why we have to break complex systems down 
into simple well understood parts. But information is the here. 
One has to have some way to "measure" progress(ask Andrei, he 
said that in his performance lecture). If a tool doesn't give 
results that can be compared, we can't see how we are solve the 
problem and it usually requires guess, looking up stuff online 
for similar problems/solutions, and usually a lot of wasted time.

So, the solution to all this is not solving the problems after 
they exist but trying to prevent them in the first place... and 
there is one and only one way to do this, and that's to write 
better tools(because after the tools, is were the problems come 
in from).


e.g., imagine compilers were perfect, no bugs... then we wouldn't 
have problems with them, no patches would be required(e.g., so 
essentially no github), etc..

But we don't work towards writing perfect tools, we work towards 
writing perfect fixes for the tools. Again, the horse before the 
cart.

I do realize it is necessary, and some people are working in the 
absolute right direction. Most, it's just the vague general 
direction with a lot of circling around, getting lost, etc.

My main "gripe", if you will, is simply that the tools are really 
really import, and that programmers in general tend to forget 
just how important. Mainly because they deal with it on a daily 
basis, and many times they've forgotten how much of their own 
lives have been wasted on needlessly solving problems that 
shouldn't have existed in the first place.

Imagine if you were given all the time back that you spend wasted 
on chasing rabbits that didn't exist? (someone wrote code that 
didn't do what it was suppose to, etc.) It would probably add up 
to more than a year(if you've been programming a long time). That 
is significant!


This is my impression of the D "leadership": Lets fix bugs and 
squabble over who's write about semantic interpretation of 
certain language constructs(e.g., extern(c++, ns)). Lets find out 
who's right and who's wrong and lets may sure no one admits they 
are wrong or accepts a compromise!

This creates "unhappiness" on both sides. 1. If Manu had his 
wish, he could test out the feature and determine if it worked 
for him. 2. If Walter had his, he could feel good about not 
introducing something that caused a lot of headaches.

This is not the solution to things. This creates division and 
separation from actually solving the real problem. The solution 
is "Lets figure out how to do both". That way, if Walter is 
wrong, he can be proven wrong and if Manu is wrong, he will be 
proven wrong(through real world practical problems). How much 
time is wasted on such arguments instead of just figuring out how 
to satisfies all parties? I personally believe it can be done if 
everyone works towards that goal. (maybe there will have be some 
compromise in technical issues, but not in goal)

Again, I'm inflating a lot of stuff and I think, for the most 
part, DMD does a good job. It works well across the board in 
general. Specific stuff though it seems to fail at in more cases 
than it should, for some reason. It's more of a mentality that is 
wide spread across people and programmers in general. It usually 
leads to an unfocused and unproductive mess in the long term. I'd 
hate to see that happen to D because I feel it is, perhaps, the 
best language out there. It's elegant to some degree, it's 
powerful, it has meta programming constructs that just make 
sense, the people behind it seem intelligent and have a strong 
desire to see it succeed... But it has a long was to go... and 
that can't happen without more support. Gui's, graphics, sound, 
database, etc must be well done and supported innately by D if it 
wants to be top dog.

Water the flower well and it grows into a beautiful thing. 
Neglect and ignore it and it will wilt and die. Same for 
children, programming languages, families, species, etc.  D's too 
good to let it fade off into the bowls of mankind.