On Tuesday, 28 August 2018 at 07:30:01 UTC, Walter Bright wrote:
On 8/27/2018 2:14 AM, Chris wrote:
bad feeling about the way things are going atm.
I can quote you a loooong list of problems that are obvious
only in hindsight, by world leading development teams.
Start by watching the documentary series "Aviation Disasters",
look at Challenger, Deepwater Horizon, Fukushima, Apollo 1,
Apollo 13, the World Trade Centers, etc. Of course, there are a
number of them in C, C++, Java, Javascript, basically every
language I've worked with.
I'll guarantee every non-trivial project you've worked on has
problems that are obvious only in hindsight, too. If you wait
till it's perfect, you'll never ship, and yet it'll *still*
have problems.
I'm not making excuses for mistakes - just don't have
unworkable requirements.
This is all good and well and I know that anyone who develops
software shoots him/herself in the foot sooner or later. But this
is not the same situation. If you have to ship something till
date X, then you are under pressure and naturally make mistakes
that are obvious only on hindsight. But D is not under pressure
to include new features so frequently. There's absolutely no
reason to rush into something that eats up a lot of your time
(better spent on more urgent problems) and by so doing produce
possible breakages.
The end of the day is, does D get the job done for you better
than other languages? That's a decision only you can make.
It has done a better job until recently. The problem are not
things like @safe, `const` and whatnot, the problem are very
practical issues such as fear of breakage / time spent fixing
things and running the code on ARM, integration into other
technologies (webasm).
Since the D Foundation was founded I really thought that part of
the effort would go into stabilizing the language and developing
better tools for various aspects of programming (not just
language features). Programming is so much more than just
language features, and languages that offer the "so much more"
part are usually the ones people adopt. But somehow D still seems
to be in its hobby hacker days. Features are first and foremost,
everything else comes second. But features get "ripped" by other
programming languages and they can pick and choose, because they
know what really worked in D, while D has to struggle with the
things that didn't work or only half worked.
Laeeth was talking about being analytical about the whole thing.
Why not find out what features are really being used? I.e. does
the majority really need - for practical purposes - partially
constructed objects?
When people choose a programming language, there are several
boxes that have to be ticked, like for example:
- what's the future of language X? (guarantees, stability)
- how easy is it to get going (from "Hello world" to a complete
tool chain)
- will it run on ARM?
- will it be a good choice for the Web (e.g. webasm)?
- how good is it at data processing / number grinding
- etc.
I think the D Foundation should focus on the more "trivial"
things too. If a company is asked to develop a data grinding web
application along with a smart phone app - will it choose D? If a
company offers localization services and translations - will it
choose D (autodecode)?
The D community / leadership is acting as if they had all the
time in the world. But other languages are moving fast and they
learn from D what _not_ to do.
Last but not least, if it's true that the D Foundation has raised
only 3.2K, then there's something seriously wrong.
