The D language

Started by
90 comments, last by Nitage 17 years, 10 months ago
I've looked at D from time to time as it's evolved, but it still has yet to offer a solution to any problems I have.

After reading all of the above posts it seems to me that D offers the functionality of C++ for the most part, except that it's moved some functionality out of an external library and into the language runtime and it's got a different syntax for achieving many of the same ends. For goodness sakes, folks, C++ has strings and associative arrays and they've been available for logner than most of you folks have been programming.

I'm not going to knock the 'differnt syntax' (aka syntactic sugar) thing, since that can make a big difference in development time. The movement of stuff into the language runtime can be a dealbreaker for many applications, though, expecially embedded apps and program deployments.

The thing that made C++ so successful was it's combination of pay-for-only-what-you-use and backwards compatibility with C. C was so popular because it was freely available and highly portable. Most "better C++" attempts, including Java and its cousin C#, and D, require that you pay for things you don't use (D not so much, but still some) and their advantage of no legacy support is negated by their lack of legacy support.

I would suggest you go ahead and learn D, use it if it gets you there. Become an expert, contribute back to the D community. Make your decision based on whether it solves a problem you have with other languages (easier to learn?), not because some evangelist has said it's unqualifiedly better than C++.

Stephen M. Webb
Professional Free Software Developer

Advertisement
Quote:Original post by snk_kid
Quote:Original post by Nitage
How would you add a member function that sets the matrix to the identity matrix? In C++, you'd have to duplicate the entire class definition, using partial specialization to pick out square matrices (the only kind of matrices that have identity matrices).




Well not quite, it's not true it's just the most obvious solution but it's not the only one. I can think of two methods that don't require (partial) specialization.

1.

#include <cstddef>#include <boost/utility/enable_if.hpp>#include <boost/mpl/equal_to.hpp>#include <boost/mpl/size_t.hpp>namespace mpl = boost::mpl;template < std::size_t M, std::size_t N >matrix<M, N>& identity(matrix<M, N>& m,                       typename boost::enable_if<                           mpl::equal_to<                               mpl::size_t<M>,                               mpl::size_t<N>                            >                        >::type* = 0) { /*<-insert-code->*/}


2.

//.... just imagine headers herenamespace mpl = boost::mpl;using namespace boost::mpl::placeholders;template < typename Matrix >struct sqr_matrix {    Matrix& identity() {          Matrix& this_ = static_cast<Matrix&>(*this);          //.......          return this_;    }    // add all other ops that are only for square matrix};template < std::size_t M, std::size_t N >struct matrix    : mpl::if_<          mpl::equal_to<              mpl::size_t<M>,              mpl::size_t<N>          >,          sqr_matrix< matrix<M, N> >,          mpl::empty_base       >::type{ .... };



Both methods are even less clear than the original C++, and far less clear than the D.

Still, if I decide to go for a new language, it's likely to be C#, the prime reason being that lots of jobs I've seen advertised around me are looking for C++/C# skills and I've never seen one looking for D.
Quote:Original post by Alpha_ProgDes
Quote:Original post by daerid
Consider a class that as one of it's members has a HANDLE to an open file.

When the object dies, you don't necessarily care about how much memory it's taking up, but you definitely want that HANDLE to the open file to have CloseHandle() called on it, or you get an orphaned open file (one of the most annoying things about windows EVER).

That sounds like more of a API issue than a language issue.


How is it an API issue? The underlying system can't make any assumptions about when the handle to the file you've opened needs to be closed, nor should it. My example wasn't meant as a subject in and of itself, but more as a sample of how the two domains of memory management and resource management are clearly separated.
daerid@gmail.com
Quote:Original post by daerid
Quote:Original post by Alpha_ProgDes
Quote:Original post by daerid
Consider a class that as one of it's members has a HANDLE to an open file.

When the object dies, you don't necessarily care about how much memory it's taking up, but you definitely want that HANDLE to the open file to have CloseHandle() called on it, or you get an orphaned open file (one of the most annoying things about windows EVER).

That sounds like more of a API issue than a language issue.


How is it an API issue? The underlying system can't make any assumptions about when the handle to the file you've opened needs to be closed, nor should it. My example wasn't meant as a subject in and of itself, but more as a sample of how the two domains of memory management and resource management are clearly separated.


Still, it is very nice to just create a std::fstream on the stack, and know that it will automatically take care of it self when you are done with it (provided it is nested in a function or other scope).
In most languages with garbage collection, we are back to the old C-style *create(), *destroy(), calls, and then the garbage collector runs at some time in the future.
At least D allows you to circumvent the garbage collector, and provides some RAII support (with auto), but as of the current release of GDC it is still easilly broken.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Quote:their advantage of no legacy support is negated by their lack of legacy support.


This is where D differs from C# and Java - D can natively link to and call libraries that expose a C interface. In fact D can also create libraries with a C interface. There are no shims or complex porting issues to deal with, and now that there is a tool called htod which converts from C headers to D import files (using a C compiler frontend to do so), using C libraries in D is almost painless.

Quote:I'm sorry but that is a pathetic example and poor C++ code.
..
Well that says it all...


Oh snk_kid, you are so cool. I don't even know how to begin to comprehend your arrogance.
_______________________________________________________________________Hoo-rah.
A lot of good points have been made by Aldacron and h3r3tic with which I agree. I especially share h3r3tic's thought that D is good by stacking up a lot of 'small' improvements, it's the totality of all those features and there's no slogan such as 'write once, run everywhere' possible with D.

For me, as a hobby programmer - and thus having different needs and goals - D is a replacement of C++, which I still think is a great language. The two languages are similar in scope and design enough for my ends that, with this I agree with snk_kid, for a broader perspective I would sooner learn scheme, haskell, python, assembler or whatever. Even C.

From my, I admit limited, point of view there are two points in D where it has a somewhat different accent than C++. The first is that it aims to be a pragmatic language, which concretely means such things as an easy to parse language(context-free grammar) so that compilers can implement the standard and tools can more easily be written, inline assembler, generally a lot less undefined behavior, etc. The second thing is it's emphasis on the prevention of errors and reliability. Contract programming and unit testing come to mind, but also this influences a lot of other things such as the ongoing debate about the raii type and copy constructors, no void initializaton, etc.

Related to the 'moving over' part, the lack of books, tutorials, libraries, immature compiler and all that seemed daunting at first to me, but I have found that the benefits of D in practice surpassed all that, benefits that free up more than enough time to learn all that stuff. There is enough in the newsgroups, spec and at www.dsource.org to get going, and the increase in productivity and enjoyment, plus the decrease in bugs, make me quite content. It's not such an adventure into the realm of wtf as it may look, at least for me most quirks (even compiler bugs) were more easily dealt with than what C++ presents as a challenge.
This is, of course, all my opinion and not fact for everyone, I don't see any merit in trying to argue D can obsolete C++ or such babble even though it does for me. My point is that D can be worth it to try it out sometime in practice.
Quote:Original post by Drakex
Quote:Does anyone have some code that shows D doing something better than C++ or at least being done in a less complicated fashion?


Alright then. This is a trivial example, but demonstrates a few key issues: operator overloading, templates, classes, and overall syntax:

Except that the example you provided doesn't show D doing anything noticably better or simpler than C++; and in a few cases the C++ version is actually clearer.

For starters, the C++ version could (and should) be re-written as
#include <iostream>         //the .h headers are deprecated#include <vector>           //STL is part of the standard libraryusing namespace std;        //just for the sake of this exampleint main(int argc, char** argv){	for(int i = 0; i < argc; i++)		cout << "Arg " << i << " = " << argv << endl;	vector<int> c(10);	c[4] = 5;	c[6] = 10;	cout << "Length: " << c.size() << endl;	cout << c[4] << ", " << c[6] << endl;        for(vector<int>::iterator i = c.begin(); i != c.end(); i++)    //this loop was present in the D version, but not the C++ version; I took the liberty of adding it                cout << *i;	c.clear();}        // 0 no longer needs to be explicitly returned

which, you will notice, is significantly shorter, and no less clear, than the D version you provided. (To be fair, the class definition in the D version is ALSO superfluous.)


Specific nits to pick:

The operator overloading example seems to me to be needlessly complicated in the D version.
For starters, the function name in C++, operator[], has the advantage of including the operator itself; whereas for D, the programmer has to know the name of the appropriate function (opPostInc, opMulAssign) and in some cases the baroque operator usage conventions (opCmp). Furthermore, in the case of the index operator [], D MANDATES that you write two functions, opIndex and opIndexAssign, which will largely duplicate one another, in order to get the same functionality as a reference-returning operator[]; the only advantage to D's indexing operator is that it can accept more than one argument, which in C++ requires overloading operator() instead.

Now lets look at the arguments to main(). Oh, what's that I see? Is that a char[][]? I laugh in the face of any language that purports to have "better string handling than C++," yet requires you treat a string as an array of chars (especially considering the D runtime already goes to the effort of converting the command-line arguments into a dynamic array, which C++ doesn't do), and thus requires that you use array semantics when dealing with them. I find their justification for using ~ as the concatenation operator instead of + to be weak (in the case of strings at least), especially since addition is conceptually related to concatenation, whereas complementation (the traditional meaning of the ~ operator) is not.

