Just an aside on the topic of D. I tried making a parser based upon the grammar in the specification here. I found that the grammar has a great many needless conflicts, many of the rules are called different names in different parts of the specification, and some parts, such as the syntax of formal parameters and contracts, aren''t even defined.

Clearly, the grammar in the specification isn''t the grammar he actually uses in his compiler. I don''t even know if the parts that are included are how his compiler does it. Although the source is available, he doesn''t use a parser generator: instead the parser is written manually, making it inconvenient unravel the syntax from the code.

This makes it unneccessarily difficult for somebody else to write an implementation of D. Part of the reason that C/C++ are so popular is that they are very well defined, and well written C/C++ code is pretty much guaranteed to be portable to 90% of compilers. When D fails to explicitly define some really quite important parts of its behaviour, you can''t be sure that programs will be portable.

Like C/C++, C# is very well defined.

ok beeting C/C++ development time is easy, but beating it while still being able to write fast native code? I think not. Thats why D is so cool (there may be others i admit but C# is not one of em).

[edited by - imr1984 on May 2, 2004 11:23:36 AM]

Mayrel pretty much said what I would have wanted to say, so I''ll leave it at that(just got up, anyway).

But I just want to make it clear(detecting sarcasm/irony around here isn''t always easy): I am NOT a girl. Never have been, never will be. "Arild" has been a male name around here for a millennium.

actually yes it does make a diff. in speed... ok write a game like call of duty in c++... it will run smoothly... now try writing the same game in java... it will probably be impossible because java doesn't support those kinds of graphics, speed. JAVA and other languages are good for quick development, but not in our lifetime will we see a 'Call of Duty' made in java.

[edited by - snyp on May 2, 2004 12:09:36 PM]

The last few posts have been on the topic of speed, and some things appear to have been moved out of perspective.

The first, and most obvious point, is that only a prize fool would implement a low-level 3D engine in Java, when performance is critical.

''Low-level'' includes software rasterisers, and OpenGL/Direct3D engines where triangles are sent to the card individually. Only a prize fool does the latter with C/C++, of course, for reasons which will be obvious in a few moments, if they aren''t already.

I''ll use OpenGL as an example, since I have nearly no experience with Direct3D. What I do when I want to draw a complex model with OpenGL is to load the vertices into normal memory, then upload them to a vertex buffer. Thenceforce, I have OpenGL read the vertex data from the buffer which will, hopefully, be in video memory.

The thing to note is that rendering a mesh in this way is not notably less efficient when using Java than when using C++, whilst piping the triangles out manually almost certainly would be (since you''ll probably need bounds checking on your vertex arrays, extra overhead for thunking between Java and the native code, etc).

If you''re a genius like Carmack, you can always improve a game by using non-portable native code. But if you''re a genius like Carmack, you''ll realise that you can outsource that non-portable code to a library. Then you can write that library in C++, and the rest of the game could be written in Java.

All this means that it is quite possible for somebody to write game with the technical sophistication of Call Of Duty in Java, so long as they use sensible coding techniques, and optionally provide non-portable high-speed implementations of key algorithms in some non-Java langauge. Ideally the latter wouldn''t be necessary because the standard libraries would be good enough by themselves.

Returning to the notional topic of debate, C#, we note that C# allows the programmer to bypass many safety ''features'' that cannot be overriden in Java. Bounds checking can be disabled, pointers can be used, non-CLI libraries can be called directly. There is no good reason why a well-designed C# program shouldn''t be just as efficient as a well-designed C++ program.

Many people complain that C#, Java and D do things "behind the programmer''s back". This isn''t a problem.

They imagine that garbage collection is an intolerable drain on processor power. The simple fact is that any good language with GC will precisely define when GC occurs, and allow the programmer to prevent GC from occuring within performance critical sections of code, or to explicitly force a GC cycle when there is time to spare.

Further more, whilst a C/C++ program is often a chain of allocations, processing and deletions, a C#/D/Java program is often a chain of allocations and processing, with deletions delayed until later. Garbage collection actually increases performance by delaying things that couldn''t be delayed in C/C++. If the language offers a effective level of control over the GC, you can, as I mentioned above, cause a GC cycle (or partial GC cycle) during a quiet period: you might have GC run between the end of an AI/physics cycle and drawing the next frame.

quote:Original post by Arild Fines
But I just want to make it clear(detecting sarcasm/irony around here isn''t always easy): I am NOT a girl. Never have been, never will be. "Arild" has been a male name around here for a millennium.

Heh. Sorry about that.

I''ve checked the so-called C# FAQ". It''s the same old boring ''everything that is good in programming is in Java so anything that isn''t in Java must be bad'' rhetoric. Pick some features from a language you don''t like, use them in the worst possible way, and then act surprised when the result isn''t what you want.

It''s kind of like comparing travelling 1,000 miles on foot to travelling 1,000 miles in a car and concluding that it''s better to go by foot, because you might open the gas cap and throw a lighted match in.