C++ sucks for games

[Rahul Jain]

Now here it is much better for C/C++ IMO.
parameters are passed using the ()'s to group them together, and the
function outside. While in Lisp, the function and parameters are in exactly
the same place.

No, the operator is in the beginning of the evaluated form and the
parameters are the rest of it. I can't see how that's "the same place"
any more than the reception is in the same place as the janitor's
closet. They're in the same building, sure, but the reception is right
at the entrance.

For me it's exactly like writing this post but removing all the comma's,
full stops etc and just leaving the words and spaces - the flow seems to
dissapear.

English has a different syntax, and an amazingly complex one. The flow
of lisp code is determined by the parens, which humans infer using the
indentation applied by the editor.

 

[Fredo]

lol. I can't believe how many people took the bait on this post.

I don't know why anyone who even knows C++ well would respond to such a
post.

Fredo

 

[Rahul Jain]

The Lisp two-liner is actually nicer on the eye, it just looks
cleaner. But I can't be sure that isn't because of all the lower case.

Heh. If only you knew the irony and history that makes this statement so
funny!!

 

[Edi Weitz]

lol. I can't believe how many people took the bait on this post.

I don't know why anyone who even knows C++ well would respond to
such a post.

You mean like you just did?

FWIW, because the OP crossposted this stuff I was able to see a lot of
postings that I usually don't see. Some of them contained interesting
technical information but most of them were elucidating more from a
sociological standpoint - I've never seen so many arguments in a short
time frame that were basically like "I've never heard of this, I don't
know what it is, but I can assure you I don't need it." Yeah, sure...

Cheers,
Edi.

 

[Rahul Jain]

But since the post-mortem referred to bugs and missing features in
GOAL, the developers seem to be putting the blame on it.

And how does this claim indicate that a mature, stable Lisp
implementation suffers from the same problems? Note that the compiler
for GOAL was written in such a system. Interestingly enough, this
"failure" of a project has put out some of the best graphics for any PS2
games and has been used in multiple games. What a disaster. I thought
you were the one who was interested more in real world results than
theoretical whining.

 

[Rahul Jain]

So, I'd say the Jax & Daxter engine is a proof-of-concept... It proves Lisp
CAN be used to make a cutting edge engine...

No, Lisp was used to make a compiler for a custom programming language
that contains features to help express operations in a way that's more
relevant to game programming and the Emotion Engine specifically. At
least this is my impression of the design of GOAL.

 

[Phlip]

lol. I can't believe how many people took the bait on this post.

I don't know why anyone who even knows C++ well would respond to such a
post.

My bad. The post rolled in just as I was investigating how the game industry
uses C++ and _Lua_.

I don't give a dang about trolling so long as the resulting thread can be
on-topic and educational.

However, Lua has no newsgroup, so I guess we must find other ways to fight
over it.

 

[Rahul Jain]

And so goes a HUGE mistake that C and C++ programmers make all the
time: using floating point arithmetic where it is not called for. Why
do they do this? Because their language does not support rational
arithmetic. And in classic "New Jersey"[1]-fashion, instead of solving
the problem by doing the right thing, they just continue to repeat the
same old mistake.

But Wall Street isn't in Jersey.

In an app I'm working on, bond coupon payment rates are stored as
fractional values (6.25% coupon is stored as 0.0625). They are then
multiplied back by 100 for displaying on screen. Of course, the lost
precision causes the number to sometimes be displayed on screen with
lots of trailing 9s or 0s and a 1 if they use the "convenient"
overloading of the + operator in Java to do string formatting using some
arbitrary format and concatenation. I used Lisp to analyze the
FP-representation (using decode-float) and made a little writeup about
how it's impossible to store such numbers accurately in FP. Ironically,
if they hadn't divided the rate by 100, FP would be fine because all
fixed coupon rates are multiples of 1/8, so the denominator will always
be a power of 2. Fun, fun.

 

[Philippa Cowderoy]

No, Lisp was used to make a compiler for a custom programming language
that contains features to help express operations in a way that's more
relevant to game programming and the Emotion Engine specifically. At
least this is my impression of the design of GOAL.

AIUI GOAL's also a Lisp variant.

 

[Kelsey Bjarnason]

You mean that there's a specified protocol for updating instances of a
class when the class's definition has changed in C++? Interesting.

Which part of "there's nothing preventing X" equates to "there is a
defined mechanism for doing X"?

Oh, right, no part.

 

[Walter]

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

Wait no more! D is here: www.digitalmars.com/d/

-Walter

 

[Alex Drummond]

I am familiar with the basic concepts of Lisp, I am familiar with the

arguments in favour of Lisp put forward by enthusiasts, and I am
familiar with the generally weak profile of Lisp enthusiasts in terms of
actually delivering product. The success of one group of talented
developers despite a plainly idiotic choice of development tools
notwithstanding. [I even quoted them, the Lisp users, to justify my
opinions.]

How many times does this have to be said?! Go to the website of a lisp
vendor and look at their success stories. For example:
http://www.franz.com/success/. Most of the projects listed there are pretty
interesting. It's ridiculous to suggest that we're basing our arguments on
the success of one set of developers.


