Hacker News Reader

Comment by mhh__ | Hacker News Reader

Consistently pragmatic, is the philosophy, really.

There are some pain points that could probably go but realistically the aim is to make writing efficient code easy and abstract code even easier within the same language.

If you learn D you get to avoid a bunch of legalese compared to C++, and lots of runtime bugs compared to Python - there are more features to learn, but they generally make quite a lot of sense when you need them e.g. Ada-style contract programming is extremely useful the moment you don't have it.

View on HN

Can you point to somewhere which makes the case for D vs C++ as of 2020 or so?

I always had the sense - without seriously looking into it though - that D was about avoiding some of the mistakes/mis-features of C++, but C++ is always getting new stuff, which doesn't sit exactly well with what D has chosen, and then it plays somewhat clunky catch-up. But I may be very wrong.

C++ has improved a lot, but many of those solutions have been half-assed versions of things D does to completion.

CTFE in D works as you would expect, constexpr is a weird hack.

Concepts in C++ are ridiculously overcomplicated and are done with a much simpler solution in D.

Ranges are also much better thought out in D.

C++ will also never replicate D's ease of use when it comes to metaprogramming - static foreach and if for example have no alternative in C++ (if constexpr is incredibly stupid)

So, you're saying: CTFEs, concepts and ranges done right. Hmm. Sounds good, actually...

https://run.dlang.io/is/dkFWTu

Sink your teeth into that. Code generation at compile time, functional programming etc.

The compiler can actually check that this is pure for you but in this case it isn't performed so it can read from stdin

D doesn't have concepts. It just takes a different approach.

> if constexpr is incredibly stupid

Would you care to elaborate what's wrong with it? When I used it I always felt it was quite straightforward.

D CTFE restricts what you can't do. If I write my own vector type, even with my own malloc (it would have to get it's memory from the GC when running under CTFE for obvious reasons, but still), I can do useful work on it at compile time and then save that result in the data segment of my executable.

Constexpr tells you what you can do. It adds huge amounts of bulk to the standard, there is syntax soup everywhere now etc.

Yes, C++ has been catching up since C++11.

One thing C++ will never have is D's `static if`, which allows injecting declarations into scopes. Bjarne Stroustrup and others closed that door: https://isocpp.org/files/papers/n3613.pdf

> One thing C++ will never have is D's `static if`, which allows injecting declarations into scope

don't be so sure

https://github.com/lock3/meta/wiki/Metaprogramming-Introduct...

a lot of it is already implemented: https://cppx.godbolt.org/z/4arx6T

Seems horrifically complicated?

it allows to generate code at basically every scope and to create your own "base language elements" like "struct", "class". AFAIK D does not allow for this, does it ?

D's templates has always been very strong and useful compared to C++'s.

The following example is similar to C macros because it generates code as string and mixes it in as code but you can combine templates as well. This example generates a struct definition.

(Edit: formatting)

  import std; // Entire package for brevity
  
  auto memberDef(string type, string name) {
    return format!"  %s %s;"(type, name);
  }
  
  auto memberDefs(string[] members...) {
    return (members
            .chunks(2)
            .map!(pair => memberDef(pair[0], pair[1])));
  }
  
  auto structDef(string name, string[] members...) {
    return format!q{
      struct %s {
        %-(%s%)
      }
    }(name, memberDefs(members));
  }
  
  unittest {
    mixin (structDef("Foo", "int", "i", "double", "d"));
    auto f = Foo(42, 1.5);
    assert((f.i == 42) && (f.d == 1.5));
  }
  
  void main() {
  }

Thanks for letting me know. This seems to be far from being adopted into C++, if at all, right? Is the C++ community behind this effort?

It has been proposed by Herb Sutter a few years ago and has been worked on since by Andrew Dutton, so yes the c++ community is definitely behind it.

See e.g. https://youtu.be/8c6BAQcYF_E

Sounds like something `if constexpr ()` comes close to

> I always had the sense - without seriously looking into it though - that D was about avoiding some of the mistakes/mis-features of C++, [...] and then it plays somewhat clunky catch-up.

My opinion is that D lost its goal on the way. It was indeed supposed to be a cleaner C++ without all its confusing history of layers of features over layer of features. And it was so, for sometime. But then they started adding this, and this, and that, everything and all sorts of kitchen sinks depending on the fad of the year; meta-programming, taking from C++, or lately rustifying itself. The current state looks to me is as indigestible as modern C++ (and the process to get there has largely been the same, the process the original goal of D meant to rid and avoid). A pile of templates and annotations. D's evolution has been a great disappointment to me. I can see Nim going that way too.

But, you know, C++ can't be seen as a proper, complete language as it stood in 1998. A lot of it was partial scaffolding for future development of the language. In order to clean it, you either had to fill in the missing 25-years-or-so of C++ features (in some form or another), or settle on a much more limited language.

It certainly looks very complex and feature heavy.

C++ doesn't implement the D features right.

For example C++20 has constexpr, consteval, constinit, for a less powerful equivalent of D's CTFE.

D use no syntax for this. Things are evaluated in CTFE when they can. The rules are simple, and you can ignore them for the first few years. It's because CTFE is considered a normal thing in D.

Reply on news.ycombinator.com