D Programming Lanugage

[NardCake]

Hello! I have recently discovered the D language and began using/learning it. After playing with it for a few days I have fallen in love with the language. How many of you have used it? Did you like it, hate it?

If none of you have heard of the language here is the website. The language is very similar to C++ (you could say C as well but I will say C++ because of the OOP features) but borrows things from other higher level languages, I think it could eventually replace C++ (meaning used for things C++is currently used for), especially since it compiles to native code.

The community at the moment is extremely small, but great. There are many libraries (some discontinued) including a version of Gtk (which works great). The language has OO features and well as importing (libraries and modules), modules/packages, and the language is very unique and just fun to write.

Since it's a compiled language I have tried some CGI/Web stuff with it, it's quite simple with it's standard library (Phobos) and very speedy. Here I have written a basic class with some simple CGI features (I'm still learning the language).

I'm interested to hear your opinions on the language and maybe some people try the language? There are multiple compilers (I suggest you fetch the official Digital Mars compiler as it's the most updated) for all major platforms.

Thanks for the read!

[vegaseat]

I remember playing around with it, but didn't see any advantages over C++.

[mike_2000_17]

I remain unconvinced of the merits of D. I find many of the design decisions questionable and many others rather inconsequential. But there are certainly some nice things about the language.

Here are some specific points (omitting things that haven't been changed from C++):

Modules vs. namespaces: I disapprove
I don't like that trade-off. Namespaces are much more flexible than modules, and introducing modules smells too much like an attempt to seduce Java/C# programmers more than anything else.

Interfaces vs. Multiple Inheritance: I approve
I'm not particularly attached to the feature of multiple inheritance in C++, and I think that Java-style interfaces are quite an acceptable alternative and it certainly simplifies the binary representation underneath, which is nice.

Inner classes: I approve, but it's nothing major
I write inner classes often in C++, and they are certainly useful, but making this a native feature is little more than a bit of syntax sugar.

Properties: Ugly, and useless
There are many nice and useful versions of this concept of "properties", this isn't one of them. This is barely more than syntax sugar without much of anything useful attached to it. This seems pretty much like the Delphi (Object Pascal) implementation of "Properties", just uglier.

The new template syntax: Ugly, and for no reason
I don't see the point of changing the syntax that everyone recognizes (e.g., foo<int>) with a new thing that is weird and confusing with the NOT operator (e.g., foo!(int)). I also don't like how it violates the scoping rules (at least, as far as I can tell), i.e., a universal truth in C++ is that pairs of curly braces always constitute a scope, it seems that D tries to use curly braces for everything (for sake of harmony) but ends up creating complex scoping rules that cannot be understood at first glance as is the case in C/C++ (and every other {}-style language, AFAIK).

Mixins: I like the idea, not convinced of the realization of it
The mixin concept seems mostly a MACRO promoted to the status of a template. I understand the idea, it is one of the few cases, in C++, where you pretty much have to use MACROs. It feels dirty to do this in C++ (using MACROs) and it does come with a number of issues (i.e., awkward scoping, hidden code, etc.), but the problem is that I don't see that any of these problems are fixed by mixins in D, they are just made prettier (i.e., reduce the "shame-factor" of using MACROs as mixins look more "official" and acceptable). I would have preferred, as an alternative, improved mechanisms for CRTP schemes (CRTP: Curiously Recurring Template Pattern), which is definitely problematic and inflexible in C++, and AFAIK, isn't much better in D.

Static If and Concepts: I approve, very nice
I think this was one of the major reason for creating D in the first place, i.e., providing better and less verbose language support for template meta-programming. I think it is pretty unanimous that, however powerful, meta-programming in C++ is too verbose and ugly, and because it has become a very popular technique, better native support is much appreciated. And of course, concepts absolutely require native language support, and they are immensely useful (and they should have made it into the C++11 standard.. Argggh!!!).

Contracts: Interesting
I haven't used that kind of system before, almost sounds like in-code unit-tests. I can't really judge how useful they are or how used they will be (seems like a bit of a burden, and the payoff is not obvious).

Scope-guards: Well, that's a surprise...
Obviously, a language designed by Andrei Alexandrescu had to include native support for scope-guards. I'm somewhat ambivalent on how useful they really are (but then again, I'm not big on writing scrictly exception-safe code).

Lazy evaluations: Neat, not convinced people will use it much
This is definitely a nice idea. It does imply some sort of template or type-erasure, neither of which is particularly nice to be created just like that (with lazy). I also don't like the context mixing that it implies both for the compiler and for the programmer (i.e., should a parameter be "lazy" because there is a good chance it won't be used in the function, or because it is expensive to create the parameter (before passing it to the function), that's what I call "contextual confusion").

Compile time evaluations: Going too far?
The main reason for restricting the constexpr feature in C++11 to simple function evaluations (small subset of C/C++ operations) is because all major compiler writers were pretty clear about the fact that anything more complicated than was is currently in the standard is far too complicated for the compiler to deal with (parse, assert, execute, and diagnose). It seems the D guys didn't get that memo.

ABI: Cool
Definitely, the greatest blunder in the inception of C++ was to decide not to define a standard ABI. Obviously, the D language designers wouldn't repeat that mistake. However, the ABI is really just the tip of the iceberg (and most C++ compilers already comply to Itanium ABI anyways), there are many other problems related to inter-operability that aren't fixed by a standard ABI.

