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.
