clayasaurus wrote:

> If we arn't going to care about version numbers, here are a few more suggestions...

We do care about version numbers.

We just don't think that 5.0 is necessarily better than 1.5.0... :-)

--anders

In article <dnq4h0$1sm5$1@digitaldaemon.com>, John Reimer says...
>
>Ben Hinkle wrote:
>
>A thanks for explaining, Ben!  The context just sounded a little too sinister for you! :D
>

I thought I emphasized that I wasn't implying anything nasty about Ben's motivation <g> If it came across differently, I apologize Ben.

>I did actually manage to find Cx on your website after it was mentioned here.
>
>-JJR

Dave wrote:
> In article <dnq4h0$1sm5$1@digitaldaemon.com>, John Reimer says...
>> Ben Hinkle wrote:
>>
>> A thanks for explaining, Ben!  The context just sounded a little too sinister for you! :D
>>
> 
> I thought I emphasized that I wasn't implying anything nasty about Ben's
> motivation <g> If it came across differently, I apologize Ben.
> 

No, you were fine, Dave.  I was just being facetious.  Still, I was surprised I had missed (or possibly forgotten about) his little experiment.

-JJR

Dave wrote:
> MyClass mc = new MyClass; // heap
> MyClass mc2 = MyClass; // RAII (stack or heap, depending on implementor choice (i.e.: GC and machine architecture))

So, is 'new MyClass;' equivalent to 'new MyClass();' now? Why not add 'int x(5);' in addition to 'int x = 5;' as well...

> Maybe I'm misunderstanding you but that sounds pretty definitive; where are you getting this information? Walter made no such commitments that I've ever seen for v0.142.

No, I just pulled the version number out of my hat :) Let's call it v0.1xy instead.

-- 
Niko Korhonen
SW Developer

Tom S wrote:
> What complexity ? We already have it. It's all about the syntactic sugar.

No, not as such IMO. Struct semantics are different enough from class semantics for them not to get mixed in that manner and the current stack allocation scheme for classes (using alloca) is so ugly and obscure that no one uses it unless it's absolutely necessary.

After the new stack allocation syntax addition we have a simple, viable way of creating class instances both on the heap and on the stack. So now we have to *choose whether we want stack or heap instances whenever we are creating a class instance*.

Each time you fork the language construct in two, you get two schools of thought. These two schools of thought will wage war on each indefinitely. This is exactly what happened with C++ (in an extreme manner) and nowadays every C++ programmer knows and uses a different subset of the language and wages war with the other programmers.

Consider:

int x = 5;
int x(5);

Which is better?

MyClass a;
MyClass a = MyClass();

Again, which is better?

void func(const MyClass& myClass);
void func(const MyClass* myClass);

Again, which is better?

C++ has created millions of ways to do the same thing, i.e. the language is full of redundant constructs. A couple of recent additions to D (type inference and stack allocation) have forked/will fork the language in two, now we have to choose between:

auto c = new MyClass();
MyClass c = new MyClass(); // Which is better?

and soon:

auto c = MyClass();
auto c = new MyClass();

People are bound to create Coding Guidelines for D with one saying 'Always use type inference' and the other saying 'Never use type inference'. I've read three different company internal style guides for C++ and all of them are completely different. I don't want the same to happen to D.

The point that I'm desperately (and rather poorly come to think of it) trying to make is that we should keep the number of lanugage constructs to a bare minimum and absolutely ban any redundant constructs. This helps to keep the language shareable, clean and easy to understand and easy to parse.

Whenever there is a choice between language constructs programmers will fight about which one is better. The only historically proven way to alleviate this issue is to reduce the number of choices. The C++ gurus standard answer of 'educating the programmers better' hasn't worked in the real world.

Only if and only if there are no choices between language constructs to fight about, programmers will not fight about them. Otherwise they will.


-- 
Niko Korhonen
SW Developer

JT wrote:
> ...One thing to mention however, most every game studio holds their
> internal procedures, libraries, tools, and cup cake recipies as guarded as the
> 1985 bears with their playbook. It would be interesting to see how many
> developers would even want to advertise their use of something like D. Not that
> I would have any problem with it but its interesting community. I would like to
> write an article for game developer magazine but im too busy. im planning a
> studio around a brand new engine and suite of tools built in D.
> 

I also think D is an ideal game programming language. In fact, game programming is how I found D in the first place. I was looking for a language that took all of the intentions of C++ but got rid of all of the bad (or difficult) things of trying to be compatible with C (or use C as a subset).

I'm still trying to form an opinion on keeping libraries and tools secret, as there are good and bad sides. I see many reinvented game libraries that just seem like a waste of time (a Matrix, Vector, etc. should be in a standard math/physics library). Also if you want to use a different game engine you have to switch all of your libraries (more waste of time). But at the same time if a company (or person), put many hours into a tool they should be able to get paid for it. Well I won't go on a long rant, but in high school and college it was hard to find an editor or a 3D modeller that didn't cost a fortune. Fortunately, some companies now make personal editions or cheaper editions for aspiring developers. I'll just stop there... My opinion is beginning to be swayed towards libraries being open with a type of FreeBSD license, while tools  should be priced accordingly (for students/indies and companies).

