• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
stephenfx

What do you think of the D language?

93 posts in this topic

Quote:
Original post by Sneftel
D tries to fix the shortcomings of C++ by adding new language features. This is a little bit like trying to fix a wrecked '53 Volkswagen by adding fins and a periscope.
It's also kind of like taking what is basically portable macro assembly language and adding object orientation and generic programming to it.

Holy shit.

As for D, I'm not interested.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Quote:
The reason you would use D over Java and C# is because D is much faster not having to rely on a VM.


You seem to be a decade late. Both Java and C# use JIT compiling now.


Alright, so instead of faster I'll just say that D does not require you to bundle a VM with it in order for the user to be able to run your program.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by clayasaurus
Alright, so instead of faster I'll just say that D does not require you to bundle a VM with it in order for the user to be able to run your program.


This is absolutely true.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
D tries to fix the shortcomings of C++ by adding new language features. This is a little bit like trying to fix a wrecked '53 Volkswagen by adding fins and a periscope.


Did you miss what D leaves out? Or how it improves / changes C++? Do you think the same of C#? If not, why not? If so, would you say C# is an attempt as futile as D?

Just about every complaint I remember from these boards about C++ is solved or at least vastly improved by D.

I genuinely don't understand what makes people so negative about D in contrast to how C# is promoted and even Java is talked about more positive than D. Especially the people that I think know what they are talking about, such as Sneftel, Promit and snk_kid. If it were not for the fact these people write intelligent posts all the time I'd think you all just pulled some opinion out of thin air. So yeah, I have some cognitive dissonance about it, but still D is a mighty fine language for me to program in (and yes I've also tried / still program in python, scheme, C#).
0

Share this post


Link to post
Share on other sites
I didn't offer an opinion (I was going to, but decided against it.) I merely said I wasn't interested.

If I have to offer an opinion, let it be this -- I prefer that a substantial numbers of developers (think tens of thousands at a minimum) use a tool before I do. I seriously doubt D has that kind of developer support. When it does (and history to date does not suggest it will ever happen), then maybe I'll give D a chance.

Oh, and one other thing -- I don't think being compiled to native code is a compelling advantage. Not requiring a support library could be, but I'd probably just use Python instead.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
I didn't offer an opinion (I was going to, but decided against it.) I merely said I wasn't interested.

If I have to offer an opinion, let it be this -- I prefer that a substantial numbers of developers (think tens of thousands at a minimum) use a tool before I do. I seriously doubt D has that kind of developer support. When it does (and history to date does not suggest it will ever happen), then maybe I'll give D a chance.


That i can grok yes, it sounds very reasonable. But saying D is a portable macro assembly language with added object orientation and generic programming is a little unfair at least, no?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DeadXorAlive
Did you miss what D leaves out? Or how it improves / changes C++? Do you think the same of C#? If not, why not? If so, would you say C# is an attempt as futile as D?

Just about every complaint I remember from these boards about C++ is solved or at least vastly improved by D.
No, I didn't miss those. And yes, to a certain extent I do think C# is a similarly futile attempt, though C# adds much less and removes much more.

My objection to D is similar to Promit's, but I'll add a bit more justification to connect that to my previous comment. Compared to C, C++ is a really really big language. It has a lot of features. It is so complex, in fact, that its features begin to interact in unintended ways. A great example of this is the thread on default arguments and virtual function binding. Who knew that those two features--which theoretically are unrelated--would combine to form unexpected-looking behavior? Or that template arguments could break preprocessor macros? There's plenty of examples of this, many chronicled on GotW and many more still being discovered by hapless C++ students and intrepid Boost developers.

And D goes so, so much further. The designers have a "why not" attitude towards adding useful-sounding features, with the result that D's feature list makes C++ look downright minimalist. Many of these features are new to the entire extended language family, or have been implemented in radically different ways than previously in the extended language family. Are mixins going to cause a problem with lambdas? Is liberal use of slices going to make DBC unmaintainable? Who knows! Who's going to find out? The early adopters.

I hope that D gains traction among some large body of hypothetical developers who, despite not being rabid D fans, end up using it in large applications with a long lifecycle. I hope this happens, because this is the only way to vet a language. Maybe I'm wrong; maybe D will all hang together and the features will turn out to mesh perfectly and I'll come to terms with the syntactic features I dislike and everything will be great. I just don't think that it's likely.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DeadXorAlive
That i can grok yes, it sounds very reasonable. But saying D is a portable macro assembly language with added object orientation and generic programming is a little unfair at least, no?

I'm willing to bet he was refering to C++, not D.

CM
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DeadXorAlive
That i can grok yes, it sounds very reasonable. But saying D is a portable macro assembly language with added object orientation and generic programming is a little unfair at least, no?
The portable macro assembler is C. C++ is what you get when you add objects and generic programming support.
0

Share this post


Link to post
Share on other sites
Sneftel, that makes sense, thanks for providing some arguments. Perhaps you're right, I guess the future will point this out when D has stabilized and bigger projects are written.

Quote:
Original post by stephenfx(...)
Which debugger are you using? I have tried Visual studio. I can step in the source file lines, and the call stack is shown, but the variable is not shown correctly. I can’t find a full function debugger for D.

For windows, since some time DMD ships with windbg 5 debugger which works for most things (newer version doesn't work as microsoft changed the format), for linux there is a patch to GDB and iirc valgrind also supports D.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Quote:
The reason you would use D over Java and C# is because D is much faster not having to rely on a VM.


You seem to be a decade late. Both Java and C# use JIT compiling now.


JIT compiling helps a lot. Java and C# can be competitive in small loops that do integer or floating point calculations. But in more complex applictions, that performance seems to be elusive. Native apps have the advantage of not dragging around a huge VM and JIT compiler. They start up right away without a lag as they're being JITted. They can be thoroughly tested and debugged, and not be subject to a bug in the next version of the VM JIT. Access to C (from the D programming language, anyway) is direct - no need to go through some JNI or marshalling interface. Direct access to C also means direct access to the operating system API.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Stachel
But in more complex applictions, that performance seems to be elusive. Native apps have the advantage of not dragging around a huge VM and JIT compiler. They start up right away without a lag as they're being JITted.
These problems are not caused by the environment, they're a product of programmer incompetence.

The problem is actually relatively simple. C# and Java make programming rather more accessible than, say, C. That's not a bad thing. But now you've got a lot of incompetent "programmers" churning out shitty code. They don't understand how the JIT engine or the GC works. They don't understand what affects performance, startup time, etc in managed apps. All of these things are entirely foreign to them, and because C#/Java is a managed language, because it is "easy", they think that these things are irrelevant to them.

They're not.

Managed languages may be easy, but they are not a blank check for programmer ignorance and incompetence. You can't fire up C# Express, write up some kinda application, and then expect it to perform well magically without any effort on your part. This is exactly the same as if you wrote up a game in C++ but were calling operator new hundreds of times per frame. Your performance would grind into the ground (and god help you if you introduced threading into that mix). The same applies to managed languages; the problems are different, but they are not gone. If you want to write high performance managed applications, then you need to buckle down and learn about how to do it.

Too many people expect C# to do the work for them. They do help out a lot, but that doesn't mean you can blindfold yourself to performance issues and hope it all works itself out. All that gets you is shitty, badly performing, and altogether irritating applications -- see Limewire for a good example. And of course most people will blame the managed environment for their own inability to code, and claim that C++ will always rule. And the ones who know better...well, they don't need to ask people about whether managed languages are "good enough". They already know they are.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by Stachel
But in more complex applictions, that performance seems to be elusive. Native apps have the advantage of not dragging around a huge VM and JIT compiler. They start up right away without a lag as they're being JITted.
These problems are not caused by the environment, they're a product of programmer incompetence.


There are plenty of incompetent C++ programmers, too. I'm not talking about them; I'm talking about people who know what they're doing.

Quote:
And the ones who know better...well, they don't need to ask people about whether managed languages are "good enough". They already know they are.


Is it reasonable to assume that Microsoft knows C# better than anyone? So why are Microsoft's major applications not written in C#? Managed languages may very well be "good enough" for a lot of applications, but when one needs to do better, one needs a native compiled language like C++ or D.

What I see as the advantage of C# over C++ is the productivity gains with a language that learns from the mistakes of C++. D learns from those mistakes, too, but doesn't throw out the performance by saddling it with a VM.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Stachel
Is it reasonable to assume that Microsoft knows C# better than anyone? So why are Microsoft's major applications not written in C#?

You sure about that? Note that nearly all of the Tablet PC APIs, as well as nearly all of the Windows Media Center programs, are in managed code. Massive portions of the new APIs -- WPF (windows presentation foundation, formerly Avalon), WCF (windows communication foundation, formerly Indigo), and the rest of WinFX -- are in managed code. They're such massive managed codebases that they actually got renamed to .NET 3.0, and they're meant to form the core for new applications. WinForms will be deprecated in favor of WPF, for example. SharePoint and SQL Server use .NET heavily. Very nearly all of the Microsoft website, MSN, Live, etc are built in ASP.NET.

Besides, most of MS' really major applications are legacy codebases, some dating back to the late 80s. You don't throw that stuff out and switch over to managed code just for the hell of it; that's retarded. Most of MS' new applications, however, are built in managed code. While I was working there, I never touched anything other than C#.

What I see in D is a language that takes C++, and compounds the mistakes made there.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by Stachel
Is it reasonable to assume that Microsoft knows C# better than anyone? So why are Microsoft's major applications not written in C#?

You sure about that? Note that nearly all of the Tablet PC APIs, as well as nearly all of the Windows Media Center programs, are in managed code.

Is Office in C#? Is the C++ compiler? Windows Media Player? Word? Excel? IE7? DirectX? Exchange? JScript? VBScript? FTP client?
Quote:
Massive portions of the new APIs -- WPF (windows presentation foundation, formerly Avalon), WCF (windows communication foundation, formerly Indigo), and the rest of WinFX -- are in managed code. They're such massive managed codebases that they actually got renamed to .NET 3.0, and they're meant to form the core for new applications. WinForms will be deprecated in favor of WPF, for example. SharePoint and SQL Server use .NET heavily. Very nearly all of the Microsoft website, MSN, Live, etc are built in ASP.NET.

I don't doubt it. But "meant to form the core of new applications" with APIs has happened before: remember MFC and COM?
Quote:
Besides, most of MS' really major applications are legacy codebases, some dating back to the late 80s. You don't throw that stuff out and switch over to managed code just for the hell of it; that's retarded. Most of MS' new applications, however, are built in managed code.

True, one should be careful about tossing working legacy, working codebases. I did check the link you provided (thank-you), but given all the code that Microsoft produces, those numbers seem to fall short of a wholesale commitment of core programming to C#. What's at issue here is what is "good enough." For the apps that demand the highest speed, are they being written in C#? Would you write a video codec in C#?
Quote:
While I was working there, I never touched anything other than C#.

Microsoft employs 10,000 programmers (just guessing, + or -). I'm sure there are MS employees who've never worked on anything but VBScript, or javascript, or C++, or you name it. It's a big company.
Quote:
What I see in D is a language that takes C++, and compounds the mistakes made there.

How does C# get it right while D gets it wrong?
0

Share this post


Link to post
Share on other sites
For that matter, would you write a video codec in C++, or even C? I was under the impression that this is one of the last bastions of hand-coded assembly.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Stachel
Is Office in C#? Is the C++ compiler? Windows Media Player? Word? Excel? IE7? DirectX? Exchange? JScript? VBScript? FTP client?
I already addressed that:
Quote:
Besides, most of MS' really major applications are legacy codebases, some dating back to the late 80s. You don't throw that stuff out and switch over to managed code just for the hell of it; that's retarded.

Exchange 2007, by the way, has managed components.
Quote:

True, one should be careful about tossing working legacy, working codebases. I did check the link you provided (thank-you), but given all the code that Microsoft produces, those numbers seem to fall short of a wholesale commitment of core programming to C#.
You're being deliberately blind. Very nearly all new projects at Microsoft are in managed code. You can't point at old multimillion line codebases and accuse them of being evidence that MS isn't dedicated to C#. That's ludicrous and does nothing except to cheapen this debate. As you point out later in your post, MS is a huge company (much, much more than 10K developers, by the way) and people work in everything.

As for D, I don't particularly feel inclined to move on to more specific complaints about the language. I'll simply refer you to my original remarks on the topic. D is just a fringe movement and that's all it'll ever be.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
You're being deliberately blind. Very nearly all new projects at Microsoft are in managed code.

Not being inside Microsoft, there's no way I can survey what languages new projects are written in. All I can see it what ships. But I do talk to developers who publicly are big boosters of C# and Java parity with C++, but privately admit the languages have years to go in the performance department.

Quote:
As for D, I don't particularly feel inclined to move on to more specific complaints about the language. I'll simply refer you to my original remarks on the topic. D is just a fringe movement and that's all it'll ever be.


About all you said can be summed up in that D isn't in widespread use. Then you said D compounds C++ mistakes (while presumably C# doesn't). It's reasonable to ask what you mean by that. I'm curious what you see when you look at D.

As for me, I wouldn't use C# for the simple reason that it attaches me at the hip to one platform. What if you write the next big game hit in C#, and want to move it to the new Nintendo/Sony Gee-Whiz game box which has no .net on it? D isn't in widespread use - agreed. But D isn't single platform, it's on several, and being integrated with gcc (GDC) means it's reasonable to get it on any platform I'd need it to be on. That's more important (to me, anyway).

0

Share this post


Link to post
Share on other sites
Quote:
You're being deliberately blind. Very nearly all new projects at Microsoft are in managed code. You can't point at old multimillion line codebases and accuse them of being evidence that MS isn't dedicated to C#. That's ludicrous and does nothing except to cheapen this debate. As you point out later in your post, MS is a huge company (much, much more than 10K developers, by the way) and people work in everything.


Wouldn't PInvoke allow them to still use most of the legacy code? Or is that how they are able to do most of the new projects in C#?

If so then why is it any different to using D's abbility to interact with c and c++ code?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Stachel
About all you said can be summed up in that D isn't in widespread use. Then you said D compounds C++ mistakes (while presumably C# doesn't). It's reasonable to ask what you mean by that. I'm curious what you see when you look at D.
I know, and it is reasonable. I just don't feel like going there. It requires too much discussion of what's wrong with C++ first, and I'm not interested in comitting that much time to this thread.
Quote:
As for me, I wouldn't use C# for the simple reason that it attaches me at the hip to one platform. What if you write the next big game hit in C#, and want to move it to the new Nintendo/Sony Gee-Whiz game box which has no .net on it?
That's legitimate.
Quote:
D isn't in widespread use - agreed. But D isn't single platform, it's on several, and being integrated with gcc (GDC) means it's reasonable to get it on any platform I'd need it to be on.
I don't buy that. First of all, if you want D on any platform other than the set that are supported -- which at the moment includes the major desktop and server operating systems, and nothing else. You're not doing any better than C# yet, and you're actually doing substantially worse than Java.

