
D at 20: Hits and Misses [pdf] - noch
https://digitalmars.com/articles/hits.pdf
======
sedatk
I think the presentation exposes the big picture: D is a _very_ loaded
language. It tries to serve every possible exotic need imaginable. Probably
not as much as C++ but that’s a committe-designed language, it doesn’t count.

The feature bloat makes it very hard to learn D, let alone being an expert on
it. I think it’s telling why its creator focuses on individual features to
assess its success. Now, all those missed features either have to be
maintained or carefully removed which is a lot of work and might actually
break existing code.

I like D because of its vision: C++ for humans. It fails on that vision simply
because it has become a gigantic incoherent product like a research project.

It probably needed a harsher approach to feature requests to make sure the
language stayed on the vision. Now it’s a programmer’s dream and a
programmer’s nightmare at the same time.

I think Go, for instance, has made a better decision to stay barebones.

I see that the creator intends to include Rust’s borrow-checking semantics
which reminds me that Rust is probably what D should have been in all aspects.

~~~
Ace17
> The feature bloat makes it very hard to learn D, let alone being an expert
> on it.

Learning 100% of any programming language should not be a goal. I know less
than 10% of the functionalities of my microwave oven or my washing machine.
This doesn't prevent me from successfully using them and save a lot of time.

Bjarne Stroustrup himself says learning all the nitty-gritty details of C++ is
counterproductive and unnecessary.

~~~
astrobe_
The problem with feature bloat is related to a very well known fact: Code is
read more often than it is written. As a consequence, if you don't know the
little details of a language, it might be a harder to read code written by
someone else that is more knowledgeable.

Consider for instance Lua, which is often read by people that have superficial
knowledge of the language. Lua has a very standard syntax that anyone with
basic general programming knowledge will understand:

> player:set_pos({x=0, y=0})

But it also has syntactic sugar:

> player:set_pos{x=0, y=0} -- note the braces instead of parens

This is where you lose half of your readers because they have to look for that
weird syntax in the manual.

In defense of language implementers, it is sometimes difficult to "resist"
feature requests. It's difficult to say "no" in general, in particular when
you are not Niklaus Wirth and have half a dozen languages designs on your
resumé; all you have is your gut feelings as justification.

~~~
Ace17
I have 15 years experience as a professional C++ programmer in various teams
and companies (and although I don't know 100% of C++17, I consider myself
productive!).

When diving into new codebases, the couple of esoteric-used-features-you-did-
not-know-existed in C++ was never a big deal. Learning the required C++
features was always a matter of days (because the codebase is full of real
examples).

Understanding the overall structure of the code, the interactions/dependencies
between the components, in what file/directory should go your first feature...
this is the hard part. And it's many orders of magnitude harder than learning
a couple of new language features.

Don't get me wrong, I'd really like that C++ and D be smaller, and I don't
like feature bloat. I once wrote a source code processor based on clang, and
then you realize how big the language really is (there are _many_ AST node
types), and having all your code written in it starts to feel like technical
debt.

However, I pragmatically have to recognize that feature bloat isn't a real
problem for professional C++ programmers (It might be, for compiler vendors -
at this point, I'm not expecting any new C++ compiler to be created).

PS1: C++ certainly gives you some shiny tools to make interesting messes (I've
seen codebases where simply including a header would change the program
behavior). This isn't related to the feature count, but rather to the semantic
of the individual features themselves, like macros/templates. At least we
don't have monkey patching ...

PS2: About your Lua example: even without knowing the syntax, can you
sincerely have the slightest doubt about what "player:set_pos{x=0, y=0}"
actually does?

------
lesbaker
Looks like this is slides from a talk Walter Bright gave which has been posted
to YouTube [1]. It helps with some missing context.

For example, I wondered why in the slides he felt implementing contract
programming in D was a miss; it seemed like a strong selling point for the
language. According to the talk (around 1:34:30), however, he felt that
contract programming was relatively unpopular/unused in D and that "assert"
covered most of the use cases for it.

[1]
[https://www.youtube.com/watch?v=p22MM1wc7xQ](https://www.youtube.com/watch?v=p22MM1wc7xQ)

~~~
mamcx
Contracts are interesting but I think to make it usefull 1) are ON on release!
and 2) Become part of the docs.

One example:

    
    
         fun date(y:i32, m:i32, d:i32)
         {... code ...}
    

