C++ sucks for games

[Steven E. Harris]

I think in part I was misled by your use of the term 'class method'
for what in a purely C++ context would usually be called a 'static
method'.

You must mean "static member function." The word "method" never occurs
in ISO/IEC 14882:1998(E) in reference to any kind of function.

 

[Kenneth Tilton]

Team programming in Lisp is eminently doable. I worked on four sizeable
team projects using Lisp for development:

1. GATE was a three-person, two year project that developed a
knowledge-based, network-aware automated testing system that was used to
find hundreds of pre-release bugs in Mac System 7. It was written in
Common Lisp.

2. The unnamed first version of the Newton operating system was a
60-person, four year project written mostly in Ralph, a Lisp dialect that
later evolved into the Dylan language. (The Dylan compiler and IDE were
written in Common Lisp.)

3. Bauhaus was the second Lisp-based version of the Newton operating
system, also written in Ralph (a third version, written in C++ and
NewtonScript, and chosen for non-technical reasons, was the one shipped).
It was a five-person, two-year project.

4. SK8 was a 10-person, five-year project to develop a general-purpose
multimedia authoring system. It was used to build perhaps a dozen projects
at Apple, some of which were later productized and some of which were
given away to educational projects. SK8 itself was eventually released as
freeware. Sk8 was written in Common Lisp.

None of them were games (though SK8 was used to build several games and
several applications that incorporated interactive video elements).

Cool. I think this thread is being fuelled heavily by the cross posting.
Since it is also in comp.games, you'll get a lot of posts from people like
me that are not satisfied unless we here from someone who has shipped a 10
month project with 7+ programmers on a console title in Lisp.[/QUOTE]

People keep saying that ("show me a game"), but I do not think it makes
any sense. Can one not judge a language just by looking at it and doing
a little programming and reading and googling? This "Sure that's a Lisp,
team project, but it's not a /games/, Lisp, team project!". <g>

By that reasoning, no new language would ever have been adopted. (And,
yes, Lisp is new. <g>)

kenny

 

[chris]

That wasn't intended to be a clever question- I actually didn't know
the answer. I just tested it, and it seems you can. I think I knew
that at some point, but I've not used C++ for some time...

So some of Lisp's object model could be put in C++ terms like this;
Create a class with no member functions and all member variables
public. Then create overloaded functions for each class the call
should be applicable to.

Lisp has rules for arranging the correct ordering of calls in
situations where the derivation tree of a class yields multiple
overloaded functions, which may not be present in C++, so that part of
the question might still cause some trouble.

Also, in defence of lisp, while you could overload all the functions
outside of class definitions these functions will not be "virtual". For
example say that we have a class A from which we have derived B,C and D.
If I have a variable of type A* (so pointer to type A, which could
actually point to type A,B,C or D) and a function grab(A*) which you
want to overload for each of A,B,C or D then I don't think this is
possible without some very nasty fiddling (ie you couldn't just define
grab(A*), grab(B*), grab(C*) and grab(D*) and then when you call
grab(thing) where thing is an A* have it go to the approriate grab).

You could do this with nasty rtti, but that isn't really very nice under
C++ and quite error-prone...

Chris

 

[Steven E. Harris]

struct Rabbit
{
Vector pos;
};
Rabbit_Jump(int distance);

No, for equivalence, you'd need something more like

void Rabbbit_Jump(Rabbit* this, int distance);

with the constraint that "this" is nonzero.

 

[mikel]

Cool. I think this thread is being fuelled heavily by the cross posting.
Since it is also in comp.games, you'll get a lot of posts from people like
me that are not satisfied unless we here from someone who has shipped a 10
month project with 7+ programmers on a console title in Lisp.

Also, it doesn't help the case when you here that the version of Bauhaus
that shipped was a C++ version... why would you even consider writing a C++
version when you've already got 2 versions written in Lisp, which is
supposed to be a far better language...

Because a marketing guy sits next to the CEO on a airplane trip and
convinces him that the C++ name is a better marketing tool than an
unknown new Lisp variant whose name is "Ralph".

