Setting up dmd properly

Tue Jan 12 12:38:50 PST 2016

On Tuesday, 12 January 2016 at 19:38:32 UTC, Jason Jeffory wrote:
> It seems the whole state of affairs in programming is "Lets do 
> the most minimal work to get X to work in environment Y. To 
> hell with everything else!". The programmers tend to do the 
> most minimal work to code stuff that they can get away with.

Since people aren't being paid to do this, and it's not enjoyable 
for many to make things universally easy across different 
environments once someone has solved their own problem, you can 
hardly object to the behaviour - particularly because different 
people are good at different things, and the guy who creates a 
project may not be the same guy needed to make it easy to use.  
Then it's more a question of treating it as a challenge to be 
solved.  It's quite amazing how much a relatively small number of 
people has accomplished, and it's something of a hazard of 
open-source that instead of gratitude people receive far more 
criticism and complaint.  (They say a 2:1 balance of 
positive:negative comments is needed for a healthy relationship).

So it's an engineering or institutional challenge - how does one 
achieve this as a community?

> This isn't 1984 but coding quality has no increased much since 
> then.

A little hyperbolic? ;)  We do seem to have higher quality 
problems today, but do you recall what code from the 80s was like?

> I've virtually had no problems with it. MS did good job of 
> modernizing the toolchain... Most people that code on linux 
> think that it should be "hard" and gui's suck, that programming 
> is suppose to be a hazing ritual. They setup their system to 
> work for them, and it works... anyone with problems must be 
> ignorant and not "pro programmers". It's kinda this elitist 
> attitude. They spend more time solving 1%'er problems than 
> creating tools that *just* work for 99% of the people. When 
> problems occur it is never their fault but the fault of the 
> ignorant cave man trying to become an godly programmer.

Do you think that's actually representative of the attitudes of 
people here?  I haven't seen that.  But work won't get done 
without a plan and without someone to actually do it and one 
can't force people to do things they don't want to do.  A big 
problem is people don't know what to work on, and maybe some kind 
of systematic approach to identify problem needs would help.

> Just search "openGL dmd"(28k) and about 80% of the results are 
> people having problems with getting openGL working with D. 
> "openGL dmd error" has 1M results, thats nearly 30 times the 
> results.

It would be a good idea to systematize this and produce a web 
report so one can see in a more structured way where the biggest 
difficulties are.  I have been talking to Adam a bit about ways 
we could do this using forum history.

I agree with your observation that there is much friction in the 
way of a new user learning D and that many simply won't persevere 
long enough.  That's nonetheless a better problem to have than 
having an intrinsically inferior product - one just needs to 
establish a process, and to have some way of organizing efforts 
to address these difficulties (which may include funding to a 
certain extent).  I think it's a necessary part of the way D has 
developed that people have focused on the language and core 
library first - it's not so long that it has been stable and 
ready to use and over time better tooling will unfold.  
(Constructive criticism and ideas may help this process).

> D has a long way to go to make it competitive... as long as the 
> tooling sucks and there are problems with stupid issues such as 
> coff vs omf, installation issues, ide issues, etc... it won't 
> get off the ground.

Depends what the competition is ;)  Coff vs OMF will disappear in 
time as people move to 64 bit.  Installation questions seem to be 
improving.  IDE support keeps getting better.

For many uses, these things are a one-off price for adopting D.  
Whether it's feasible to pay that depends on what you are doing 
and the people you are working with.

> The D "core" seems to be mainly interested in fixing and 
> enhancing very niche issues in D instead of working on making 
> it a viable and usable candidate for the masses.

But it is in the nature of things that disruptive technologies 
start off as inferior in certain respects and it's only with time 
that they can be a superior competitor across the board to the 
dominant technologies.  See Clayton Christensen's work "The 
Innovator's Dilemma".  It is what it is, and one can't wave a 
magic wand to force people to work for free on shiny tools to 
make it easy.  If that's what one wants, then one can do one's 
small part to encourage this to happen - work on that oneself and 
contribute it, file bugzilla issues, fund the D foundation (once 
it is ready).  But simply complaining won't change anything.

BTW I hardly think that memory allocation, containers, 
documentation, and web site (recent areas of focus by leadership) 
are niche issues.

> Anyways, sorry for the rant... not like things will change. D 
> does fill a niche, and it shows ;/ Just wish I could drive the 
> Ferrari! I know it's awesome! but the Mazda is more 
> affordable(Man hours wise) and gets me to where I want to go 
> without hassle.

Maybe you're right and it's not ready for you for now (although 
this might change).  It's easy to overestimate what's possible in 
a short period of time and underestimate over a longer period.  
The web site and documentation are very much better today than 
when I first looked at D maybe 1.5-2 years back.