Alex

[...]
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.)

Have you heard of the concept "secondary source"? You don't need to
host a brain slug to know it's a bad idea. You just look at the people
who host them.

I am familiar with the basic concepts of Lisp, I am familiar with the
arguments in favour of Lisp put forward by enthusiasts, and I am
familiar with the generally weak profile of Lisp enthusiasts in terms of
actually delivering product. The success of one group of talented
developers despite a plainly idiotic choice of development tools
notwithstanding. [I even quoted them, the Lisp users, to justify my
opinions.]

Learning to use Lisp idiomatically would take some time. I can find
better uses for that time. I don't buy the crap about it
revolutionising thinking processes, because of the general lack of
revolutionary Lisp-based software. So it's just another language. I
have programmed in about a dozen languages - I don't keep count. If I
need to learn one of the various versions of Lisp sometime, I'll learn
it.

Nowhere in my posts have I criticised any element of Lisp as a language
per se. But based on observation I have criticised the notion that
games development productivity would be enhanced dramatically by a
switch to Lisp, which was the thrust of the posts on this thread,
particularly the initial one. Since you yourself have now admitted that
you prefer to stick with C++, it is rather clear that similar arguments
hold sway with you.

- Gerry Quinn

 

[Alex Drummond]

The previous two replies to your post have covered pretty much everything,
but with regard to your statement that most languages don't support
closures, it's not true. Take a look at (for starters):

Python
Ruby
Smalltalk
Perl
Lisp (of course)
Lua
Haskell, ML, etc.


Alex

[snips]

* Closures

Don't know about those, I'll check the thread - but are these particularly
significant, given that C++ (and presumably C, and presumably umpteen
other similar languages) don't support them? I mean, they can hardly be
the be-all and end-all of programming, right? Just how much of an
improvement _do_ they make over not having them?

* Macros (ability to add your own control structures, etc.)

Not sure what you mean here, but last I checked, C++ did support macros.

* More sophisticated OO system (multiple dispatch, etc.)

Great. C++'s model is already sufficiently complex to be annoying, and
you want a more complex model?

* Garbage collection.

Never seen this one defended as being actually useful for anything but
hand-holding of incompetent coders.

* More sophisticated exception handling system (allows restarts).

Not sure what "allows restarts" means; if I catch an exception, it's up to
me how to proceed: free some resources and try the operation again, for
example.

Better idioms for resource control (e.g. unwind-protect). * More
paradigms suppported: Imperative, OO, functional, logic (if you use a
library like Screamer).

Okay, this sounds reasonable. Not that I've ever needed imperative or
logic coding, but if one needs them and they can't be accomplished in C or
C++, then, sure.

 

[Alex Drummond]

Which part of "there's nothing preventing X" equates to "there is a

defined mechanism for doing X"?

Oh, right, no part.

It doesn't equate; I think Rahul was just pointing out that the Lisp
language standard guarantees certain behaviour regarding instances of
modified classes, meaning that code which modifies classes can be written
portably. Stricly speaking, non-portable C++ code is not written in C++, it
is written in some sort of (C++)++


Alex

 

[Alex Drummond]

[My apologies for the double post on c.l.lisp. The previous poster is

one of those twits who silently change follow-ups.]

KNode seems to do it for me. Sorry.

Not as many as other languages.

Because less people use it.

Repeating mistakes does seem to be human nature.

I guess that's why so many people use C++.

Unless you are selling the technology, or unless a technology gives you
special capabilities that those not using it don't have, "getting ahead
in technology" is a fool's motivation. Mature technology is cheaper and
more reliable as a general rule.

Lisp is mature, older than C++ in fact.

Template metaprogramming as such is never used by most sensible
programmers. Macros, by contrast, are ubiquitous in Lisp as I
understand it. And if the development environment had been an object-
based system with proper interfaces, it shouldn't have mattered whether
his code was comprehensible. Something for addicts of 'generic
programming' to ponder. But that's all beside the point. I don't know
what particular aspects of the program were incomprehensible to the
other developers, I just threw it out as one of the problems that
afflicted the one games development team famous for developing in Lisp
and still actually achieving something.

I can't buy the first sentence. What about the performance advantages of,
say, epxression templates for matrix arithmetic. Sounds sensible enough to
me. The development environment may well have been object-based. Do you
know whether or not the Lisp dialect the used was OO?


Alex

[My apologies for the double post on c.l.lisp. The previous poster is
one of those twits who silently change follow-ups.]

Just go to the website of a Lisp vendor and look at the "success stories"
section or equivalent. Lots of interesting real-world applications, e.g.
http://www.franz.com/success/customer_apps/bioinformatics/harvard.lhtml.

Not as many as other languages.

These are all problems with the hastily written /compiler/, not with
Lisp. If there was a mature Lisp compiler targetting PS these wouldn't
have been issues. So these are merely arguments against using Lisp on the
PS, so far as I can see. Clearly the arguments were not compelling enough
to prevent Naughty Dog from using the same technique again.

Repeating mistakes does seem to be human nature.

