C++ sucks for games - Other Technologies

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.

I won't argue that it wouldn't be useful, but sbcl doesn't support that
option, although Slime does. Cmucl doesn't appear to do it either.

In my limited understanding of Lisp implementations, it would appear not to
be too hard, so why doesn't it? Alternately, which Lisps do?

"Mark A. Gibbs" <x_gibbsmark@rogers.com_x> writes:

> that is not trivial to do, no matter what macros or other tricks you
> use. i don't know lisp that well, but i have a hard time seeing this
> pattern being easily implemented in any garbage collected
> environment.

As others have pointed out, unwind-protect provides an RAII ****ogue,
though more akin to Java's finally clause than C++'s paired
constructor-destructor guarantees. Common Lisp macros allow one to
craft similar scoped acquire-release semantics as syntax.

Here are a few macros I find useful toward that end. The first,
with-transaction, runs cleanup forms only if the primary protected
form does not run to completion, or, rather, performs some "non-local
transfer of control." The second, with-restart-transaction, adds a
simple restart around the transaction. The third,
with-cleanup-on-error, only runs the cleanup forms if the primary
protected form exits by way of signaling an error condition.


(defmacro with-transaction (protected-form &rest cleanup-forms)
(let ((gsuccessfulp (gensym "successfulp-")))
`(let ((,gsuccessfulp nil))
(unwind-protect
(multiple-value-prog1
,protected-form
(setq ,gsuccessfulp t))
(unless ,gsuccessfulp
,@cleanup-forms)))))


(defmacro with-restart-transaction ((name format-control &rest args)
protected-form &rest cleanup-forms)
`(with-simple-restart (,name ,format-control ,@args)
(with-transaction
,protected-form
,@cleanup-forms)))


(defmacro with-cleanup-on-error (protected-form &rest cleanup-forms)
(let ((gcond (gensym "cond-")))
`(handler-case
,protected-form
(error (,gcond)
,@cleanup-forms
(error ,gcond)))))

--
Steven E. Harris

"Mark A. Gibbs" <x_gibbsmark@rogers.com_x> writes:
> Hannah Schroeter wrote:
> > const std::string& x;
[...]
> you could just as easily create nightmare typo scenarios in any language,
> including plain english. that example is plainly a careless mistake. no one
> and no language can promise that some idiot won't come along and do something
> stupid to muck everything up.

One can do stupid mistakes in any language, but C++ is absolutely at the top
of the list for having single character typos cause so much havoc.

There are just so many pitfalls to be disciplined about it's beyond belief.
C++ is wonderful at providing so much control and abilities to the programmer,
but the cost is death at the slightest relaxing of your guard.

If I had to do a game in a compiled, non-GC language, I would pick Delphi or
even Ada. Delphi has a very well designed OS interface, though, and its easy
to extend its foreign function calls.

If I had to pick an easy-to-use language it would be Java or C#: simple
programming model, garbage collection, easy to train other developers.

If I had to pick the most technically superior language it would be a Lisp
variant. Now if only people would not be so scared of it.

I am not a games developer (just a lurker), and certainly games have real time
considerations, but I am suspecting that the majority of a game's logic can be
expressed in "easy code", code where garbarge collection is not a big deal,
and the speed optimizations that clutter a design are not necessary.

Those performance-centric portions of a game engine can be done in whatever
hacky way that gets the job done: C/C++/ASM. But the callers of the game
engine's services do not themselves need to be high performance -- they need
only invoke the high-performance services.

C++ just doesn't scale well for doing large projects. That is, unless you are
willing to *not* use most of its low level features.

C++ is just too much work. Languages have evolved and there is no reason not
to use a better one.

At the very very least: garbage collection is a step up, a sign of being
civilized. It's like flying a jet versus riding a horse and buggy. The cases
where one does *not* use GC should be in the minority, in very controlled and
planned situations with good reasons.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

Rahul Jain <rjain@nyct.net> writes:
> Philippa Cowderoy <flippa@flippac.org> writes:
>
> > reference counting is severely flawed as GC systems go - the only real
> > advantage being the predictable performance
>
> Predictably slow, maybe...

Referencing counting does not actually give predictable performance. Usages
patterns of access can still vary widely, and freeing a particular usage can
cause a cascade of collecting as one release frees the next and on down the
chain.

Referencing counting actually tends to give "spikes" of garbage collecting.

A proper GC tends to spread out the collections over time, giving better and
more consistent peformance.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

Gerry Quinn <gerryq@DELETETHISindigo.ie> writes:

[Kenny Tilton:]
>> If you click on the name next to each "gush" you can read the full story
>> behind it. While I jokingly called them "Sound bites to die for", as one
>> who made the shift from C to Lisp I can assure you that what look like
>> gushes are actually simple, sober statements of fact. Lisp is that much
>> better.

[Gerry Quinn:]
> Sober statements of fact of the same kind as "When Jesus came into my
> life, I was saved." It may well be a coruscating central truth for the
> person saying it, but its truth is of a kind that will have limited
> value for (say) a Buddhist.

If it turns out that Christianity is right[1] then that
truth will have considerable value for any Buddhist who
is prepared to heed it. And if it turns out that Christianity
is wrong then it isn't really a truth, even for people who
see it as one.

[1] i.e., there actually is a God, Jesus really was God
incarnate, following Jesus really leads to eternal
life, etc., etc., etc.

Of course, in matters of religion so much is either subjective
or very hard to ascertain that perhaps the sort of "personal
truth" you allude to is often the best one can get. But
software development isn't so woolly; some languages really
are, and can be shown to be, better for some tasks than other
languages. You simply can't write device drivers in Python,
and you'd be crazy to write theorem provers in Visual Basic.

There's still a strong element of subjectivity: as well as
some languages being better for some *tasks*, some are better
for some *people*. I find that (to take three somewhat different
examples) C, Python and Lisp fit my brain a bit more naturally
than C++, Perl and ML. So if I say "Perl is a mess" or "C++
is too easy to screw yourself with" you can, I suppose, put it
down to my idiosyncrasies. But if I say "Lisp's macros make it
easy to do things that are unbearably painful in C++", that's
a verifiable (or falsifiable, though as it happens it's true)
statement that anyone can check given a little time and an
open mind.

--
Gareth McCaughan
..sig under construc

On Mon, 25 Oct 2004 14:26:16 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:

>
>"Neo-LISPer" <neo_lisper@yahoo.com> wrote in message
>news:87k6tf9ev3.fsf@yahoo.com...

>> 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.

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.

George
--
for email reply remove "/" from address

In article <ktilton-5B854B.10415227102004@nyctyp02-ge0.rdc-nyc.rr.com>,
ktilton@nyc.rr.com says...
> [...]
> 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.

Indeed, this Lisp concept is so powerful that you'll find
a weak copy of offered for C++ in Visual Studio, namely
the "edit-and-continue" feature. Only Lisp does it better.


Christer Ericson
Sony Computer Entertainment, Santa Monica

In article <MPG.1be86d3f274c9d24989a59@news.indigo.ie>,
gerryq@DELETETHISindigo.ie says...
> > for games written with Lisp,
> > http://www.franz.com/success/custome...ughtydog.lhtml
>
> Yes, one team wrote parts of some of their games in Lisp, and that one
> example has been trumpeted to the rooftops ever since.

Parts? Pretty much everything was written in Lisp (GOAL); except
for certain parts that were written in assembly (such as PS2
microcode for the PS2 equivalent of vertex shaders).


> Read their
> 'post-mortem' on Gamasutra and you'll find that the benefits were far
> more ambiguous than you would think to listen to the Lisp boosters. To
> put it briefly, it featured strongly in both the "what went right" and
> "what went wrong" sections.

Read it again. The drawbacks with Lisp (GOAL) listed in the "what
went wrong" section have almost nothing to do with Lisp as a language,
but to do with the immaturity of their tools (often a problem with
proprietary tools), and the difficulty of finding employees who
grok Lisp.

I know several of the programmers at Naughty Dog (who are just a
stone's throw down the street from here). And they think Lisp (GOAL)
is better than C++. Furthermore, these are incredibly talented
programmers, and only fools would not pay attention to what
they're saying.

You said: "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."

Let's turn that on its end shall we. The guys at Naughty Dog
are clearly more experienced than you are, making you the novice.
They have _constentently_ produced some of the best sellers on
the PS1 and PS2. You have produced some small shareware games
that at worst would take a programmer a week or two to hack
together. You have in the past admitted you have no experience
with functional languages, yet you insist on telling the world
how you (the novice) know better, putting C++ ahead of Lisp.
Isn't that special?


Christer Ericson
Sony Computer Entertainment, Santa Monica

"Philippa Cowderoy" <flippa@flippac.org> wrote in message
news:Pine.WNT.4.53.0410271456270.1840@SLINKY...
>
> [Note that I'm not a Lisp fan - I largely hack in Haskell and happen to be
> hanging around on cgdpm]
>
> On Wed, 27 Oct 2004, Computer Whizz wrote:
>
>> > That everything in Lisp uses the prefix notation can also make it very
>> > easy to learn. Some languages want a lot of syntax:
>> > ++c; c++; a+b;
>> > But most functions are using prefix anyway:
>> > f(x, y, z); or in Lisp
>> > (f x y z)
>>
>> That's horrible... What if 'x' was also a function name etc... It just
>> doesn't seem good to have the function name inside the ()'s to me.
>>
>
> If x is a function, then (f x y z) passes the function x to f. There's
> nothing wrong with this in Lisp, or in many other programming languages -
> it allows you to write things like map, the function that applies another
> function pointwise to every element in a list.

Yes... While x has no parameters passed (or does it?). Does forgetting the
space (or common typo) mean that (f xy z) causes an error. A quick scan
through the file wouldn't really show it up as well as f(x, y, z) IMO - but
to each his own.

>
>> > and if you do in C f(x, y, g(z)); then you also need your brackets
>> > like
>> > the Lisp version; f(x y (g z))
>>
>> Having the function name inside AND outside ()'s... I'll stick to the
>> most
>> common "always outside ()'s" thanks.
>>
>
> That was a typo for (f x y (g z)).

Ah - ok. Sorry.

>
>> I don't remember that at all... I just put ','s in between the passed
>> parameters. Just emphasises the difference between a space and a change
>> of
>> parameter.
>>
>
> In Lisp there pretty much is no difference to emphasise.
>
> --
> flippa@flippac.org

Hmmm - I am probably going to have a hard time explaining myself out of my
own mess here... I guess it's just a matter of opinion and preference to the
syntax.
To each his own.

--
=========
Comp Whizz
=========