The D language

Started by
90 comments, last by Nitage 17 years, 9 months ago
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?
Advertisement
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<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
-...
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?
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
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.

This topic is closed to new replies.

Advertisement