Thoughts about D
IM
3di at gm.com
Mon Nov 27 08:33:42 UTC 2017
On Monday, 27 November 2017 at 02:56:34 UTC, Walter Bright wrote:
> 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
Thank you Walter, and all for your replies.
I want to re-state that I really like D, *despite* of feeling
frustrated with it sometimes. I only mentioned in my post some of
the things I don't like about D, but I didn't mention the many
things I _DO_ like about it, but that's not the point now.
I intend to stick with D for a while. I bought all the available
books about D I could find and reading through them. I watched
many of the DConf videos, and I read the (weekly?) blog post. I
also intend to write a doc introducing D and its benefits to my
co-workers and colleagues, suggesting that we could use it in
some areas where it makes sense, but my D knowledge isn't quite
there yet. Also I won't be able to write it until I manage to
overcome my points of frustration with the language.
My plan to overcome my frustration is:
- Continue learning and experimenting with D.
- Stop thinking about D as C++ with slightly better syntax, and
do a paradigm shift.
What I hope to see in D in the feature:
- Sane correct defaults (as someone mentioned above, @safe by
default for instance?).
- More exposure. I sometimes feel like there isn't enough D
material to consume on a regular basis (and I and certainly many
others are eager to learn more and more about the language). i.e.
one blog post (weekly?), and a single DConf annually is not
enough. In the C++ world, there's always something to read
(various blog posts) or something to watch (CppCon, C++Now,
Meeting C++, code::dive, Pacific++, ...etc.)
Thank you all for the hard work that I really appreciate!
More information about the Digitalmars-d
mailing list