C++ sucks for games

[Peter Ashford]

Appologies for digging up this rather old thread, but I'd not read
comp.games.development.programming.misc for a wee while and the title of
this thread just made me laugh out loud.

It's like standing in front of the pyramids and saying "Stones suck for
construction". Jeez, C++ may have some flaws (lots, even), but it's
done kinda okay in the game development stakes ;o)

 

[Gerry Quinn]

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?

I answered you: obviously I have experience with programs *large enough*
to be able to make this point. The games on my website are quite large
enough. Any game bigger than about 2 KLOC that has significant non-code
elements is large enough. With the exception of Naughty Dog's not
particularly successful experiments with using Lisp [I make no comment
about the games themselves - I know they have been well-received but I
haven't played them], my games seem in fact to be about as large as any
game that has ever been developed in Lisp. Which justifies my
observation in another way. If it's so great, why isn't it competing in
the marketplace?

And furthermore:

With regard to "slinging together a few algorithms and producing a basic
pre-designed game", you may note that I've done that in C++ and two
others have done it in Lisp on this thread, taking about two hours each.
And now if we want to extend this rather trivial but playable game, we
will have to sit back and think about user interfaces, graphics,
gameplay options, etc. We'll have a little bit of algorithmic work to
do if we want to create AIs, but again it will be a tiny part of it.
Probably it will take longer to select / create a series of AI faces to
respond to game state than it will to code the AI for 'Concentration',
(though it must be admitted that this is as primitive as AI gets). In
other words, MAKING FINISHED GAMES IS NOT ABOUT EASE OF EXPRESSING
ALGORITHMS. And I see no reason to suppose that it will become so in
larger projects, even in _James Bond's 3D Concentration 2005_. So,
irrespective of any experience I may or may not have, I consider the
point substantially justified by argument on this very thread.

Now, are you going to address the point, or continue with the ad
hominems. Or do you in fact accept its validity, but merely object to
me saying it?

- Gerry Quinn

 

[Gerry Quinn]

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

Well, I would be far more interested in art - I do screensavers, after
all, and a screensaver that paints would be cool. As for routers, let
alone their efficiency, I have no interest in them whatsoever!

I suspect that any 'artist' AI I did would be in C++. Even if I were
manipulating strings of interacting semantic tokens, I would likely
treat them as data. Lisp-ers would assert that I was "re-creating Lisp
in C++", perhaps with some justification. But it's do-able, and would
probably be a relatively small part of the development process...

[Obviously the above is speculative as I don't know how to make an
'artist' AI, and maybe I would be forced to consider another language if
I did figure it out.]

- Gerry Quinn

 

[Gerry Quinn]

Gerry Quinn wrote:

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

but I checked and so would the Basic one.

Good point - that puts Basic ahead even further in this regard.

- Gerry Quinn

 

[John Thingstad]

Appologies for digging up this rather old thread, but I'd not read
comp.games.development.programming.misc for a wee while and the title of
this thread just made me laugh out loud.

It's like standing in front of the pyramids and saying "Stones suck for
construction". Jeez, C++ may have some flaws (lots, even), but it's
done kinda okay in the game development stakes ;o)

Agreed

This thread has been on any topic known to man.
I think it was started on Lisp sucks for games.
And then someone turned the rounds.
C is good at low level.
Lisp is good at data strucures.
C++ data strucures are more laborious.
So we have a good old combo C + Lisp.

comments?

 

[Stefan Scholl]

comments?

Nope.

 

[Jon Boone]

With regard to "slinging together a few algorithms and producing a
basic pre-designed game", you may note that I've done that in C++
and two others have done it in Lisp on this thread, taking about two
hours each.

Do you consider the concentration game to be simple enough that
any "competent" programmer ought to be able to throw it together in
two hours?

Should we take into consideration the total years of programming
experience of the folks who threw them together?

Is it relevant as to how long each of you has been programming in
the language that you used to throw it together in two hours?


It seems to me that the point you make about it taking as long in
lisp as in C++ (where the original claim was lisp was more
productive) can not be substantiated meaningfully without this extra
context.

--jon

 

[Philip Haddad]