So then you go to retarget GDC to your new platform, let's say the PS3. First of all, that's a tremendous waste of time. Apart from the time spent on implementing the compiler and any supporting runtimes, you have to deal with compiler bugs that arise. Ok, so the frontend shouldn't have any bugs, but you have to rewrite the machine code generation, and that's very likely to be wrong for a while. You'll also have to re-implement the entire backend of the optimization system, or D still won't be usable as a core language. Don't forget, that includes building support for platform intrinsics (Altivec, etc) and making sure the compiler knows how to optimize those too.

Let's suppose you finished all of that. Now you can finally start building your game. Of course you're running many months late at this point, but moving on. Since you're using D for everything, you can't actually license third party middleware now, unless you're willing to write significant glue code. (In the case of a C API, like RenderWare, this might be possible -- in the case of PhysX or Unreal, you're in for a world of hurt.) So now you have to build your own engine completely from scratch. At this point you're looking at a total development timeline which is north of 4-5 years. Whatever console you were planning to launch for is probably obsolete at this point. In order to support the next gen, you have to go back and fix GDC to deal with the new architecture, which is now an 80 core monstrosity...you see where this is going.

Now don't get me wrong, the above story applies almost verbatim to C#, just with Mono instead of GDC. That's exactly why professional development is is not using C#; being locked out of consoles is not acceptable. However, D doesn't really have an advantage in this area, nor does Java or anything other than the native language which the manufacturer is supporting -- which is always C++.

