Sign in to follow this  
Red Ant

The D language

Recommended Posts

Red Ant    471
Hi, I'm reading up about the D language and what I've seen so far looks very promising. So far I've been mostly programming in C++ and Python and I love both languages (of course I realize that neither language is quite without flaws, but I still think they're both great languages). I've also had contact with Java, C# and Perl but didn't find them particularly appealing. D seems to aim at providing a 'better C++' sort of. Well anyway, reading the DigitalMars D page has certainly whetted my appetite and I'm definitely eager to get started about D. Are folks here using D a lot? Do they think D has a future? Apart from the fact that it's always good to learn new things, is there a reasonable chance that D will become an important language to know?

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by Red Ant
D seems to aim at providing a 'better C++' sort of.


Well trys to be but i personally think it's a failed attempt to be truely better than C++ in all aspects which D isn't. Really if you want to give an alternative to C++ that is better than C++ and/or fixes all issues with C++ with similar syntax and deals with all the things that advance C++ programmers actually do with C++. There are much better ways to go about designing such a language but unforunately no such language (with similar syntax) *currently* exists.

Quote:
Original post by Red Ant
Are folks here using D a lot?


Not really, only a very small minority. I'll tell you one thing D will never take the majority of C++ programmers away for very good reasons despite some of it's advantages.

Quote:
Original post by Red Ant
Do they think D has a future?


Probably but not a bright one or nothing of significance.

Quote:
Original post by Red Ant
Apart from the fact that it's always good to learn new things


You're not going to learn anything new, you're just going memoize syntax because there similar languages. They're both imperative languages, try learning some other languages that are based on completely different programming paradigms then you will truely learn something new and broaden your view on problem solving.

Quote:
Original post by Red Ant
is there a reasonable chance that D will become an important language to know?


No but it doesn't hurt to learn it either.

[Edited by - snk_kid on June 28, 2006 6:43:34 AM]

Share this post


Link to post
Share on other sites
ColmMac    122
Torus Trooper is a pretty cool game made in D. It's plays and looks great so D is definately a viable language to program games in.

It's a langauge on the my list of languages to learn. I've only made a brief read up on it (mainly as a result of playing a bunch of Torus Trooper) but it does have pedigree.

As for whether it has a future, I like it more than C# since it compiles to native code. I don't think it will ever become a majority language sinceit has no marketing machine pushing it at the moment.

Colm Mac

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by ColmMac
It's plays and looks great so D is definately a viable language to program games in.


Virtually any language is a "viable language to program games in".

Quote:
Original post by ColmMac
I like it more than C# since it compiles to native code.


This is a silly reason to like it more. There is nothing preventing a compiler vendor implementing the C# standard with a compiler that compiles straight to native but then it devoids some the advantages of doing so.

Quote:
Original post by ColmMac
I don't think it will ever become a majority language sinceit has no marketing machine pushing it at the moment.


This isn't the main reason and besides there was never a "marketing machine pushing" C++.

Share this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by nsto119
snk_kid, what don't you like about D?


I don't dislike or like D but the claims that it's a truely better alternative than or fixes all aspects/issues of C++ are false.

Share this post


Link to post
Share on other sites
Lode    1003
I too am disappointed in D because I hoped it would be an improved C++. But in fact it's an entirely new programming language, so many advantages of C++ are left out.

I'd like to see a programming language that is
-C++
-without headers, and isntead an alternative way to link source files together
-with you never needing to duplicate function declarations/definitions (this is part of the "remove header" plan)
-with binary literals (0b01011101001)
-with nested functions
-with backwards compatibility to C removed
-with an improved standard library, including standard libraries for simple graphics, GUI, audio, network, file management, mouse, realtime keyboard input, printing, terminal and multithreading
-with easier support for making vectors pointers to a mix of parent and child classes with virtual functions, like pointer containers that automatically destroy objects, note that pointer containers aren't in the standard at the moment
-with a programmer NEVER needing to use "new" and "delete", with all situations that could require the use of those having a replacement that auto-deletes (for example the vectors and pointer containers)
-with binary literals
-with a MUCH simpeler form to use iterators to elements of containers, I'm sorry but I dislike a variable type with a name like std::vector<int>::iterator, there has to be a better way to handle this, if needed make containers and iterators part of the language itself, for example the type int+ could be an iterator to containers of ints
-with more operators that can be overloaded
-with the ability to use the ` character instead of the " character for strings (I took this idea from D)
-with array literals
-without the inline keyword, it's not needed anymore
-with certain undefined things defined, like some special operator orderings there are and cases with the % operator
-with 64-bit integers, 128-bit integers, 128 floating point numbers (variable types that are defined to have at least that amount of bits)
-with an extra modulo operator that will turn (-1 % 3) into 2 instead of -1
-with an extra division operator that will turn (-1 / 2) into -1 instead of 0
-with more logical names for variable types, a int with at least 32 bits is now called "long", what's longer than a long, a "long long", what's longer than a "long long"? a "long long long" or "super long"? This might bet pathetic in the future, a naming sheme of the form "sint16", "uint64", "float128", ... would be a better alternative
-with UTF-8, UTF-16 and UTF-32 characters
-with a variable type that is encouraged to be used to represent 8-bit bytes and that is unsigned, many people have had confusions with chars being used for files and them being signed
-with "nan" and "inf" values being part of the language instead of part of the library
-with fixed point types
-...

Share this post


Link to post
Share on other sites
Aardvajk    13205
With regard to Lode's point about iterator names, I believe an 'auto' data type is being discussed for C++ that would derive its type from the right-hand side of its initialisation:

vector<int> v;
for(auto i=v.begin();i<v.end();++i)

// etc

Would obviously require an initialisation, like a reference, but would save a lot of typing. Does anyone know if this idea is still being bandied around for the next standard?

Share this post


Link to post
Share on other sites
Nitage    1107
Many of your suggestions would hurt the language:
Quote:

-with a MUCH simpeler form to use iterators to elements of containers, I'm sorry but I dislike a variable type with a name like std::vector<int>::iterator, there has to be a better way to handle this, if needed make containers and iterators part of the language itself, for example the type int+ could be an iterator to containers of ints

If you did that then programmers couldn't create custom containers.

Quote:

-with nested functions

That would require some changes to stack frames which could hurt performance, especially in tight loops and reduce the ability of compilers to inline functions with nested functions.

Quote:

-with backwards compatibility to C removed

That would remove the ability of the language to use OpenGL, Win32, LUA, Python, etc. A huge majority of APIs are written in C - removing support for C would be enough to make many programmers dismiss switching from C++ to your language

Share this post


Link to post
Share on other sites
Lode    1003
Quote:
Original post by EasilyConfused
With regard to Lode's point about iterator names, I believe an 'auto' data type is being discussed for C++ that would derive its type from the right-hand side of its initialisation:

vector<int> v;
for(auto i=v.begin();i<v.end();++i)

// etc

Would obviously require an initialisation, like a reference, but would save a lot of typing. Does anyone know if this idea is still being bandied around for the next standard?


Actually the "auto" keyword lights up in my editor when using C++ highlighting, does this keyword have any meaning already in C++?

Share this post


Link to post
Share on other sites
SiCrane    11839
Yes, it's a storage class specifier meaning that the variable has automatic storage (i.e. is allocated on the stack). It's a pretty pointless keyword.

Share this post


Link to post
Share on other sites
Rebooted    612
Quote:
Original post by Lode
Actually the "auto" keyword lights up in my editor when using C++ highlighting, does this keyword have any meaning already in C++?
It is a remnant of the B language if I remember correctly. B required you use the auto keyword when declaring local variables. In C it was not required, but was left in for backwards compatibility. The proposal to add limited type inference into C++ reuses the auto keyword and gives it some purpose.

Share this post


Link to post
Share on other sites
Simian Man    1022
Well, auto is already a keyword but right now it does not do anything. (It used to be used to indicate a variable should be put on the stack, but that is already the default)

Share this post


Link to post
Share on other sites
kSquared    1356
There is absolutely nothing wrong with learning another language. Anyone who thinks that broadening your horizons is a bad thing needs a clue-by-four upside the head. At the risk of overusing this somewhat stale analogy, all programming languages are simply tools in your toolbox. Sometimes a project will call for the gentle touch of a screwdriver; other times it will require high-grade explosive dynamite. Trying to hack through a mountain with a screwdriver is using the wrong tool for the job, so you want as many tools available to you as possible.

That said, learning another programming language is not a trivial endeavor (despite what those "Learn C++ In 21 Seconds!!!oneone~~!" books may tell you), if only for the reason that you don't have infinite reserves of time. You may be better served in terms of a career and as a problem-solver by choosing a language that is somewhat more mainstream, like C#, Java, or (dare I say it) Ruby.

Share this post


Link to post
Share on other sites
NotAYakk    876
Cute shopping list. Mine:
# A full, functional, compile-time programming language that generates the code to be compiled, integrated into the language.
# Nice syntax for both compile-time and run-time code.
# A better string paradigm than C++'s.
# input, output and input/output parameters
# Decoration of methods and objects (virtual shouldn't be a keyword -- it should be a decoration, implemented within the language)
# The ability to rebuild language constructs within the language. Ie, if the language supports virtual functions, it should be possible to implement virtual functors with a constant amount of framework effort.
# template-like programming that crosses compilation units
# The ability to make strong type-safe contracts at compile time
# The ability to work out what the machine-level code resulting from your actions is.
# Multi-threaded support embedded in the language. But see above: any multi threaded syntax must be reimplementable and modifiable by the programmers.

I want a language that lets me write and use code multipliers easily. I want to be able to write N lines of code and generate N^2 or N^10 or e^N lines of assembly, all determined at compile time. You can currently do this in C++ -- I'm not aware of any other language that lets you do this (other than languages where you simply reinvoke the compiler on generated output). And the syntax in C++ is ugly.

Share this post


Link to post
Share on other sites
swiftcoder    18426
I have used D a couple of times, and these are the main things I have noticed:

Better arrays (and therefore strings) than C (but not as good as STL containers).
Garbage collection (not sure if this is a pro or a con).
Anemic standard library, particularly no templated linked-list (but the community could wheigh in on this one, and write one).
Very fast compiles (the same small project of mine compiles in less than 1/10 of the time written in D).
No support for dynamic libraries (and this is the deal breaker for me).

Share this post


Link to post
Share on other sites
Aldacron    4544
Quote:
Original post by Red Ant
I'm reading up about the D language and what I've seen so far looks very promising. So far I've been mostly programming in C++ and Python and I love both languages (of course I realize that neither language is quite without flaws, but I still think they're both great languages). I've also had contact with Java, C# and Perl but didn't find them particularly appealing.


I'm using D quite a bit and have been for three years or so. I have a D Blog and I maintain a collection of C bindings for libraries like OpenGL, SDL, OpenAL, and more over at dsource.org. I know of at least one commercial C++ game project that being converted to D right now, but that's the only commercial app I know of at this time.

D is still in development and is getting better with each release. There are warts, of course, particularly with some things not working as intended. Overall it's a pleasure to work with.

In the three years I've been using the language I've noticed that there tends to be two types of people who give D a look: the ones who glance through the docs and dismiss it offhand as inferior to C++/Java/ or wherever they are coming from, and the ones who actually dig in and try it out. The former aren't going to like anything new no matter how great it is. The latter are looking for alternatives and are generally happy with what they have found in D. I don't take much stock in the comments people make based on what they have read in the documentation. They have no idea what they are talking about until they have actually typed enough D code to get a feel for it. It's like the people who say, "Java is slow" - they are clueless.

Quote:
Original post by Red Ant
D seems to aim at providing a 'better C++' sort of.


It's not trying to be a "better C++". It's trying to be a "better language" in general. It incorporates ideas from a broad spectrum. I think that it largely succeeds, but there are some kinks yet to work out.

Most of the ideas came from Walter's 20+ years experience of writing C++ compilers. One of his major goals for D is that it not only be easy for programmers to use, but also for compilers to parse. Decisions on syntax and features are always made with that in mind. A D compiler is much easier (and cheaper) to put together than a C++ compiler.

Quote:
Original post by Red AntAre folks here using D a lot?


Few in the GDNet crowd tend to use anything outside of C++, though I seem to have noticed an increase in C# posts in recent months. I don't expect many people around here to bother with D for a long while yet.

Quote:
Do they think D has a future?


I think it does. And so does the D community at large. If we didn't, we wouldn't be using it.

Quote:
Apart from the fact that it's always good to learn new things, is there a reasonable chance that D will become an important language to know?


Walter Bright has been around C++ circles for over 20 years. In that time, he has built up quite a list of contacts. Big names in the C++ world, such as Scott Myers, Andrei Alexandrescu, Bruce Eckel, and Matthew Wilson, for example. Some of D's design was inspired from the ideas of, or discussions with, such people. Walter still has ongoing debates and discussions with them on the D way, both privately and publicly (some of the discussions you can see at comp.lang.C++).

Whether or not this means D will be 'important' remains to be seen. The problem is that it fills a strange niche that is somewhere between managed languages (Java, C#) and systems languages (C++, C). It offers many benefits over C++ and C, and can interface cleanly with legacy C code, but it remains to be seen if it's enough to convince a technical mangager that he should switch his codebase from C++ to D. And while I think D is much more pleasant even than Java, I don't think D is even going to be considered much by that market. The VM makes things like reflection, dynamic instantiation and some other features easier to implement than in a compiled language. D has none of that (though Walter has said relflection is something he wants to add down the road).

Whether it becomes important or not, there's nothing wrong with learning to use it. Programming in D has actually helped me to become a better C++ programmer. So even if I never use the language outside of my little hobby projects, it has still been worth learning.

Share this post


Link to post
Share on other sites
evolutional    1393
A couple of years ago I also looked at D thinking that it would The Next Big Thing TM. What I found was that although the language seemed nice, there simply isn't the userbase there to support you if you need it. Think of C#, it is sponsored by one of the biggest companies in the world and millions of businesses are using it daily, investing money, time and effort into learning it, writing about it and using it. Open Source projects have sprung up to wrap commonly used libraries for Game Developers (OGRE, Irrlicht, SDL, Lua, OpenGL and many many more). These are supported and in use by many hobby projects, often these ports or wrappers are supported officially by the teams behind the original libraries.

When you look at D you see a potentially capable language that has many nice features, however does it truly have the support network there for you to work effectively? Will you be able to turn to a multitude of books or online resources to solve your problem quickly, or will you have to puzzle over it for days and/or be at the mercy of the original language implementor to answer your query (as an aside, I find the language author a little arrogant after swapping a few emails with him a while back). If you wanted to quickly make your game, you will probably find that the common libraries aren't wrapped for you, or they are partially implemented as a toy project for someone else who looked at D a few years back and thought how great it was, then changed their mind leaving the library/wrapper unfinished.

I guess what I'm saying is that if you want to use D, don't expect an easy ride and the extra effort you'll put into making libraries and other things work will most likely exceed the time and effort saved by the 'extensions' provided by the language.



Share this post


Link to post
Share on other sites
Aldacron    4544
Quote:
Original post by swiftcoderBetter arrays (and therefore strings) than C (but not as good as STL containers).


Most of the container implementations I have seen in D are implemented on top of D arrays to enhance them, not replace them. D's dynamic arrays are so flexible that they can be used as vectors, stacks, queues, maps and even trees with very little effort. Most people do tend to wrap up that functionality and templatize it. I just don't see STL containers as being any better. I guess it's just a matter of what people are used to. Some D users have implemented STL-like libraries, others have implemented something modelled after Java's collection framework.

Quote:
Garbage collection (not sure if this is a pro or a con).


Ultimately it's a pro. Right now, it's iffy. The current implementation gets the job done but it is by no means optimized. This will (hopefully) be remedied before a 1.0 release. But D does give you the ability to bypass the GC completely.

Quote:
Anemic standard library, particularly no templated linked-list (but the community could wheigh in on this one, and write one).


A lot of people point to this as a deficiency. The library has a long way to go, for sure. But for now, Walter's focus is on stabilizing the implementation and the spec and crushing bugs. The library has been discussed multiple times on the NG and will get an overhaul before 1.0. Even so, there is already an alternative, community-driven, standard library called Ares.

Quote:
Very fast compiles (the same small project of mine compiles in less than 1/10 of the time written in D).


What's really cool about that is when you use Derek Parnell's Build to compile your project. I've never seen a simpler or faster compiler tool chain for any language.

Quote:
No support for dynamic libraries (and this is the deal breaker for me).


D has had support for DLLs for several compiler versions now. Initially, the implementation required that each DLL have its own GC, but that has been remedied. I'm not sure where the shared library support stands on Linux right now, though.

Share this post


Link to post
Share on other sites
swiftcoder    18426
Quote:
Original post by Aldacron
D has had support for DLLs for several compiler versions now. Initially, the implementation required that each DLL have its own GC, but that has been remedied. I'm not sure where the shared library support stands on Linux right now, though.


OK, I am downloading the latest version now to see whether this can be made to work on a Mac ;)

Do you have any idea how they managed this? I mean that there was no way to make sure a function would be virtual, this was decided by the compiler.

Share this post


Link to post
Share on other sites
Aldacron    4544
Quote:
Original post by swiftcoder
OK, I am downloading the latest version now to see whether this can be made to work on a Mac ;)


DMD is only implemented on Windows and Linux. To compile D programs on Mac you will need GDC, an implementation built on top of GCC. GDC is usually a few versions behind DMD. I have no idea if it supports shared libraries. You can get precompiled binaries for the Mac at http://gdcmac.sourceforge.net/.

Quote:
Do you have any idea how they managed this? I mean that there was no way to make sure a function would be virtual, this was decided by the compiler.


Sorry, I haven't a clue. I'm not at all interested in the internals of the compiler, though there are a lot of people who are, as evidenced by the NG posts. Perhaps if you ask in digitialmars.d you will get an informed answer. But I'm not quite sure what you mean about virtual functions. In D, all member methods are virtual by default, as in Java, and can be made non-virtual with the 'final' keyword. Inlining is decided by the compiler, but not virtualization.

Share this post


Link to post
Share on other sites
Actually I think headers are really good.

Its like a summery documentation of all your classes and methods, instead of having to see the structure of the class with all the implementation inside, which is confusing. Because over information is usually bad, and you want to hide some information from yourself so you wont get confused.

Quote:
Original post by Lode
I too am disappointed in D because I hoped it would be an improved C++. But in fact it's an entirely new programming language, so many advantages of C++ are left out.

I'd like to see a programming language that is
-C++
-without headers, and isntead an alternative way to link source files together
-with you never needing to duplicate function declarations/definitions (this is part of the "remove header" plan)
-with binary literals (0b01011101001)
-with nested functions
-with backwards compatibility to C removed
-with an improved standard library, including standard libraries for simple graphics, GUI, audio, network, file management, mouse, realtime keyboard input, printing, terminal and multithreading
-with easier support for making vectors pointers to a mix of parent and child classes with virtual functions, like pointer containers that automatically destroy objects, note that pointer containers aren't in the standard at the moment
-with a programmer NEVER needing to use "new" and "delete", with all situations that could require the use of those having a replacement that auto-deletes (for example the vectors and pointer containers)
-with binary literals
-with a MUCH simpeler form to use iterators to elements of containers, I'm sorry but I dislike a variable type with a name like std::vector<int>::iterator, there has to be a better way to handle this, if needed make containers and iterators part of the language itself, for example the type int+ could be an iterator to containers of ints
-with more operators that can be overloaded
-with the ability to use the ` character instead of the " character for strings (I took this idea from D)
-with array literals
-without the inline keyword, it's not needed anymore
-with certain undefined things defined, like some special operator orderings there are and cases with the % operator
-with 64-bit integers, 128-bit integers, 128 floating point numbers (variable types that are defined to have at least that amount of bits)
-with an extra modulo operator that will turn (-1 % 3) into 2 instead of -1
-with an extra division operator that will turn (-1 / 2) into -1 instead of 0
-with more logical names for variable types, a int with at least 32 bits is now called "long", what's longer than a long, a "long long", what's longer than a "long long"? a "long long long" or "super long"? This might bet pathetic in the future, a naming sheme of the form "sint16", "uint64", "float128", ... would be a better alternative
-with UTF-8, UTF-16 and UTF-32 characters
-with a variable type that is encouraged to be used to represent 8-bit bytes and that is unsigned, many people have had confusions with chars being used for files and them being signed
-with "nan" and "inf" values being part of the language instead of part of the library
-with fixed point types
-...


