« prev ( programming ) next »

23 October 07
in programming

Some reflections on programming in D, and why it kicks serious ass over C++, leaving it dead and broken on the sidewalk

[some typos fixed, thanks comments]

I’ve finally found a worthy replacement for C++. I’ve used C++ a lot in the last 10 years. I’ve written a protein viewer in C++. I’ve done research for scientific papers in C++. But yet, even though I’ve tried to take the moral high road with the STL, C++ just feels ugly and unwieldy.

I remember the horrendous learning curve from C to C++. There was so much to get right – C++ throws out the compactness of C for a baroque welding of different programming paradigms and backwards-compatibility.

So it was with some trepidation that I tried out D, yet another saviour for C++ programmers. Now that I’ve been using it for a few months, I have to say, do believe the hype.

Quoting from an article on D, D is a multiparadigm statically-typed compiled language that achieves conceptual integrity. That is, the author of D, Walter Bright, is willing to say no to features, ultimately leading to cleaner and prettier code.

Here’s a small but illuminating example. In D, objects are always allocated on the heap. You always create objects with “new”. You can’t create static objects. What good does that you? By sacrificing the ability to statically declare objects, we know that objects are always pointer-allocated. Hence, there will never be any ambiguity between obj.property and obj_pointer->property. So you can eliminate the -> operator. It’s always obj.property and your code becomes that much easier to read.

While on the subject of objects, here’s another call. In D, all object methods are virtual. No if’s or but’s – sorry, you don’t get to choose. What you get is the elimination of a whole swathe of potential bugs as you try to inherit from an un-inheritable static methods. Objects are objects after all, because of inheritance. Walter Bright argues that the place to optimize is in the compiler – because of the strictness of defining virtual methods, a compiler can analyze where it would be faster to automatically substitute static methods for virtual methods. Hey, even when you think you lose, you win.

Indeed, Walter Bright comes from a very unusual place compared to most designers of computer languages. He has spent most of his career implementing C++ compilers (plus writing the odd bestselling computer game), and has designed D, in large part, from the point of a compiler writer. A lot of the features are designed to make it easier for the compiler writer.

Dynamic Arrays

The biggest gain in D are built-in dynamic arrays, with a spare and elegant notation. They clean up the horrendous eye-sore that is the STL in C++. I don’t know about you but one of the biggest reasons I switched to C++ was the Standard Template Library. The STL would whisper sweetly in your ear promising that you never have to roll out your own linked list again, or dynamic array, or hash table. But at what cost? For such largesse, my code got a whole lot uglier. Ever tried using iterators?

include <vector>
vector<int> int_list;
// some kind of initialization
vector<int>::iterator iter;

for (iter = int_list.begin(); iter!=int.end(); i++)
{
  // do something with *iter
}

Butt ugly, and a pain to type out. In contrast, dynamic arrays are built into D, so that you can get the same functionality with very clean syntax.

int[] int_list;
// initialization

foreach (i; int_list)
{
  // do something with i
}

Walter Bright, like Guido in Python, and Larry in Perl, realized that most programmers use dynamic arrays all the time, and so made it part of the language. The syntax is so clean that it is, dare I say it, almost pythonic.

Half the power of dynamic typing

Don’t get me wrong though, I don’t use C++ now unless I have to. I do most of my day-jobs in Python. In Python, I really like dynamic typing. Whilst there are many advantages to dynamic typing, perhaps one of the greatest is that you can blissfully avoid dealing with the return type of a function, and just keep on plugging.

In D, the “auto” keyword gives you this same advantage. If you’re declaring a variable that fetches a variable from a function, you declare it’s type “auto” and D will look up the type for you. I’ve saved so much time because of this little feature. And my program is still statically-typed and correct.

Strings that fit in the language

It seems sad to say this, but C++ really should have had a decent string class a long time ago. The one that comes with the STL feels bolted on, you always to keep in mind that you have to interface with C strings at some point. Well, in D, there is a beautiful built-in string class, with lots of useful methods. Even better, since D has built-in dynamic arrays, the string class is conceived as a dynamic array on char “char[]”, and you have the same powerful syntax available to you as with all other dynamic arrays, like for instance, the “foreach” loop.

