C++ sucks for games

[Szymon]

[.....]

As for language benefits: garbage collection, macros, special variables,
untyped variables/typed data; the list datastructure; multimethods,
editing-with-parentheses (shocked?); multiple-inheritance done right;
the meta-object protocol; lexical scoping; closures; first-class
functions; lack of syntax; native-compiled speed; reflection ala RTTI;
the loop macro; &rest, keyword and optional arguments to functions;
different kinds of method combinations; destructuring-bind (long
story);...

modules,

exeption system,

compiler macros,

reader macros,

customizable pretty printer,

multiple values,

*DEBUGGER-HOOK*,

(COMPILE NIL --code--),

SERIES,

enviroment manipulation (via AUGMENT-ENVIRONMENT),

extensible (Gray) streams,

.... and GO


Regards, Szymon.

 

[Frank Buss]

Noone said that such a thing is not possible in a turing complete
programming language. We are discussing about how complicate Lisp is,
because you usually don't write 10*3+4 but (+ (* 10 3) 4). If this is
complicated, what is foo(+, 10, 15) in that case?

a nice example I've wrote some months ago to compare C++ and Lisp. The
C++ version:

template <class T>
struct SquaredSum {
T operator()(const T& sum, const T& next) const {
return sum + next * next;
}
};
typedef vector<double> DoubleVector;
DoubleVector v;
v.push_back(-1.2);
v.push_back(0.99);
v.push_back(23);
DoubleVector::value_type length = accumulate(v.begin(), v.end(),
DoubleVector::value_type(0), SquaredSum<DoubleVector::value_type>());
cout << sqrt(length);

The Lisp version:

(reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23)))

 

[Christer Ericson]

[...]
If I feel the need to learn and use Lisp I will do so. So far I don't
see any good reason to interest myself in it.

How about learning it in order to perhaps get a clue about
what you're talking about. (I realize it's a novel thought
for you, but you really should try it some time.)


Christer Ericson
Sony Computer Entertainment, Santa Monica

 

[Frank Buss]

The Lisp version:

(reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23)))

sorry, is a bit longer

(sqrt (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23))))

But the C++ version is longer, too, because I've omitted all the includes,
"using namespace std" and the main-function.

 

[Christer Ericson]

[...]

No disrespect to Naughty Dog.. Awesome engine and excellent game produced
from it...
but it did take them 3 years to make the game...
That's a luxury most of us console developers don't have.

The development of the engine was staggered with production
of previous (PS1) games. As all smart production is done.

The game itself didn't take three years. Most (non-sequel)
PS2 games take about two years, so I don't see them having
any more time than any other developer.

In 20years of writing games, Naughty Dog is the first company I've seen to
make a top game from Lisp, and I'd say thats because they have top
programmers and designers who could have made the same game in C if they had
applied the same algorithms... and it might have been made in less than 3
years...who will ever know?

Several top games, even.

And, pray tell, why would "top programmers [...] who would
have made the same game in C if they had applied the same
algorithms" _deliberately_ reject C for a Lisp-based language
to write their games?

Anyway, that's not important.

The key point here is that the reason companies don't switch
from C/C++ to Lisp (or any other language) just like that,
is because there are so many other aspects to things than
just the language.

C/C++ has a critical mass, meaning it's easy to find compilers,
development environments, other tools, programmers, etc.

When comparing C/C++ to the superior, but less mainstream
language X (where X might be Lisp or whatever you want),
you have to weigh the benefits X beings against its
drawbacks.

Most companies are afraid of the drawbacks -- which is
perfectly reasonable -- which is why we see 99.5% or so
of all games being written in C++.

That does not mean C++ is better as a _language_ for
game development. It might mean it is a better _choice_
of a language for game development (given the constraints
the company is working under). These are different things.

If all other things were equal and the choice stood
between C++ and a language X that is arguably better,
it would be a no-brainer for me to instigate our studio
switching to language X for development. However, all
other things aren't equal and even though there exists
several languages X better than C++, we already have
a large investment in existing C++ code that we cannot
justify the costs of switching.


Christer Ericson
Sony Computer Entertainment, Santa Monica

 

[Hartmann Schaffer]

...
<QUOTE>
While he called his Lisp techniques and programming practices
"revolutionary," others referred to them as "code encryption," since
only he could understand them. [--] Also, it took over a year to develop
the compiler, during which time the other programmers had to make do
with missing features, odd quirks, and numerous bugs.
</UNQUOTE>