OK, I'm going to voice my thoughts on this issue, since the main
reason I started programming was to write games. I've gone from C to
C++ to misc other languages, and now Lisp. I think that C++ is
probably the best language to write a game in IF it is meant to be
commercial and up fast. This is just because of the fact that there
are a lot of C++ libraries already written. Not so for Lisp. (NOTE:
Keep up the good work Kenny!)
However, I think that the key point is that C++ is very fast at
complex math operations. This is important for objects that are
rasterized, floating cameras, etc. Even though Lisp has dozens of
types ranging from bignum to fixnum to integer, it is still slower
than C++ at complex math operations. Lisp needs a library that it can
load at run-time that provides faster math types. Not nessecarily C++
style types, but maybe similar.
The again, I am still pretty new to Lisp so maybe there are ways that
floating cameras and such can be implemented without too much
trouble... if this is the case, please let me know. Also, quaternions,
which are really easy to construct in C++; I can't figure out how to
in Lisp. (NOTE: Incorrect use of semicolon in previous sentence). Does
anyone know how to do quaternions in Lisp here?
Finally, there is the matter of the GC. I don't really have any good
ideas on this, except that there may need to be a different algorithm
in place for game GCs.

 

[Peter Lewerin]

It's like standing in front of the pyramids and saying "Stones suck for
construction".

Well, that was an interesting analogy. Judging by the realities of
pyramid building, I'd say the only reasonable conclusion would be
approximately "Stones suck for construction".

Reversing the analogy, you seem to be saying that using C++ for game
development is extremely labor intensive, will almost always be
finished far too late, is lamentably inefficient (compare total size
to usable volume in the pyramids) and incomplete (if you want any kind
of utilities (such as light or fresh air) in a pyramid, you have to
bring them yourself), can really only be attempted by large
corporations - preferably governments, and has frankly been obsolete
since before antiquity.

I think C++ is a lot better than that. Maybe not as good as Lisp, but
it's still very good for most projects.

;-)

 

[rif]

However, I think that the key point is that C++ is very fast at
complex math operations. This is important for objects that are
rasterized, floating cameras, etc. Even though Lisp has dozens of
types ranging from bignum to fixnum to integer, it is still slower
than C++ at complex math operations. Lisp needs a library that it can
load at run-time that provides faster math types. Not nessecarily C++
style types, but maybe similar.

This is not entirely correct. Many (but not all) Common Lisp
implementations compile to native code. Use such an implementation.
Be willing to declare the types of variables in inner loops. Play
with it a while. You will find (as I did) that numerical programs
will be essentially the same speed as C. CMUCL is especially strong
in this regard.

rif

ps. I *do* feel that CL's lack of "inline" non-homogeneous arrays
(i.e. arrays of structures) gives C/C++ advantages for certain kinds
of programs which need to be simultaneously quite fast and extremely
memory efficient, but that's a different story.

 

[Peter Lewerin]

(e-mail address removed) (Jerry Coffin) wrote

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.

I think you'd find it difficult to find even one Lisp advocate that
takes that position. There are Lisp kooks (such as the one who
started this thread), of course, but what language doesn't have its
share of those?

I think the problem is rather that most people in the programming
business are so thoroughly convinced that Lisp is a useless and
obsolete language that when they see someone advocating it, they
immediately assume that this person is insane, ignorant,
proselytizing, or all of those at the same time. In my experience,
"coming out" as a Lisp user is considered at best eccentric, at worst
rude and provocative, on the "standing up in church and announcing
that you're a gay Wiccan" level of 'provocative'.

I honestly don't care one bit what language people use for
programming, and I don't know any Lisper who does either.

 

[Pascal Bourguignon]

Does anyone know how to do quaternions in Lisp here?

Don't you know how to program a function in lisp?



(defpackage "HAMILTON-COMMON-LISP"
use "COMMON-LISP")
shadow "+" "*" #|...|#))
(defpackage "HAMILTON-COMMON-LISP-USER" use "HAMILTON-COMMON-LISP"))
(in-package "HAMILTON-COMMON-LISP")
(do-external-symbols (s "COMMON-LISP")
(unless (member (symbol-name s) '("+" "*" #|...|#) :test (function string=))
(export s)))
(export '(QUATERNION QUATERNIONP + * #|...|#))



(defstruct (quaternion
constructor %make-quaternion)
predicate quaternionp)
print-object print-object))
(ri 0 :type number)
(jk 0 :type number));;quaternion


