Archive for the ‘Discussion’ Category

D is Neither C++ Nor java

Friday, September 15th, 2006

Get it in your head right now: D is not C++ and D is not Java!

There is a natural tendency when learning a new language to, initially, attempt to use it the same as a language you are more familiar with. This is especially true when the two languages are similar in syntax. Since most newcomers to D seem to primarily come from C++ and Java, and since D is similar to both languages in many respects, people are naturally trying to shoehorn C++ and Java idioms into D, sometimes becoming frustrated when things don’t work as they expect.

Feature requests for functionality found in other languages are not uncommon on the D newsgroup. I personally think Walter has done a great job of sticking to his guns for the most part. Granted, some of the features that he relented on after the community harrassed him have turned out to be incredibly useful. Some have even given D a unique flavor that really sets it apart.

I would love to see reflection/introspection capabilities similar to Java or C#. That would really put D in a unique position, being the statically compiled systems language that it is. I wouldn’t mind seeing a more explicit syntax for properties, but it’s not something I consider a deal breaker. I can do without assignment overloads, but if such a thing ever did make it in, I wouldn’t cry about it.

So I have my opinions and everyone else has their own. But it’s not the feature requests and wishlists in and of themselves that prompted this post. It’s the reasoning behind some of them. I get the impression that some feature requests are made not because they are great ideas that would improve the language, but because they would bring D more in line with language X.

I shall repeat myself: D is not C++ and D is not Java!

One of the reasons so many C++ programmers have such a disdain for Java is because they can not, or will not, take their C++ hats off long enough to learn that Java isn’t C++. I have seen enough microbenchmarks, which are generally useless anyway, coded in Java by C++ programmers to know that C++ programmers can’t write Java code. When you whip out a Java compiler, you have to be wearing a Java hat.  Operator overloading is not a feature in Java, so if you are thinking in Java you won’t miss it. The same holds true in reverse, of course — Java programmers need to be wearing a C++ hat when Stroustrup comes off of the shelf.

One more time: D is not C++ and D is not Java!

When you come to the Land of D, drop whatever hat you are wearing at the gate. Keep your fundamentals, because you’ll need those. Keep the memory of what it was like to wear that other hat, because sometimes those C++ or Java tricks may come in handy in the D world. But under no circumstance should you expect to find yourself on familiar terrain. Sometimes you will, but familiar does not mean identical.

The next time you see yourself looking for that C++ or Java feature that D doesn’t have, ask yourself which hat you are wearing. When you have the D hat on, most of the time you’ll find that you just don’t need that feature at all.

Technorati Tags: , ,

D Discussion at GameDev.net

Wednesday, June 28th, 2006

There is a new thread over at GameDev.net where someone is asking about D. That’s akin to a straight guy walking into a gay male bar to meet a woman. GameDev is a fantastic resource, but the majority of forum users are fairly biased toward C++ and rarely give any informed answers to such questions. Such threads usually degenerate into language bashing and misinformation dumps. So far, the thread has actually been civil and people have shared their personal experiences with D. Still, they aren’t D users and it’s obvious that they haven’t looked at D in a long while.

I know a lot of you are using D to make games or game engines. If you are one of them, perhaps you should get on over to GDNet and let Red Ant know your experiences with D, both good and bad, and what you think of it, so that he can better decide if it’s something he’d like to explore.

Technorati Tags: ,

More on Policies

Saturday, June 17th, 2006

A limitation that I quickly ran into with my attempt at templated, inherited policies was D’s lack of support for multiple inheritance. Normally, I have no need for MI, but this is one case where it would have been neat to have. As long as a class uses one policy, the templated, inherited approach is good enough. To solve the multiple policy problem, I went with templated containment:


import std.stdio;
class Host(G, M)
{
    G g;
    M m;

    void doSomething()
    {
        g.foo();
        m.bar();
    }
} 

class GreetPolicy
{
    void foo()  { writefln("Hello World!"); }
}

class MeetPolicy
{
    void bar() { writefln("Nice to meet you!"); }
}

void main()
{
    Host!(GreetPolicy, MeetPolicy) h = new Host!(GreetPolicy, MeetPolicy);
    h.doSomething();

    Host!(GreetPolicy, MeetPolicy) h2 =
        new Host!(GreetPolicy, MeetPolicy)(new GreetPolicy(), new MeetPolicy());
    h2.doSomething();
}

By using two constructors in the template, policies which require constructor args can still be used. The only drawback to this over the inheritance model is that the host does not inehrit the interface of the policies. The inheritance approach is pretty powerful in that regard. With the inheritance form of the template, if the host expects the policy to implement one non-private method but the policy actually implements more, the host inherits all of those methods as well. If there’s a way to mimic that with templated containment, I haven’t figured it out yet. Maybe someone else has?

Technorati Tags: , , ,

Policy-based Design in D

Friday, June 16th, 2006

I’m still a noob when it comes to templates in D (and in C++ for that matter). I have a basic understanding of what’s possible, but when people post complex templates on the NG I’m always left scratching my head. Today, I was working on a project and decided I wanted to implement a certain feature using a policy-based design. So I turned to my test folder (which I recently emptied, I do lots of little D tests to figure things out) and implemented policy.d:


import std.stdio;
class Host(T) : T
{
    void doSomething()
    {
        T.foo();
    }
} 

class GreetPolicy
{
    void foo()  { writefln("Hello World!"); }
}

class GreetHost : Host!(GreetPolicy) { }

void main()
{
    GreetHost host = new GreetHost();
    host.doSomething();

    Host!(GreetPolicy) h = new Host!(GreetPolicy);
    h.doSomething();
}

I can’t stop thinking how cool that is. First, I had no idea if I would be able to let Host subclass(T). Second, I was sure the first example usage would work, since that’s how I implement Singletons in D. But, the second useage, I wasn’t really sure of. I was quite stoked when the script ran and printed “Hello World” twice. I can’t wait to wrap my head around more template magic.

Technorati Tags: , , ,

Growing Pains

Sunday, May 21st, 2006

I started a guild once in an MMOG I played regularly. I wanted to gather together some like minded people that I could depend on to be there and help each other out. It worked out quite well. We became a tight knit group and gradually added new members to the fold when we found them agreeable. Two years later, we had become so large that playing the game became like work for me. I was constantly arbitrating disputes, soothing hurt feelings, chastising trouble makers, and doing my best to keep things interesting, motivate my ‘officers’ to take some of the work load, make new members feel welcome, and generally do everything but enjoy myself. When I took a break from the game, the different cliques that had formed behind the scenes (as happens when you have so many people in one group) eventually caused the guild to fracture. Things were never the same again. (more…)