I'm not hearing the touted benefits of Lisp here, folks. Here are some
briefer excerpts from 'What went wrong' - I'm sure you can put some spin
on them to say it's not really Lisp's fault, just the fault of the big
bad horrible world that doesn't love Lisp, or re-writes Lisp programs in
different languages as part of the big plot to keep it down:

"even now C++ has some advantages over GOAL...the compiler would be
unresponsive until the process had completed, sometimes taking as long
as 15 minutes...One of our greatest frustrations and loss of
productivity came from our slow turnaround time in making a change to a
level or animation and seeing that change in the actual game."

I'm not hearing the touted benefits of Lisp here. Correct me if I'm
wrong, but according to many posts in this thread, isn't Lisp supposed
to be the magical wand that fixes things like the above?

reading the points you quoted, they boil down to two arguments:

1. the programmer who considered it "code encryption" weren't familiar
with the language and either lazy or slow learners

2. they used a tool that was still in development

now imagine a post mortem from programmers who were unfamiliar with
C/C++ on a project were the C/C++ compiler is written while they develop
the product. do you think it would be any different?

...

hs

 

[JKop]

Kelsey Bjarnason posted:

[snips]

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.

To hand-hold people who aren't bright enough to free memory they no
longer need?

Is that directed toward myself? If so, then that's exactly what I've
been arguing.


-JKop

 

[JKop]

A question:


Why do people still talk about C?


As far as I'm aware, C++ is and can do everything that C can do, but has
more features. Would anyone be able to inform me of any reason why
people still programme in C, or why they even talk about it?


-JKop

 

[Szymon]

[.....]

and type system... (DEFTYPE & stuff)

..

 

[Paul Foley]

A question:

Why do people still talk about C?

As far as I'm aware, C++ is and can do everything that C can do, but has
more features. Would anyone be able to inform me of any reason why

Yes. Obligatory car analogy: C is a Ferrari. C++ is a Ferrari with
helicopter rotors, 18" naval guns, and those 8 foot diameter wheels.

people still programme in C, or why they even talk about it?

For one thing, you can link to it from other languages without wanting
to tear your hair out.

 

[JKop]

Paul Foley posted:

Yes. Obligatory car analogy: C is a Ferrari. C++ is a Ferrari with
helicopter rotors, 18" naval guns, and those 8 foot diameter wheels.

While I understand the intention of your analogy, still...

It's incorrect in that, if one were not to make use of the 18" navals guns
or of those 8 foot diameter wheels, then the mass of these extra objects
would act as a hinderance for the vehicle: A greater force would be needed
to accelerate and deccelerate the vehicle.

While... with C++ ( comparing it to C ), the extra features in no way
hinder. So if I were to expand on your original analogy:

C is a Ferrari. C++ is a Ferrari with helicopter rotors which increase the
Ferrari's mass by 0, and its volume also by 0, also it has 18" naval guns
and 8 foot diameter wheels which increase both its mass and volume by 0.

For one thing, you can link to it from other languages without wanting
to tear your hair out.

Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
code) ?

Would this not be adequeately achieved with:

extern "C" {


?

-JKop

 

[Alex Gian]

Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...

If the syntax of "(+ 2/3 2/3 1/3)" confuses you, then I expect you will
have massive problems when you encounter C++'s templates, parameterized
types, and STL!!

But I expect those are pleasures that still lie in store for you!
For instance, cam you understand the following easily?
It's just a random snippet from yesterday's std C++ list.

template <typename E, typename T>
friend std::basic_ostream< E, T>& operator<<
( std::basic_ostream< E, T>& os, const A& obj)

If you can, but still experience difficulty with "(+ 2/3 2/3 1/3)", then
I expect you have a mind that works in a very interesting way....

 

[Computer Whizz]

Fair enough.

Anyway, this is a nice counter example to the (rather outrageous, IMO)
claim that C++ has a natural syntax. You write 1/2 and it actually
means... zero.

Personally I find 1/2 against natural writing (at least in maths).
I put everything above a /2 ...
So the equation would be: (a*sqr(t)+v*t)/2
Although I come from a BASIC background and don't know about the / in C++ .

 

[Computer Whizz]

same in C:
f(xy, z);


André

In C you'd get a type mismatch or the fact that the correct parameters
aren't passed... But if there's a variable named xy that's passed to a
function with variable... I'll just stop myself there shall I...
"...and if we went to the moon and back, and added 3 to the square root
of..."

I'll just say that I find C syntax easier to use and that's that.

 

[Andreas Krey]

* JKop ([email protected])
....

While... with C++ ( comparing it to C ), the extra features in no way
hinder.

a) So what. Why use a tool with loads of extra features that
simply aren't used?