(defmethod print-object ((self quaternion) stream)
(format stream "#Q(~A ~A ~A ~A)"
(realpart (quaternion-ri self))
(imagpart (quaternion-ri self))
(realpart (quaternion-jk self))
(imagpart (quaternion-jk self)))
stream);;print-object

;; TODO: Add a read syntax for #Q(r i j k)


(defun quaternion (r &optional (i 0) (j 0) (k 0))
(%make-quaternion :ri (complex r i) :jk (complex j k)))


(defun q+ (&rest args)
(if (null args)
0
(do ((args (cdr args) (cdr args))
(ri (quaternion-ri (car args))
(common-lisp:+ ri (quaternion-ri (car args))))
(jk (quaternion-jk (car args))
(common-lisp:+ jk (quaternion-jk (car args)))))
((null args) (%make-quaternion :ri ri :jk jk)))));;q+


(defun q* (&rest args)
(if (null args)
1
(do ((args (cdr args) (cdr args))
(ri (quaternion-ri (car args))
(common-lisp:-
(common-lisp:* ri (quaternion-ri (car args)))
(common-lisp:* jk (conjugate
(quaternion-jk (car args))))))
(jk (quaternion-jk (car args))
(common-lisp:+
(common-lisp:* ri (quaternion-jk (car args)))
(common-lisp:* jk (conjugate
(quaternion-ri (car args)))))))
((null args) (%make-quaternion :ri ri :jk jk)))));;q*


(DEFUN + (&REST ARGS)
"
DO: A Generic addition with numbers or quaternions.
"
(COND
((EVERY (FUNCTION NUMBERP) ARGS)
(APPLY (FUNCTION COMMON-LISP:+) ARGS))
((EVERY (FUNCTION QUATERNIONP) ARGS)
(apply (function q+) args))
((some (lambda (x) (not (or (numberp x) (quaternionp x)))) args)
(ERROR "Incompatible types for '+': ~S"
(MAPCAR (FUNCTION TYPE-OF) ARGS)))
(t (apply (function q+)
(mapcar
(lambda (x) (cond
((quaternionp x) x)
((complexp x) (quaternion (realpart x) (imagpart x)))
(t (quaternion x)))) args)))));;+


(DEFUN * (&REST ARGS)
"
DO: A Generic multiplication with numbers or quaternions.
"
(COND
((EVERY (FUNCTION NUMBERP) ARGS)
(APPLY (FUNCTION COMMON-LISP:*) ARGS))
((EVERY (FUNCTION QUATERNIONP) ARGS)
(apply (function q*) args))
((some (lambda (x) (not (or (numberp x) (quaternionp x)))) args)
(ERROR "Incompatible types for '*': ~S"
(MAPCAR (FUNCTION TYPE-OF) ARGS)))
(t (apply (function q*)
(mapcar
(lambda (x) (cond
((quaternionp x) x)
((complexp x) (quaternion (realpart x) (imagpart x)))
(t (quaternion x)))) args)))));;*


;;;; hamilton.lisp -- -- ;;;;


Then:

(in-package "HAMILTON-COMMON-LISP-USER")
(+ 10 (quaternion 1 1 1 1) (complex 100 100)) ==> #Q(111 101 1 1)
(* 2 (quaternion 0 0 0 1) (complex 0 1)) ==> #Q(0 0 2 0)

