C++ sucks for games

[Matthew Danish]

int fact(int x) {
if (x == 0);
return 1;
return x * fact(x-1);
}

and:

(define (fact x) (if (= x 0)
(1
(* x (fact (- x 1))))))

For the record, my eyes jumped to the extra parenthesis before the 1
right away, but it took me a number of seconds to spot the extra ; in
the C code. It is telling that Lisp programmers really do look at the
beginning of forms, and (1 ...) is immediately obvious as an invalid
form. I am both a C and a Lisp programmer---I have programmed in C
far longer than Lisp---and one thing I remember always hating was
discovering that 2 hours spent debugging compilation errors could be
attributed to a misplaced semi-colon. Of course, once I started using
Emacs seriously, this problem faded; much the same for Lisp.

 

[Svein Ove Aas]

You talk about fashion (what language the mass uses) and claim that
the current most popular language is the best. Statements of that
form are rarely correct, and this particular one is spectacularly
wrong.

Instead of posting in this interminable (and mostly uninformed)
fashion, why not try to put your code where your mouth is? Pick some
problem that can be solved, without libraries, in some small
number-let's say 200-of lines of C/C++. Then I'll do the same in
lisp. Then we both solve both problems, and see how much
processor/memory/lines of code/time it takes for each of the 4
solutions.

Better yet, make the problems public.
I *love* a decent challenge.

 

[Paul Foley]

Better yet, make the problems public.
I *love* a decent challenge.

http://www.frank-buss.de/challenge/index.html

Also http://shootout.alioth.debian.org/

--
"If all else fails, immortality can always be assured by spectacular
error." -- John Kenneth Galbraith

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

 

[Jerry Coffin]

[ ... ]

It's not ambiguous if you're a C compiler, but it is if you're a human who
hasn't memorised all the operator precedence rules.

Based on this reply, about all I can guess is that you don't know what
"ambiguous" really means. Being ignorant of the meaning of a statement
doesn't imply that the statement is ambiguous; to be ambiguous, it
must be impossible to determine the meaning of the statement,
regardless of one's knowledge of the language, etc.

My utter ignorance of Japanese is FAR from justification for claiming
that all Japanese is ambigous.