Since then I've seen similar things happen again. For example, a much
more recent project with which I am familiar was implemented in C++
specifically so that marketing people could cynically explain to
prospective customers that C++ is better and faster than the Java
competition (though, in fact, the implementors' own numbers proved that
was not true).

 

[Christopher C. Stacy]

There are no "member functions" in Lisp, all functions exist outside
the definition of classes. That will sound strange to people only
familiar with the C++ style of OO, but it works very nicely once you
get used to it. [Chris:]

In that case, you could simply write C++ and not use member
functions. Arguing that C++'s member functions don't look like normal
function calls and in lisp they do sounds stupid if in fact lisp
doesn't have member functions.

I think you may have misunderstood Greg. Although it's true
that Lisp doesn't have "member functions", it isn't true that
Lisp is like C++-without-member-functions. If you abandon
member functions in C++, then inheritance becomes impossible.
Lisp's "generic functions" *do* support inheritance.

Ah, sorry. I know a (little) lisp, so I should have realised the point.

I find these lisp vs. C++ discussions fun, but also wonder
if they have any purpose.

No, not really.

 

[Kenneth Tilton]

[Greg Menke:]

There are no "member functions" in Lisp, all functions exist outside
the definition of classes. That will sound strange to people only
familiar with the C++ style of OO, but it works very nicely once you
get used to it.
[Chris:]

In that case, you could simply write C++ and not use member
functions. Arguing that C++'s member functions don't look like normal
function calls and in lisp they do sounds stupid if in fact lisp
doesn't have member functions.
I think you may have misunderstood Greg. Although it's true
that Lisp doesn't have "member functions", it isn't true that
Lisp is like C++-without-member-functions. If you abandon
member functions in C++, then inheritance becomes impossible.
Lisp's "generic functions" *do* support inheritance.

Ah, sorry. I know a (little) lisp, so I should have realised the point.

I find these lisp vs. C++ discussions fun, but also wonder
if they have any purpose.

No, not really.

I discovered CL because someone noticed my thrashing search for A Better
Way (whined about periodically on macdev on CompuServe) and suggested
MCL. "Information. It's all good." (tm) Of course I would not say that
if this had degenerated into a silly flamewar, but it has not.

kt

 

[Peter Lewerin]

(e-mail address removed) (Björn Lindberg) wrote

Not really, because then they would lose all
polymorphism. Ie. overloaded functions can be used to achieve type
dispatch, but the dispatch will not be polymorphic.

Not *all* polymorphism (if it's useful to cast back to the base class,
it will still work) but most of it is lost, yes. My statement was
more of an observation than an endorsement.

 

[Hartmann Schaffer]

class's and methods are just a structural concept. C has structs and if you
wanted to implement a class with methods, its just as easy to do it in C.
Of course, virtuals and hierachy get messier, though still possible.

== C++ ==

class Rabbit
{
Vector pos;

public:
Jump(int distance);
};


== C ==

struct Rabbit
{
Vector pos;
};
Rabbit_Jump(int distance);

are those two really the same? afaiu, with

Rabbit nick;

nick.jump(3)

the rabbit nick gets passed as an implicit argument to the function

hs

 

[Gerry Quinn]

[--]

I am not sure that it actually hints at why it is a bad idea - it does
explain why you think of self-modifying code that other people think is not.
Regarding the "badness" of it well I think there are a number of situations
in real world (not computer games, or at least this is not as important in
computer games) where a significant source of problems (especially when
trying to interpret visual scenes) comes from the inability to precisely
predict the nature of the enviroment in which the programs (in this dealing
with image understanding) are expected to operate. Furthermore even if you
could know all the different states that the enviroment could be in, you
wouldn't know a priori what the state of the enviroment would be in any
particular time. Consequently one (maybe not the only one) way to achieve
robust performace is a program that is capable to determine the state of the
enviroment at runtime and adapt to the enviroment that is found.
"Self-adaptive software" (I think the name was originally introduced in 1998
by a DARPA research project) is a model-based approach to building robust
systems. What happens is that in the real world the lack of adaptiveness is
bad as usually it means only that your program will work brilliantly in the
demo case but not in the actually challenging problems.