Because of course you can only get ahead in technology by copying what
everyone else is doing.

Unless you are selling the technology, or unless a technology gives you
special capabilities that those not using it don't have, "getting ahead
in technology" is a fool's motivation. Mature technology is cheaper and
more reliable as a general rule.

Regarding code obfuscation in Lisp, I think it's fair to say that Lisp
macros are just a bit easier to understand than template-metaprogramming
in C++. Also, if some guy decides to write some stupidly complex Lisp
code, that's not really Lisp's fault, is it? The stock response to
criticism of C++ seems to be "that wouldn't happen if you coded
sensibly".

Template metaprogramming as such is never used by most sensible
programmers. Macros, by contrast, are ubiquitous in Lisp as I
understand it. And if the development environment had been an object-
based system with proper interfaces, it shouldn't have mattered whether
his code was comprehensible. Something for addicts of 'generic
programming' to ponder. But that's all beside the point. I don't know
what particular aspects of the program were incomprehensible to the
other developers, I just threw it out as one of the problems that
afflicted the one games development team famous for developing in Lisp
and still actually achieving something.

- Gerry Quinn

 

[Coby Beck]

I shall investigate it pretty soon, as I shall be getting alot more free
time... I shall then just pop in to your lisp newsgroup to post my
thoughts... Don't expect anything of me though - the mindset is boggling!

Look forward to your visit. But forget what other people expect of you,
expect more from yourself. Pop in and *listen*, don't pop in and post
ill-considered thoughts.

 

[Paul F. Dietz]

I like the more natural way than that used in Lisp - that's all.

'Natural' here is a synonym for 'conforms to my unreasoning prejudices'.

In other words, you are rejecting the syntax because it's different
from what you're used to, and that difference is bubbling up out
of your unexamined subconscious as a felling of 'unnaturalness'.

Paul

 

[Rahul Jain]

AIUI GOAL's also a Lisp variant.

Yes, but bugs in GOAL's compiler and confusing semantics of GOAL's
operators are not a problem with the Lisp that was used to create the
compiler. Language design is hard. This is the first attempt at making
something that encapsulates the architecture of the Emotion Engine, so
I'd expect there to be some impedance mismatches.

 

[Rahul Jain]

Template metaprogramming as such is never used by most sensible
programmers. Macros, by contrast, are ubiquitous in Lisp as I
understand it.

They are usually how you do the thing that Lisp is for: creating new
language features.

And if the development environment had been an object-
based system with proper interfaces, it shouldn't have mattered whether
his code was comprehensible. Something for addicts of 'generic
programming' to ponder. But that's all beside the point.

And absolute buzzword-induced foolishness. Object orientation and
interfaces does not have anything to do with the issue you mention. I
have no clue what "generic programming" is, but simply having
polymorphism and definable type hierarchies does nothing to indicate
_what_ it is some operator is supposed to achieve. The current project I
am on at work is a case in point. They don't comment or document their
code because they think that if you want to know what the code does,
just read it. Of course, that's utter nonsense. Documentation tells us
not what the code does, but what the point of some code is. No amount of
polymorphism will explain the design rationales and models behind some
API or language.

I don't know what particular aspects of the program were
incomprehensible to the other developers, I just threw it out as one
of the problems that afflicted the one games development team famous
for developing in Lisp and still actually achieving something.

Then you shouldn't assume that it was something in the compiler that was
hard to understand and not some specially-designed operator in GOAL that
had semantics that weren't quite properly defined.

 

[Jerry Coffin]

[ ... ]

Although, I would write that code in Lisp as:

(loop for i below 11 collect i)

....and in C++ you (or at least I) would quite possibly write it using
std::generate_n.

The main thing you fail to realize, due to the complexity of C syntax,

I don't find C's syntax particularly complex at all -- though I'm the
first to admit that this may be due (in part) to having used it nearly
as long as I have Lisp.

is that C code has just as much structure as Lisp code (more actually,
because the structure goes immediately to semantically significant
constructs),

I have to admit this is an argument that surprises me -- while I agree
that C code generally has more (and better) structure that most Lisp
code, this is the first time I've seen even the most rabid advocate of
a language claim that its lack of structure was actually an advantage.

but that structure is obfuscated by the variety of
characters used to delimit various semantic constructs.

The syntax of C obfuscates structure only to the least perspicacous of
observers.

In Lisp, we just
have one set of characters to delimit all constructs and the semantics
are determined by the operator at the beginning of a form.

....or at the end, or in a property list, or just about anywhere else
you feel like putting it. I won't bore you with the (ancient) code
that did it, but I have some old Lisp here that accepts input in
postfix format (as non-list S-expressions, natch) and prints turns
them into normal infix notation.

[ ... ]

Your problem is that you're looking at the parens, not at the shape of
the code.

I suspect what he's really missing is the fact that Lisp is almost
always written using an editor that's aware of Lisp syntax to at least
a fairly reasonable degree, so indentation and some sort of
highlighting to match parentheses is extremely common -- though in
fairness it should be pointed out that it's common primrarily because
machine help is nearly an absolute necessity to compensate for the
paucity of Lisp syntax.