Last but not least:
Garbage collection: What happened to the Golden Rule of system programming?
I have no problem with the idea of an opt-in garbage collector (if it is done right), for the very few times when it is actually useful. But the D language has decided to go for an op-out method, even worse, for a class-bound opt-out method (via scope class). I think that's a terrible idea. I don't know if the language designers were drunk or something when they came up with that idea. And the justifications on their webpage is feeble at best, and as usual with these things, they make a lot of assumptions about what is "typical" code. They also introduce reference-semantics mixed with traditional C++ value-semantics, and without call-site distinctions for it.... oh God, that's just aweful, even C++/CLI is better than that, which is setting the bar pretty low.

So, in conclusion, I think there are some good things, some bad things, and some interesting new things which are unclear whether they'll be useful or not. Overall, I think they should have been a lot more conservative in their improvements of C++ (and let's not kid ourselves here, this language is intended to be a "C++ rebooted", regardless of what they might say). I think they started with a good idea, i.e., to fix some of the annoying quirks of C++ that make modern development a bit too verbose or awkward, but then, they decided to throw in everything but the kitchen sink.

[NardCake]

Nice! Some of this is interesting to me since I'm not great at these type of languages yet. (I started with PHP) The only thing I don't quite get from your post is how Modules are supposed to seduce C# programmers because C# has namespaces. (I only wrote in C# briefly, I may not be aware os a feature)
Also, thanks for your opinions.

[ddanbe]

FYI C# has no thing called Modules, VB.NET seems to have them, don't know about Java.
If you have Classes and Namespaces, why would anyone need to have Modules?

[NardCake]

Wow In my post I meant to say C# doesn't have namespaces, stupid mistake! My post made no sense lol.

And I think the modules are supposed to create a Java like package system.

[mike_2000_17]

Yeah, I'm not super familiar with C#'s rules about what it calls "namespaces", and if they are actually just modules in disguise. The point is that C / C++ works on the basis of having "dumb" header-file inclusion that are nothing more than an instruction to find a given file and copy-paste it's content where the include-statement appears. The C++ namespaces are used to compartmentalize things to avoid name-clashes. Modules or packages work differently, an import statement tells the compiler (or interpreter) to fetch everything that belongs to that module / package. At least, that is the traditional concept of modules (called packages in Java / Python, called "units" in Delphi (Object-Pascal), etc.). Both have their merits and their problems, and I think, as with many other things of that nature, there is no need for a "pure" solution.

The main advantage of modules is that you can avoid the whole "copy-paste lots of code and parse it, even though you probably parsed it already" problem with the traditional C/C++ header files. For example, units in Delphi are very nice in that respect because they can be essentially pre-compiled and pre-linked (i.e., the so-called Delphi "smart linker") into some kind of hybrid between a C/C++ object file and a shared library, for each unit. Of course, some C/C++ compilers can mitigate that problem to some extent with pre-compiled headers, but that's not really a great solution (and often doesn't work or do any good).

The main advantage of inclusion-mechanism is that they are very flexible, which is mostly a result of the behavior being so "dumb". There are many useful tricks that rely on this simple "copy-paste" behavior.

Modules, depending on the details, often do more harm than good when it comes to name-clashes and things like that. And if you want to avoid name-clashes by importing only some specific parts of a module, the verbosity can quickly be overwhelming. I don't have much experience with modules-based languages, but from what I have seen, it always seems terribly verbose and ugly. Delphi's version of modules (units) is very nice and doesn't have that problem, but Java or .NET stuff is pretty terrible to look at, and seems to throw things back to the K&R C era (i.e., declare every individual thing you need at the top and then write the code).

And the benefits of modules in a C++-like language (like D) is unclear to me. The advantage of modules, as in, "pre-compiled, pre-linked units of code", can only really manifest itself in traditional template-free code (i.e., C-style procedural code and Java-style OOP code), which is not currently much of a problem for anyone. It is true that such code generally compiles much slower in C/C++ than in languages that have modules, however, it still compiles very fast in C++ (e.g., I had a project back in the day with about 30 kLOC in template-free C++ code that compiled in about 5 minutes, which is totally acceptable, even though a similar-size project I had in Delphi compiled in about 15 seconds). Where the real problem lies is with template-heavy code, which can take an excrutiating amount of time to compile. If you want modules-style advantages to apply to template-heavy code, you are basically requiring "export templates" on steroids, a concept that compiler-vendors hate with a passion and were clamering to abolish (which it was in C++11). You can, of course, introduce modules and let the compiler vendors decide how to make modules for template-heavy code, as I believe is the case in D, but I doubt any compiler vendors will make serious attempts at doing much optimizations there. So, modules don't really solve the problem, they just brush it under the rug. And all this at the expense of the flexbility of the traditional file-inclusion / namespace mechanisms. So, I'm not convinced this thing really hits the mark, but I may be wrong.

[james.lu.75491856]

Most languages say they have namespaces. They really have variable spaces. Except for python;
if you take, say the number 3, it is refrenced from these "free lists" up to sys.maxint, so if you
assign a bunch of names to 3, it will take the same amount of memory if you did nothing at all;
But, if you had some mutable objectsa that are the same and created like this:

a = []
b = a

and edited b, a would change too. (That's why python dict's keys' can't have mutable objects)