I find it particularly interesting that C and C++ both contain some
things that (based on pure syntax) really ARE ambiguous, but those
attacking them seem to be sufficiently ignorant that they don't even
realize what they should be citing (that's a hint guys: your side
deserves a MUCH better argument than you're putting up for it).

[ ... ]

C requires semicolons at the end of every line, no matter how
obvious it is where the break between two lines of code is.

This is simply incorrect. If I choose to do so, I can write an
arbitrary number of lines of C without semicolons. C _does_ require a
semicolon at the end of a _statement_ (and in a few other situations),
but equating a statement with a line simply shows (though it's already
pretty obvious) that you really don't know what you're talking about.

The difference here is really only in arithmetic expressions.

That's simply not true -- infix expressions can be useful in all sorts
of non-mathematical situations. In any case, the thing we program IS
called a "computer", but you sound as if nobody should actually expect
it to be able to do any computation!

[ ... ]

Not true in my personal experience. Lisp code is very easy to track because
its structure is explicit. C code is potentially very confusing (e.g. a
multiline else clause which is indenteded correctly, but which isn't
deliniated by { }).

How can that possibly be confusing?

[ ... ]

This test didn't work for me, I spotted both errors in a few seconds.

The question is "how few?" Based on the content of your post, it would
appear that you know Lisp a LOT better than you know C in any case. As
such, if the two were about equally readable, you would have been able
to spot the problem in the LISP much MORE quickly.

[ ... ]

Depends what you mean by punctuation. It has fewer rules of punctuation, but
probably more punctuation characters (if you count the parens).

Given Kaz's mention of "waste of keystrokes", the actual number of
characters seemed to be the only possible interpretation.

 

[David Steuber]

People who have just begun a project, or indeed who have never completed
a real project, are apt to overestimate the importance of algorithms in
programming.

I don't understand this. What are programs if they are not
expressions of algorithms?

 

[David Steuber]

Why do 99.99% of game companies use C & C++ instead of Lisp...
There's plenty of startup companies that could use Lisp if they wanted to...

It would be extreme arrogance to assume they're all just stupid...

It took a while for things like electricity and telephones to catch on
as well. Don't even get me started on indoor plumbing.

 

[Pascal Bourguignon]

I don't understand this. What are programs if they are not
expressions of algorithms?

Well, a big part of the programs is composed of pure sequential algorithm:

do-stuff-1
do-stuff-2
do-stuff-3

This is "algorithm" the same way 1 is a power of two...

For example the algorithm to display a small dialog box would be:

display label field
display text field
display ok button
display cancel button

Nice algorithm...

If you compare the size of CLI executable with that of GUI executable
(without counting resources), you'll get an aproximation of the
importance of algorithms in current software... (the GUI algorithms
are stored in the GUI libraries, not in the GUI executables!)

 

[Cameron MacKinnon]

I don't understand this. What are programs if they are not
expressions of algorithms?

/* Well, first, there's all those comments that line-noise language
programmers have to type to remind their fellow programmers (and
themselves) what this function does, and its history of bug fixes and
modifications, refactorings, etcetera */

then theres(the explicit, input, and out, parameter type declaration) {
and a;
bunch of;
similar declarations;
for the local variables used;

your algorithm here;
maybe some explicit deallocation of resources;
returning(something);
}



So programs = algorithms + bookkeeping. Outsource as much of the
bookkeeping as you can, I say!

 

[William Bland]

So programs = algorithms + bookkeeping. Outsource as much of the
bookkeeping as you can, I say!

And I'd say one of the best things about Lisp is that you can teach the
language itself to do much of the bookkeeping, so that you can outsource
the bookkeeping to the compiler

Cheers,
Bill.

 

[Bulent Murtezaoglu]

[...]
WB> And I'd say one of the best things about Lisp is that you can
WB> teach the language itself to do much of the bookkeeping, so
WB> that you can outsource the bookkeeping to the compiler

Indeed. Peter Seibel's book has a cute story based on this analogy.
The Story of Mac, he calls it. Check it out:

http://www.gigamonkeys.com/book/macros-defining-our-own.html

cheers,

BM

 

[Svein Ove Aas]

http://www.frank-buss.de/challenge/index.html

Also http://shootout.alioth.debian.org/

Been there, done that, didn't bother to get the t-shirt.

Thanks anyway, though.

 

[Cameron MacKinnon]

I find it particularly interesting that C and C++ both contain some
things that (based on pure syntax) really ARE ambiguous, but those
attacking them seem to be sufficiently ignorant that they don't even
realize what they should be citing (that's a hint guys: your side
deserves a MUCH better argument than you're putting up for it).

Why bother arguing about shift/reduce and reduce/reduce conflicts and
the de facto and de jure meanings of e.g. a[x+++y] = x+++y; - every
language has a wart or two in the corner cases, and C defenders are just
going to reply that such things are bad style and not done anyway. If
mere syntax was the biggest hindrance to productivity, then
preprocessors, smart editors and code formatters could solve it.

Say, speaking of citing, don't you still owe us one from your claim that
"[t]ests have repeatedly shown that C is far more readable than Lisp."

 

[Stewart Gordon]

JKop wrote:

C += 2, C

In the above expression, would the former not be evaluated before the
latter?

Oops, you're right.

C += 2, C - 2

(Caveat: if C is a floating point, there might be loss of precision in
the process.)

Stewart.

 

[Jerry Coffin]

(e-mail address removed) (matt knox) wrote in message
[ ... ]

Instead of posting in this interminable (and mostly uninformed)
fashion, why not try to put your code where your mouth is? Pick some
problem that can be solved, without libraries, in some small
number-let's say 200-of lines of C/C++.

"without libraries" produces an artificial environment so the results
become meaningless at best. C++ is defined to include a standard
library, and for most practical purposes is non-functional without it
(e.g. the language proper includes no I/O facilities at all). Worse,
one of the major (and explicit) motivations in the design of C++ is to
improve the ability to both design and use libraries.

Then I'll do the same in
lisp. Then we both solve both problems, and see how much
processor/memory/lines of code/time it takes for each of the 4
solutions.

I've seen a few challenges on this general order, but while the
results are usually interesting, I've yet to see many that were really
very meaningful.

Consider, for example, what happens if I post 200 lines from an OS
kernel. Now, many of the algorithms in an OS kernel are pretty simple,
and could certainly be expressed in Lisp quite easily -- but in most
cases, the result wouldn't be usable.

Another possibility is when something that looks like (and really IS)
C or C++ is interpreted as SystemC, which compiles the code all the
way down to gates for an FPGA (or CPLD, ASIC, etc.) Just for example,
I could write something that emulates a CPU in C. It could be
translated to Lisp and also emulate a CPU. But the C can also be
compiled as SystemC to produce a real, live CPU. In theory the same
thing _should_ probably be possible from Lisp -- but I'm not aware of
a toolset that will really do it. By contrast, I've taken a fair
number of algorithms written in C and C++, and made them run on a FPGA
with only minimal extra work (mostly doing a constraints file that
designates what pins will be used for the inputs and outputs).

 

[Gerry Quinn]

[question and non-answer elided]

GQ> I think the nub of the issue is that, if you take away the
GQ> relatively useless ability to write self-modifying code,

I don't understand where this self-modifying code idea is coming from.
Do you mean the ability to write code that writes code? Self
modifying code, in the usage I am familiar with, means changing the
code (not data) in memory as the code itself runs. An example would be
changing jump destinations in running code by modifying the immediate
operand of the jump instruction to get home-made memory-indirect jumps
in ISA's that lack such things. These tricks may have been (ok were)
cute 15-20 years ago, but they tend to stall the deep pipelines in
modern processors. Perhaps the usage/meaning of the term has shifted
due to this?

I would say "self-modifying code" includes any program in which code is
generated and executed as part of the expected output of the program.
It's no longer running itself as originally written.

I know there are inevitable ambiguities and special cases, simply
because there is no real dividing line between code (to be executed) and
data (to be manipulated). I would augment my definition above to
exclude cases in which there is a 'hierarchy of execution levels'. I
would not consider code that runs a cellular automaton that performs a
computation to be self-modifying, for example. The generated code has
to have approximate 'parity of esteem' with the original code.

GQ> what
GQ> Lisp is mainly good for is representing complicated
GQ> algorithms.

This is like saying "what lawyers are good for is winning cases."
(But to stretch the analogy, the lawyer in question lets you draw up
interesting contracts too).

You see, you make my point for me. Lisp-ers see one real benefit of
Lisp but they do not realise it is not nearly so important as they
imagine.

GQ> But representing complicated algorithms is a
GQ> solved problem on any modern high-level language, and any
GQ> extra benefits from Lisp are likely to be minimal for 99% of
GQ> programming tasks.

I assume this 99% number is coming from the same place you got the
data about professional lisp users not finishing projects. But I
would agree that most programming tasks, where 'most' is measured
by headcounts, LOC or programmer-hours are indeed mundane.

The claim is that the extra benefits from Lisp come in handy (or might
even be essential in some sense) for _interesting_ programming tasks.
What I mean by 'interesting' are things the programmer and the
customer (and quite possibly anyone else) have not done/used before.
This doesn't necessarily mean researchy open ended stuff (where your
deliverable is not likely to be a finished program anyway.) It can
mean things that are just becoming practical (eg: viaweb and such) or
problems nobody really tried to re-solve with modern tools/knowledge
(eg ITA and such).

But that claim cannot be justified because so many interesting
programming tasks are completed in other languages.

I honestly don't believe there is ANY programming task (excluding those
referring specifically to Lisp!) for which Lisp is in any way essential.
Sure the programming tasks on the page referred to are interesting, but
they are not all *that* special.