Quote:
Wouldn't PInvoke allow them to still use most of the legacy code? Or is that how they are able to do most of the new projects in C#?
A lot of that code is application level, not library level. PInvoke doesn't really help there. That's not the important part though. You simply don't reimplement code that has been working flawlessly for a decade unless there's a really big problem with the system. There are much better ways of spending developer time.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
D isn't in widespread use - agreed. But D isn't single platform, it's on several, and being integrated with gcc (GDC) means it's reasonable to get it on any platform I'd need it to be on.
I don't buy that. First of all, if you want D on any platform other than the set that are supported -- which at the moment includes the major desktop and server operating systems, and nothing else. You're not doing any better than C# yet,


C# is windows only. DMD is on Windows and Linux, and GDC adds several more to that. D is way ahead of C# on platform support.

Quote:
and you're actually doing substantially worse than Java.

So then you go to retarget GDC to your new platform, let's say the PS3. First of all, that's a tremendous waste of time. Apart from the time spent on implementing the compiler and any supporting runtimes, you have to deal with compiler bugs that arise. Ok, so the frontend shouldn't have any bugs, but you have to rewrite the machine code generation, and that's very likely to be wrong for a while. You'll also have to re-implement the entire backend of the optimization system, or D still won't be usable as a core language. Don't forget, that includes building support for platform intrinsics (Altivec, etc) and making sure the compiler knows how to optimize those too.

