C++ sucks for games

[Neo-LISPer]

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.

[Szymon]

"Computer Whizz" <ol*********@ho tmail.com> writes:

[.....]
It even looks worse than Assembler IMHO. Very confusing indeed.
And I do try to be fair in my assessment, I do not want to attack Lisp's
power etc in any way - just point out that the syntax isn't exactly "nice".

Read this:

[ http://srfi.schemers.org/srfi-49/srfi-49.txt ]

It's proposition for python-like (optional) synatax for Scheme (Scheme is
dialect (it forked (afaik) in ~1975) of LISP).

....

defun (fac x)
if (zerop x) 1
* x
fac (1- x)

....

..

[Karl A. Krueger]

In comp.lang.lisp Mario S. Mommer <m_******@yahoo .com> wrote:

Minimally 'Lisp aware' includes not only paren-matching but also
automatic reindentation of code (just as in any other language, in
Lisp you rely on indentation to make things clear). In emacs, this is
<ESC> C-q.

I think there are similar facilities for vim, but I don't know for
sure.

There most certainly are.

vim has a Lisp mode, which can be turned on automatically when you open
a file that vim recognizes as being Lisp code. It includes paren
matching (the "%" command), syntax highlighting, auto-indenting (placing
the cursor when you press enter), and reindenting of expressions (the
"==" command).

--
Karl A. Krueger <kk******@examp le.edu> { s/example/whoi/ }

Every program has at least one bug and can be shortened by at least one line.
By induction, every program can be reduced to one line which does not work.

[Fred Gilham]

You forgot to say that junior colleges and technical training
schools have flooded the market with low to mediocre skilled
programmers who know only the language du jour and nothing of
software engineering practices.

Major 4 year institutions have also put out many of these kinds of
people. In my pre-cs-higher-education days, when I was a self-taught
hacker type, I wandered through some cubicles in the place I worked
asking, "What does a semaphore do?" The real question was "Can I do
what I want with semaphores?" The closest to an answer I got from A
ROOM FULL OF CS DEGREED ENGINEERS was, "I heard about them in college
once."

I promptly went out and, using semaphores, wrote a poor emulation of a
print spooling system that would freeze the entire system when someone
took a printer off line. But I at least had an excuse.

--
Fred Gilham gi****@csl.sri. com
When I was growing up, I found that the main argument against
laissez-faire, and for socialism, was that socialism and communism
were inevitable: "You can't turn back the clock!" they chanted, "you
can't turn back the clock." But the clock of the once-mighty Soviet
Union, the clock of Marxism-Leninism, a creed that once mastered half
the world, is not only turned back, but lies dead and broken forever.
-- Murray Rothbard

[Computer Whizz]

"Peter Lewerin" <pe***********@ swipnet.se> wrote in message
news:b7******** *************** ***@posting.goo gle.com...

"Computer Whizz" <ol*********@ho tmail.com> wrote:

Actually, a pseudo-Lisp of the above would probably be something like:

(output "gfgf" variable (func blah 2))
(change variable)
(setf var2 (func blah 2))
(output var2 variable1)

"function" is an actual function name in Lisp, so I changed it to
"func" for this example.

That wasn't so horrible, was it?

Thanks very much.
- True, it's better than what I misguidedly wrote...

--
=========
Comp Whizz
=========
(The C++ beginner)

[Carl Muller]

"Computer Whizz" <ol*********@ho tmail.com> wrote in message news:<cl******* ***@news6.svr.p ol.co.uk>...

I am also pointing out the fact that if Lisp is supposed to be good for the
"newbie" then how come it looks WORSE off than every other programming
language that I have "gazed" upon?
It even looks worse than Assembler IMHO. Very confusing indeed.
And I do try to be fair in my assessment, I do not want to attack Lisp's
power etc in any way - just point out that the syntax isn't exactly "nice".

