C++ sucks for games - Other Technologies

hmm. I remember vividly doing lisp at uni.
I think the assignment was a simple long division problem. I remember that
only a few people in the entire class managed to work out a way of achieving
it... I problem that is a newbie would do in C without breaking a sweat.

After that, no-one ever used lisp again...

...except the Jax & Daxter developers. Their game engine runs on an
interpretted lisp platform (I believe) and has spawned some of the most
impressive platformers I've ever seen...

So the moral is....
I don't know, but I won't be switching to Lisp any time soon...
Maybe its good once you get the hang of it...
But I think it may be too recursive & bottom-up programming for most brains
to want to deal with...



"Neo-LISPer" <neo_lisper@yahoo.com> wrote in message
news:87k6tf9ev3.fsf@yahoo.com...
> Hey
>
> Recently, I researched using C++ for game programming and here is what
> I found:
>
> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.
>
> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.
>
> You can not even change function definitions while the program is
> running and see the effects live (the ultimate debugging tool).
>
> Alternatively, you can't execute a small portion of the program
> without compiling and linking the whole thing, then bringing your game
> into a specific state where your portion of the code is being executed.
>
> The static type system locks you into a certain design, and you can't
> *test* new ideas, when they come to you, without redesigning your
> whole class hierarchy.
>
> C++ is so inflexible, even those who do use it for games, have to
> write their game logic in some other language (usually very slow,
> inexpressive and still garbage collected). They also have to interface
> the two languages.
>
> C++ lacks higher-order functions. Function objects emulate them
> poorly, are slow and a pain to use. Additionally, C++ type system does
> not work well with function objects.
>
> C++ programs can not "think" of new code at run-time, and plug that
> new code into themselves in compiled form. Not easily, anyway.
>
> C++ coding feels very repetitive, for example, when writing class
> accessors, you often have to write const and non-const methods with
> completely identical function bodies. Just look at STL.
>
> When programming in C++ you feel like a blind person trying to draw
> something. You don't _see_ the data structures that your procedures
> will operate on. Lisp programming is much more visual.
>
> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.
>
> C++ lacks automatic memory management and so it encourages copying
> objects around to make manual memory management manageable.
> Reference-counting schemes are usually slower than modern garbage
> collectors and also less general.
>
> Most important, C++ syntax is irregular, and you often find yourself
> typing repetitive patterns again and again - a task easily automated
> in languages with simpler syntax. There are even books on C++
> patterns, and some C++ experts take pride in being able to execute
> those patterns with computer-like precision - something a computer
> should be doing to begin with.
>
> C++ programs are slow: even though the compilers are good at
> micro-optimizing the code, programmers waste their time writing
> repetitive patterns in C++ and debugging memory corruption instead of
> looking for better algorithms that are far more important for speed
> than silly micro-optimizations.
>
> It's hard to find good programmers for C++ projects, because most of
> the good programmers graduated to languages like Lisp or avoided C++
> altogether. C++ attracts unimaginative fellows with herd mentality.
> For creative projects, you want to avoid them like a plague.
>
> It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.

Neo-LISPer wrote:

> Some senseless stuff

Besides your poor trolling attempts (most of your arguments just show that
you have no knowledge of C++) you don't even tell us what the alternative
to C++ in game programming could be.

--
To get my real email adress, remove the two onkas
--
Hendrik Belitz
- Abort, Retry, Fthagn? -

> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.

AKA Retarded mode.

> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.

There's a 90% failure rate for lions when hunting. They still eat.

I would presume that that "very high failure rate" becomes a bit lower when
you're dealing with proficient C++ programmers.

> You can not even change function definitions while the program is
> running and see the effects live (the ultimate debugging tool).

Nothing to do with the language. Such a debugging tool could be developed,
why not develop it?

I myself wouldn't use it.

> Alternatively, you can't execute a small portion of the program
> without compiling and linking the whole thing, then bringing your game
> into a specific state where your portion of the code is being executed.

That's because there's no such thing as "half a program". If you really want
this, copy-paste it to another file and just append:

int main(){}

to the end of it.

> The static type system locks you into a certain design, and you can't
> *test* new ideas, when they come to you, without redesigning your
> whole class hierarchy.

Bullshit. Vague bullshit.

> C++ is so inflexible, even those who do use it for games, have to
> write their game logic in some other language (usually very slow,
> inexpressive and still garbage collected). They also have to interface
> the two languages.

Provide an example. I myself forsee no reason or motive to do or have to do
this.

> C++ lacks higher-order functions. Function objects emulate them
> poorly, are slow and a pain to use. Additionally, C++ type system does
> not work well with function objects.

"function objects". Get over it! It's just syntatic sugar!

> C++ programs can not "think" of new code at run-time, and plug that
> new code into themselves in compiled form. Not easily, anyway.

"think of new code at run-time". That's because it takes intelligence to
write code, something which computers lack. As for the code coming from
somewhere else, well it's done extremely easily actually - we call it
dynamic linkage.

