C++ sucks for games

[Ian Wild]

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

Hmmm... you'd jump at "D", were it available, based only
on the name, and since you know it IS available, ... ?

 

[Marco Parrone]

So if I tell you that you can also use a pen as a stabbing weapon, are you
suddenly not going to use it to write anymore based upon the premise that is
has an extra feature that isn't used?

Not a good example.

Another example: You need a watch, what watch do you choose:

1) the one with just time and chrono

2) the one that has incorporated: mp3 player, photo-camera, radio,
and walkie-talkie?

I prefer the `1', more elegant, more lightweight, likely less prone to
faults.

If I would consider useful some features of `2', maybe I would
consider taking `2', or I may consider to get `1' plus a separate
device implementing the desired function.

Just as how Delphi code won't compile as C++ code.

I see no reason whatsoever to not choose the latter which evolved from the
former.

Are you sure that the latter is better? For any purpose?

C++ is not a superset of C, it is another language.

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

So you base your language chooses on hype.

People still programming in C is like a C++ programmer writing 1998 Standard
code -- it's been superseeded.

So I'm wondering, why do people write C code today, October 29th 2004?

Because they prefer C to C++. Or because C fits better some particular
domain.

Please note, while I prefer C to C++, I'm not blaming C++.

 

[Gerry Quinn]

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

 

[Gerry Quinn]

Gerry Quinn wrote:

reading the points you quoted, they boil down to two arguments:

1. the programmer who considered it "code encryption" weren't familiar
with the language and either lazy or slow learners

According to some they are geniuses whose decision to use Lisp should be
a guiding light for us moronic hordes. But in point of fact, I don't
see how it boils down to that. From the basic fact of problems arising,
we can't decide whether GOAL or its users were inadequate. But since
the post-mortem referred to bugs and missing features in GOAL, the
developers seem to be putting the blame on it.

2. they used a tool that was still in development

now imagine a post mortem from programmers who were unfamiliar with
C/C++ on a project were the C/C++ compiler is written while they develop
the product. do you think it would be any different?

No. Those who used such an environment in such circumstances, while
mature technologies were available, would have made a stupid choice and
would probably fail. Even if they succeeded despite themselves, those
who copied them would still be idiots.

- Gerry Quinn

 

[Bulent Murtezaoglu]

[...]
GQ> I am familiar with the basic concepts of Lisp, I am familiar
GQ> with the arguments in favour of Lisp put forward by
GQ> enthusiasts, and I am familiar with the generally weak profile
GQ> of Lisp enthusiasts in terms of actually delivering product. [...]

"Enthusiasts" who do things for fun are not expected to deliver
"product" regardless of what langauge they use. If you have reason to
say this about people who use lisp professionally compared to users of
other languages, then perhaps you could tell us that reason? (AI
that wasn't in the 80s doesn't count).

cheers,

BM

 

[Stefan Ram]

but this was a statement from 1993:
http://groups.google.com/groups?as_umsgid=<[email protected]>
I don't know the details of the C++ standard, some things might
be better in the current standard.

I believe that the standard of 1998 (and now: 2003) has
even more features than C++ as of 1993.

In any case, the standard ISO/IEC 14882:1998(E) has about 776
pages and is is based on the then C standard ISO/IEC 9899:1990
(E) with about 219 pages - which is needed as a reference and
to interpret the C++ standard, which refers to it not only for
the C standard library but also for behaviour of parts of the
C++ library. These are about 1000 pages for the language
specification. Nowadays, that old C standard is difficult to
obtain at all, so the whole specification even isn't
accessible easily.

**

Did I mention yet, than in many C++ implementations the
expression

-1 < 3000000000

is false, while

-1 < 2000000000

is true?

 

[Greg Menke]

And no - the trouble with Lisp to begin with is trying to find the "core" ()
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.

I think you are fundamentally misunderstanding Lisp program structure.
Unless you've happened to land in the middle of some huge FP example,
Lisp reads like any other procedural language.

Gregm

 

[Andreas Krey]

* Frank Buss ([email protected])
....

but this was a statement from 1993:

http://groups.google.com/groups?as_umsgid=<[email protected]>

I don't know the details of the C++ standard, some things might be better
in the current standard.

No way. C++ is awfully convoluted and full of nasty traps many of which
you need to be actively aware of. A few days ago I had the line

clid = v;

corrupting an iterator. Now, v is a Some *, while clid is a SomeRef,
and it turned out that the SomeRef(Some *) constructor was broken
and only called because I forgot the SomeRef:perator=(Some *)
assignment operator. But class SomeRef would also have been seriously
broken if I just *omitted* the SomeRef:perator=(const SomeRef)
assignment operator.

C++ is also awfully wordy to write. Even the simple STL iteration
is a very lengthy expression. But then it is handy not to have
to do all this stuff yourself (in a typesafe way), and this is
the reason I finally (re)started to use C++.

Andreas

 

[Andreas Krey]

* JKop ([email protected])