One of the more interesting developments in D, is the introduction of the concatenation operator ~. At first I was puzzled by this, because in C++, you concatenate strings by “string1 + string2” so why the need for this new operator? But addition (+) is a fundamentally different operation to concatenation (~). You don’t notice this in C++ because there are no built-in dynamic arrays in C++, and thus concatenation of arrays in the STL is done with methods. However, from a conceptual point of view, concatenating strings should be like concatenating any dynamic array:

int[] vals1 = [1, 2, 3];
int[] vals2 = [5, 6, 7];
int[] vals3 = vals1 ~ 4 ~ vals2; // [1, 2, 3, 4, 5, 6, 7]

char[] string1 = "Hello";
char[] string2 = "world!";
char[] string3 = string1 ~ " " ~ string2;  // "Hello world!"

There is also a slicing command for dynamic arrays:

char[] feeling = "smile";
char[] length = feeling[1..5]; // "mile"

Ever tried declaring a hash-table in C++? It’s not pretty. In D, to create a dictionary of numbers with strings as a key, simply declare:

int[char[]] ages;
ages['me'] = 33;

The end result is that strings and dictionaries are just as expressive in D, as they are in Python or Perl.

No more header files, or not repeating yourself twice all the time

C was created in the days of kilobyte memory, and precious compiling cycles. Hence the header file was created out of necessity for sane compiling times, as the compiler can make assumptions just from reading the header files. C++ inherited this. The result is that for any decently sized project, you type a lot of things twice. This, obviously, violates the DRY (Don’t Repeat Yourself) principle of maintainable code.

What better way to eliminate this painful redundancy in typing than to eliminate the preprocessor altogether? That’s exactly what Walter Bright has done. The D compiler scans the source of all modules to reconstruct the available functions in order to check the typing. You only have to type one thing once.

But there’s more. One of the interesting consequences of not having header files is that objects can’t be declared over multiple source files. If you write huge-ass objects with a massive declaration and multiple source files, you’re asking for trouble anyway. By forcing you to write everything in one source file, you are forced to program better. Another side-effect is that since objects are only ever declared in one file, in D, all object methods and properties are implemented inside the declaration braces:

class MyObject
{
  this()
  {
    // constructor
  }

  void my_method()
  {
  }
}

In D, you will never have to type the awfully verbose my_object::my_method again. Constructors are called “this” instead of the ridiculous notation in C++ of my_object::my_object. That’s a lot of wins for readability.

Still, a lot of people complained about the loss of templates with the loss of the pre-processor, so Walter Bright caved in, and introduced templates in D, except he made it better. Better, that is, for the compiler writer. In C++, templates are declared with the characters “<" and ">“, which causes huge head-aches for C++ parsers, as the parsers have to untangle this from genuine greater-than and less-than operators. In D, they are declared with “!(” and “)”, which cause no problems for D parsers.

Syntactic Sugar

There’s also plenty of syntactic sugar in D that gives you a lot of wriggle room when designing objects. For instance, if you have an object method with no parameters that returns a value:

class MyClass
{
  int my_func();
}

You can call the function as:

auto my_object = new MyClass();
auto val = my_object.my_func;

You now have a choice of changing the function into a property without changing the code that calls the function.

With parameters in a function, the key-words “inout” tells D that it’s a call-by-reference, and D will let you use the same variable. No more juggling with pointers to pass values out of a function.

Optional Garbage collection

If anything marks the philosophy of D, it is this: you get garbage collection and manual memory management. D lets you play with pointers, but keeps them in the gun cabinet when not in use. This feature above all marks Walter Bright as the über-pragmatist of language designers. I don’t know of any other language that allows this. If you let your variables dangle, D will clean up after you, but if you really do need to control every bit and byte, you can, perhaps shooting off your foot in the process.

But that’s the weird thing about D, although you can conceivably write operating systems and device drivers in it, you can also hack out a quick-and-dirty text-mangling script. Now that’s conceptual integrity.

( comments )

Mark on 10/23 said:

Nice post!

D does sound infinitely better than C++, not that I’ve spent much time with either. In fact, just the short-comings of C++ that you’ve described D addressing makes me feel like I did myself a service in avoiding C++ as much as possible.

A lot of the improvements (a real string class, garbage collection, sane iterators, no header files) are all things I’ve just taken for granted as a Java programmer. However, the extra touches in D such as “auto” and the concatenation and slice operators look very nice and are things that Java still lacks.

The one thing I really wish Java had was a way to pass around function handles (without having to wrap them in objects and use interfaces). Where does D stand on that? Can you still grab a pointer to a function and pass it around, or does D have something more elegant?

Bosco on 10/23 said:

Hi Mark,

Yes, D has first class functions, though apparently, closure doesn’t work so well (I haven’t tried this out yet). D doesn’t let you access the function pointers to object methods. Instead you create a delegate to an object method, which is like a function.

FeepingCreature on 10/24 said:

Okay, to clear some things up.

First, D does have non-virtual class methods, but virtual is the default. You can mark a method or a class as “final”, which means it can’t be derived from anymore. This sometimes leads to significant speed-ups because of potential inlining.
The -> thing is not related to all objects being on the heap (although that is a good thing as well). It’s merely a matter of convenience. Theoretically, C++ could ditch -> in favor of . as well – there’s no ambiguity here that I know of. Except it doesn’t. Because it sucks. :p
Also, the attribute for parameter-by-reference is “ref” or “inout” on older compilers. “out” is the same, but initializes the variable to the default value at the start of the function.

Agreed on the rest. D is awesome :)
PS: Walter Bright, not Walter Smith.
PPS: D templates own C++ templates’ butts.

UhhhJavaAnyone? on 10/24 said:

Well what you describe here as innovations by Walter Bright, seem like a straight lift from Java, which has been around for more than 12 years now. D might certainly combine the best of both worlds, but lets call D for what it is; A compromise.

Horia Coman on 10/24 said:

“Good artists borrow / Great artists steal” I believe Picasso once said. Frankly there isn’t an idea in programming languages that hasn’t been done before (yeah, UhhhJavaAnyone, even mighty Java stole most of it’s good stuff from the likes of Lisp and Smalltalk before it, as most of it’s core concepts from C++). I’ve glossed over D a bit , and it seemed nice (certainly an improvement over C++ – it actually made be feel good about programming in an imperative language), but it still felt a little too cluttered.

anon on 10/24 said:

Where’s the ‘know the whole language’ innovation from Java then?

Nicola on 10/24 said:

Well Freepascal offer all of that and much more, is still compiled and all

anon on 10/24 said:

You switched to C++ because of the STL?! Many of us were coding C++ well before the STL came along! As much as I hate all this bitching about C++, D does look very interesting – at least it compiles to real object code and Walter understands optimisation inside and out by all accounts…

If you think C++ is bad, try coding everthing in assembler for a week! :-P

stack objects on 10/24 said:

D does have the ability to allocated objects on the stack by using the scope keyword. If used on the variable definition within a function the object will be allocated on the stack. If the the class is defines as a scope class then all instances of it must also be scope.

Also you can create good ol’ structs which behave more like c++ classes.

Tim on 10/24 said:

I wonder how D is practically different than C#?

Dynamic arrays are covered via ArrayLists.
Dynamic typing is covered (sort of) via Object.
There are no header declarations any more.

I have worked with C/C++/C# for 15 years and the last 5 or 6 with C# has been nearly perfect for me.

Peter on 10/24 said:

Sounds like a worst-of-all-worlds language. The reason to use C is because it is a great cross-platform assembly language — it has historically been very fast and efficient (this is likely no longer going to be the case, due to improvements in JIT, the advent of multicore, and the growing gap between CPU and memory performance). In addition, there is a wide body of existing code.