Let's suppose you finished all of that. Now you can finally start building your game. Of course you're running many months late at this point, but moving on. Since you're using D for everything, you can't actually license third party middleware now, unless you're willing to write significant glue code. (In the case of a C API, like RenderWare, this might be possible -- in the case of PhysX or Unreal, you're in for a world of hurt.) So now you have to build your own engine completely from scratch. At this point you're looking at a total development timeline which is north of 4-5 years. Whatever console you were planning to launch for is probably obsolete at this point. In order to support the next gen, you have to go back and fix GDC to deal with the new architecture, which is now an 80 core monstrosity...you see where this is going.

Now don't get me wrong, the above story applies almost verbatim to C#, just with Mono instead of GDC. That's exactly why professional development is is not using C#; being locked out of consoles is not acceptable. However, D doesn't really have an advantage in this area, nor does Java or anything other than the native language which the manufacturer is supporting -- which is always C++.

Since D is open source and integrated in to gcc (the gnu D compiler is called GDC), it presumably is fairly straightforward to get it supported on any target that gcc supports, which is quite a lot. I doubt it would be as easy as a recompile, surely there'll be some bugs, tweaks, and adjustments for each platform. But it is feasible, and there are consultants who can be hired to do it. In essence, it's low risk and straightforward to write a check to get it done. You're not dead in the water holding your $5,000,000 bag. You don't need to write a new code generator, or optimizer, etc. If those game consoles are using g++ as their supported C plus plus compiler, then the pieces exist to get GDC working on it.

