View mode: basic / threaded / horizontal-split · Log in · Help
December 14, 2005
Re: A safer/better C++?
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
December 14, 2005
Re: A safer/better C++?
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
December 15, 2005
Re: A safer/better C++?
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
December 15, 2005
Re: A safer/better C++?
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
December 15, 2005
Re: A safer/better C++?
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
December 15, 2005
Re: A safer/better C++?
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.
December 15, 2005
Re: A safer/better C++?
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).
December 15, 2005
Re: A safer/better C++?
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.
December 15, 2005
Re: A safer/better C++?
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
December 15, 2005
Re: A safer/better C++?
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....
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home