Share this post


Link to post
Share on other sites
h3r3tic    228
Not sure if this is going to interest anyone, but I'd like to share my D story with fellow gamedevers.

When I first read an article about D, I realized that it had some very nice features and I liked some of its design ideas. But then I thought to myself "hey, C++ gives me everything already, I don't need a language that tries to be 1% better while having instability issues, small user base and poor standard library". So I dismissed it and for some time forgot about it.

Some time later, I was looking for a scripting language that could enhance some of my C++ programs. I asked around #gamedev and have been told to try Python. So I gave it a try and after some time, fell in love in the language as my brain was forced to expand beyond my little C++ world. In a very short time I realized that C++ wasn't so perfect as I thought it was and my previous "I love C++" statements became outdated. I programmed in Python for about a year and after some time I realized that C++ had some advantages I haven't been aware of before - static typing that is. I hated fixing errors at runtime. That and Python's poor relative runtime performance made me wish for a statically compiled, statilally typed language. Then at one time I magically recalled the D language. I decided to give it a try again.

I downloaded the D compiler, some basic IDE for it and started playing around. At first it seemed like a weird mix of Java, C++ and Python. It had C-like structs, Java-like classes, Python's easy way of dealing with strings, but also some weird C++-like templates. Initially I was quite lost when coding in it, I posted in the newsgroups asking about some C++ features that I couldn't find in D - I considered D to be flawed because it removed some of the C++ stuff that I got used to.
Yet after some time, I got a better view of the language, I knew it wasn't just C++ with enhancements, it had its very own style, one in which the earlier problems seemed to dimnish - and the extra features, each of which were really tiny, when added up, made a huge difference to the programming experience.