Certainly self-adaptive programming (hardware or software) is a valid
tool, and it's generally accepted that the brain uses something of the
kind.

Again, it's not something you insert willy-nilly into ordinary programs.
Self-modifying software is bad generally, not bad always.

With regard to games, self-modifying code probably had its heyday in the
80's, when it was used to insert custom bits of assembly to get the most
out of the slow processors of the day. On the PC, 'compiled sprites'
were common, for example.

- Gerry Quinn

 

[Gerry Quinn]

Claims? What claims? Those are good programmers who answered my survey
by saying they went looking for a better way and found it.

[Followed by some claims by two guys. Guys who may be eminent in the
computing field but whose primary work seems to be writing and
consulting. Guys who therefore have a vested interest in language churn
and silver bullets.]

What exactly did they *build* with their various flavour-of-the-month
languages?

Anybody else's irony meter pinging its glass casing? Lisp, with roots 40+
years old and a decade old ANSI standard being referred to as "flavour of
the month"!

But didn't one of them write about how great and productive Perl was for
a couple of months before he decided it was actually crap and went on to
Python or something?

Again, I don't have a clue what software he developed during these two
months of fevered Perl productivity...

- Gerry Quinn

 

[Gerry Quinn]

Cool. I think this thread is being fuelled heavily by the cross posting.
Since it is also in comp.games, you'll get a lot of posts from people like
me that are not satisfied unless we here from someone who has shipped a 10
month project with 7+ programmers on a console title in Lisp.

Heck, I've only asked for pointers to a few little Windows games or
screensavers similar to my own!

Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers

 

[Svein Ove Aas]

Claims? What claims? Those are good programmers who answered my survey
by saying they went looking for a better way and found it.

[Followed by some claims by two guys. Guys who may be eminent in the
computing field but whose primary work seems to be writing and
consulting. Guys who therefore have a vested interest in language
churn and silver bullets.]

What exactly did they *build* with their various flavour-of-the-month
languages?

Anybody else's irony meter pinging its glass casing? Lisp, with roots
40+ years old and a decade old ANSI standard being referred to as
"flavour of the month"!

But didn't one of them write about how great and productive Perl was for
a couple of months before he decided it was actually crap and went on to
Python or something?

Again, I don't have a clue what software he developed during these two
months of fevered Perl productivity...

The search for something better goes ever on.
Hopefully he'll end up with Lisp eventually, but maybe he's happy as he is.

I had a brief romance with Python myself before I found Lisp, but that means
nothing at this point; I'm *sticking* with Lisp, as, apparently, are
everyone else.

 

[Duane Rettig]

Heck, I've only asked for pointers to a few little Windows games or
screensavers similar to my own!

Check out

http://www.franz.com/success/customer_apps/artificial_intelligence/kurzweil.lhtml

and links.

The mention about use as a screensaver seems to imply that it is
generated statically, and I'm sure that is also possible, but I've
also seen it actually running as a screensaver in the background,
generating new paintings each time.

 

[Michael Sullivan]

3. Bauhaus was the second Lisp-based version of the Newton operating
system, also written in Ralph (a third version, written in C++ and
NewtonScript, and chosen for non-technical reasons, was the one shipped).
It was a five-person, two-year project.

[...]
Also, it doesn't help the case when you here that the version of Bauhaus
that shipped was a C++ version... why would you even consider writing a C++
version when you've already got 2 versions written in Lisp, which is
supposed to be a far better language...

What part of "chosen for non-technical reasons" did you have trouble
understanding?


Michael

 

[rmagere]

Certainly self-adaptive programming (hardware or software) is a valid
tool, and it's generally accepted that the brain uses something of the
kind.

Again, it's not something you insert willy-nilly into ordinary programs.
Self-modifying software is bad generally, not bad always.

With regard to games, self-modifying code probably had its heyday in the
80's, when it was used to insert custom bits of assembly to get the most
out of the slow processors of the day. On the PC, 'compiled sprites'
were common, for example.

Ok so we seem to agree self-adaptive software is not bad per se but it's
application and/or programmer dependent about whether it will increase
or decrease the quality of a given software.

 

[Kaz Kylheku]