b) There are some parts that *do* hinder and make C code not
compile as C++.

....

Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
code) ?

You seem not to have understood what they are.

Andreas

 

[Computer Whizz]

Yes, that's right. However, they are still not so easy accessible like the
infix operators in our earlier discussions. Therefore complex numbers
would need to be included in the base language. If you need them for just
one part in your program, then do this in C++:
(+ #C(3 4) 25)

Just look at the example program on the site you posted.

Have fun


André

True, C++ does have some missing things from it's "base" language (Oh how I
sorely missed strings at first glance when I first tried C++)...
But I did get to realise about using chr[] and chr* quite soon, and then
including the <string> library.

I read a bit on that D programming language mentioned somewhere, about
complex numbers being much easier to use - and indeed it seemed so.

And no - the trouble with Lisp to begin with is trying to find the "core" ()
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.

So before I pass out - I shall post this message and retire.

 

[JKop]

Andreas Krey posted:

* JKop ([email protected])
...

a) So what. Why use a tool with loads of extra features that
simply aren't used?

So if I tell you that you can also use a pen as a stabbing weapon, are you
suddenly not going to use it to write anymore based upon the premise that is
has an extra feature that isn't used?

b) There are some parts that *do* hinder and make C code not
compile as C++.

Just as how Delphi code won't compile as C++ code.

Pick a language, C or C++.

I see no reason whatsoever to not choose the latter which evolved from the
former.

If tomorrow a new programming language were to come out called "C+=2" or
"D" (yes, I know this name is taken!), then I'd abandon C++ in a heartbeat
in favour of its "latest evolution".

But for the foreseeable future, it doesn't look like C++ will change its
name. It looks like we'll just have Standard 1998, Standard 2003, and so
on...

People still programming in C is like a C++ programmer writing 1998 Standard
code -- it's been superseeded.


So I'm wondering, why do people write C code today, October 29th 2004?

...

You seem not to have understood what they are.

What *what* are?


-JKop

 

[Greg Menke]

In C you'd get a type mismatch or the fact that the correct parameters
aren't passed... But if there's a variable named xy that's passed to a
function with variable... I'll just stop myself there shall I...
"...and if we went to the moon and back, and added 3 to the square root
of..."

Its not clear what would happen. Does f() have a declaration? Is xy
a variable or a function? If a function, does it have a declaration?
And what about z?

A Lisp compiler will give a number of warnings about unrecognized
symbols and mismatched/missing parameters in the scenario- without the
need of any additional context that a reader will need to decypher
what a C compiler will do.

I'll just say that I find C syntax easier to use and that's that.

Spend some time with Lisp and you'll find C syntax isn't "easier".
And really, you can't honestly make that statement until you're
familiar with both anyhow.

Gregm

 

[Stefan Ram]

b) There are some parts that *do* hinder and make C code not
compile as C++.

See:

http://david.tribble.com/text/cdiffs.htm

**

To /read/ a C++ program, one has to learn all the features of
C++ that might appear in such a program. "C++ is already too
large" according to Message-ID: <[email protected]> by
Bjarne Stroustrup.

C++ is full of exceptions and special rules. For example, an
initialization "int const v = 7;" is allowed within a class
specifier, while "double const v = 7.0;" is not. In
"std::vector<std::vector<int>> v;" the ">>" is parsed as the
operator ">>". "T t(u);" defines a variable t with type "T"
and initial value "u", while "T t();" declares a function "t".
Now guess, whether "std::vector<int> v(
std::istream_iterator<char>( cin ),
std::istream_iterator<char>() );" defines and initializes an
object "v" or declares a function "v". The type "vector<bool>"
is neither a container nor does it contain bool-objects, while
other "vector<...>"-classes are containers containing the
"..."-objects. To hide an external function from other
compilation units, one might use "namespace { ... }" or
"static", while "static" within a class has a completely
different meaning, and "static" within a function has
still another meaning.

 

[Frank Buss]

To /read/ a C++ program, one has to learn all the features of
C++ that might appear in such a program. "C++ is already too
large" according to Message-ID: <[email protected]> by
Bjarne Stroustrup.

[...]

but this was a statement from 1993:

http://groups.google.com/groups?as_umsgid=<[email protected]>

I don't know the details of the C++ standard, some things might be better
in the current standard.