On 11/26/2017 4:14 PM, IM wrote:
I'm a full-time C++ software engineer in Silicon Valley. I've been learning D
and using it in a couple of personal side projects for a few months now.
Great! Glad you're enjoying it and took the time to post your thoughts.
- 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!
You'll find the same language in 2014 as today, it hasn't changed much. All
languages (except C) in common use accrete features.
D does have some baggage that has been removed, like `typedef`, but on the whole
whenever we try to remove something, someone always has built their store around it.
The good news, however, is just use the subset of D that works for you.
- 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.
The idea is if you just want to write code, you can eschew using them (except
'override'), and just write code. They're all used for optimization or to
provide enforceable self-documentation. Other languages would require those to
be documented in the comments, which is not enforceable and even more wordy :-)
'override' is as opposed to 'virtual' which C++ requires and D doesn't.
- 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.
That's true. Java looked like it was going to take over the world when D was
young. These days I'd get rid of inner classes in favor of lambdas if I could,
but you can just ignore inner classes.
- 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.
That's true. But it's hard to beat GC for just writing code and getting it to
run safely and without pointer bugs.
- 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).
The idea with TLS is to deal with endemic threading bugs other languages have.
The default in C/C++ is for globals to be shared, which is completely
impractical to examine a large code base for. __gshared is meant to stand out
and be greppable, making code much more auditable.
- 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.).
D structs are value types, and classes are reference types. Everything flows
from that. C++ structs and classes are the same thing, and can be used as both
reference and value types at the same time, whether that works or not. I rarely
find C++ classes with documentation saying if they are intended as a reference
or value type, and the documentation won't prevent one from misusing it.
I'm not the only one to suggest that making the value/ref design decision is a
pretty crucial one to make before designing the code. :-)
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.
Many people have difficulty with D when coming from, say, C++, because it does
require a different way of thinking about code. This passes once one gains
experience and comfort with D. After all, my early Fortran code looked just like
BASIC, my C code looked like Fortran, my C++ code looked like "C with a few
classes", and my D code looked a bit too much like C++ :-)
I have recently finished converting the Digital Mars C++ compiler front end from
"C with classes" to D. Even though it is a rote line-by-line translation, it
simply looks better in D (much less of a snarl). Over time, as I refactor bits
of it, it'll steadily look better. I find it significantly easier to write good
looking code in D, and it is less verbose than C++.
For some trivial examples,
C++: unsigned long long
D: ulong
C++: template<typename T> struct S { ... };
D: struct S(T) { ... }
C++: for (int i = 0; i < 10; ++i)
D: foreach (i; 0..10)
C++: decltype
D: auto