Claims? What claims? Those are good programmers who answered my survey
by saying they went looking for a better way and found it.

[Followed by some claims by two guys. Guys who may be eminent in the
computing field but whose primary work seems to be writing and
consulting. Guys who therefore have a vested interest in language
churn and silver bullets.]

What exactly did they *build* with their various flavour-of-the-month
languages?

Anybody else's irony meter pinging its glass casing? Lisp, with roots
40+ years old and a decade old ANSI standard being referred to as
"flavour of the month"!

But didn't one of them write about how great and productive Perl was for
a couple of months before he decided it was actually crap and went on to
Python or something?

Again, I don't have a clue what software he developed during these two
months of fevered Perl productivity...

The search for something better goes ever on.
Hopefully he'll end up with Lisp eventually, but maybe he's happy as he is.

I had a brief romance with Python myself before I found Lisp, but that means
nothing at this point; I'm *sticking* with Lisp, as, apparently, are
everyone else.

People tend to stick with Common Lisp because there is nowhere else to
go without compromising something. Not having access to the source
code as a data structure is a very, very bad hit to have to take, so
that rules out the vast majority of languages.

Before I got into Lisp, I was quite a bit into meta-programming. I'm
one of those guys who used Lex and Yacc countless times. It was hard
for me to complete a project without some custom language being used
in it somewhere.

In Lisp you can just integrate the custom language into the program,
and nobody thinks it's a big deal. Other Lisp programmers accept and
understand what you have done as a matter of course.

You are allowed to think along the lines: how do I extend the language
so that it meets the challenges of my current problem?

After a while, you really get used to this.

Once some great programmer said that no matter what language he works
in, he thinks in just one language.

Programmers who think in Fortran tend to believe that all languages
are basically just syntactic sugars for the same thing. They prove
that to themselves by continously encountering success in testing
their ability to write Fortran in any language they encounter. Lisp
just appears as Fortran with parentheses.

The Lisp programmer's internal language isn't Fortran, with its
imperative statements, loops and variables. The internal language is
an empty abstract syntax tree, to which that programmer is willing to
assign any semantics whatsoever.

When you think that way, then languages which don't let you encode
those semantics just get in your way, because you have to do the
translation of your internal language in your head, and then use your
fingers to spit out the translation. You have to do the tedious job of
the compiler that you are not able to write. In Lisp, you write that
compiler, insert it into your program, and then write in the real
language in which you conceived the solution. Other people then see
and understand your language directly, instead of having to guess at
it by reverse-engineering a hand-written translation.

 

[Peter Lewerin]

But didn't one of them write about how great and productive Perl was for
a couple of months before he decided it was actually crap and went on to
Python or something?

No, that was Bruce Eckel at <URL:
http://www.mindview.net/WebLog/log-0025>.

AFAIK, he hasn't been converted to Lisp yet, so he is *still* doomed
to a tantalizing and hopeless search for a usable programming language
;-)

 

[Michael Naunton]

Heck, I've only asked for pointers to a few little Windows games or
screensavers similar to my own!

Here's the source to the game Concetration. I wrote it a few days ago
for my daughter... Note that it's not production code, just a couple of
hours fun project (I added a comment or two for you.)

http://www.naunton.us/michael/cl/concentration.lisp

 

[Gerry Quinn]

The Lisp programmer's internal language isn't Fortran, with its
imperative statements, loops and variables. The internal language is
an empty abstract syntax tree, to which that programmer is willing to
assign any semantics whatsoever.

When you think that way, then languages which don't let you encode
those semantics just get in your way, because you have to do the
translation of your internal language in your head, and then use your
fingers to spit out the translation. You have to do the tedious job of
the compiler that you are not able to write. In Lisp, you write that
compiler, insert it into your program, and then write in the real
language in which you conceived the solution. Other people then see
and understand your language directly, instead of having to guess at
it by reverse-engineering a hand-written translation.

So if you asked a Fortran programmer to acquaint you with the thoughts
of Aristotle, he would give you an English translation of his works.
Whereas a Lisp programmer would give you the original, plus a copy of
'Teach Yourself Ancient Greek'.

- Gerry Quinn