The D language

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]

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

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++.

snk_kid, what don't you like about D?

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.

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::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
-...

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 v;
for(auto i=v.begin();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?

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::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

Quote:

Original post by Lode *snip*

C# offers a lot of that

Back to D - I always thought D would work better as a scripting language.

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 v; for(auto i=v.begin();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++?

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.

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.

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)

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.

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.

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).

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.

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.

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.