This scream for more context (and better param names!). With contracts:

    
    
         fun date(y:i32, m:i32, d:i32)
         assert
             y in 0..9999
             m in 1..12
             d in 1..31
         {... code ...}
    

But I need to see it in the docs, in the tooltips, etc. Now are useful!

~~~
klipt
Good old February 31.

~~~
mamcx
Nothing like a bug behind a safety feature :)

~~~
elgenie
That’s … not a bug.

A buggy assertion would be one that fires when the input is correct.

Assertions aren’t formal verifiers or replacements for a test suite.

------
CamperBob2
I use binary literals all the time, for what it's worth, in code involving
hardware interfacing. Only complaint with C++14's implementation is that they
didn't allow underscores to be inserted for clarity, a la Verilog.

Those underscores turn out to be a _really_ big deal, and leaving them out of
C++ was a massive mistake. Nobody wants to read constants like
00110100101101011011011101011110, but 00110100_10110101_10110111_01011110 is
fine. An implementation of binary constants that doesn't allow this is going
to be less popular.

~~~
alexhutcheson
You can use ' as the digit separator, like:

    
    
        0b00110100'10110101'10110111'01011110
    

It's not ideal, but using underscores was off the table, because things like
_100_ are actually valid variable names and it would have caused parsing
issues.

~~~
WalterBright
_100_ is an identifier in D, too. The simple rule is _ can be embedded in a
numeric literal, it just cannot start one.

~~~
alexhutcheson
Actually I got this wrong - the ambiguity occurs with C++11 user-defined
literals, not with variable names. See [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2008/n274...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2008/n2747.html)

------
Thorrez
Interesting that garbage collection is listed as a miss due to latency, and Go
has gotten popular with garbage collection with an emphasis on low latency.

~~~
pjmlp
The big issue is lack of technical resources to improve GC's performance on
D's runtime.

Some improvements have been made lately, but not at the level of manpower and
CS background from other GC enabled languages.

I am quite confident that if D had something like Microsoft behind it, its GC
would long be as good as Sing# or System C# (M#) were.

~~~
WalterBright
> The big issue is lack of technical resources to improve GC's performance on
> D's runtime.

The underlying issue is that to make the GC more performant requires the
addition of "write gates", where writing through a pointer notifies the GC
that the memory object has changed. This is a reasonable choice when a
language is heavily GC dependent (like Java).

However, D is not at all heavily GC dependent. But it is very dependent on
memory references. Hence the GC speedup from adding write gates would be more
than lost from the cost of executing those write gates.

------
voldacar
Will the "misses" be removed from D eventually?

~~~
earenndil
Many of them have been already.

~~~
WalterBright
A tree needs pruning now and then :-)

~~~
petre
I hope that doesn't mean removing the GC in favour of borrow checking or
manual memory management.

~~~
WalterBright
The GC, although often maligned, is highly useful and will stay.

------
fithisux
What I find D interesting is that it is a really good fit for scientific
programming. Maybe Julia is an answer, but in terms of producing interoperable
code, it is the holly Grail. And people can port their Java code mostly
painlessly. Science is the killer app of D where GC is a blessing in disguise.

------
renox
Some of the slides are contradictory: miss lack of safety by default and miss
focus on GC. Well if you want safety by default, then either you use a GC or
you're a Rust/cyclone clone, I don't see a third way..

~~~
pjmlp
The third way is not throwing out the baby with baby water.

The path pursed in the past by Mesa/Cedar, Modula-3, Sing# or more recently
System C#.

Provide automatic memory management by default, while offering all the tooling
stack and global allocation, with low level stuff and untracked references
requiring explicitly unsafe code.

For more modern approaches that combine those ideas with Cyclone ones, Chapel,
Swift, Ada/SPARK, ongoing Haskell and OCaml support for linear types.

So you get the productivity of automatically memory management, graphs, self
referencial structures and what not, while being able to go low level for more
fine-grained resource management.

------
kjs3
D is 20? That's.......telling.

~~~
tastyminerals
That is if we count the development of D1 which appeared in 1999. Later in
2007 D2 emerged with breaking changes. D1 was discontinued in 2011 and D2
became simply D. So, yes formally D is 20 years old but one could say that
it's newer reworked version is just 12.

~~~
WalterBright
I _started_ on D 20 years ago. It was a couple years before I even managed to
make a prototype that people could play with. 20 years ago it was a few notes
on a piece of paper :-)

------
faissaloo
I guess they never miss huh

