Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


What do you think of the D language?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
93 replies to this topic

#21 Sneftel   Senior Moderators   -  Reputation: 1781

Like
0Likes
Like

Posted 12 September 2006 - 04:55 AM

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.

Sponsor:

#22 ToohrVyk   Members   -  Reputation: 1591

Like
0Likes
Like

Posted 12 September 2006 - 05:13 AM

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.


A clever comparison. I myself have never found an use for D — when I can afford not to use C++, I'll use another language, such as C# or O'Caml or Prolog, and when I have to use C++, well, I just have to.

#23 Rebooted   Members   -  Reputation: 612

Like
0Likes
Like

Posted 12 September 2006 - 05:16 AM

Quote:
Original post by ToohrVyk
A clever comparison. I myself have never found an use for D — when I can afford not to use C++, I'll use another language, such as C# or O'Caml or Prolog, and when I have to use C++, well, I just have to.
Exactly my thoughts. Nothing really wrong with D as such.

#24 clayasaurus   Members   -  Reputation: 139

Like
0Likes
Like

Posted 12 September 2006 - 08:32 AM

The whole purpose of D is to make programming _easier_. You can write the same code in C++ with 100 files and 10,000 lines, or the same program in D with 50 files and 7,000 lines (assuming 3,000 lines are simply class definitions and function prototypes). You can compile large D projects without makefiles ( http://www.dsource.org/projects/build ), and large projects only take a couple of seconds to compile. You can use it as a scripting language alternative in *nix ( http://digitalmars.com/d/rdmd.html ).

It is a misconception that D is equal to C++ with more features. Rather, some features are added (template metaprogramming ( http://digitalmars.com/d/templates-revisited.html ), lazy evaluation of function arguments ( http://digitalmars.com/d/lazy-evaluation.html ), exception safe programming ( http://digitalmars.com/d/exception-safe.html ), and memory management ( http://digitalmars.com/d/memory.html ) and some are subtracted such as the C Macro language and other support of legacy C code.

Some features are refined, like the ability to have real typedef's, modules (which reduce project size by 50% compared to C++), built in arrays and strings, delegates instead of function pointers, and not having to use the rely on pointers, or when there are pointers they don't have their own special '->' syntax, rather just '.'

To show off the metaprogramming capabilities of D, look at a compile time raytracer program here http://www-users.mat.uni.torun.pl/~h3r3tic/ctrace/ .

The reason you would use D over Java and C# is because D is much faster not having to rely on a VM and gives access to assembly within the D language itself, not relying on the backing of a large corporate interest (less political issues), open to suggestions and improvements, but most importantly are the huge productivity boosts of dealing with a refined language rather than a clunky one.

The reason D does fall short is only because there are less libraries available for D than C++, which has nothing to do with the language itself but only goes to show that currently the D community is small. In order to overcome this obstacle, D gives access to the C language which does make it possible to bind D to C and C++ code. C++ code binding is a little bit harder but there are tools available to automatically do this for you, and there are also tools to automatically turn C .h files into .d files which allows you to access C functions within D.

#25 ToohrVyk   Members   -  Reputation: 1591

Like
0Likes
Like

Posted 12 September 2006 - 08:37 AM

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.



#26 Promit   Moderators   -  Reputation: 7341

Like
0Likes
Like

Posted 12 September 2006 - 08:53 AM

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.

#27 clayasaurus   Members   -  Reputation: 139

Like
0Likes
Like

Posted 12 September 2006 - 08:59 AM

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.



#28 ToohrVyk   Members   -  Reputation: 1591

Like
0Likes
Like

Posted 12 September 2006 - 09:16 AM

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.



#29 daerid   Members   -  Reputation: 354

Like
0Likes
Like

Posted 12 September 2006 - 09:21 AM

Holy crap. Never seen this thread before.

#30 DeadXorAlive   Members   -  Reputation: 535

Like
0Likes
Like

Posted 12 September 2006 - 12:37 PM

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

#31 Promit   Moderators   -  Reputation: 7341

Like
0Likes
Like

Posted 12 September 2006 - 12:46 PM

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.

#32 DeadXorAlive   Members   -  Reputation: 535

Like
0Likes
Like

Posted 12 September 2006 - 12:55 PM

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?

#33 Sneftel   Senior Moderators   -  Reputation: 1781

Like
0Likes
Like

Posted 12 September 2006 - 01:16 PM

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.


#34 Conner McCloud   Members   -  Reputation: 1135

Like
0Likes
Like

Posted 12 September 2006 - 01:30 PM

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

#35 Promit   Moderators   -  Reputation: 7341

Like
0Likes
Like

Posted 12 September 2006 - 01:31 PM

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.

#36 DeadXorAlive   Members   -  Reputation: 535

Like
0Likes
Like

Posted 12 September 2006 - 01:32 PM

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.



#37 Stachel   Members   -  Reputation: 100

Like
0Likes
Like

Posted 02 October 2006 - 04:06 PM

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.



#38 Promit   Moderators   -  Reputation: 7341

Like
0Likes
Like

Posted 02 October 2006 - 05:24 PM

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.

#39 Stachel   Members   -  Reputation: 100

Like
0Likes
Like

Posted 03 October 2006 - 06:26 AM

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.

#40 Promit   Moderators   -  Reputation: 7341

Like
0Likes
Like

Posted 03 October 2006 - 06:38 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS