Thoughts about D

Michael V. Franklin slavo5150 at yahoo.com
Mon Nov 27 01:32:33 UTC 2017


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



More information about the Digitalmars-d mailing list