When I was placing my very first steps in D, it still had inconsistent Unicode support, weak template system with an awkward instantiation system (literally, you had to use the 'instance' keyword) and it was generally quite messy. Yet with time, D's weaknesses started to fade away, as Walter kept adding new features and squashing bugs. For instance, now D's got better template metaprogramming support than C++; e.g. I've seen one thread today about a guy trying to use 'if' inside templates to control which fields would be instantiated. D's got just that - 'static if'. And it's got more - delegates, very neat builtin arrays with slicing, GC, foreach (that's a solution for easy iteration in containers), built-in associative arrays, Unicode strings, inner classes, nested functions, and so on.

To be fair - I've had moments when I wanted to screw D altogether. These were mainly back when the D compiler's version sill had two digits after the decimal point (now it.s 0.161). I've seen dozens of internal compiler errors and filled lots of bugreports on the newsgroups. But this is because, as one guy said... 'I rape the compiler'. I make it do things which I wouldn't dare to accomplish in C++. And D's got the power to make complex code - e.g. I've coded a library with functionality similar to Boost::bind - with function composition and all the whistles.
I don't want to cheat anyone, if you play with D, expect seeing some undocumented behaviour and compiler problems. The thing is that these hardly ever are issues that make development impossible. And Walter has shown that he cares about commercial developers e.g. by sending them specially patched versions of the compiler before its official release.

How does D present itself for game development ? You won't find any engines waiting for you like you would in C++. There are a few being developed, but don't expect Unreal3. Yet if you're a developer willing to code that internals by yourself, some groundwork has already been done for you. D's got bindings to many game-related APIs. Aldacron's Derelict binds libs like OpenGL, OpenAL, DevIL, SDL, libvorbis and some more.

I haven't written very much gamedev-related code in D due to various RealWorld(tm) issues ( yeah, evolutional - I was supposed to show some cool 3d stuff ;) ). I've been working a bit on a simple game engine dubbed 'Heresy'. Eventually it turned out into a lame photon-mapping and GUI playground, but I've experimeted with other stuff as well (and I'm going to continue). Some (a bit outdated) info can be found here: http://codeinsane.info.tm/projects.spy
If you wanted to check some D and do some GL stuff in it, I've got a site with instructions about how to set up Derelict and open a GL window thru SDL: http://dmedia.dprogramming.com/

Anyway, I've been coding in D for about 2.5f years now and I'm not going back to C++. D is highly addictive.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this