Of course, you may add a lot of overiding functions, such as ABS,
TYPEP, etc. Right now:
(typep (quaternion 0 0 0 1) 'number) ==> NIL ; it should return T...

 

[Jerry Coffin]

[ ... ]

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

My guess is that in this case, you're either carefully maintaining
ignorance, or else for you Lisp is automatically simpler until/unless
it's _drastically_ more complex (e.g. 100 times as much code).

Just for example, I was recently looking at some C++ code for
designing FIR filters. It's part of SPUC, available at
spuc.sourceforge.net. As-delivered, the particular piece I'm looking
at (remez_fir.cpp) contains 282 lines of actual code (i.e. lines that
contain _anything_ other than white space or a comment).

I did a search for Lisp code that was apparently (about) equivalent,
and (to eliminate personal bias allowing me to pick a particularly bad
example) took the first thing Google turned up. The result was:

http://www.dxarts.washington.edu/docs/clmman/fltdes.lisp

Looking specifically at the code for Remes exchange. Using the same
criteria (lines, as delivered, that contain something other than
comment or whitespace) it's slightly longer (313 lines). Worse, while
I'm sure some people know Lisp enough better than C++ that they find
it easier to follow, it's difficult for me to imagine how that could
be. Nearly no name in the code is more than a couple of characters
long, and most are utterly meaningless, even to somebody who starts
out knowing what he's looking for.

Far worse, however, is the flow of control: the C++ code contains 9
functions, with a bunch of loops (I didn't try to count them) and the
only thing that qualifies as "unstructured" even from a completely
puritanical viewpoint is 2 break statements.

At least if I'm reading it correctly, the Lisp is a whole different
story. In fact, I'm scared to describe it -- I'd appreciate it if one
of the more frequent Lisp users would check, but are all those "go's"
what I think they are?

I have to admit that even I can hardly believe I could have stumbled
across such awful code by accident, but I've re-checked: I simply
typed "Lisp FIR filter" into Google, following the _first_ link it
came up with, clicked on "filter" in the "brief index" and then
clicked on the link to "fltdes" on about the sixth line (or so)
showing on-screen at that point. IOW, I'm pretty sure I didn't do much
where I could have influenced the choice of what code I looked at, but
unless I'm reading it entirely incorrectly, I'd be hard-put to blame
anybody for thinking I spent hours coming up with the worst piece of
garbage on the planet.

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.

What is this "32-bit C", you speak of? About all I can think of that
you might be talking about is "C prior to the current standard". The
current standard for C includes a 'long long' data type that has a
minimum of 64 bits. This isn't exctly a brand-new standard either --
it's been around for roughly 5 years now.

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?

If I want 64-bit integers used throughout, I won't _try_ do so -- I'll
use long long and it WILL happen.

As far as the rest goes, you're going back to exactly the kind of
examples I talked about before: things that are utterly remote from
what most of us care about or have any use for.

Let's face reality: I'm pretty sure my bank wouldn't tell me their
total deposits to the penny right now, not to mention for every one of
the last 30 years. Even if we assumed that it did, it would be an
amazingly large bank indeed for even a 30-year total of deposits to
exceed what fits into a 64-bit integer.

Even a ridiculous as those are, we're left with the final step, which
is the most utterly ridiculous of all: the notion that anybody in the
world cares at all about whether that number ends with 71 or 72 cents.

When you're dealing with an individual account, being accurate to the
penny matter. When (for example) large companies do their quarterly
SEC filings, they typically round to something like hundreds of
thousands of dollars -- even though they're NOWHERE close to exceeding
the range of a 64-bit integer.

[ ... ]

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

I guess that might be a fun project, but there's really not a whole
lot to an Ethernet switch. A router is in a completely different
league. Some types of switches (e.g. ATM switches) are fairly complex,
but Ethernet switches are pretty trivial, almost regardless of the
language you choose.

 

[Brian Downing]

http://www.dxarts.washington.edu/docs/clmman/fltdes.lisp

Looking specifically at the code for Remes exchange. Using the same
criteria (lines, as delivered, that contain something other than
comment or whitespace) it's slightly longer (313 lines). Worse, while
I'm sure some people know Lisp enough better than C++ that they find
it easier to follow, it's difficult for me to imagine how that could
be. Nearly no name in the code is more than a couple of characters
long, and most are utterly meaningless, even to somebody who starts
out knowing what he's looking for.

Far worse, however, is the flow of control: the C++ code contains 9
functions, with a bunch of loops (I didn't try to count them) and the
only thing that qualifies as "unstructured" even from a completely
puritanical viewpoint is 2 break statements.

At least if I'm reading it correctly, the Lisp is a whole different
story. In fact, I'm scared to describe it -- I'd appreciate it if one
of the more frequent Lisp users would check, but are all those "go's"
what I think they are?

Uh, if you look at the comments that file looks a hell of a lot like an
(very direct) translation of some Fortran code. So if it looks like
Fortran, that's probably why. Compare with the output of f2c.

Heck, it even says at the top:

;;; translation of most of the FORTRAN programs given in "Digital Filter
;;; Design" by Parks and Burrus

I doubt you'd find any competent Lisp programmer who would actually
write new code like that - it's nasty.

It is unfortunate that your search turns that up as the first result.

-bcd

 

[Peter Seibel]

[ ... ]

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

My guess is that in this case, you're either carefully maintaining
ignorance, or else for you Lisp is automatically simpler
until/unless it's _drastically_ more complex (e.g. 100 times as much
code).

Just for example, I was recently looking at some C++ code for
designing FIR filters. It's part of SPUC, available at
spuc.sourceforge.net. As-delivered, the particular piece I'm looking
at (remez_fir.cpp) contains 282 lines of actual code (i.e. lines
that contain _anything_ other than white space or a comment).

I did a search for Lisp code that was apparently (about) equivalent,
and (to eliminate personal bias allowing me to pick a particularly bad
example) took the first thing Google turned up. The result was:

http://www.dxarts.washington.edu/docs/clmman/fltdes.lisp

Looking specifically at the code for Remes exchange. Using the same
criteria (lines, as delivered, that contain something other than
comment or whitespace) it's slightly longer (313 lines). Worse,
while I'm sure some people know Lisp enough better than C++ that
they find it easier to follow, it's difficult for me to imagine how
that could be. Nearly no name in the code is more than a couple of
characters long, and most are utterly meaningless, even to somebody
who starts out knowing what he's looking for.

Far worse, however, is the flow of control: the C++ code contains 9
functions, with a bunch of loops (I didn't try to count them) and the
only thing that qualifies as "unstructured" even from a completely
puritanical viewpoint is 2 break statements.

At least if I'm reading it correctly, the Lisp is a whole different
story. In fact, I'm scared to describe it -- I'd appreciate it if one
of the more frequent Lisp users would check, but are all those "go's"
what I think they are?

You did read the comments at the top of the file didn't you?
Particularly this one:

;;; translation of most of the FORTRAN programs given in "Digital
;;; Filter Design" by Parks and Burrus

And "translation" may well be generous--transliteration is more like
it. This is hardly idomatic Lisp code.

But in a perverse way this shows another of Common Lisp's strengths.
While TAGBODY and GO are almost never used directly since there are
higher-level control constructs built on top of them for all your
structured programming needs, the fact that they are available does
allow Common Lisp to be used to do this kind of transliteration. Which
is another kind of expressiveness. For instance, suppose one started
from a working FORTRAN program--as these authors seem to have done.
You could do a straight transliteration into GO-full Common Lisp and
get it working. Now you have a version in Common Lisp that works and
you can hook it into your test framework and then start refactoring it
into idomatic Common Lisp while being fairly confident that you're not
breaking anything. To say nothing of the fact that you could probably
write a few ad-hoc refactoring tools in Lisp to help tidy up the
FORTRAN-esque code 'cuz of that whole code-is-data thing.

-Peter

 

[Kenny Tilton]

OK, I'm going to voice my thoughts on this issue, since the main
reason I started programming was to write games. I've gone from C to
C++ to misc other languages, and now Lisp. I think that C++ is
probably the best language to write a game in IF it is meant to be
commercial and up fast. This is just because of the fact that there
are a lot of C++ libraries already written. Not so for Lisp. (NOTE:
Keep up the good work Kenny!)
However, I think that the key point is that C++ is very fast at
complex math operations. This is important for objects that are
rasterized, floating cameras, etc.

Thx for the encouragement, but if someone hired me tomorrow to do a
first-person shooter, I would simply research the best open game engines
and write the bindings. If it was C++, we would grind out the necessary
"C" glue. The game play would be in Lisp. We might even build a language
On Lisp which non-techies could use to script scenarios.

The game engine would include scene graph management for optimized
rendering and a physics engine for optimal simulation of the game world.
I would not be worried so much about speed as I would be about
development cost, but you would get your C/C++* if that is your concern.
Probably the greater speed advantage would come from (hopefully) better
algorithms in mature libraries.

kenny

* This also facilitates pulling off "a Corman", in which one reassures
management that one is using C++.

k

 

[Frode Vatvedt Fjeld]

Just for example, I was recently looking at some C++ code for
designing FIR filters. It's part of SPUC, available at
spuc.sourceforge.net. As-delivered, the particular piece I'm looking
at (remez_fir.cpp) contains 282 lines of actual code (i.e. lines
that contain _anything_ other than white space or a comment). [..]

Taking what I presume you consider a decent piece of C++ code as a
starting point, and then comparing it to the google "I feel lucky"
Common Lisp version, isn't a terribly good way to eliminate personal
bias. In fact, just "terrible" describes that method better, IMHO.

And, I suspect, don't FIR filters fit my description of one of the two
areas where the benefits of Common Lisp aren't all that clear, namely
some special purpose number crunching? I mean, when you have some
functional abstraction with a very clearly defined mathematical
relationship between input and output, and algorithms without too much
fancy control flow, then almost any language/syntax will do (sometimes
even assembly), and effortless (predictable) performance becomes the
more important factor.

Finally, it seems to me others here have showed that properly written
Common Lisp does quite a bit better than the example you found.

What is this "32-bit C", you speak of? About all I can think of that
you might be talking about is "C prior to the current standard". The
current standard for C includes a 'long long' data type that has a
minimum of 64 bits. This isn't exctly a brand-new standard either --
it's been around for roughly 5 years now.

So since five years, no 32-bit C integer wrap-around has occured by
mistake? The whole issue is simply solved by introducing 64-bit "long
longs"? And the possibility of any computation exceeding 64 bits of
integer precision can just be ignored? Pennies can be ignored, even if
we're counting millions of transactions? Well, then I suppose C++
really is the language for you.

If I want 64-bit integers used throughout, I won't _try_ do so --
I'll use long long and it WILL happen.

Right, it's everyone else who make the bugs happen. What a pity it's
not you who write all software.

 

[Gerry Quinn]

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

I don't find that. Succinct, perhaps, but I see no special merit in
terseness. Surely the ease of recognition of common patterns and idioms
is far more important?

I speak as one who has of late taken to scoping off any part of a
function that has variables local to that part, with a pair of curly
brackets that have a line each. (Dividing functions into 'mini-
functions' that can be refactored as necessary, if you like.)

Maybe I've just got a bigger screen. (Or maybe it's because using a
mouse it's easier to scroll?

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.

Fortunately, this Lisp advantage has been incorporated into all
languages since Fortran, by way of the underscore '_' character. The
new 'camelCase' technology has also helped with giving comprehensible
names to symbols. (Of course it only works when case is significant...)

- Gerry Quinn

 

[Gerry Quinn]

Do you consider the concentration game to be simple enough that
any "competent" programmer ought to be able to throw it together in
two hours?

Should we take into consideration the total years of programming
experience of the folks who threw them together?

Is it relevant as to how long each of you has been programming in
the language that you used to throw it together in two hours?

That's a valid point. You would need fluency with the language,
familiarity with relevant libraries, and familiarity with game
programming idioms. If any beginning programmer, in whatever language,
is about to shoot himself because it looks like Concentration is going
to take him several days - don't do it! You WILL get better!

Of course there is another point as well - how much does the
productivity of beginners count? It counts for something (look at the
popularity of Basic) but does it count for large single-purpose
projects?

It seems to me that the point you make about it taking as long in
lisp as in C++ (where the original claim was lisp was more
productive) can not be substantiated meaningfully without this extra
context.

Well, there is truth in that, but on the other hand, "how fast can an
experienced programmer do it" is probably a pretty relevant metric. As
for inexperienced programmers, I don't think Lisp is going to take over
from VB any time soon...

- Gerry Quinn

 

[Gerry Quinn]

This is not entirely correct. Many (but not all) Common Lisp
implementations compile to native code. Use such an implementation.
Be willing to declare the types of variables in inner loops. Play
with it a while. You will find (as I did) that numerical programs
will be essentially the same speed as C. CMUCL is especially strong
in this regard.

From what I've seen, Lisp is deployable (more neatly than Java) on the
main target platform for indie games and it should be fast enough for
many projects, if not all of them.

I certainly think Lisp is a viable language for developing games,
although nothing has convinced me that it's better than C++. Probably a
proliferation of finished PC games would do more to convince me than all
the argument in the world.

- Gerry Quinn