C++ sucks for games

[Frode Vatvedt Fjeld]

Of course, this is true of any high level language.

Not really.

In C++, customisation comes mostly from defining classes and
methods - the language syntax remains consistent throughout.

Which seems like a win to me...

It's really strange to see someone argue against something they
clearly have not the faintest idea of how works or what are the
benefits to be had. It's like seeing someone insisting on still using
horses for general transportation because they can't fit a car into
the stable, and what to do with all those horse-shoes?. It's just
uninformed.

 

[Alex Drummond]

It's not ambiguous if you're a C compiler, but it is if you're a human

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.

Depends on what you mean by ambiguous. It's pretty clear that what I meant
was something which could plausibly be thought to have several distinct
meanings. If you don't like me using the word ambiguous outside its narrow,
techincal sense to express that meaning, fine, but what I wrote made sense.

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.

FFS, I meant a line as in a unit of code which needs to be terminated by a
semicolon in C (should have said "statement", I guess). I did not literally
mean a sequence of characters terminated by a newline, since (as you so
kindly point out) this would have made what I said completely incorrect.
Doesn't take much charity of interpretation to work out what I meant here.

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!

Virtually all of C's infix operators are arithmetic (if you include
bitshifting, etc.). Your last sentence doesn't make any sense to me.

How can that possibly be confusing?

Erm, this is a classic C error. It looks like several statements belong to
the else clause (from the indentation), but actually only one does. Not so
difficult to spot, but at least as hard as the extra paren in your example
Scheme code.

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.

No, I know C++ better than I do Lisp, actually. It's only your pedantic
interpretation of "ambiguous" and "line" that have convinced you otherwise.

Regardless of how well I know C++, I'm certainly not a CL guru, and even I
was able to spot that extra paren almost immediately. It's not like we're
talking a difference between hours and days here.

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

Fair enough, but I wasn't referring back to that comment. I think someone
else on this thread posted a comparison showing that the typical number of
non-alphanumeric characters in C and Lisp source is virtually identical.


Alex

[ ... ]

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.

 

[Philippa Cowderoy]

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.

The ability for Spirit to exist and be used is still important though.
I've made a lot of use of similar libraries in Haskell, and it's looking
likely that this'll lead to a few things I simply couldn't have done with
parser generators.

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.

I do have use for parametric types in my day-to-day programming, but then
I don't have to do any extra work for the parametricity. I'm tempted to
agree with you as far as day-to-day C++ goes though.

 

[Alex Drummond]

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.

Well, you can do that in Lisp, but it's not usually encouraged. Usually you
generate the code at compile time (using macros) and thus there is no
self-modifying code by your definition.

You're also using a somewhat odd definition of "self-modifying". This is
generally taken to mean code which actually changes existing code at
runtime, rather than just adding more code.

But let's say we accept your definition. Virtually no-one is advocating Lisp
because it has the ability to generate code at runtime. This can be useful
in a few special cases, but it's not usually talked about in pro-Lisp
propaganda -- macros get much more attention.

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.

Maybe we can put that down to Lisp and C++ being Turing Complete


Alex

"GQ" == Gerry Quinn <[email protected]> writes:

[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

 

[Alex Drummond]

Programmers who want high performance numeric code. Or programmers who

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.

Expression templates tend to produce faster code, unless you want to write
out all your matrix multiplications, etc. out long had. Also, you can
combine expression templates with various loop unrolling tricks using
metaprogramming. (Personally I wouldn't do anything so vile -- I'd use
Lisp I totally agree that in the best case, this nasty stuff is kept
fenced off in a library.

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.

I don't agree, although I see your point. For me, C++ is just unusable
without templates. But this is probably because I'm used to languages with
proper static type systems, like ML and Haskell.

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.

They're less bolted on than C++ classes (for example you can write generic
functions dispatching on built in types). It's probably possible to write a
CLOS implementation solely using macros, but as far as I know most
implementations support CLOS more directly. In what sense do classes lack
access specifiers? There's no public/private/protected as such (although
you have the option for read-only access, etc.) but that's not because
these constructs couldn't be implemented in Lisp; it's just a design
decision of CLOS. CLOS isn't based on the C++/Simula model of OO.


Alex

 

[Jon Boone]

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.

What ever do you mean by "bolted-on"?

They are built with Lisp macros, no doubt for ideological reasons

Most of any Common Lisp system is going to be written in Common
Lisp (which means either macros or functions).

perhaps as a consequence they seem to lack things we might expect
such as access specifiers.

The lack of access specifiers is a design decision, not a
by-product of implementation.

What is it that you use access specifiers for?

--jon

 

[Bulent Murtezaoglu]

