C++ sucks for games

[Trent Buck]

Quoth Jeff on or about 2004-11-14:

Sounds more like the question is "what is art?"

Art is anything a collector is prepared to pay for.

-trent

 

[Gerry Quinn]

While you're math is correct, it's only distantly related to the right
math to do. Basically, your math would be right IF you were talking
about randomly producing one specific output. The problem is that
there are MANY possible 4 megapixel pictures worth looking at. As
such, the correct question has little to do with the total number of
possiblities, and a great deal to do with the _percentage_ that are
worth looking at -- if 90% of the possible outputs qualified as art,
then random generation would typically do the job in a few seconds.
If, OTOH, only one in 2^256 arrangements is worth looking at, then the
chances of producing something interesting before the second law of
thermodynamics has its ultimate triumph are slim indeed.

I think the notion that even as many as one in 2^256 could conceivably
be worth looking at indicates a poor feel for the 'law of large
numbers' as applied to cases like this.

For an easier example to analyse, consider the set of all books 4
million characters long. What proportion are worth reading?

- Gerry Quinn

 

[Gerry Quinn]

I have taken your suggestion and modified it slightly. Guessing is
now a button-1 press. Aborting a line of guessing is pressing button-2
or button-3 anywhere on the board.
(center and right clicks on a right-handed three button mouse).

I just have it so that you can cancel a guess with a click. But on
retrospect, in Concentration that is cheating - I put it in
automatically because in most games it is a standard user interface. It
would only work in Concentration if no cards are turned over until all
arer selected.

The concentration game is written such that one can create a game
where one has to match any n tiles (where n >= 2). Its strange playing
match 3 on a 9x6 board. Makes my head hurt. The way the
game is written if 3 tiles need to match one has to get the first
two to match before one is even allowed to select a third tile. Is
this the proper rule for Concentration? (are their official rules?).

I don't know, but that's the rule I came up with also! I find you don't
need to increase the board size - sets of 3 are hard enough on small
boards!

- Gerry Quinn

 

[Gerry Quinn]

Quoth Gerry Quinn on or about 2004-11-13:

The issue is whether a large proportion
of tasks can be 'naturally' expressed in a form unique to Lisp, and in
no other way. In other words, what tasks 'naturally' require Lisp'd
unique features, and are much harder to express without them?