- Gerry Quinn

 

[Gerry Quinn]

I don't understand this. What are programs if they are not
expressions of algorithms?

Others have answered. I would say that a program is a recipe for
marshalling resources to produce a particulasr output. Unless you call
things like images or lists of GUI button positions algorithms,
algorithms are just some of the resources to be marshalled. They are
important, but they are a small part of the program.

if ( player.pos.x > monster.pos.x ) monster.vel.x = monster.speed;
...is an algorithm, but it's quite trivial compared to the artwork,
gameplay and level-design issues relating to the monsters.

- Gerry Quinn

 

[Gerry Quinn]

So programs = algorithms + bookkeeping. Outsource as much of the
bookkeeping as you can, I say!

I think you'll find there's a little more than that to producing a
finished product...

- Gerry Quinn

 

[Gerry Quinn]

So? Given that they were pretty successful, despite writing their own
compiler instead of using a production quality Lisp compiler, I think
they're good evidence that Lisp is a suitable language for games. The other
successes show that Lisp is good for complex programs in general.
Admittedly, if you don't want to write a complex game, Lisp might not be
much of an advantage.

I want to write *good* games. The simpler, the better.

In truth, I don't have problems with algorithms. The stuff I do may not
be world-shaking (as Christer Ericson likes to point out) but probably
the algorithmic content is a bit higher than the average shareware game
or screensaver.

Even for projects on this scale, algorithms are the easy bit. At least
for me. Your mileage may vary.

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

 

[Gerry Quinn]

Programmers who want high performance numeric code. Or programmers who want
to write a parser (http://spirit.sourceforge.net/). Both things which game
programmers will probably want to do at some point.

Not on this scale. Spirit is part of a library project on the STL
level. And I suspect game programmers who want maximal numerical
performance are much more likely to drop to C or ASM than to try
anything fancy with templates.

My view, perhaps controversial, is that templates are for writing
libraries that will see massive re-use. Day-to-day programming will use
such libraries, but day-to-day programming should not involve writing
templates. I would go so far as to say that most professional C++
programmers should never have to write template code at all, except for
their own education and amusement. And that's basic template code, not
elaborations on it.

GOAL is not Common Lisp. You should know that Common Lisp supports OO if
you've done even a smidgen of research. In fact it was the /first/ ANSI
standardised OO language. So in terms of being standard and being OO, it
pretty much beats C++.

When I wrote that I HAD done a smidgeon of research, and my impression
was that yes, Common Lisp has classes, but they have a very 'bolted-on'
look. They are built with Lisp macros, no doubt for ideological reasons
- perhaps as a consequence they seem to lack things we might expect such
as access specifiers. That's why I wrote what I did.

- Gerry Quinn

 

[Gerry Quinn]

This is how lisp always works. You customize the language to the
application domain, so that you can describe _what_ you want acheieved,
not _how_ you might want it done in some specific situation that may not
even be relevant to the final production application.

Of course, this is true of any high level language. In C++,
customisation comes mostly from defining classes and methods - the
language syntax remains consistent throughout.

Which seems like a win to me...

- Gerry Quinn