If you want to code quickly, without worrying about program performance, you can switch to a high-level language like Ruby.

D sounds like it takes many of the performance hits of high-level languages, while giving primarily a few minor syntactic advantages over C++, and (significantly) garbage collection. All methods virtual is a big performance hit. The compiler can’t just optimize this out — the compiler doesn’t know what you’ll be linking to (especially with dynamic linking, but even with static linking, it is a different stage). All objects on the heap? Speed hit. A lot of the other things you described as well also give you a speed hit. You also lose all compatibility with C.

Once that happens, you might as well switch to a full high-level language.

Aside from that, it’s not obvious what D offers over Java or C#.

Jarrett Billingsley on 10/24 said:

Mark: D has function pointers and delegates. Delegates are a sort of “fat pointer” which hold a reference to an object and a pointer to one of its methods. Delegates can also be references to nested functions (yes, you can declare functions inside functions which have access to the outer function’s stack frame), although in the interest of simplicity and speed, there are no functional-like closures which keep their outer variables once returned. It can be faked pretty well with a nested struct, though. ALso, you can get a pointer to just an object’s method (i.e. class A {...}, &A.foo), but calling it is tricky, and won’t perform a polymorphic call. Pointers-to-members can be simulated symbolically using templates instead.

UhhhJavaAnyone: virtually every language borrows from every other language. D borrowed features from Java, yes (in fact, looking at the Wayback Machine you’ll see back in 2001 or so the plan for D was more or less for it to be a compiled Java!), but programming in D is far, far different from programming in Java. I’ve done both. D is much more expressive. Java’s generics are a joke next to templates and all the other compile-time machinations you can do in D; dynamic arrays and maps are so much easier to use than ArrayList and HashTable; operator overloading; I could go on. Java feels like a straitjacket in comparison. That, and the two languages are aimed at completely different targets, so I doubt D will be trying to oust Java from its niche.

Tim: C# is closer to D than Java, that’s for sure, although it tends to do a lot more stuff dynamically than D does. I also dearly miss dynamic arrays when using C#. Having to create an object is just so cumbersome for something that’s so common. Regardless, I have a great deal of respect for C# and how it develops, far more than for Java, for sure. (No, I’m not taking any kind of industrial politics into consideration here; from a purely linguistic standpoint, I like C# much more than Java.)

Jarrett Billingsley on 10/24 said:

Peter: by marking a method ‘final’ you basically prevent the compiler from making the method virtual, in which case those calls can be inlined, just like non-virtual calls in C++. Marking all the methods you don’t want to be virtual turns out to be much less buggy than the inverse. Objects can also be allocated on the stack, using the ‘scope’ keyword, or anywhere you want by declaring a custom class allocator (operator ‘new’, just like C++). And no, you don’t lose all compatibility with C: it’s still binary-compatible with C, so binding to a C library does involve translating the header file to D unlike C++, but it’s not like you have to jump through hoops with some Native Interface like with Java and C#. Most C header translation is mechanical and there are tools (htod, bcd.gen) to do so. And any other perceived performance hits, like AAs and arrays — believe me, they are not that big. D consistently performs about as well as C++ and C in most speed tests, except in contrived “kill the GC” examples of course.

You’re right, you do lose some of the flexibility that C++ gives you. But the language is not Java and it won’t try to hold your hand all the time. There are ways to make it do what you want, and efficiently.

Joe on 10/24 said:

You have a bad example for the first one by comparing iterating through an array to using foreach in D. Why? Because you could have used the C++ for_each(vec.begin(), vec.end(), ) and it would have been the same thing.

Frank LaRosa on 10/24 said:

I started using the D programming language ten years ago – when it was called Java.

shampoonator on 10/24 said:

Nice “short” description of D, might be worth a look.

Peter on 10/24 said:

“you get garbage collection and manual memory management … I don’t know of any language that allows this”

Objective-C 2.0 now supports optional garbage collection in addition to the ‘retain-release’ manual memory management idiom.

Michael on 10/24 said:

@Steve: I don’t know anything about D, but I found PyD (http://dsource.org/projects/pyd) which claims to be Boost.Python for D.

Cyrus on 10/24 said:

Try http://www.dprogramming.com/

Bosco on 10/24 said:

@Steve, haven’t tried interfacing D and Python yet. But what is interesting is that Walter Bright has written a complete implementation of Javascript in D (http://www.digitalmars.com/dscript/)

@everybody, sorry about the typos and sloppy grammar, I’d put up the post hoping to edit it later. Too late now.

Bosco on 10/24 said:

@Jarret Billingsley, thanks for your great answers. Reading your answers, I think I finally understand closures in D. You can get a closure by creating a object and then grabbing a delegate to it’s methods. It’s a nice workaround for closures without putting in the massive overhead of dynamic lexical scoping.

Mike on 10/24 said:

You should check out Objective C.

It looks weird at first, but it’s awesomeness. In obj-C, it’s perfectly legal to do what would be the equivalent of:

null->foo();
and obj->inexistentMethod();

Once you wrap your head around that, you see programming as it was meant to be. I’m just sad I can’t yet use it in any of my real dev environments.

Clay on 10/24 said:

Steve: http://pyd.dsource.org/

Eugueny on 10/24 said:

I am shocked by people comparing D to Java or C#. Guys, did you read the article? Or bothered to google “D Language”?

First and foremost D has real and powerful templates AKA generics, unlike pathetic substitutes that Java/C# have to offer. Additionally D offers a sane multiple inheritance in form of mix-ins: the lack of multiple inheritance is the primary cause for Java/C# frameworks being so verbose and dumb: you cannot even compare that “cheap OOP for the masses” to what the power of templates+mixins bring you. Go and read Alexandresku’s “Modern C++ Design” to get started.

There are several powerful features in D that author did not mention such as native support for contract programming and native&easy integration with C, i.e. D can natively call any C function located in a dynamic module, which means that it easily, without any effort inherits 100% of that massive code base available to C programmers (over 90% of linux ‘-dev’ packages).

Finally, there is a GCC front-end for D, which means that your D source code is about to be ‘write once run everywhere’ on any Unix/mac platform. And the standard library is quite mature too, in fact there are two of them.

MrX_TLO on 10/24 said:

D does very well in the big language benchmark shootout. It’s programs are almost all shorter than C++ and use less RAM but are slower on recursion.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=dlang&lang2=gpp

What really amuses me though is how as the years go by, the C family works so hard to add features that other languages had designed in from the start.

C family programmers really need to get out and try other languages more. These problems have not only been solved, but often decades ago.

Tom on 10/24 said:

I too would recommend checking out Objective-C. It has the advantage of being a superset of C, it’s very dynamic yet still compiled, and with Objective-C 2.0 it offers pretty much everything D offers (optional GC, etc)

sya on 10/24 said:

We have C D … E F G H I J K L M N

i see a pattern.

The biggest problem is

WHEN IS THERE A CLEAR WINNER?

A language which IS fast but doesnt restrict you a lot or whose complexity will fall on your head one day?

I get too tired of so many languages…
while many have disadvantages, there isnt a language that KICKS ALL OTHER BUTTS in these regards, there are always the itchy drawbacks :(

C is in fact just syntactic sugar for assembly… C++ is an abomination as far as complexity went… D is a nice idea but its like fighting against HUGE MONSTERS already
(java on one side, C# and net on the other)...

Ruby is a cool language but either its TOO SLOW, not USED WIDELY ENOUGH (should kick php’s butt) or it just isnt giving THE biggest edge (yet?) on the performance increase…

dont get me started on haskell, only the smartest of smartest will learn and use it. (Yes, we should attract php script kiddies too!)

perl is slowly dying, only C dinosaurs use it… python has a nice concept but suffers from bad decisions such as implicit self and chaining the developer by imposing guido’s thoughts on him, taking the fun out of it in this process…

THE STATE OF PROGRAMMING LANGUAGE IS VERY SAD :(

Bale on 10/24 said:

D is not going to replace C++, just like Java didn’t replace it. It’s most likely that C++ will continue to evolve over time (albeit slowly as hell). C++ has its problems, but with so many people using it, so many programs written in it, and so many libraries available for it, it’s not going away for a long time.

Also, the next revision of the C++ standard is going to add optional garbage collection and lots of other improvements/fixes. Look up C++0x in Wikipedia.

Joseph Garvin on 10/24 said:

I’m a bit bothered by methods not being final by default, but not for optimization reasons. The virtual methods of a class serve as an interface to future programmers as to how they are supposed to extend a given class. There are a lot of Java books that recommend making all methods final and only making them virtual as necessary — what C++ does by default. If you leave your methods virtual most of the time, you might find people extending your class in ways you didn’t expect, increasing the chance that any changes you later make in the base class will break subclasses.

Jabo on 10/24 said:

I couldn’t have put it any better myself, there is a updated version of the C++ standard coming that addresses quite a few of the syntatic sugar such as declaring stl objects and filling them with constant data. I know these sorts of discussions tend to attract the name-your-favorite language debates unfortunately.

Another brief thing I will is that one of the beauties of C/C++ is that you can extend it pretty nicely to address almost anything you find it lacking, especially things you learn in other languages. Want reference counted objects? nothing stops you from doing it.

kenny on 10/24 said:

Whenever I see D touted as an excellent language I see a large number of people saying “Why not use C#/Java?”. D is a language which really hasn’t found a niche yet. C, C++, Java/C# (sort of the same niche), PHP, Perl, Python, Ruby, and to some extent Haskell and Erlang have all found their niches or have at least made a significant impression on the language landscape. D seems to have shown up late to the party and everyone is already sloshed; it’s very much a language meant to clean up C++‘s warts, but everyone has found their alternative already, or swear by C/C++ because they write very low-level code or can’t make a single compromise against speed. I really see the strongest niche for D to be people who are just fed up with C++ and want the stuff they have taken for granted in dynamic languages but still want to create native binaries with no JVM or JIT compiler shenanigans.

I spent some time trying to write a game in D with the SDL bindings, but I remember getting frustrated with getting the libraries to cooperate because I’m so used to the “it just works” design of modules in dynamic languages.

OJ on 10/24 said:

How easy is it to write GUI apps? 3D (DirectX/OpenGL) apps? What’s the threading support like?

Everyone always has something to whinge about with regards to a language’s syntax, but that really doesn’t matter at all. What matters is what you can do with it.

Mike on 10/24 said:

Is D a “failsafe” language? By this I mean, for example, do programs give an error by default if a full disk occurs during a write to a file?

(By this criterion, Python is safe, C and Perl are not, for example.)

Bosco on 10/24 said:

@JavaFans, it’s true, there’s no unique innovation (except the combination of pointers and garbage collection) in D, but it’s how they’re put together that’s unique.

There are two main directions that guide the design of D. First, features found in other languages are implemented in D in (what I consider) the most elegant notation. This surely makes it easier to program , which will result in less errors, if only from the point of view of memorization and typing mistakes.

The other direction is that care has been taken to make sure the features don’t burden the compiler writer unnecessarily. Lexical problems that are common in C++ parser are circumvented in D. This actually has a huge impact of the end-user because the easier the language is to implement, the smaller and faster the resultant compiler will be. This will result in faster compiling and linking performance, and less compilation errors. And remember, the current compilers are very very raw.

@MrX_TO: you will find that D borrows some features from high-level languages, but only those that can implemented efficiently in a compiled languages (no lexical closures for example). The language is pretty fast.

@kenny, QJ: D is still a pretty young language, so the libraries are not mature yet. Assuredly, mature and reliable libraries will come.

@Mike: D has exceptions, and these errors can be caught, if you so choose.

Wernight on 10/25 said:

Between C++ and C#, there is D?

D lack of the strong points of C#, being not only all the language evolutions but also the OS abstraction, huge .NET library (.NET and C# go in pair) and the powerful Visual Studio (which handles C# way better than C++).

D lack also of the strongest points of C++, naming the portability, and speed. Yes I include also speed, because but not limiting, there is no stack memory allocation. Event C# has stack allocation mechanism (struct and stack_alloc).

What would drive people using D? Is the speed difference so small (in the worse case), the compiler support enough, and does it support existing C++ code? It’s certainly not going to surpass C#, Java or such modern languages as it lacks of too much for that.

chmike on 10/25 said:

What I miss is a good IDE with debugger like eclipse for java or visual C++.

The D language is solving many issues of C++, so it truly better. But developpement productivity is tightly bound to the IDE, and debugging is very important.

I’ll switch when there will be a good IDE available.

Stephen Uitti on 10/26 said:

Walter Smith == Walter Bright? I assume that’s a typo.

So, I’m running Ubuntu. What’s the easiest way to install D?

rpgfan3233 on 10/26 said:

I’ve tried D before, and I must say that I dislike the size of the files it produces. Then again, I never really cared while doing C++, which I then moved toward C (just to learn it). I ended up favoring C for small personal projects when possible. However, after I ran a test today, I must say that I like the results I saw:
hello.c.exe (gcc) – 4096B
hello.c++.exe (g++) – 263168B
hello.d.dmd.exe (dmd) – 113180B
hello.d.gdc.exe (gdc) – 98304B

Then again, everything was done via Cygwin ports of the compilers (compiled with the -mno-cygwin switch) except for the Digital Mars D compiler (dmd). Whether that is a factor or not, I don’t know, but I do like how small it is compared to the C++ version. It has potential, in my opinion.

Sonniferous Malodium on 10/26 said:

What about Euphoria? http://www.rapideuphoria.com/

Lewis on 10/26 said:

Use Java

Jarrett Billingsley on 10/28 said:

Kenny & OJ: As far as game programming in D things are much better than they used to be. There’s now a project called Derelict, which offers cross-platform bindings to OpenGL (several versions), GLUT, SDL and many SDL add-in modules, DevIL, ODE, FreeType, OpenAL, and OGG/Vorbis. They’re all extremely easy to use, and you can use them exactly as you would in C. I downloaded Derelict and within 20 minutes I had an SDL app using OpenGL to draw some triangles. I’ve also made DirectX 9 bindings to D, though they’re based on the June 2005 SDK and are probably a bit out of date by now.

Wernight: it’s not at all aimed at the same niche as C#, just as C++ isn’t. Apples to oranges in that case. As for C++: fast, yes I suppose, but portable? What gave you that idea? And what makes you think that D isn’t portable? What defines portability in your mind? If you mean “you can take your app and compile it on multiple platforms with a minimum of fuss” then D meets that definition. D also defines a standard ABI that all implementations must follow, something C++ never did and now pays the consequences for. Also: no stack allocation? D does support stack allocation of class instances, using scope references (RAII). There’s no corresponding allocation method for arrays (though it’s been requested many times), but there are statically-sized arrays, like int¹⁰⁰, which will be allocated on the stack like in C.

Malcolm D on 10/29 said:

C++ is probably going to change for the better with C++0X (the new standard for C++)
Things like auto, and foreach, and garbage collection.
But that doesn’t totally diminish all your point.

Stewart on 10/31 said:

As a full-time C++ programmer for many years, and someone who has given (informal) courses on C++ programming techniques, I consider C++ to be a brilliant failure. It’s simply too difficult to use properly.

Scott Meyers’ books (“Effecive C++”, etc) are excellent, even indispensible. But I’m looking for programming languages that don’t need thick books telling you how to make it work.

Eljay on 11/05 said:

C# is the Microsoft language of choice. Try to get your C# running on OS X or Linux.

Objective-C is the Apple language of choice. Try to get your Objective-C running on Windows or Linux. Even moreso with Objective-C 2.0.

D Programming Language is not tied to Microsoft or Apple operating systems. I have been able to write D programs that run on Windows, OS X, and Linux.

D Programming Language is an evolutionary step from C++, pulling in some best of breed concepts from other languages such as C++, Java, C#, Python, and a host of other tried-and-true languages.

If I were to write a programming language, I would be very happy if the result was D. (Just as if were I to write an embeddable scripting language, I’d be very happy if the result was Lua.)

D Programming Language is a new born babe. It just hit 1.0 this year, after gestating since 1999. It’s maturity is about the same as C++ was in 1990. Which isn’t a bad thing.

One metric for success for a computer language is “Is it used?” By that metric, C++ is a runaway success in many segments. Java is success, but mostly in the enterprise segment (and rightfully so, J2EE is fantastic).

Is D Programming Language a success? It’s not even a year old yet! Give it time. Anyone who has used C++ for enough years to become dischanted with it will find D Programming Language a breath of fresh air.

Ben Pop on 11/05 said:

@Eljay: Um, Mono handles C# on *NIX systems, and GCC can compile Obj-C just fine IIRC.

So far, D has seemed like a language with promise to me, and its designer is one of those brilliant programmers that you see once in a while. Unfortunately, I really have no incentive to program it, and learning it is difficult with the features changing frequently. I stick to my dynamic languages for the most part; Python and Lua. With those languages under my belt, I feel most unmotivated to learn a language that—at least for now—feels to be in the same domain.

I feel lucky to have refused so far to learn C++.

Don on 11/06 said:

D is theoretically cross platform, but you will notice that it’s heavily windows oriented. If you go to the dprogramming.com site you will see software announcements that make no reference to platform, but the packages do not run on Mac, Linux, Solaris or anything but Windows.

So windows is clearly the implied platform of choice and what gets the primary support.

If this wasn’t the case you might still see modules for just certain platforms, but there would be significant notice of this.

I think that is why it was mentioned earlier that D isn’t cross platform. It’s cross platform only in the sense that C is.

I’m looking for a language very much like D, but one that I can feel safe doing cross platform development. I would not recommend using D for cross-platform programming – at least not now.

Bosco on 11/06 said:

@Don, check out the GDC compiler for D. To quote “GDC is a D language front end for the GNU Compiler Collection”. It works fine on MacOSX, and it works under Linux as far as I know.

Don on 11/06 said:

The compiler may work, but I need cross platform libraries. If you look on http://www.dprogramming.com you will notice that there is an assortment of packages, but many of them only for Windows.

This is no different than C which has the same situation. Some languages seem to have a very strong emphasis on cross-platform compatibility and some less emphasis. D seems to be about where C is in this regard.

So I cannot complain about this if I’m comparing it to C.

D is still a very appealing alternative to C for me – I’ve been looking into this for several months and what I’ve found is that it’s not as fast as C despite the hype, but it’s way more fun and easier to program in.

That’s a good compromise. In my CPU intensive testing it’s about 1.4 times slower. This was about 8 months ago, has the compiler improved much since then?

Steve Guerrero on 01/03 said:

Garbage collection is an advantage? I’ve always found it pathetic that the solution to human errors in resource management should be a non-deterministic nanny cleaning up after you, sweeping the problem under the rug. Honestly, the effort should be directed at development tools that analyze code for resource leaks and fix them in the code…not at some random point in runtime.

Eric Zijlstra on 03/31 said:

@Steve. Sometimes GC is a good thing. A GC is not desired when logic path is mostly hierarchical because you can delete objects when you leave functions. On the other hand, consider implementing something like the following simplified example without a GC: a messaging system that redistributes objects to multiple listeners that may be running in multiple threads. The message-objects are shared between the listeners (to avoid copying) and because it is a threaded environment the listeners may return before the message is fully processed. Therefore the messaging system has no knowledge whether an object is still in use. To solve this you need reference counting or something like that. Add the notion of delayed destruction and you basically implemented GC. Why waste time by doing this yourself while the compiler can do this more efficient? When you have used a GC for a while you start to think different: objects do not have a owner anymore and you’ll create designs that are more elegant and easier to understand. And by the way, D also supports manual memory allocation.