Setting up dmd properly

Tue Jan 12 13:05:08 PST 2016

On Tuesday, 12 January 2016 at 20:38:50 UTC, Laeeth Isharc wrote:
> 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.

No, but what's the point if there is not a proper supported tool 
chain to make most advantage of this stuff. It's like putting the 
horse before the cart(or, more sensical, having the cart pull the 
horse).

The "leadership" focuses on what they believe is the best stuff, 
but they are not in a position to know what the best stuff is 
precisely because they are the leaders. They must ask the people 
they are doing this all for. If Walter, for example, want's his 
baby to grow up to fill an important part of human history(if 
not, then why all the work?), it seems wise that he make it the 
easiest to use. Easier = more people use it = more useful to 
people = bigger = longer = better.

By niche, I mean simply compared to the overall D developmental 
issues. Web site design may not be totally niche, but solving 
some rare dmd internal compiler problems are. Also, D can't 
compete with the web server community so it is also niche in that 
regard. (until you make D easy to use, whats the point of 
creating cool stuff for it... no one will use it if they can't 
get there easily)

>> 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.

I don't disagree with anything you have said. The problem is 
mainly an "attitude".  It's the same attitude that people make 
about life "I'll die, go to heaven, so whats the point of 
"fixing" stuff here, now?".  But that attitude is what make it 
bad in the first place. Letting things "ride" because it's the 
easier thing to do but just perpetuates the problem which grows.

D, obviously, has done some great things. But there seems to be a 
huge lack of focus on the important things that will make it 
better.

It's quite simple, the 100 or so people working actively on D's 
growth can't do much of anything compared to 1M people working on 
it. Hence, it would seem best to figure out how to get the 1M 
people working on it quick as possible. As the 100 people toil 
away at solving these "niche" problems, they are not working on 
making D "affordable" to everyone. They are not multiplying their 
effort. They have a 1:1 leverage ration instead of 100:1.

D should be much larger than it is. How long as it been out? 
There is a dysfunctional issue with D.  Look how fast go and rust 
took off? There are reasons for that. Mainly because they created 
an easier to use and more functional toolset.  Kids that are 
getting into programming that have issues with X will drop X in 
blink of an eye and move on to Y. If Y is easy and works and does 
what they want, then they will stick with Y. At some point 
they've invested in Y and continue to use it. D has the issue 
that it is not easy to use beyond basic trivial non-dependent 
coding.  Hence when these kids try to do real world stuff(openGL, 
audio, GUI's) and run into 1984 problems, they move on to 
something easier.

D has so much resistance that it has to overcome this if it cares 
to be a dominant player. Focusing on the wrong stuff is wrong. D 
does that a lot IMO... or at least neglects the right stuff(easy 
of use is a huge factor, and partly D has this in a fundamental 
way, but not in a "everyday real world use" way).

My main issue with D is not so much what it does, but that I feel 
it is not covering enough ground on certain areas that I feel my 
investment in it will not return anything. I could spend 10 years 
becoming a D pro and if D goes fades away, then what would it all 
have been for? Each person that makes such a choice of using D 
will have to ask themselves that question. Some obviously are ok 
with investing in it, *many* are not(the masses). That concerns 
me, because the D "leadership" doesn't seem to think it matters. 
What D needs is a marketing genius that can make D in to 
something viable.