Andreas Krey posted:
.....

What *what* are?

Static libraries and DLLs. They both contain machine code and
linkage information.

Andreas

 

[Gerry Quinn]

[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

 

[Steven E. Harris]

Hmmm... you'd jump at "D", were it available, based only on the
name, and since you know it IS available, ... ?

Just in case you mean to imply that D is not available, there's plenty
to read here:

http://www.digitalmars.com/d/

 

[Stewart Gordon]

JKop wrote:

If tomorrow a new programming language were to come out called "C+=2"

<snip>

If it's going to follow the sequence semantically, it would have to be
called "C+=2, C".

Stewart.

 

[Coby Beck]

Not as many as other languages.

With all due respect to conflicting subjective points of view, all it takes
is a single counter example to refute the often voiced opinion that "lisp
may very well be <yada yada> but you cannot write real world applications
with it"

I don't think any body will dispute there are fewer lisp success stories
than C++ ones but that is as useful a data point as there are many more C++
failure stories than lisp ones.

 

[Svein Ove Aas]

sorry, is a bit longer

(sqrt (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23))))

But the C++ version is longer, too, because I've omitted all the includes,
"using namespace std" and the main-function.

The others are fair, but I don't think you could include main in that
statement of omission.

Recall the purpose of main: It works as the starting point for a standalone
executable. An interactive C++ REPL presumably wouldn't require you to type
it in between each expression, so we'll drop that.

A Lisp program that was meant to create a standalone executable would, in
fact, include pretty much the same amount of code as that main function to
do it.


That said... Oh my, is that really the best C++ code for the purpose?

 

[Coby Beck]

FWIW you really do not notice all those parens after you get used to lisp
expressions and they are less intinidating when you realize they take the
place of all of ,;}) in C/C++ (not in every instance of course)

Besides, not everyone (myself included) would write the above as it is, I
never use recursion for an iterative problem.

(defun make-down-list (n)
(loop for i from n downto 0
collect i))

Scheme is something you could write a compiler for in a reasonable
time. Common Lisp is a bit more complex.

I think he may have meant "compiler" in the sense of macros are like
compilers for your own domain specific language on top of lisp rather than
re-implementing the language(?).

Stick with Commn Lisp.

 

[Svein Ove Aas]