[...]
JB> The lack of access specifiers is a design decision, not a
JB> by-product of implementation.

JB> What is it that you use access specifiers for?

I know you guys are just waiting for someone to quote Erik Naggum on
c++ 'protections' by continously asking a c++ person 'why do you need
access specifiers.' So I will oblige:

"... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result is
that thieves and bums use C++ and nice people use CLOS."

happy flaming,

BM

 

[Jerry Coffin]

(e-mail address removed) (Jerry Coffin) wrote in message
[ ... ]

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.

Rereading this, it occurs to me that it could be interpreted as
implying that only "pretty simple" algorithms can be expressed in
Lisp, which was NOT my intent at all -- I was thinking of the hundred
to two hundred line limit previously expressed, and thinking that
quite a few of them could fit within this limit in either C++ or Lisp.

I apologize if anybody was insulted by my poor wording.

 

[Jon Boone]

[...]
JB> The lack of access specifiers is a design decision, not a
JB> by-product of implementation.

JB> What is it that you use access specifiers for?

I know you guys are just waiting for someone to quote Erik Naggum on
c++ 'protections' by continously asking a c++ person 'why do you need
access specifiers.'

Actually, I had no such intention. My purpose is to gain a better
understanding of what the access specifiers are actually used for.
I know the *theory* of how they are used, but what's the actual
practice?

When I first learned Java, I was put off by the fact that perl's
OO support didn't include mechanisms for *forcing* the protection.
This seemed wrong, because most of my exposure to OO at the time was
via C++/Java. I had done a wee bit of OO programming in Scheme
during college, but it wasn't easy for me to recall at the time.

The perl methods seem more acceptable to me now that I know CLOS.
Now I wish perl had more CLOS support, rather than more C++/Java
support.

Oh yeah, and I wish it had more parenthesis and prefix-syntax.

--jon

 

[Petter Gustad]

Another possibility is when something that looks like (and really
IS) C or C++ is interpreted as SystemC, which compiles the code all

I don't think this apply to a lot of applications. Further most
programs will benefit using a different algorithm when mapped to a
FPGA (or ASIC) from a Von Neumann architecture. An example is CRC
calculation which is usually implemented using a table in software,
but the using xor gates which have been parallelized from the serial
form in hardware.

You will find quite a bit of Lisp influence in the EDA world. Take a
look at the EDIF format, it's Lisp. SDF files for back annotation,
it's Lisp. Also some major EDA applications like Cadence Design
Planner was written in Lisp.