> C++ coding feels very repetitive, for example, when writing class
> accessors, you often have to write const and non-const methods with
> completely identical function bodies. Just look at STL.

Incorrect.

If both function bodies are identical, then there's no need to write a non-
const version.

If there exists both a const version and a non-const version, then this
indicates that one version alters the object, while the other doesn't.
Conclusion: different code.

You could also make the non-const version call the const version, and then
just do something extra.

> When programming in C++ you feel like a blind person trying to draw
> something. You don't _see_ the data structures that your procedures
> will operate on. Lisp programming is much more visual.

"procedures"? Never heard of them. I've heard of "functions" alright. I must
say I don't... see... your argument, no pun intended.

If you have a function which takes in an object of a certain class, or as
you call it "data structure", then... (actually, it's so simple I'm not even
going to finish this paragraph).

> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.

Bullshit. Vague bullshit.

> C++ lacks automatic memory management and so it encourages copying
> objects around to make manual memory management manageable.

int auto k = 4;

int* auto p_w = new int(4);

> Reference-counting schemes are usually slower than modern garbage
> collectors and also less general.

Which "garbage collector"? "less general" = vague bullshit.

> Most important, C++ syntax is irregular, and you often find yourself
> typing repetitive patterns again and again - a task easily automated
> in languages with simpler syntax.

I don't see your argument. I've never encountered such.

> There are even books on C++
> patterns, and some C++ experts take pride in being able to execute
> those patterns with computer-like precision - something a computer
> should be doing to begin with.

There's books on a lot of things.

> C++ programs are slow: even though the compilers are good at
> micro-optimizing the code, programmers waste their time writing
> repetitive patterns in C++ and debugging memory corruption instead of
> looking for better algorithms that are far more important for speed
> than silly micro-optimizations.

Define "programmers". I myself don't fit into the inuendo of a definition in
the above.

> It's hard to find good programmers for C++ projects, because most of
> the good programmers graduated to languages like Lisp or avoided C++
> altogether. C++ attracts unimaginative fellows with herd mentality.
> For creative projects, you want to avoid them like a plague.

MS-DOS was written in C++. Window XP was written in C++. Linux was written
in C++.

Come to think of it, what *wasn't* written in C++?

> It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.

My opinion differs.


-JKop

JKop <NULL@NULL.NULL> writes:

> > C++ game developers spend a lot of their time debugging corrupted
> > memory. Few, if any, compilers offer completely safe modes.
>
> AKA Retarded mode.
>
> > Unsurprisingly, there is a very high failure rate among projects using
> > C++ for modern game development.
>
> There's a 90% failure rate for lions when hunting. They still eat.
>
> I would presume that that "very high failure rate" becomes a bit lower when
> you're dealing with proficient C++ programmers.
>
> > You can not even change function definitions while the program is
> > running and see the effects live (the ultimate debugging tool).
>
> Nothing to do with the language. Such a debugging tool could be developed,
> why not develop it?
>
> I myself wouldn't use it.
>
> > Alternatively, you can't execute a small portion of the program
> > without compiling and linking the whole thing, then bringing your game
> > into a specific state where your portion of the code is being executed.
>
> That's because there's no such thing as "half a program". If you really want
> this, copy-paste it to another file and just append:
>
> int main(){}
>
> to the end of it.
>
> > The static type system locks you into a certain design, and you can't
> > *test* new ideas, when they come to you, without redesigning your
> > whole class hierarchy.
>
> Bullshit. Vague bullshit.
>
> > C++ is so inflexible, even those who do use it for games, have to
> > write their game logic in some other language (usually very slow,
> > inexpressive and still garbage collected). They also have to interface
> > the two languages.
>
> Provide an example. I myself forsee no reason or motive to do or have to do
> this.
>
> > C++ lacks higher-order functions. Function objects emulate them
> > poorly, are slow and a pain to use. Additionally, C++ type system does
> > not work well with function objects.
>
> "function objects". Get over it! It's just syntatic sugar!
>
> > C++ programs can not "think" of new code at run-time, and plug that
> > new code into themselves in compiled form. Not easily, anyway.
>
> "think of new code at run-time". That's because it takes intelligence to
> write code, something which computers lack. As for the code coming from
> somewhere else, well it's done extremely easily actually - we call it
> dynamic linkage.
>
> > C++ coding feels very repetitive, for example, when writing class
> > accessors, you often have to write const and non-const methods with
> > completely identical function bodies. Just look at STL.
>
> Incorrect.
>
> If both function bodies are identical, then there's no need to write a non-
> const version.
>
> If there exists both a const version and a non-const version, then this
> indicates that one version alters the object, while the other doesn't.
> Conclusion: different code.
>
> You could also make the non-const version call the const version, and then
> just do something extra.
>
> > When programming in C++ you feel like a blind person trying to draw
> > something. You don't _see_ the data structures that your procedures
> > will operate on. Lisp programming is much more visual.
>
> "procedures"? Never heard of them. I've heard of "functions" alright. I must
> say I don't... see... your argument, no pun intended.
>
> If you have a function which takes in an object of a certain class, or as
> you call it "data structure", then... (actually, it's so simple I'm not even
> going to finish this paragraph).
>
> > Constructors and smart pointers make it hard to tell cheap operations
> > from expensive ones.
>
> Bullshit. Vague bullshit.
>
> > C++ lacks automatic memory management and so it encourages copying
> > objects around to make manual memory management manageable.
>
> int auto k = 4;
>
> int* auto p_w = new int(4);
>
> > Reference-counting schemes are usually slower than modern garbage
> > collectors and also less general.
>
> Which "garbage collector"? "less general" = vague bullshit.
>
> > Most important, C++ syntax is irregular, and you often find yourself
> > typing repetitive patterns again and again - a task easily automated
> > in languages with simpler syntax.
>
> I don't see your argument. I've never encountered such.
>
> > There are even books on C++
> > patterns, and some C++ experts take pride in being able to execute
> > those patterns with computer-like precision - something a computer
> > should be doing to begin with.
>
> There's books on a lot of things.
>
> > C++ programs are slow: even though the compilers are good at
> > micro-optimizing the code, programmers waste their time writing
> > repetitive patterns in C++ and debugging memory corruption instead of
> > looking for better algorithms that are far more important for speed
> > than silly micro-optimizations.
>
> Define "programmers". I myself don't fit into the inuendo of a definition in
> the above.
>
> > It's hard to find good programmers for C++ projects, because most of
> > the good programmers graduated to languages like Lisp or avoided C++
> > altogether. C++ attracts unimaginative fellows with herd mentality.
> > For creative projects, you want to avoid them like a plague.
>
> MS-DOS was written in C++. Window XP was written in C++. Linux was written
> in C++.
>
> Come to think of it, what *wasn't* written in C++?

