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.