But anyways I've used Torque, OGRE, GeometricTools (used to be Wild-Magic), and lately I've been using OSG. My main problem is that all of those are in C++, which means I would have to redo all (or parts) of those libraries. Guess I better get coding...

PS: I like the reference to the 1985 Bears :) And if your studio needs any programmers for this brand new engine... let me know.

In article <dnoru3$mgr$1@digitaldaemon.com>, Niko Korhonen says...
>I also would like to see bit arrays and AA's in the standard library instead of the language; IMO D isn't high-enough level language for that.

While I agree that bit arrays in the core language, in retrospect, were probably
a mistake they are in the language, are used, and so need to stay.
I'll disagree with the AA's. I use them and like them a lot. It's a well used
data structure, and having them in the core makes them just sweet.

>Not to mention that I downright abhor the "whisper syntax". In the last couple of months I've seen D gradually mutating towards C++ with new features that increase complexity. Please don't make it any more complicated than it already is.

The whisper syntax was necessary at the time because D didn't support typesafe
variadic argument lists. It does now (which is why writefln() works).

In article <dnos3h$mp9$1@digitaldaemon.com>, Niko Korhonen says...
>Yes, but for argument's sake consider a situation where a project has 5M lines of DMD 0.141 code. Assume that it turns out that DMD 0.141 has a nasty compiler bug that forces the project to use some pretty ugly workarounds. Suppose this bug was fixed in DMD 0.143, but 0.142 added a breaking change which would need tens or possibly hundreds of man-hours to track down the needed changes in the source. The customer doesn't want to pay for these hours so the project management refuses the compiler update. Bang! The project is forever stuck with DMD 0.141 and the programmers are likewise stuck using these ugly workarounds and can only dream about the nifty new features that DMD 0.150 brought; say bye-bye to employer morale.
>
>I've seen a project at my work place that has stuck into Java 1.3.1_b24 forever because of some nasty breaking changes in the immediately following JDK version. It's horrible when that happens. Probably the worst thing that can happen in software development.

I agree this can happen - and it does happen with every language. The flip side is that if D doesn't constantly improve as a language, it will die. Show me a language that is unchanging and I'll show you a dead language. D has no choice but to move forward.

That said, there is good reason to fork D once 1.0 is set - one fork will be purely bug fixes, the language improvements go into the other fork.

Walter Bright wrote:

> That said, there is good reason to fork D once 1.0 is set - one fork will be
> purely bug fixes, the language improvements go into the other fork.
> 
> 

This is a truly wonderful statement!

-JJR

In article <dnrn8u$2vcs$1@digitaldaemon.com>, Lucas Goss says...
>
>JT wrote:
>> ...One thing to mention however, most every game studio holds their
>> internal procedures, libraries, tools, and cup cake recipies as guarded as the
>> 1985 bears with their playbook. It would be interesting to see how many
>> developers would even want to advertise their use of something like D. Not that
>> I would have any problem with it but its interesting community. I would like to
>> write an article for game developer magazine but im too busy. im planning a
>> studio around a brand new engine and suite of tools built in D.
>> 
>
>I also think D is an ideal game programming language. In fact, game programming is how I found D in the first place. I was looking for a language that took all of the intentions of C++ but got rid of all of the bad (or difficult) things of trying to be compatible with C (or use C as a subset).
>
>I'm still trying to form an opinion on keeping libraries and tools secret, as there are good and bad sides. I see many reinvented game libraries that just seem like a waste of time (a Matrix, Vector, etc. should be in a standard math/physics library). Also if you want to use a different game engine you have to switch all of your libraries (more waste of time). But at the same time if a company (or person), put many hours into a tool they should be able to get paid for it. Well I won't go on a long rant, but in high school and college it was hard to find an editor or a 3D modeller that didn't cost a fortune. Fortunately, some companies now make personal editions or cheaper editions for aspiring developers. I'll just stop there... My opinion is beginning to be swayed towards libraries being open with a type of FreeBSD license, while tools
>  should be priced accordingly (for students/indies and companies).
>
>But anyways I've used Torque, OGRE, GeometricTools (used to be Wild-Magic), and lately I've been using OSG. My main problem is that all of those are in C++, which means I would have to redo all (or parts) of those libraries. Guess I better get coding...
>
>PS: I like the reference to the 1985 Bears :) And if your studio needs any programmers for this brand new engine... let me know.


Yeah I agree somehwhat with what you are saying. The culture of the industry has ultimately helped cause the situation where there is soooo much bad code floating around. Most of it is private and you never see it until you are getting paid to fix it :/ But even the commercial engines are a joke - they are mostly old engines with generation after generation of layers over them. Im still split between having a fully open engine or not, but I believe the core tools should be open. Ultimately I would love to be able to publish an open source engine with licensed artwork, but im not sure how realistic that is. Most of the engines you mentioned are nowhere near production quality, although I think bits like the Open Dynamics Engine can save a company a LOT of money. Idealy more and more companies would be using open libraries and contributing to them. Then, maybe we can spend more time focusing on gameplay and artwork....