D's template instantiation syntax is rather wonky (admittedly this is a rather trivial criticism). Seriously, what's that exclamation-point doing there? Yes, < > can be ambiguous at times, but templateName!(arg) looks like some twisted alien-hybrid destructor.

In D, constructors and destructors are named this() and ~this() respectively; but this is just a cute novelty.

In fact, the only clear advantage that your example shows, indirectly, is D's better support for variadic functions ( writefln() to be specific ). If you want to show D doing something better or simpler than C++, might I suggest an example that uses features of D that are not trivially duplicated in C++?
Quote:Original post by Anthony Serrano(...) If you want to show D doing something better or simpler than C++, might I suggest an example that uses features of D that are not trivially duplicated in C++?


How about a regular expressions compiler? At the end of the following article you can find the source code:
templates revisited

Quote:
How do D templates fare with something much more significant, like a regular expression compiler? Eric Niebler has written one for C++ that relies on expression templates. [4] The problem with using expression templates is that one is restricted to using only C++ operator syntax and precedence. Hence, regular expressions using expression templates don't look like regular expressions, they look like C++ expressions. Eric Anderton has written one for D that relies on the ability of templates to parse strings. [5] This means that, within the strings, one can use the expected regular expression grammar and operators.

The regex compiler templates parse the regex string argument, pulling off tokens one by one from the front, and instantiating custom template functions for each token predicate, eventually combining them all into one function that directly implements the regular expression. It even gives reasonable error messages for syntax errors in the regular expression.

Calling that function with an argument of a string to match returns an array of matching strings:

import std.stdio;
import regex;

void main()
{
auto exp = &regexMatch!(r"[a-z]*\s*\w*");
writefln("matches: %s", exp("hello world"));
}




Quote:Original post by Anthony SerranoIf you want to show D doing something better or simpler than C++, might I suggest an example that uses features of D that are not trivially duplicated in C++?

How about you take a look at the examples I posted ?
If Joe's favorite vacation spot is Guam, and Jack's favorite vacation spot is Boracai (in the Phillipines), and each has never visited the other's favorite spot, then any discussion on the finer points of each is going to be fruitless. Joe may have read about Boracai, and seen pictures, but that is a far cry from actually walking the white sand beaches (btw, if you ever get the chance to go, it's worth the trip - Guam is a tourist trap).

These language debates are just as fruitless. Everyone explaining what they see as good points about D in this thread are people who use the language on a regular basis. The ones saying why it isn't all that are people who read the spec and, maybe, toyed with it a little bit for a couple of hours, maybe two years ago.

We can theorize about syntax, libraries, and features all day long. We can show source snippets all day long. All of that is meaningless. A majority of people using D right now did not just get off of the boat. They have been programming for years. They come from diverse backgrounds, but mostly from C, C++, or Java. They experimented with D over time, for one reason or another found it to be a better alternative, and started using it.

Once you've put D to work in an actual application, the benefits become apparent. How can you say a restaurant sucks if you've never eaten there or only had one dish? How can you say a movie was terrible if you've never seen it or only seen the previews? I have a very solid basis to compare D to Java because I have quite a bit of experience with both. My C++ experience is not so extensive, but I have created applications with it and not just toyed around with source code snippets. So I feel comfortable in my own comparisons of the three languages.

In terms of programming theory, sure, discussions on specs and features have meaning. But when you are talking about the pros and cons of using a language, then specs and features have no context unless you've actually put them to use. I don't know about others, but I wouldn't go running out to hire a patent attorney to defend me in a murder trial. It's amazing how otherwise sensible people fail to apply the same criteria in these programming language discussions.

I suggest that anyone looking to get info about the pros and cons of D visit the forums at dsource.org (particularly the General forum), or the digitalmars.d.learn Newsgroup (web interface here if you don't like news clients) and ask the people who use D every day. They understand the pros and cons of the language because they've done more than look at the spec. They are also very helpful in helping new users along, and very vocal in telling Walter what they like, don't like, and want to see changed. Reading through digitalmars.D will give you an idea of some of D's dark side.

Obviously, if you've dismissed the language just on the spec or aren't in the market for anything new, then there's no reason to bother with it. I'm not going to waste my time trying to convert anyone. New languages are for people who are not satisified with what already exists and are looking for alternatives. I'm not into that "my Dad can kick your Dad's ass" sort of thing, but I am into helping out other people by introducing them to an alternative language that I think has great potential. If they try it, like it, and stick with it, great. If they don't like it, fine. But at least then they'll have a basis for their opinion when discussing the language with other people.

This topic is closed to new replies.

Advertisement