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