I use Common Lisp to increase my design productivity. I've written
tools to parallelize CRC, explore architectures, microcode assembler
generators, test environment to ASIC's that I've designed, etc. Even
though I know C++ (started C++ programming in the late 80's) better
than Common Lisp I'm more productive in Common Lisp and hence this is
the language of my choice.

Petter

 

[Hartmann Schaffer]

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

afaik, AMD used a lisp written system to verify the design of their 64
bit processors. search for ACL2 (sorry, don't have the url handy)

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

i briefly looked at the ACL2 website, and it seems quite capable of dong
that

hs

 

[Gareth McCaughan]

With that given, tests have repeatedly shown that C is far more
readable than Lisp. Just for an obvious example, consider finding
problems in code, such as:

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

In my testing, C programmers find the problem in the C code an average
of more than five times as fast as Lisp programmers find the problem
in the Lisp code.

Strange. I found the Lisp problem slightly faster than
I found the C problem; about 3 seconds for the C and
about 2 seconds for the Lisp. (I consider myself a fairly
expert programmer in both languages, and I have written
a lot more C and C++ than Lisp recently; I don't think
the difference can be explained by my being much better
at Lisp than at C.)

In addition, C compilers almost universally give
SOME sort of complaint pointing (at least indirectly) to the problem
in the C code (typically pointing out the dead code) while Lisp
compilers (and interpreters, the last time I looked) generally accept
the latter code without so much as a peep.

Really? The equivalent Common Lisp code produces an error
at compile time in CMU CL and at definition time in CLISP.
Your code seems to be in Scheme; the Scheme implementations
I've tried are much less satisfactory.

Lisp hardly provides a suitable platform from which to launch such a
diatribe. Rather the contrary -- Lisp has more extra punctuation than
nearly any other language extant.

Not true, actually.

In any case, while counting keystrokes has some meaning when
evaluating calculators (yes, I still use HPs), typing in punctuation
on a normal keyboard rarely seems to be a real source of major
problems. If terseness is your measure of choice anyway, then any
choice other than APL seems nearly indefensible for you.

On a large scale, Lisp is capable of being extraordinarily terse.
That doesn't tend to show up in toy programs, though, so it
doesn't get noticed so readily by newcomers to the language.

 

[Kenneth Tilton]

Strange. I found the Lisp problem slightly faster than
I found the C problem; about 3 seconds for the C and
about 2 seconds for the Lisp. (I consider myself a fairly
expert programmer in both languages, and I have written
a lot more C and C++ than Lisp recently; I don't think
the difference can be explained by my being much better
at Lisp than at C.)

Jeez, your eyes did not shriek aloud at that semi-colon at the end of a
line beginning "if ..."?!

You over-estimate yourself on C (which I have not done in anger for nine
years).

As for a Lisp excerpt beginning "(1 ", well, ...

PWUAHHHAAHAHHAHAAHAHAAHHAAAAA....

You all need to just stop this idiotic thread. There is one simple idea,
to be respected or rejected: those who are saying "lisp roolz" are also
people who know one or more of C, Java, C++, Python, Perl, and Ruby, and
they are saying Lisp is so dramatically more effective for them that
they would not use anything else (if their bosses let them). meanwhile,
there are no such ranters for other languages which also know Lisp.

Draw your own conclusions.

kt

 

[Szymon]

[.....]

(+ (complex 3 3) (complex 3 -3) 3) => 9

why not

(+ #C(3 3) #C(3 -3) 3)

;-)

[.....]

Regards, Szymon.

 

[Petter Gustad]

[.....]

(+ (complex 3 3) (complex 3 -3) 3) => 9

why not

(+ #C(3 3) #C(3 -3) 3)

I did not want to introduce a new syntax (i.e. a reader macro) and
confuse the OP (maybe suggest that I had written C# backwards . It
appears that he was confused enough already. Hence I chose to use the
complex function since it represents the same syntax as he had been
shown earlier in the thread, even though it's more verbose.

Petter

 

[Gerry Quinn]

Well, you can do that in Lisp, but it's not usually encouraged. Usually you
generate the code at compile time (using macros) and thus there is no
self-modifying code by your definition.

You're also using a somewhat odd definition of "self-modifying". This is
generally taken to mean code which actually changes existing code at
runtime, rather than just adding more code.

I disagree - it is in fact rare for code to be changed per se. What
would be the point in writing code whose only purpose is to be written
over? Whether original code is erased or not is completely irrelevant
to the issue of whether code is self-modifying. The *program* is still
self-modifying.

But let's say we accept your definition. Virtually no-one is advocating Lisp
because it has the ability to generate code at runtime. This can be useful
in a few special cases, but it's not usually talked about in pro-Lisp
propaganda -- macros get much more attention.

I believe it was part of the belief some years ago that Lisp was somehow
the way to create AI. But I accept that things may have moved on.
Albeit only as far as macros.

- Gerry Quinn

 

[Gerry Quinn]

They're less bolted on than C++ classes (for example you can write generic
functions dispatching on built in types). It's probably possible to write a
CLOS implementation solely using macros, but as far as I know most
implementations support CLOS more directly. In what sense do classes lack
access specifiers? There's no public/private/protected as such (although
you have the option for read-only access, etc.) but that's not because
these constructs couldn't be implemented in Lisp; it's just a design
decision of CLOS. CLOS isn't based on the C++/Simula model of OO.

That seems clear. May it be assumed it does not claim to possess the
advantages of the C++/Simula model of OO?

- Gerry Quinn

 

[Gerry Quinn]

The lack of access specifiers is a design decision, not a
by-product of implementation.

What is it that you use access specifiers for?

The same thing I use the safety catch on a gun for. It stops me
shooting myself in the foot.

- Gerry Quinn

 

[Gerry Quinn]

Not really.

What do you mean? Rabbit::Jump() seems a perfectly applicable example.

It's really strange to see someone argue against something they
clearly have not the faintest idea of how works or what are the
benefits to be had. It's like seeing someone insisting on still using
horses for general transportation because they can't fit a car into
the stable, and what to do with all those horse-shoes?. It's just
uninformed.

Well, many of the boasts about Lisp seem to be about its ability to
create 'new languages' for a given problem domain. You mutter about
people not seeing the benefits, but you don't seem so keen to elucidate
them.

- Gerry Quinn

 

[Computer Whizz]

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.

Yes - but "our" buildings have walls between the rooms.
(OK - I sound like an ass a little there... Still, Lisp programmers seem all
happy and ine saying "I can read Lisp code OK" when it's not you - but the
editor reading it out for you.
I might use a simple syntax highlisghter to show variables/functions/static
text but I can just as easily judge and evaluate raw C/C++/most other
languages - even if they've been typed by a monkey with no actual use of the
tab key... )

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.

That's where they differ more prominently! C/C++/whatever IS (at least in my
mind) very similar to English. It has words following each other in a
"flow".