Yes, that's right. However, they are still not so easy accessible like
the infix operators in our earlier discussions. Therefore complex
numbers would need to be included in the base language. If you need them
for just one part in your program, then do this in C++:
(+ #C(3 4) 25)

At this point I'd like to point out that, although complex numbers are part
of the standad CL library, if they weren't, it would be fairly easy to add
them.

Add a "complex" type, shadow the built-in arithmetic functions to make them
understand it, add a read-macro to make the #C(n m) syntax work... all in
all, not terribly much work, and you'd end up with the exact same syntax
that is used for the (built-in) complex types we have today.

Of course, the concept of a built-in type does tend to blur somewhat when a
simple two-key chord lets me look at the compiler's/library's definition of
any given function.

The point is, if someone needs anything CL lacks, they can simply add it. If
you need matrix-capable functions you can write them yourself, and they'll
work just like the built-in arithmetic functions even if you want to call
them something different.

That, for me, is one of the greatest features of CL.

 

[Svein Ove Aas]

So you'd want to program like this:

(deformula "
1 2
S = --- a t + v t
2 i
")

Note that in ASCII-art, it's still quite parseable.

Actually, I'd like to use a math-aware editor that would take special
keystrokes and interpret them to build a mathematical expression visually.

Like Mathematica does, if you've used it. (Or Lyx, although not as well.)

That's neither here nor there, though; no language known to me does that,
although I'm sure I could make Lisp do it with the appropriate editor
extensions. The same goes for C, though, even if I *would* have to use
comments for things they were never meant to do.

 

[Kaz Kylheku]

One might easily think that Lispers accepted the brackets but still
don't like them. In fact most Lispers even love them. The brackets (or
any other mechanism that tells the compiler where an expression starts
and ends) make many things easy.

What if you want to compute something like that:
a + b + c + d + e + f + g + h + i + j + k + l;

(with usefull names)

Here Lisp only needs one +:
(+ a b c d e f g h i j k l)

These are the technical, objective advantages of Lisp syntax:

- precedence and associativity do not exist, and so there are no
ambiguities

- every well-formed syntax corresponds to a data structure. There is a
bidirectional conversion path between a data structure and syntax,
allowing Lisp programs to manipulate Lisp source code.

- a few simple rules can be applied to format Lisp syntax in a
readable way, even if it has very deep nesting. Lisp can be written as
a sideways tree (think of a Windows tree control, for instance):

a +--- b +-- e
| |
| +-- f
|
+--- c
|
+--- d --- e

Just add parentheses and keep basically the same shape:

(a (b e
f)
c
(d e))

From this you can tell right away that there is a main list headed by
the main connective A, with three other constituents. They all start
on separate lines and are at the same indentation level.

This formatting can be applied to very deep expressions to make sense
out of them.

You cannot nicely format deeply nested infix expressions, because the
connectives are sandwiched between the constituents; they do not
nicely pop out on one side for a sideways diagram.

In the prefix notation, the main connective comes first, which allows
you to put the other ones to the left and on separate lines, without
rearranging the lexical order of the tokens.

Given (+ a b) you can write that as:

(+ a
b)

But given A + B, you cannot write that as:

A
+
B

because the order has been permuted. Your compiler won't take it.
There isn't any nice order in which you can separate the connective
from the constituent expressions.

Sometimes I use this style in C++,

A +
B

So that say ((A || B) && C) && !(X || Y) becomes (oh boy, I can't even
see what the main connective is):

((A || B) && C) &&
!(X || Y)

then

((A ||
B) &&
C) &&
!(X ||
Y)

Blech, anomaly with the ! operator which is prefix. This quickly
becomes way too ugly and the main connective doesn't stick out; it's
still buried. The first && sticks out to the far right, looking more
prominent. Maybe:

((A ||
B) &&
C) &&
!(X ||
Y)

now we at least have a sideways tree shape of sorts. But this is ugly
as sin. If we translate to Lisp we get:

(and (and (or a
b)
c)
(not (or x
y)))

Beautiful. I can mentally convert that to a combinational logic
circuit diagram flowing right to left.

We can selectively fold obvious pieces to one line:

(and (and (or a b)
c)
(not (or x y)))

(and (and (or a b) c)
(not (or x y)))

(and (and (or a b) c) (not (or x y)))

These kinds of transformations are easy to do back and forth,
particularly with Lisp-aware editors.

Even in the completly flat version, I know right away that the main
opeation is an AND, without having to parse through the whole thing.

 

[Kaz Kylheku]

Yes, that's right. However, they are still not so easy accessible like the
infix operators in our earlier discussions. Therefore complex numbers
would need to be included in the base language. If you need them for just
one part in your program, then do this in C++:
(+ #C(3 4) 25)

Just look at the example program on the site you posted.

Have fun


André

True, C++ does have some missing things from it's "base" language (Oh how I
sorely missed strings at first glance when I first tried C++)...
But I did get to realise about using chr[] and chr* quite soon, and then
including the <string> library.

I read a bit on that D programming language mentioned somewhere, about
complex numbers being much easier to use - and indeed it seemed so.

And no - the trouble with Lisp to begin with is trying to find the "core" ()

What trouble with Lisp? What is your Lisp experience?

and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.

That is actually wrong; to properly understand a Lisp expression, you
must work from outside in. You first consider it to be a list, where
the first element denotes the identity of the operator. Otherwise you
can get tripped up. For instance, suppose you had:

(defclass a (foo b c) ..)

If you were looking from the inside out, you might think that there is
a function call (FOO B C). But in fact, this is a DEFCLASS form, where
class A is being defined, and its base classes (multiple inheritance)
are FOO, B and C. The DEFCLASS operator has complete control over the
interpretation of the rest of the form; you have to know its semantics
in order to understand that form.

You read the form left to right. The main connective is always
leftmost. Its constituents can be read from left to right, and their
connectives are also on the left and so forth. Speaking of Forth, that
is the language you must be thinking of which requires some right to
left thinking.

The C and C++ languages have plenty of prefix forms. Function calls:

f(g(x, y), z); // analogous to (f (g x y) z)

sizeof (char *); // sizeof operator is prefixed

return 3; // return operator

if ...
for ...
while ...
switch ...
class ...

All prefix operators, like in Lisp. Oh yes and there are lists all
over the place in C++ source. Lists of function and template
arguments, lists of declarations and statements, lists of base
classes, lists of base class initializers, lists of this lists of
that. They all have inconsistent syntax with each other! Semicolon
terminators here, comma separators there. Initial colon elsewhere. In
Lisp source code, anything that is a list has the same syntax as any
other list, whether it be a list of arguments, list of base classes,
list of variable forms in a LET or whatever.

As to your other point, it is actually infix syntax which forces you
to get to the ``inner core'' just to discover what operation is being
done and get the gist of the expression. Consider the case where you
have:

< ... some long expression ...> + < .. some long expression ...>

You have to parse the thing just to find out that the + buried in the
middle is the main connective. To parse it you have to take into
account operator precedence, associativity and all that. Until you do
the parse, you don't even know that it's an additive expression.

Lisp was deliberately designed so that the main connective is easy to
find without parsing. This isn't a coincidence; it makes it easier to
write code which analyzes and processes code. Such code is found in
Lisp macros, which are parts of a Lisp program that extend the
language with new syntax and semantics that other parts of a program
use.

So before I pass out - I shall post this message and retire.

Please tell us it's for good.

 

[JKop]

Stewart Gordon posted:

JKop wrote:


<snip>

If it's going to follow the sequence semantically, it would have to be
called "C+=2, C".

Stewart.

C += 2, C

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


-JKop