D can directly access any library that has a C interface. If it has a C plus plus interface, it is only accessible from C plus plus (C# has no C plus plus interface, neither does Java, nor any language other than C plus plus). There is a tool called SWIG that can be used to create C wrappers to C plus plus libraries, this has been used with some success. It isn't necessary to reimplement the library from scratch, unless the game engine API is based on template metaprogramming (!).

There is one C plus plus interface that D does support directly - COM interfaces - for what that's worth.

C# is different. It's closed source. Reimplementing it is just not feasible. Mono is nowhere near being a credible solution.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Stachel
Mono is nowhere near being a credible solution.

Oh man, now you've really gone and pissed Promit off.

By the way, I'm not sure if you're aware of this, but generally speaking the correct spelling is C++. I know its easy to get confused, what with + being pronounced plus and all.

CM
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Conner McCloud
Quote:
Original post by Stachel
Mono is nowhere near being a credible solution.

Oh man, now you've really gone and pissed Promit off.
It happens. This is just the part where I leave the thread, because the person I'm talking to is an idiot.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Conner McCloud
By the way, I'm not sure if you're aware of this, but generally speaking the correct spelling is C++. I know its easy to get confused, what with + being pronounced plus and all.


The trouble is, for some reason the pluses don't appear, so it looked like I was writing just plain C with a blank after it in the preview window. I don't know what the problem is with the forum software. I suppose some kind of escape is necessary, but I don't know what it is. So rather than be misunderstood, I wrote it as 'plus'.

0

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  
Followers 0