s/require/leverage/. There is a significant difference between X
`requiring' Y and X being able to take advantage of Y. Whether
deliberately or accidentally, you seem to be conflating these two
distinct relations.

I haven't enough experience with lisp to give good examples of tasks
that leverage Lisp extras. I will give some poor examples instead.

I earlier mentioned specialization of flow control structure[0], which
cannot be written correctly in C or C++. Another is return-from, which
can only be approximated in C / C++ with the goto operator.

The thing is, these are language features, and don't address the
question above - what problems really need them? As for augment.h, it
seems to be an attempt to create macros to extend C. If you do have a
problem that needs a functional language, I think you would be better
off using one rather than abusing C!

From any perspective, which is easier to read?:

dotimes (i, 10)
printf ("%d", i);

for (i=0; i<10; ++i)
printf ("%d", i);

For me, the second is easier, because of familiarity. But I donlt think
the first has any natural advantages to someone unfamiliar with either
language. They may ask "What's a dotime - some kind of dot?". printf()
is of course a C grotesquerie.

The easiest language to read for a naive reader would IMO be BASIC:

for i = 0 to 10
print i
next i


- Gerry Quinn

-trent
[0] See doseq() in http://144.132.79.25/~twb/src/common/augment.h

 

[Raistlin Magere]

For me, the second is easier, because of familiarity. But I donlt think
the first has any natural advantages to someone unfamiliar with either
language. They may ask "What's a dotime - some kind of dot?". printf()
is of course a C grotesquerie.

The easiest language to read for a naive reader would IMO be BASIC:

for i = 0 to 10
print i
next i

Well you could also write
(loop for i from 0 to 10 do
(print i))

 

[Trent Buck]

Quoth Gerry Quinn on or about 2004-11-14:

The thing is, these are language features, and don't address the
question above - what problems really need them?

I think we are debating different things. I contend[0] that, for at
least some tasks, a solution can be expressed more readily and succintly
by an experienced Lisp programmer in Lisp than an experienced C/C++
programmer in C/C++. You counter this by pointing out that solutions
can still be expressed in C/C++.

I am not disputing this. I have agreed and continue to agree with you
on this point. But as other denizens have pointed out, this is akin to
saying that all turing-complete languages are equal, simply because they
are turing-complete. I think this is a rather monochromatic view to
adopt, but until your demonstrate the ability to grade languages more
finely I see no pupose in continuing this discussion.

As for augment.h, it
seems to be an attempt to create macros to extend C. If you do have a
problem that needs a functional language, I think you would be better
off using one rather than abusing C!

I don't always get a to choose which language I use :-(

And I don't see it as abuse. I'm merely extending C upwards to the
algorithm in my head at the same time as I extend my algorithm down to
C. A dotimes loop is closer than a for loop to 'do { X } Y times',
which is how I think about some loops.

In that respect, dotimes() is to for() what for() is to while(), since
'for (I;P;M) B' is congruent to 'I; while (P) { B; M; }'.

(Oh, and C is just as functional as Lisp. The lack of memory manglement
and destructors simply makes it more difficult

printf() is of course a C grotesquerie.

Lisp's (format) isn't much better.

-trent

[0] Please note that this is an article of faith; I feel I do not have
sufficient empirical evidence to assert it as fact.

 

[Pete Kirkham]

For me, the second is easier, because of familiarity. But I donlt think
the first has any natural advantages to someone unfamiliar with either
language. They may ask "What's a dotime - some kind of dot?". printf()
is of course a C grotesquerie.

Additionally, you can't tell whether the loop variable ranges 1 to 10 or
0 to 9 using 'dotimes'.

The easiest language to read for a naive reader would IMO be BASIC:

for i = 0 to 10
print i
next i

I was going to point out that Fortran at least has the numbers 0 and 9
in the code which corresponds to the C for loop to print out the numbers
0 to 9:

do 100 i = 0, 9
write (*, *) i
100 continue

but I checked and so would the Basic one.


Pete

 

[Wade Humeniuk]

I don't know, but that's the rule I came up with also! I find you don't
need to increase the board size - sets of 3 are hard enough on small
boards!

Actually I added new games in the Game Menu of various sizes yesterday evening.
(Its in the new concentration.zip)
The biggest selection from the game menu is New 8x9 Match 4.
My 11 year old son played it last night. He actually found it funner at the
more difficult levels. Took him about 15 miuntes for the biggest game.
(He was very thankful for the abort button presses)

Wade

 

[Trent Buck]

Quoth Pete Kirkham on or about 2004-11-14:

Additionally, you can't tell whether the loop variable ranges 1 to 10 or
0 to 9 using 'dotimes'.

Unless a) you read the header; b) you read the documentation; or c) you
knew I borrowed it from Lisp

....but point taken.

-trent

 

[Jerry Coffin]

[ ... ]

I think the notion that even as many as one in 2^256 could conceivably
be worth looking at indicates a poor feel for the 'law of large
numbers' as applied to cases like this.

What part of "second law of thermodynamics has its ultimate triumph"
didn't you understand? The _ultimate_ triumph of the second law of
thermodynamics is when all the energy in the universe reaches
equilibrium...

IOW, when I cited 2^256, it was intended as a constrast, not as
something that was conceivably worth searching -- rather the contrary,
I cited it as something that was obviously ridiculous to even
consider.

As far as cases like this go, the basic problem is somewhat similar to
breaking encryption by exhausting the key-space. If you honestly care
about whether I have a feel for the subject matter, feel free to read
through my old posts on sci.crypt -- and even if you don't care much
about my feel for things, some of it is worth reading in its own right
-- darned little of it though...

 

[Jerry Coffin]

[ ... ]

I think we are debating different things. I contend[0] that, for at
least some tasks, a solution can be expressed more readily and succintly
by an experienced Lisp programmer in Lisp than an experienced C/C++
programmer in C/C++.

Especially if we restrict both to the base language (i.e. without
using add-on libraries) this would be almost impossible to dispute --
just for an obvious example, a program to multiply two 60-digit
numbers is clearly simpler in Lisp than in C or C++.

The same is true in the other direction as well though -- solutions to
some problems are clearly easier in C or C++ than in Lisp (e.g. many
typical engineering problems).

Unfortunately most people don't write things that fall so obviously
into an area where Lisp provides such obvious advantages -- I'm
reasonably certain my bank balance hasn't involved any 60-digit
numbers recently!

Many of the examples cited by the Lispers in this thread have the same
problem. At least to me, even if we all agreed that what a computer
produced really was art, it would miss the point.

The relevance of an example program having been written in a
particular langauge depends on the problem it solves being relevant to
the problems I'm likely to want to solve. Writing a program that does
"art" (even assuming we all agreed it was art) means little to me,
because I can see little relationship between the kinds of things it
probably does and the kinds of things I want to do.

The same is true in the other direction as well, though I think the C
and C++ advocates have been a bit more sensible (or at least
restrained) in what they cite, even though obvious examples in this
direction are much more relevant (and therefore compelling) to the
kinds of things I happen to do. Nearly all of us (on both sides of the
fence) run OSes written in C, post to an Internet that runs almost
entirely on code written in C, etc. At least for the problems I happen
to enjoy solving, those examples are far more relevant. If I had a
choice between creating a drastically better art program or a
drastically better router, I'd do the router (in fact, I sort of
already am...)

Now, that's NOT meant as a commentary on the fundamental capabilities
of the languages themselves, only on the examples that have been given
in this thread. I'm well aware that if I wanted to badly enough, I
could write the software for a router in Lisp. I believe, however,
that for this particular pursuit, Lisp would present more shortcomings
than advantages. Some of the Lisp advocates seem to believe (or at
least want others to believe) that Lisp always provides advnatages
with no weaknesses, an idea with which I disagree.

Another basic point that I think a lot of people miss is that in the
end, most of us ultimately program for enjoyment -- yes, my regular
job has something about "software" in the title, but if I didn't enjoy
programming, I'd find a different job. I believe I've mentioned
previously in this thread that I've written Lisp off and on for over
20 years, and implemented Lisp a few times as well. For better or
worse, Lisp just doesn't suit me very well -- I'm glad I studied it,
and I think my programs are better for having done so, but the fact of
the matter is that as far as real enjoyment goes, my first Lisp
interpreter (written in 8080 assembly language) was simply a lot more
fun than any of the coding I've ever done IN Lisp.

I'm the first to admit, however, the people differ from each other as
well -- the fact that I enjoy one thing more than another doesn't
imply that somebody else will do the same. A person's choice of
programming language is, to a large extent, a reflection of their own
personality. This is why the statement above about their being
problems that are easier to solve in Lisp more or less misses the
point. The real question is whether I (or whoever) find those
particular problems interesting to solve, and whether I find it
interesting to solve them in the way(s) that Lisp supports. In my
case, the answer is generally no. Others obviously disagree -- and
more power to them, IMO.

Unfortunately, at least to most appearances, most Lisp advocates have
a rather different sentiment: specifically that eveybody must
acknowledge that Lisp is the ultimate answer to all possible
programming problems. IMO, they're welcome to believe that if they
want, but the need they seem to feel to carry their crusade to the
rest of the world is annoying at best, and downright anti-social most
of the time -- on the order of somebody with whom every conversation
inevitably turns into an argument in which peace can only be restored
if everybody else acknowledges the superiority of their particular
political or religious views.

 

[beliavsky]

Additionally, you can't tell whether the loop variable ranges 1 to 10 or
0 to 9 using 'dotimes'.


I was going to point out that Fortran at least has the numbers 0 and 9
in the code which corresponds to the C for loop to print out the numbers
0 to 9:

do 100 i = 0, 9
write (*, *) i
100 continue

Since the 1990 standard you can terminate the do loop in Fortran with
enddo, rather than a numbered line with continue. Most Fortran 77
compilers offered this extension. The simplest solution in Fortran is
to use an implied do loop,

write (*,"(10(i6,/))") (i,i=0,9)

where the "/" in the repeat edit descriptor "(10(i6,/))" says to print
each 'i' on a new line. Fortran rules!

 

[Christer Ericson]

[...]
But they don't address the point I was making:

"The time it takes to sling together a few algorithms and produce a
basic pre-designed game is insignificant. Even if Lisp were ten times
more productive in this regard, it wouldn't make any difference. [...]
Productivity in messing around with small programs that are not for
general release is not really an advantage."

Tell me, is your point based on:

a) your extensive experience writing large programs,
b) your extensive experience with Lisp, or perhaps
c) your complete lack of experience with either.

It is based on my extensive experience in writing programs that are
large compared to the toy programs being discussed.

Christer, I suggest you back off.

No, seriously, do you have any experience whatsoever with
either large programs or Lisp? If not, what grounds do
you have for making this point?

Christer Ericson
Sony Computer Entertainment, Santa Monica

 

[David Steuber]

This is becoming a battle of words.
What does expressiveness really mean?
Turing complete, terse, succinct are easier to get a grip on.

Terse, succinct, and expressive are all nearly synonymous to me in
this context.

There is another issue. In Perl, for example, you can write very
terse code thanks to all the funky one character variables and stuff.
Reading it afterwards can be problematic though. I suspect there is
a point where code can be too concise so that the effort to read and
understand it is higher than for slightly more verbose code.

How densely packed do you want your ideas? Saving typing is good.
Being able to read the code six months later is also good.

I've found that Lisp tempts me into writing particularly descriptive
names for symbols mostly thanks to the simple legality of the -
character in a symbol name. This is not super terse, but it can be
darn readable if the name is well choosen. Even with the long names,
functions can still be quite short. It seems like a paradox but Lisp
makes it reasonable to do.

 

[Trent Buck]

Quoth David Steuber on or about 2004-11-14:

There is another issue. In Perl, for example, you can write very
terse code thanks to all the funky one character variables and stuff.

Someone once observed that if you count keystrokes instead of
characters, Perl isn't particularly amazing in this respect -- you hit
the shift key a lot.

Incidentally, parens don't need shift on my keyboard

-t

 

[Trent Buck]

Thank you. That was an EXCELLENT article; in fact it's very nearly the
article I would like to have written, were I articulate enough.
-t

 

[John Thingstad]

I've found that Lisp tempts me into writing particularly descriptive
names for symbols mostly thanks to the simple legality of the -
character in a symbol name. This is not super terse, but it can be
darn readable if the name is well choosen. Even with the long names,
functions can still be quite short. It seems like a paradox but Lisp
makes it reasonable to do.

Some languages like Pascal need to have code expressed a certain way to
even work.
You typically spend a lot of time finding that way.
Turbo Pascal (this was a long time ago..) got around many of the
limitations of Pascal by putting strange squiggles in comments
that altered the behaviour of code.
In comparison programming in C was a relief.
Suddenly the problem was't how to express a problem but rather
which method to choose.
I would then say that C is more *expressive* than Pascal.
Similarly I feel that Smalltalk fits like a straight jacket.
If forces you to convolute the problem to fit the language.
Again you spend your time battling the language rather
than working the problem.
Lisp is 'loose and free'. I can program in the paradigm of choice.
That would depend on the problem and my taste.
I have plenty of option's of how to express the problem.
So Lisp is more *expressive* than Smalltalk.

Succinct is accurate and to the point.
No messing about like them Turbo Pascal squiggles.

The less time you spend combating the language the
more time you have to focus on the problem.
There is a direct link to productivity I think.

 

[Frode Vatvedt Fjeld]

The same is true in the other direction as well though -- solutions
to some problems are clearly easier in C or C++ than in Lisp
(e.g. many typical engineering problems).

I know of two kinds of programs that are easier to write in C than
Lisp: Those that mainly interface with the very C-centric operating
systems/environments, and some casese of special-purpose
number-crunching programs where the "portable assembly"-mode of C can
provide decent performance reasonably well (so, the program as such
isn't easier to write, but getting the expected performance is). Other
than this, I know of no such "typical engineering problems".

Unfortunately most people don't write things that fall so obviously
into an area where Lisp provides such obvious advantages -- I'm
reasonably certain my bank balance hasn't involved any 60-digit
numbers recently!

Let's say your bank balance is represented as an integer number of
1/100 units of some currency. In 32-bit C, you'd be able to represent
some 40 million. It'd be an interesting event to see Bill Gates come
deposit his money and you explain to him that unfortunately "the
integer wrapped around, so we can only tell you your balance modulo 40
million". And what when you need to calculate the bank's accumulated
deposits? Or the average of this over the last three decades? Would
you try to ensure that 64-bit integers are used throughout and cross
your fingers that nothing unforeseen happens?

[..] At least for the problems I happen to enjoy solving, those
examples are far more relevant. If I had a choice between creating a
drastically better art program or a drastically better router, I'd
do the router (in fact, I sort of already am...)

Funnily enough, I happen to have written a sort-of ethernet switch in
Lisp

 

[Kaz Kylheku]

One might add that McCarthy's incentive to create LISP (yeah, old style)
was inspired by the awkwardness of expressing proofs using the Turing
machine as a model..

This is becoming a battle of words.
What does expressiveness really mean?
Turing complete, terse, succinct are easier to get a grip on.

Expressiveness is the degree to which you don't have to tell the
computer *how*, only *what*.

Usually, that also leads to terseness, because the what is usually
shorter than the how.

 

[John Thingstad]

printf() is of course a C grotesquerie.

Lisp's (format) isn't much better.

-trent

[0] Please note that this is an article of faith; I feel I do not have
sufficient empirical evidence to assert it as fact.

The big win in Lisp is on manipulation of complex data structures and
operations on them.

C's advantages is the closeness to the operating system and hardware.
C++ is pretty much the same.

You'r examples seem to be missing the key issues.