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.
761  27916 
Neo-LISPer wrote: Hey
...
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.
My opinion to others:
Do not feed the trolls. Please!
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" <ne********@yahoo.com> wrote in message
news:87************@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 <NU**@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" <NU**@NULL.NULL> wrote in message
news:o9*******************@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" <NU**@NULL.NULL> wrote in message
news:o9*******************@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" <NU**@NULL.NULL> wrote in message
news:Je*******************@news.indigo.ie... Catalin Pitis posted:
"JKop" <NU**@NULL.NULL> wrote in message
news:o9*******************@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 :D
Catalin
Catalin Pitis wrote:
"JKop" <NU**@NULL.NULL> wrote in message
news:o9*******************@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? -
On 2004-10-25 15:08:22, JKop wrote: MS-DOS was written in C++. Window XP was written in C++. Linux was written
in C++.
You're funny! :-)
In comp.lang.c++ JKop <NU**@null.null> wrote: C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
AKA Retarded mode.
(inspired response to obvious troll)
What part of "Do not feed the trolls" was hard to understand?
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
"Catalin Pitis" <ca***********@iquestint.com.renameme> wrote in message
news:2u*************@uni-berlin.de...
"JKop" <NU**@NULL.NULL> wrote in message
news:o9*******************@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.
afaik dos was assembler...
"Neo-LISPer" <ne********@yahoo.com> wrote in message
news:87************@yahoo.com... Hey
Recently, I researched using C++ for game programming and here is what
I found:
As other industries using C++ - even for highly graphical, rich-content
physics simulations - report fewer of these problems, the game programming
culture itself might be to blame.
C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
The alternative, garbage collection, tends to corrupt memory too. Have you
heard of a high-availability Visual Basic program?
Game programmers need efficient and deterministic garbage collection. If
they don't code it themselves, following healthy styles, they will corrupt
memory.
Unsurprisingly, there is a very high failure rate among projects using
C++ for modern game development.
That's because there's a high failure rate period, and most games use C++.
You can not even change function definitions while the program is
running and see the effects live (the ultimate debugging tool).
There are those who don't need to debug. The game programming industry has
only begun to adopt unit testing in a very few shops.
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.
Test isolation would help that. If objects are decoupled, you can write a
test that plays with only one of them.
Playing with unit test cases, and adding them very easily, is a great way to
preserve all those little experiments, and convert them into constraints.
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.
Then don't use the static type system.
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.
You make that sound like a bad thing. Most programs have two languages
(consider the glorious union of VB and SQL). Games need a scripting layer to
decouple designing the game play from its engine. Most other applications
with an engine use this model, too.
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.
So what? It also makes the Prototype Pattern a pain in the nuts. These
issues are not in the domain, they are just implementation alternatives.
C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.
So, uh, use the scripting layer?
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.
It sounds like you need to tell us you are less than perfectly adept at C++.
Have you used it for games?
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.
That's because you are familiar with Lisp.
Constructors and smart pointers make it hard to tell cheap operations
from expensive ones.
All cheap and expensive operations are impossible to predict and hard to
tell apart. Profile.
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.
Prefer pass-by-reference above all other kinds, because its cognitively
efficient and usually execution efficient.
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++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
disturbs me most.
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.
How could that complaint be specific to C++?
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.
That's because educating someone to write low-risk C++ is difficult. Vendors
have clogged our markets with low-quality languages that purport to allow
inept programmers to write code at a lower risk than C++ provides.
Games must have high performance, so C++ is the leading language for now.
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
Christopher Benson-Manica <at***@nospam.cyberspace.org> writes: (inspired response to obvious troll)
What part of "Do not feed the trolls" was hard to understand?
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
[I wouldn't normally participate in a flame-infested thread like
this, but since you're so literally asking for for things you need
to know..]
While I agree that the OP was trolling by posting his article to
c.l.c++, it is still my opinion that he was in many parts correct and
the "inspired" response was nothing but a display of complete
ignorance. Many of the issues raised by the OP are truly something you
need to know about (if you don't already), regardless of which
programming language you prefer, IMHO.
--
Frode Vatvedt Fjeld While I agree that the OP was trolling by posting his article to
c.l.c++, it is still my opinion that he was in many parts correct and
the "inspired" response was nothing but a display of complete
ignorance. Many of the issues raised by the OP are truly something you
need to know about (if you don't already), regardless of which
programming language you prefer, IMHO.
Ignorance? Arrogance maybe? (no pun intended)
As for the issues raised being truly something you need to know about... do
you need to tell a child not to eat its own excrement? No. Why? It figures
that out for itself. If you're writing code and you have "new" all over the
place and you've no "delete"'s, then you'll figure out the aim of the whole
"Garbage Collection" ideal. I myself am not retarded, so I've no need for
"Garbage Collection". If, hypothetically speaking, I forsaw that I would
temporarily become retarded (a golfclub to the head maybe), then I would
make use of auto_ptr, but that has yet to happen.
Isn't great how we're all entitled to our own opinions! ;-P
-JKop
many of these issues may exist, but are not that big of a deal really, and
there is the problem that higher-level languages often have a poor c
interface and typically need interface stuff to be written to access c code
(and thus most system api's, along with parts of the project likely being
written in c).
c++ is typically much better at accessing c code than most other languages.
any other issues are fairly minor (there is a lack of convinient syntax for
many things, but these things are not that hard to pull off through other
means). some things would be nice (syntactic closures and lexical scoping,
....), but do not justify many other costs.
using languages other than c or c++ tends to end up being more expensive.
this post can be generally be referred to as trolling, however.
"Neo-LISPer" <ne********@yahoo.com> wrote in message
news:87************@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.
On Mon, 25 Oct 2004 15:50:36 +0200, Hendrik Belitz wrote: Catalin Pitis wrote:
"JKop" <NU**@NULL.NULL> wrote in message
news:o9*******************@news.indigo.ie...
> Come to think of it, what *wasn't* written in C++?
Pretty much everything worthwhile.
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.
I doubt it. I'd bet MSDOS was written in assembler.
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
I.e., you're ignorant. [By the way, it's spelled "Lisp", not "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).
Which Emacs? Emacs was original TECO macros (hence the name), then
Lisp. (Some) Unix versions are now written in C with (a crufty
ancient) Lisp as "extension language", yes (but there's hardly any
call for your "only": a fair amount of the core functionality is in
Lisp, and there's rather more Lisp than C there)
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
Google for "Mirai" and "Genera", for starters.
[You C++ types still have a way to go to catch up to 1980's Lisp :-)]
--
Malum est consilium quod mutari non potest -- Publilius Syrus
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
Disclaimer: I don't dislike C++, but the responses to the OP's (mostly
valid) criticisms are pretty uninformed. The alternative, garbage collection, tends to corrupt memory too. Have you
heard of a high-availability Visual Basic program?
Game programmers need efficient and deterministic garbage collection. If
they don't code it themselves, following healthy styles, they will corrupt
memory.
Erm no, garbage collection does not corrupt memory unless the garbage
collector is buggy. Have you ever seen a VB program segfault? If you have
special requirements for garbage collection, you just need a garbage
collector tuned to your requirements (e.g. the real-time garbage collectors
available in some implementations of various languages).
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.
Test isolation would help that. If objects are decoupled, you can write a
test that plays with only one of them.
Playing with unit test cases, and adding them very easily, is a great way
to preserve all those little experiments, and convert them into
constraints.
Unit tests help you to /test/ code, but not to debug it. When you've found a
bug, you still need to do the work of actually fixing the code. This is
much easier if you have an environment which supports dynamic redefinition
and interative compilation.
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.
Then don't use the static type system.
Not using the static type system would entail not using C++ (unless you
intend to represent all your data as void * and fill your program with
casts).
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.
You make that sound like a bad thing. Most programs have two languages
(consider the glorious union of VB and SQL). Games need a scripting layer
to decouple designing the game play from its engine. Most other
applications with an engine use this model, too.
Clearly a separate scripting language is not desirable if you can avoid it
(performance and code overhead from interfacing the two languages, being
constrained by an enforced separation between interelated parts of the
program, etc.) It is difficult to avoid having a separate scripting
language in C++ because it doesn't support incremental compilation. It's
certainly not impossible to avoid it (Half-Life doesn't have one, for
example), but you pay the price: make a trivial mistake in your Half-Life
mod code and the fix-reload-test cycle can be a couple of minutes long.
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.
That's because you are familiar with Lisp.
Indeed, it's much easier to express complex data structures in Lisp.
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.
So what? It also makes the Prototype Pattern a pain in the nuts. These
issues are not in the domain, they are just implementation alternatives.
This makes no sense. Higher order functions are a win, period. Function
objects are just less powerful than higher order functions (assuming that
these functions are closures). If you've been paying attention to R&D in
programming languages for the past 20-30 years, you'll notice that higher
order functions are one abstraction mechanism that just about every new
language has adopted (often prior to the development of C++). They're so
useful that some people have invested a lot of time into hacking some kind
of HOF facility into C++ (c.f. the Boost Lambda Library).
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.
Prefer pass-by-reference above all other kinds, because its cognitively
efficient and usually execution efficient.
"Usually" being the operative word. You're also missing the OP's point
completely. If you pass by reference, you enormously increase the
complexity of your memory management code. Sure, C++ has lots of ways to
encapsulate this complexity, but you still have to deal with it, and the
common methods of doing this amount to using a buggy and rather inefficient
GC.
Alex
Phlip wrote:
"Neo-LISPer" <ne********@yahoo.com> wrote in message
news:87************@yahoo.com... Hey
Recently, I researched using C++ for game programming and here is what
I found:
As other industries using C++ - even for highly graphical, rich-content
physics simulations - report fewer of these problems, the game programming
culture itself might be to blame.
C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
The alternative, garbage collection, tends to corrupt memory too. Have you
heard of a high-availability Visual Basic program?
Game programmers need efficient and deterministic garbage collection. If
they don't code it themselves, following healthy styles, they will corrupt
memory.
Unsurprisingly, there is a very high failure rate among projects using
C++ for modern game development.
That's because there's a high failure rate period, and most games use C++.
You can not even change function definitions while the program is
running and see the effects live (the ultimate debugging tool).
There are those who don't need to debug. The game programming industry has
only begun to adopt unit testing in a very few shops.
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.
Test isolation would help that. If objects are decoupled, you can write a
test that plays with only one of them.
Playing with unit test cases, and adding them very easily, is a great way
to preserve all those little experiments, and convert them into
constraints.
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.
Then don't use the static type system.
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.
You make that sound like a bad thing. Most programs have two languages
(consider the glorious union of VB and SQL). Games need a scripting layer
to decouple designing the game play from its engine. Most other
applications with an engine use this model, too.
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.
So what? It also makes the Prototype Pattern a pain in the nuts. These
issues are not in the domain, they are just implementation alternatives.
C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.
So, uh, use the scripting layer?
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.
It sounds like you need to tell us you are less than perfectly adept at
C++. Have you used it for games?
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.
That's because you are familiar with Lisp.
Constructors and smart pointers make it hard to tell cheap operations
from expensive ones.
All cheap and expensive operations are impossible to predict and hard to
tell apart. Profile.
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.
Prefer pass-by-reference above all other kinds, because its cognitively
efficient and usually execution efficient.
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++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
disturbs me most.
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.
How could that complaint be specific to C++?
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.
That's because educating someone to write low-risk C++ is difficult.
Vendors have clogged our markets with low-quality languages that purport
to allow inept programmers to write code at a lower risk than C++
provides.
Games must have high performance, so C++ is the leading language for now.
JKop <NU**@NULL.NULL> writes: Ignorance? Arrogance maybe? (no pun intended)
Ignorance and arrogance are the best of friends.
As for the issues raised being truly something you need to know
about... do you need to tell a child not to eat its own excrement?
No. Why? It figures that out for itself. If you're writing code and
you have "new" all over the place and you've no "delete"'s, then
you'll figure out the aim of the whole "Garbage Collection" ideal. I
myself am not retarded, so I've no need for "Garbage
Collection". If, hypothetically speaking, I forsaw that I would
temporarily become retarded (a golfclub to the head maybe), then I
would make use of auto_ptr, but that has yet to happen.
I'm sorry, but it is quite obvious that you are ignorant of many
aspects of memory management. I'd recommend you find any introductory
book on the subject and read it.
[comp.lang.lisp and comp.games.development.programming.misc trimmed
from recipient list.]
--
Frode Vatvedt Fjeld
JKop wrote:
<snip> 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.
<snip>
Actually, it tends to indicate that one version returns a non-const
pointer/reference and the other returns a const pointer/reference.
[Followups trimmed]
Stewart.
Neo-LISPer wrote: 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.
<snip> 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.
Yes I can. I can write a module that runs one or two functions from the
project as the whole program.
<snip> 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.
<snip>
I guess the answer is: if you can't find anyone to join your C++ team,
start your project in a language that everyone likes.
Have you checked out D? It addresses a handful of your issues.... http://www.digitalmars.com/d/
Stewart.
> 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...
I don't want to feed the troll, but you're showing some pretty incredible
ignorance. Just go to the "success stories" section of any lisp vendor's
website if you want to find some examples of real applications written in
lisp.
LISP 3D-Engines: None that I know of, I expect there's one or two.
LISP kernels: Plenty. Google for "lisp machine".
LISP device drivers: Same as for kernels.
LISP numerical toolkits: Probably they exist; don't know of any. This is
just a library issue.
Alex
Hendrik Belitz wrote:
Catalin Pitis wrote:
"JKop" <NU**@NULL.NULL> wrote in message
news:o9*******************@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...
Neo-LISPer wrote:
<snip>
Yes, it does suck -- however it sucks a lot less than a majority of the other
available languages.
If you ever decide to come out of your cave and re-join society in a beneficial
manner, you should probably consider thoroughly studying the topic of languages
and posting a comprehensive comparison of them w/ respect to a particular
task/topic (such as game programming).
Phlip wrote: C++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
disturbs me most.
stroustrup probably meant to put that in, but there would have been way
to many issues with null mind pointers.
indi >> Come to think of it, what *wasn't* written in C++?
Pretty much everything worthwhile.
Retard.
-JKop
In article <41********@duster.adelaide.on.net>,
"Maahes" <ma****@internode.on.net> wrote: 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.
Post the C version (or just give a fuller spec) and I'll try it in Lisp.
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...
I wonder which Lisp you were using. The modern Common Lisp has all kinds
of ways to iterate, some simple, some complex, and one (LOOP) which is
effectively a built-in iteration mini-language. So no one is forced to
do recursion, and many Lispniks frown on it style-wise if an iterative
approach would work.
Recursion takes a while to get the hang of, but not long and then it can
be quite elegant.
kenny
Neo-LISPer wrote: Hey
Recently, I researched using C++ for game programming and here is what
I found:
[Snip -- This section already commented on by others elsethread.]
It is my opinion that all of the above makes C++ a very bad choice for
commercial game development.
It is your opinion and you are welcome to it.
My observation from watching shows on video games is that there
are only a handful of different types. My guess is that the
engine is written in some language, Pascal, C++, Lisp, and
each "level" is written in a higher level language. Once the
engine is working, they don't change it. Most of the changes
are made using the higher level language. A video game project
doesn't want its time wasted in coding up each level in C++,
C, Pascal, Ada or whatever. A less time-consuming method is
to write each level using a higher level language. Many
game shops have specialized languages for their engines.
Perhaps you need to learn that the choice of the language
is not the issue. The issue is the quality of the product
that one can produce using the given language. If the
shop dictates that assembly is the language, then the
company must produce the best quality product using
assembly. In many shops, there is no choice on which
language can be used. You use their language and live
with it.
So if you are independently developing games, then by
all means, use the language you are most comfortable
with. However, do the rest of us a favor and keep
your opinions of other languages to yourself. The
issue of the "best" language for a given project is
and will always be a religous issue.
--
Thomas Matthews
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq: http://www.comeaucomputing.com/learn/faq/
Other sites: http://www.josuttis.com -- C++ STL Library book
Neo-LISPer wrote: Hey
Recently, I researched using C++ for game programming and here is what
I found:
While I personally prefer Lisp for my side projects, C++ is not an
absolutely horrid language for game development. It is definitely much
better than C; overloading operators and templates allow a "weak man's
macro system" and virtual functions provide some much-needed dynamicness.
C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
Why must both sides of the garbage collection debate go to such extremes?
Pro-garbage collectors say that garbage collection prevents all resource
leaks. I know that this is not true as I have seen many resource
"leaks" occurring because the programmer forgot that some part of the
code would hold a reference to some data.
Anti-garbage collectors say that garbage collection is fast, but with
unreliable slowdowns. While this is true, I have found that in
application development, the slowdown is not noticeable at all. I view
arena allocation and deallocation as a more game-centric garbage
collector, which works quite well in many games.
On the whole, I find that I rarely need garbage collection in my
programs. But when I do need garbage collection, I *really* need it. I
think Lisp is right here to default to the more general solution
(garbage collection) unless you explicitly tell it otherwise.
Unsurprisingly, there is a very high failure rate among projects using
C++ for modern game development.
There is a very high failure rate among modern game development
projects, period. I don't think this has as much to do with the
programming language as it does with insane schedules/no real
direction/increased expectations. This is improving. Supposedly.
That doesn't mean that using a more high level language wouldn't speed
up development -- it would.
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.
A REPL debugging mechanism allowing function definitions is extremely
cool. If it had an integrated unit-test tester, that would be super
good. It's so good that I find myself implementing a half-assed REPL
test loop for any language which doesn't have a built in one. In C++ it
looks like this:
void functionToTest( int a, string& b );
int main() {
int a;
string b;
while( true ) {
BKPT();
functionToTest( a, b );
}
}
Every reasonable debugger will let me change the values of a and b.
It's a Read, Eval, Print Loop with out the Reading. :P
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.
I can't comment on this one way or the other, as I only have a few
months experience with Lisp. My guess is that the implicit interface
will prove similarly difficult to modify with Lisp as the static type
system does with C++.
Any eXtreme Programming Lispers or C++-ers care to comment?
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.
This is a very valid point. Game logic is one of the most obvious
applications of a REPL and function redefinition at runtime, which is
why many games use a language such as Python that supports such
features. As stated above, this is a great feature for *any* part of
development.
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.
Really? I find that function object emulate higher order functions
extremely well. It would be nice if the dispatch on them could be
either static (using templates and overloading) or dynamic (using
virtual functions), but it's simple to create such a library.
The main problem I have with function objects is that writing a separate
class is distributing logic in a way that's both confusing and annoying.
I should not have to write a separate class for this one function when
all the logic for that class is available to the compiler.
I already know about Boost.Lambda and I have found it to be impossible
to use. Every time I make a little change in my lambda function, I get
tons upon tons of errors. I last tried to use Boost.Lambda about a year
ago; has it improved its usability?
C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.
I assume you are thinking about closures like cl-ppcre uses. While this
is doable in C++ using template meta-programming, it's so convoluted to
not be usable. C++ really needs a macro system like Lisp's.
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.
A better macro system would help here again. I know that I'd much
rather write:
DEF_ACCESSOR( int foo(), { /* code */ } );
than
int foo_impl() const { /* code */ };
int foo() const { return foo_impl(); }
int foo() { return foo_impl(); }
The first is just more to the point.
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.
I have no idea what you are saying here. Can you give an example of a
problem where the solution in Lisp is much more visual than in C++?
Constructors and smart pointers make it hard to tell cheap operations
from expensive ones.
Any language with flexible abstractions is going to have this problem.
Can you tell me if foo() is faster or slower to execute than bar(a,b)?
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.
See above for my feelings on garbage collection.
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.
I agree here as well. C++'s syntax is awful, and its deduction rules
are even worse. This made Boost.Lambda to be such a pain to use. A
good macro system would help here as well.
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.
As stated before, macros would be nice. Unlike template meta
programming, I find that quasi quotation macros make sense.
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 seems to be quite easy to find good programmers for C++ projects.
It's hard to find great C++ programmers; the kind that think outside the
proverbial box. Lisp seems to encourage such thinking by its very
nature of being a programmable programming language. They're there, but
they are also much more rare.
If this is a good or bad thing is left to the company
It is my opinion that all of the above makes C++ a very bad choice for
commercial game development.
Since you stated many strengths of Lisp, it is natural that on most of
these statements, Lisp is better. On the whole, Lisp and C++ are very
similar (except with regards to macros), Lisp and Python/Java/C#/your
favorite dynamic language even more so. Lisp and C++ just take
different approaches to what the default assumption should be:
Lisp tries to assume the most general, and let the programmer specify
specifics when the generic solution is too slow. Lisp prematurely
pessimizes.
C++ tries to assume the fastest possible thing, and let the programmer
specify generics when needed. C++ prematurely optimizes.
So which is worse? Premature optimization is the root of all evil, but
premature pessimization is the leaf of no good. I prefer to start with
the general case and then optimize the hell out of it if needed, but
other programmers differ.
-- MJF
JKop schrieb: While I agree that the OP was trolling by posting his article to
c.l.c++, it is still my opinion that he was in many parts correct and
the "inspired" response was nothing but a display of complete
ignorance. Many of the issues raised by the OP are truly something you
need to know about (if you don't already), regardless of which
programming language you prefer, IMHO.
Ignorance? Arrogance maybe? (no pun intended)
As for the issues raised being truly something you need to know about... do
you need to tell a child not to eat its own excrement? No. Why? It figures
that out for itself. If you're writing code and you have "new" all over the
place and you've no "delete"'s, then you'll figure out the aim of the whole
"Garbage Collection" ideal. I myself am not retarded, so I've no need for
"Garbage Collection". If, hypothetically speaking, I forsaw that I would
temporarily become retarded (a golfclub to the head maybe), then I would
make use of auto_ptr, but that has yet to happen.
Isn't great how we're all entitled to our own opinions! ;-P
-JKop
Garbage Collection is not just for the retarded -- it becomes sort of an
requirement when dealing with lock-free collections, for example. And
you are wrong to believe that your programs won't leak memory just
because you aren't retarded.
Regards
"JKop" <NU**@NULL.NULL> news:aV*******************@news.indigo.ie... C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
AKA Retarded mode.
With C++ you can't vary safe/fast mode on per function or per line
basis.
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.
Actually, you can change program during execution (at least in VC++
7.1) however in half of cases you have to stop and recompile 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.
Than cut and add "main()" to another file and stop/start program each
time ??? In Lisp you can share intermediate data between small
portions of the program.
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.
You forced to think of types all time. It's kind of unnecessary
foresight in many cases.
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.
You have to use interpreter for scripting. Hardly It would be
interpreter of C++.
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!
Really? IMHO they are very limited imitation of closures.
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.
I.e. C++ self-reflection sucks.
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.
So "cut and paste" technology is used all time ;-))
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).
It means that on Lisp you can easily try current piece code to see it
does well and write another small piece. In C++ you forced to write as
much as possible before you start visualize results (maybe because
"edit and continue" doesn't work properly?).
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);
From MSDN:
"The auto storage-class specifier declares an automatic variable, a
variable with a local lifetime. It is the default storage-class
specifier for block-scoped variable declarations
An auto variable is visible only in the block in which it is declared.
Few programmers use the auto keyword in declarations because all
block-scoped objects not explicitly declared with another storage
class are implicitly automatic. Therefore, the following two
declarations are equivalent:
// auto_keyword.cpp
int main()
{
auto int i = 0; // Explicitly declared as auto.
int j = 0; // Implicitly auto.
}
"
Is that automatic memory managment ???
Reference-counting schemes are usually slower than modern garbage
collectors and also less general.
Which "garbage collector"? "less general" = vague bullshit.
What's the difference ??? Anyway reference-counting is slower than
modern generational GCs.
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.
It means no macro. C preprocessor and templates is hardly comparable
with Lisp macro.
C++ programs are slow: even though the compilers are good at
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++?
You are mistaken: MS-DOS and Linux were not written in C++ (maybe
because C++ compilers at that time were very buggy). And also very
doubtful that Windows XP core was written in C++.
Many many things were not written in C++.
Lisptracker
JKop wrote: Come to think of it, what *wasn't* written in C++?
Linux comes to mind.
Really? What was it written in?
-JKop
C and assembly. Look at the source for it.
And I don't think MS-DOS could've been written in C++, wasn't that before
C++ was around?
"Neo-LISPer" <ne********@yahoo.com> wrote in message
news:87************@yahoo.com...
Personally, I couldn't care less! What're you trying to accomplish, change
someone's mind? No, you're just trolling. So get lost, and let us do some
real work.
-Howard
"Joe Laughlin" <Jo***************@boeing.com> writes: And I don't think MS-DOS could've been written in C++, wasn't that before
C++ was around?
The first native C++ compiler I used under DOS was Zortech C++. This
must have been around 1988/1989.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Neo-LISPer" has been quoting the "Mike Cox" known-troll in his sig in
some previous postings to comp.lang.lisp [1] I gave him the benefit of
the doubt for a few posts, but that might tell you where he's coming
from if you've encountered "Mike Cox" trolling before. For some reason
"Mike Cox" started attempting to troll comp.lang.lisp a while back,
too, it's even possible Neo-LISPer and Mike Cox are the same person.
Note that it may more innocent (even if it is Mike Cox!), could be just
the overenthusiastic lisp newbie effect (no one more zealous than the
recently converted) - if so, then, Neo-LISPer, please don't do that.
Two wrongs don't make a right [2].
I urge people in both language communities to write games in whatever
languages they bloody well feel like, and to not feed the trolls. Like
I probably just did by posting this. Gaah.
[1] http://groups.google.com/groups?q=gr...hoo.com&rnum=1
[2] See recent silly "Why Lisp Sucks for Games" thread on comp.lang.lisp
caused by an article by someone self-identifying as a microsoft c++
programmer and apparently feeling some compulsion to attack (somewhat
poorly) the use of lisp in games. Or, better, don't...
Florian Bachmann posted: JKop schrieb:While I agree that the OP was trolling by posting his article to
c.l.c++, it is still my opinion that he was in many parts correct and
the "inspired" response was nothing but a display of complete
ignorance. Many of the issues raised by the OP are truly something you
need to know about (if you don't already), regardless of which
programming language you prefer, IMHO.
Ignorance? Arrogance maybe? (no pun intended)
As for the issues raised being truly something you need to know
about... do you need to tell a child not to eat its own excrement? No.
Why? It figures that out for itself. If you're writing code and you
have "new" all over the place and you've no "delete"'s, then you'll
figure out the aim of the whole "Garbage Collection" ideal. I myself
am not retarded, so I've no need for "Garbage Collection". If,
hypothetically speaking, I forsaw that I would temporarily become
retarded (a golfclub to the head maybe), then I would make use of
auto_ptr, but that has yet to happen.
Isn't great how we're all entitled to our own opinions! ;-P
-JKop
Garbage Collection is not just for the retarded -- it becomes sort of
an requirement when dealing with lock-free collections, for example.
And you are wrong to believe that your programs won't leak memory just
because you aren't retarded.
Regards
Perhaps. But I've been right thus far.
-JKop
JKop wrote: Ignorance? Arrogance maybe? (no pun intended)
As for the issues raised being truly something you need to know about... do
you need to tell a child not to eat its own excrement? No. Why? It figures
that out for itself. If you're writing code and you have "new" all over the
place and you've no "delete"'s, then you'll figure out the aim of the whole
"Garbage Collection" ideal. I myself am not retarded, so I've no need for
"Garbage Collection". If, hypothetically speaking, I forsaw that I would
temporarily become retarded (a golfclub to the head maybe), then I would
make use of auto_ptr, but that has yet to happen.
Depending on the amount of memory and the size of each allocated block
garbage collection can be faster, or manual handling can be faster. If
you have many small to medium sized objects then garbage collection is
faster, otherwise not so. Copious amount of research exist. Start
some where around here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
Retarded? It has nothing to do with being retarded. Sometimes the
requirements of a program is such that you cannot predict when a
resource can be freed without designing this into your program
(I can't really think of many examples where this is not the case)
and that can be hard. When GC can sometimes even make your program
faster... No brainer. (And for the reading impaired, I am not
saying... Nah, figure it out yourself)
--
Thomas.
"Neo-LISPer" <ne********@yahoo.com> wrote in message news:87************@yahoo.com...
[snip]
don't feed the troll!
JKop <NU**@NULL.NULL> writes: 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.
By any reasonable standards, C++'s type system is a brain-damaged
throwback to the 1960s. Much better static type systems can be found
in languages like Haskell and ML. Hell, there's even an assembler with
a better type system: http://www.cs.cornell.edu/talc/ 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!
Yeah, and with just a bit more typing, you've got yourself a Turing
machine. You can do anything you want in C++, so why would you ever
want to switch to a better language? 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.
Where do you think the word "function" comes from? It comes from
mathematics, where it has a very well-defined meaning and certain very
well defined properties. One of these properties is that for any
input, it always returns the same output. This particular meaning has
been universally adopted by the computer science community. In almost
all languages (Miranda and Haskell are the only two exceptions I
know), what you call "functions" are actually procedures or
subroutines, in that they can return different outputs for the same
input. This includes pseudo "functional" languages like ML too, since
it has assignment, references and mutable arrays.
Vladimir
Petter Gustad wrote: "Joe Laughlin" <Jo***************@boeing.com> writes:
And I don't think MS-DOS could've been written in C++,
wasn't that before C++ was around?
The first native C++ compiler I used under DOS was
Zortech C++. This must have been around 1988/1989.
Petter
And MS-DOS was first written in the early 80's.
<snip crap>
LOL, you're hilarious. Stop researching and write a game, then tell us what
you should write it in.
WTH
"Joe Laughlin" <Jo***************@boeing.com> writes: Petter Gustad wrote: "Joe Laughlin" <Jo***************@boeing.com> writes:
And I don't think MS-DOS could've been written in C++,
wasn't that before C++ was around?
The first native C++ compiler I used under DOS was
Zortech C++. This must have been around 1988/1989.
And MS-DOS was first written in the early 80's.
That was my point...
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad <ne***********@gustad.com> writes: And MS-DOS was first written in the early 80's.
That was my point...
I don't know what Tim Paterson used when he wrote the original QDOS in
6 weeks in 1980, but I very much doubt that it was C, which I think
was still a rather experimental thing used by strange cult of unixists
at that point.
--
(espen)
Petter Gustad <ne***********@gustad.com> writes: And MS-DOS was first written in the early 80's.
That was my point...
I don't know what Tim Paterson used when he wrote the original QDOS in
6 weeks in 1980, but I very much doubt that it was C, which I think
was still a rather experimental thing used by the strange cult of
unixists at that time.
--
(espen)
In article <87************@yahoo.com>, ne********@yahoo.com says... Hey
Recently, I researched using C++ for game programming and here is what
I found:
[snip]
What is it about Lisp that makes novices fall in love with it? They
don't actually *produce* anything with it, mind you, but they insist on
telling the world how superior it is to every other language.
Dude, write a good game in Lisp and that will impress us a lot more than
a load of blather about how C++ is unsuitable for game programming. The
thing is, we use C++ for game programming, so we know whether it is
suitable or not. We've even seen a few games in our time that are
written in Java, Delphi, Flash or VB. But from the Lispers, all we see
is the same old hot air...
- Gerry Quinn
>> 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.
Post the C version (or just give a fuller spec) and I'll try it in Lisp.
:) It was 15 years ago so I only have the vague memories and impressions
left...
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...
I wonder which Lisp you were using. The modern Common Lisp has all kinds
of ways to iterate, some simple, some complex, and one (LOOP) which is
effectively a built-in iteration mini-language. So no one is forced to
do recursion, and many Lispniks frown on it style-wise if an iterative
approach would work.
Well, sounds like its probably very different to the lisp we used 15 years
go. All we could seem to do is have lots of brackets with calls to functions
embedded..
2*(5+Speed)+Velocity
looked something like:
(+ (* 2 (5 Speed +)) Velocity)
Recursion takes a while to get the hang of, but not long and then it can
be quite elegant.
kenny
Didn't we switch from coal to oil yyeeaarrss ago?
Most powerplants run on Coal still (and some crazy countries use Nuclear).
I think oil is just used for cars and trucks and gays.
-JKop
Maahes wrote: Didn't we switch from coal to oil yyeeaarrss ago?
Most powerplants run on Coal still (and some crazy countries use Nuclear).
I think oil is just used for cars and trucks and gays.
Many run on natural gas.
Note followup.
Paul
Read all that. Understand your gripes, but that's not C++, that's how you
use it.
We've done 8 projects in C++ and never had a failure. And that's on
cross-platform consoles (Gamecube, ps2, xbox, pc) where you cannot have a
crash or significant bug or you can't release the game.
If anyone else has failures, I doubt its because of C++. I have noticed
that some C++ coders have the worst habits of overcomplicating simple
problems that I've ever seen. Again, not C++'s fault, though templates,
references, constructors and inheritance makes it easy to write code that is
unreadable without a debugger.
To stop from failures, we restrict usage of C++ to as simple as possible. We
have our own memory management systems that are far better than garbage
collectors because they don't fragment memory at all, which is critical on a
console because you can't afford to run out of memory due to unforseen
fragmentation.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Peter Lewerin |
last post by:
peter.lewerin@swipnet.se (Peter Lewerin) wrote
> There is a paradigm
> difference between CLOS and non-OOP Lisp code, but the language is the
> same, and it's quite possible to mix the two.
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