That's because you haven't used the language lisp aspires to be:
unlambda ( http://en.wikipedia.org/wiki/Unlambda )

[Greg Menke]

"Maahes" <ma****@interno de.on.net> writes:

But of course, no Lisp programmer would write it this way. If you want a
list, which contains all elements from n to 0, you can write it like this:

(defun make-down-list (n)
(when (>= n 0)
(cons n (make-down-list (1- n)))))

I'll stress one last time - IMHO, the reason your not getting any converts
to Lisp from this thread is that those three lines look very complex to a C
program, simply because of the 5 brackets at the end of the last line. If I
wrote an IF statement with that many brackets, I have to be very careful
with it.. and I certainly wouldn't want to deal with that on every one of my
statements...

Your C++ example would look like magic to someone who wasn't
conversant with the stl- if thats in fact what you're using. If it
isn't, then I think your example is oversimplified.

I'm sure you're quite happy dealing with nested parens when writing
arithemtic. Is there some reason why parens around code is different?

I'll probably go off and learn some more lisp now, since all these posts
have made me think there might be a fabulous language there if you can get
past the excessive use of brackets...
C and C++ wouldn't be so bad if it weren't for all the semicolons.

And its certainly a simple enough language to write your own compiler so
maybe I can play with that for a game. I doubt I'd have any luck convincing
anyone at work that our scripting language should be Lisp though... I don't
think most of our designers could handle all those brackets...

Can they handle the semicolons? If so, parentheses won't present any
additional difficulty. But by all means, even if you don't use it at
work, spend some time learning Lisp- it will certainly make you a
better C/C++/Java programmer.

Gregm

[Kelsey Bjarnason]

[snips]

On Wed, 27 Oct 2004 14:33:01 +0000, Kenneth Tilton wrote:

1. While working I can simply compile a changed (fixed or improved)
five-line function and re-run. Better, if this is an interactive
application which pauses for user input, I can do this during a pause,
then return to the application window and offer new input and see the
new code run. Or if I land in the debugger because of a bug in some
function, I can fix the function and then tell the debugger to
re-execute the stack frame which failed. Where the bug was actually in
some caller arbitrarily high up the call chain, I can tell the debugger
to restart /that/ frame.
This is not a language issue; this is a _tools_ issue. This is a question
of whether or not your _debugger_ allows you to do this sort of thing;
nothing in the C or C++ language specs prevents it.
2. Some bugs are not so obvious. The code looks fine, but they are
working on data which does not look right. My applications are modelled
in part with trees of long-lived instances. If I land in the debugger
while processing node X, I can have the debugger "return" the node to an
interactive command-line as a value I can then play with, say by passing
it to a custom bit of code which will traverse the tree looking for
anomalies. This can include developing new diagnostic code to traverse
the tree, all while my application is patiently waiting at the debug
prompt. I have many a time done this, found the problem, and not just
fixed a bug but refactored massively, including changing the class
hierarchy, and then discovered after hours of work that the debugger was
still waiting at the point where the application failed. And often it is
possible to simply say "try that again" and the application resumes
successfully.
Again, you're discussing _tool_ issues, not _language_ issues.
3. Hard bugs are hard bugs. We do not just find them, because all the
usual suspects had alibis. They seem impossible. I joke about having a
thousand monkeys typing, but in reality the many runs made sometimes
simply to make the bug reproducible are guided by decades of general
programming experience and complete knowledge of my design and it still
feels like monkeys typing. At unpleasant times like these, even a
twenty-second wait to recompile and link becomes an onerous burden to
anyone who has done development in an interactive environment.

And again...

there's plenty wondrous stuff written in C++ too.

Hang on. Don't say "so what?". /You/ said you would not listen to anyone
who had not done a serious project. I did a serious project (several,
actually). Now you have to listen to me. :)

Sure, if you give us something that suggests there's a benefit to the
language. So far, you haven't.

Why is Chevy better than Ford? Well, see, if I use Michelin radials, I
get better road grip. Umm... so? That's a *tires* issue, has nothing
whatsoever to do with why one car is better than the other. You keep
giving us tires, while making claims about the cars.

[Kelsey Bjarnason]

[snips]

On Mon, 25 Oct 2004 14:42:38 +0000, JKop wrote:

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?

[Jock Cooper]

"Maahes" <ma****@interno de.on.net> writes:

[snip]

This is not to say that Lisp, in the hands of an expert, is not an
incredibly powerful language which is fast and easy to program... But I
can't see it getting many converts from the land of C programmers...

I am one C (and Perl) programmer who switched to lisp; mainly because
of lambdas/closures and macros. As someone who used to use pass
around function pointers frequenty in order to customize the behavior
of other functions, a Lisp closure is for me a huge huge win. And
macros can save a huge amount of typing and code duplication; sure a
function can often do the trick but there are cases when only a macro
will do. The result of all this is extremely consise and clear code.
Complaining about 'all those parentheses' is like saying XML would be
great if it didn't have all those damn tags everywhere.

At least in my case I didn't come to Lisp until I was fed up with
fighting with C to get it to do what I wanted it to. Early in my
C career I hadn't had enough of these fights to realize yet why
something like a closure or special var can be so useful. As far
as macros, well I always had used C macros a lot; and of course a
Lisp macro is an order of magnitude more powerful than a C macro.

--
Jock Cooper
www.fractal-recursions.com

[Svein Ove Aas]

Carl Muller wrote:

"Computer Whizz" <ol*********@ho tmail.com> wrote in message
news:<cl******* ***@news6.svr.p ol.co.uk>...

I am also pointing out the fact that if Lisp is supposed to be good for
the "newbie" then how come it looks WORSE off than every other
programming language that I have "gazed" upon?
It even looks worse than Assembler IMHO. Very confusing indeed.
And I do try to be fair in my assessment, I do not want to attack Lisp's
power etc in any way - just point out that the syntax isn't exactly
"nice".

That's because you haven't used the language lisp aspires to be:
unlambda ( http://en.wikipedia.org/wiki/Unlambda )

The last time I looked at that, I had never used any FP-capable language,
and I thought it was rather weird.

Now, I know better. I know it is in fact a decent representation, in a
Picassoan way, of some of the contortions I have had to use in such
languages.

So... does anyone want a nice, chewy monad?