Linux comes to mind.

>> Come to think of it, what *wasn't* written in C++?
>
> Linux comes to mind.


Really? What was it written in?



-JKop

"JKop" <NULL@NULL.NULL> wrote in message
news97fd.40000$Z14.14510@news.indigo.ie...
>
>>> Come to think of it, what *wasn't* written in C++?
>>
>> Linux comes to mind.
>
>
> Really? What was it written in?
>
C

Also MSDOS and MS WIndows were developed in C, as far as I know.

Catalin

Catalin Pitis posted:

>
> "JKop" <NULL@NULL.NULL> wrote in message
> news97fd.40000$Z14.14510@news.indigo.ie...
>>
>>>> Come to think of it, what *wasn't* written in C++?
>>>
>>> Linux comes to mind.
>>
>>
>> Really? What was it written in?
>>
> C
>
> Also MSDOS and MS WIndows were developed in C, as far as I know.
>
> Catalin



HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa

HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa

ha ha ha


OOOHhhhhhhhhh, it's too much.


Didn't we switch from coal to oil yyeeaarrss ago?


-JKop

"JKop" <NULL@NULL.NULL> wrote in message
news:Je7fd.40004$Z14.14518@news.indigo.ie...
> Catalin Pitis posted:
>
>>
>> "JKop" <NULL@NULL.NULL> wrote in message
>> news97fd.40000$Z14.14510@news.indigo.ie...
>>>
>>>>> Come to think of it, what *wasn't* written in C++?
>>>>
>>>> Linux comes to mind.
>>>
>>>
>>> Really? What was it written in?
>>>
>> C
>>
>> Also MSDOS and MS WIndows were developed in C, as far as I know.
>>
>> Catalin
>
>
>
> HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa
>
> HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa
>
> ha ha ha
>
>
> OOOHhhhhhhhhh, it's too much.
>
>
> Didn't we switch from coal to oil yyeeaarrss ago?
>
>
> -JKop

It seems not

Catalin

Catalin Pitis wrote:

>
> "JKop" <NULL@NULL.NULL> wrote in message
> news97fd.40000$Z14.14510@news.indigo.ie...
>>
>>>> Come to think of it, what *wasn't* written in C++?
>>>
>>> Linux comes to mind.
>>
>>
>> Really? What was it written in?
>>
> C
>
> Also MSDOS and MS WIndows were developed in C, as far as I know.
>
> Catalin

You're totally correct in this. But most higher-order toolkits are written
in C++.

BTW: I don't know a single piece of "real" software that was written in LISP
(AFAIK even Emacs only uses LISP as an extension and scripting language:
Something that is really bad bevhaviour according to the original troll ..
eerrh ... poster).

I am also awaiting good examples for LISP 3D-Engines, LISP- OS kernels, LISP
device drivers, LISP text processors or LISP numerical toolkits. Feel free
to copy your whole project source code for these topics to your
news-transfer-daemon /dev/null...

--
To get my real email adress, remove the two onkas
--
Hendrik Belitz
- Abort, Retry, Fthagn? -