On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
- D is unnecessarily a huge language. I remember in DConf 2014,
Scott Meyers gave a talk about the last thing D needs, which is
a guy like him writing a lot of books covering the many
subtleties of the language. However, it seems that the D
community went ahead and created exactly this language!
IMO, I don't think it's too bad. I'd rather have those features,
than not have them. One of the best features of D is it's
modeling power. Due to the rich feature set of D, you can model
your code exactly how you think about it; you don't have to
change the way you think about a problem to accommodate the
limitations of your programming language.
Furthermore, compared to C++, the end results is MUCH better.
I've written a small memory-mapped IO library in both C++ and D.
It heavily leverages templates and compile-time features of both
languages. The C++ version turned into a monstrosity that even
I, the author, couldn't understand. The D version was quite
beautiful and elegant, much less verbose, and even had a few
features I couldn't figure out how to do in C++.
- D is very verbose. It requires a lot of typing. Look at how
long 'immutable' is. Very often that I find myself tagging my
methods with something like 'final override nothrow @safe @nogc
...' etc.
I agree, but I don't think it's as bad as C++ (see my comment
above). But, unfortunately, D has chosen the wrong defaults, IMO:
(1) We should be opting out of @safe, not opting into it
(2) D should be final-by-default (See
https://wiki.dlang.org/Language_design_discussions#final-by-default for how that got shot down)
(3) Perhaps D should be nothrow by default, but I'm not sure
exactly how that would work
(4) As a systems programming language first and an applications
programming language second, I argue that the GC should be
something we opt into, not opt out of. With `scope` and DIP 1000
features, we may eventually get there.
(5) I think variables should be `immutable` by default like they
are in Rust, but others disagree.
You get the idea. I think part of this is due to historical
accidents. D is, unfortunately, carrying a lot of technical debt.
- It's quite clear that D was influenced a lot by Java at some
point, which led to borrowing (copying?) a lot of Java features
that may not appeal to everyone.
Many seem to think of D as a better C++, but like you, I see more
of an influence from Java too. I like the convenience of *some*
of those Java-like features. So, I consider the influence of
Java somewhat of a strength in D.
- The amount of trickeries required to avoid the GC and do
manual memory management are not pleasant and counter
productive. I feel they defeat any productivity gains the
language was supposed to offer.
I agree. See the documentation for `scope` and DIP1000. I think
the situation may get better if we can continue momentum on those
features.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
There's also been some recent work this month on RAII with
-betterC which may be of interest to you. But I still see
-betterC as a copout, avoiding the difficult work of decoupling
the compiler from the runtime.
- The thread local storage, shared, and __gshared business is
annoying and doesn't seem to be well documented, even though it
is unnatural to think about (at least coming from other
languages).
I think the thread local storage is a great feature of D. It's
one of the defaults that D actually got right. I don't care for
the double-underscore convention of __gshared that seems to be
borrowed from C, but we're lucky to have it. It comes in handy
sometimes.
It's hard to know what difficulty users encounter when reading
the documentation. If you think it can be improved, please
submit a pull request to https://github.com/dlang/dlang.org
- D claims to be a language for productivity, but it slows
down anyone thinking about efficiency, performance, and careful
design decisions. (choosing structs vs classes, structs don't
support hierarchy, use alias this, structs don't allow default
constructors {inconsistent - very annoying}, avoiding the GC,
look up that type to see if it's a struct or a class to decide
how you may use it ... etc. etc.).
I run into those design dilemmas any time I start learning a new
programming language, even with highly productive languages like
C#. It takes time for me to work through a few ideas and finally
arrive at the right idioms that work. But once they get worked
out, it's cooking with gas.
I could add more, but I'm tired of typing. I hope that one day
I will overcome my frustrations as well as D becomes a better
language that enables me to do what I want easily without
standing in my way.
Thanks for sharing your thoughts. It's always interesting to
hear what people think.
Mike
