C++ sucks for games

[Kenny Tilton]

That's more an example of what I'm saying than a refutation of it. Lots
of gushing about Lisp, but hardly a mention of any shipped projects...

If you click on the name next to each "gush" you can read the full story
behind it. While I jokingly called them "Sound bites to die for", as one
who made the shift from C to Lisp I can assure you that what look like
gushes are actually simple, sober statements of fact. Lisp is that much
better.

As you can imagine, every author programs in all the usual languages as
well as Lisp. "no projects" is simply a measure of Lisp's current
miniscule (but growing) mindshare. The proof is that successful projects
such as paul graham's on-line store software got translated from Lisp to
(Java? C++? I forget) after Yahoo acquired it. I just learned another
successful product developed in Lisp got translated to java, probably to
be more marketable (I have not heard why, just that the java version is
/less/ capable than the Lisp version.)

kenny

 

[Jerry Coffin]

I don't know what Tim Paterson used when he wrote the original QDOS in
6 weeks in 1980, but I very much doubt that it was C, which I think
was still a rather experimental thing used by the strange cult of
unixists at that time.

That's actually open to some controversy. I don't know whether it's
really accurate or not, but according to some of the people and
Digital Research, Tim didn't really write much new at all: he just
ported CP/M to the x86. A fair amount of CP/M was written in PL/M (a
PL/I variant) and source was (they claim) routinely distributed to
system integrators and such. There was a PL/M86 compiler (though I'm
not sure exactly when it became available), so a simple re-compile at
least sounds like a semi-plausible possibility. I never saw the source
code to it myself, so I can't really comment on how portable it was or
how much rewriting a port would have entailed.

If true, this would mean that the first versions of MS-DOS were
written in PL/M86, but it's only fair to point out that the people
making the claims had a fairly clear interest in those claims being
believed.

In any case, I would be exceptionally surprised if those versions of
MS-DOS were written in C++ or even C.

 

[Hartmann Schaffer]

I don't know what Tim Paterson used when he wrote the original QDOS in
6 weeks in 1980, but I very much doubt that it was C, which I think
was still a rather experimental thing used by the strange cult of
unixists at that time.

you couldn't write an OS for the 8086 in C before atrocities like near,
far, huge, etc were invented, and that came later

hs

 

[Rahul Jain]

But I think it may be too recursive & bottom-up programming for most brains
to want to deal with...

Your code may be, but my Lisp code isn't.

Bottom-up is useful when you're trying to build a system that has
certain behaviors and then gradually link up those behaviors into a
program as you figure out what the program should do. E.g., first build
the physics engine and then build the game logic once the game designers
have figured out how the gameplay should be.

 

[Rahul Jain]

All big applications need a scripting layer, an efficient engine layer, and
back-end layers in assembler. There is no /a-priori/ way to guess where the
cutoff between them is, or what language to use in the scripting layer.

That is a perfect argument for using Lisp, since your scripting layer is
simply the use of the operators defined in the engine layer. And, of
course, you can use your Lisp implementation's way of doing assembly
routines (using lisp macros to micro-optimize the really
performance-sensitive bits.

 

[Rahul Jain]

many of these issues may exist, but are not that big of a deal really, and
there is the problem that higher-level languages often have a poor c
interface and typically need interface stuff to be written to access c code
(and thus most system api's, along with parts of the project likely being
written in c).

Good thing he wasn't talking about the higher-level languages you often
see, then.

 

[Rahul Jain]

Yes I can. I can write a module that runs one or two functions from the
project as the whole program.

And where does the state of the game come from in that module?

 

[cr88192]

Good thing he wasn't talking about the higher-level languages you often
see, then.

yes, this is primarily a problem with interpreted languages...

with compiled languages there is a lot of variation in ffi quality.

 

[Rahul Jain]

I can't comment on this one way or the other, as I only have a few
months experience with Lisp. My guess is that the implicit interface
will prove similarly difficult to modify with Lisp as the static type
system does with C++.

Any eXtreme Programming Lispers or C++-ers care to comment?

His point was not about the sum total of work needed. He specifically
emphasized "*test*". If you want to change something in your design in
C++, you need to propagate that change everywhere. In Lisp, you just
change the code and load it and play around with the bits you've
changed. When you want to play around with other parts, you start
changing them. If it looks like this is a bad idea, you can just revert
back to what's in source control and figure out a different way.

 

[Espen Vestre]

That's actually open to some controversy. I don't know whether it's
really accurate or not, but according to some of the people and
Digital Research, Tim didn't really write much new at all: he just
ported CP/M to the x86. A fair amount of CP/M was written in PL/M (a
PL/I variant) and source was (they claim) routinely distributed to
system integrators and such.

There are lots of versions of this story floating around, but in
any way there's a lot of truth to the joke that Windows 95 was
really CP/M 95 ;-)

In any case, I would be exceptionally surprised if those versions of
MS-DOS were written in C++ or even C.

No doubt. The first time I even heard of C might have been as late
as in 1984(*), a friend of mine told me he had discovered this cool new
programming language C that was derived from BCPL (1984 also
was the year of the first Macintosh, which had Pascal-centric
libraries).

(*) probably partly because I had just briefly heard of unix at that time,
I was used to TOPS-10/20 and VMS.

 

[Hendrik Belitz]

No doubt. The first time I even heard of C might have been as late
as in 1984(*), a friend of mine told me he had discovered this cool new
programming language C that was derived from BCPL (1984 also
was the year of the first Macintosh, which had Pascal-centric
libraries).

(*) probably partly because I had just briefly heard of unix at that time,
I was used to TOPS-10/20 and VMS.

Indeed C is much older and was primarly developed to get a fast higher-level
language for the development of unix-

 

[Gerry Quinn]

If you click on the name next to each "gush" you can read the full story
behind it. While I jokingly called them "Sound bites to die for", as one
who made the shift from C to Lisp I can assure you that what look like
gushes are actually simple, sober statements of fact. Lisp is that much
better.

Sober statements of fact of the same kind as "When Jesus came into my
life, I was saved." It may well be a coruscating central truth for the
person saying it, but its truth is of a kind that will have limited
value for (say) a Buddhist.

- Gerry Quinn

 

[Gerry Quinn]

Try it and see. I came to Lisp rather late (age 44, after 17 years of
programming, the prior eight years in C at home and Vax Basic/Cobol in
tall buildings) and it was a revelation. No pointers, no manual memory
management, no syntax, interactive -- basically, all the crap was gone
and nothing but the fun of programming was left.

My interest in programming is concerned with the products it creates.
[And as always, I remain at a loss as to why 'interactive' programming
appeals to people. If I have bugs I prefer to find them, rathger than
type at random and hope they go away.]

They

You are right! This is because Lisp is usually discovered as a hobby
language, since almost no one uses it at work.

With all due respect, nobody who has not produced a substantial product
with Lisp is in a position to tout its superiority. This is not just an
issue with Lisp. All sorts of methodologies are pushed as the Next Big
Thing on these newsgroups. Almost invariably, the pusher hasn't shipped
even the smallest game.

I was a kitchen-table developer looking for a better way to develop the
next generation of a line of educational software done originally in C,
so I ended up Actually Using(tm) Lisp. It scales nicely to the real
world, and as you might imagine with anything powerful, the bigger the
task the bigger the payoff.

Then a friend asked me to do a rather huge business app (clinical drug
trial management). The kind big companies spend $100m on. We produced
something vastky better than the current state of the art on $1m. Screen
shots (which give zero idea of the underlying complexity of the problem)
are here (starting after "win32 gui samples"):

http://www.tilton-technology.com/cellophane-precursor.html

The screen shots don't tell me anything, really, as there is nothing
there that couldn't be implemented easily in MFC etc. I'll take your
word for it that the underlying data management system is a wonder. But
there's plenty wondrous stuff written in C++ too.

- Gerry Quinn

 

[Thomas Schilling]

Sober statements of fact of the same kind as "When Jesus came into my
life, I was saved." It may well be a coruscating central truth for the
person saying it, but its truth is of a kind that will have limited
value for (say) a Buddhist.

Ever used Lisp?

 

[Stewart Gordon]

And where does the state of the game come from in that module?

I first thought the OP meant to bring the game into a specific state by
actually playing the game. Obviously, you'd bring it into a specific
state programmatically instead.

Stewart.

 

[=?ISO-8859-1?Q?Andr=E9_Thieme?=]

Well, sounds like its probably very different to the lisp we used 15 years
go. All we could seem to do is have lots of brackets with calls to functions
embedded..

2*(5+Speed)+Velocity

looked something like:

(+ (* 2 (5 Speed +)) Velocity)

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)

No need to look if there are other operators included. Anyway, if you
need to do a lot of math then don't hesitate to use a math module, so
you can write mathematical expressions like you are used to.

That everything in Lisp uses the prefix notation can also make it very
easy to learn. Some languages want a lot of syntax:
++c; c++; a+b;
But most functions are using prefix anyway:
f(x, y, z); or in Lisp
(f x y z)
and if you do in C f(x, y, g(z)); then you also need your brackets like
the Lisp version; f(x y (g z))

You don't need to remember stuff like "never put a semicolon after curly
braces... as long they did not close a struct", etc...


André

 

[Computer Whizz]

Ever used Lisp?

I haven't - but by the examples given in this thread alone I shudder to
think of it.
C++ is like MOST other languages I have seen, top-down, functions with a
pretty stable syntax (some shortcuts like +=).
Lisp seems to be loads of functions all conversed about (+ function(*
function(a, b)), c) instead of just "a * b + c" ... Or something along those
lines.
It makes sense to me to have:
"output this "gfgf" #variable# $function(blah, 2)
change #variable#
call $function(blah, 2) again into #var2#
output #var2# #variable1#"
then to have:
"(((output(outfunc((("dfgg")varfunc(#var#))funcfunc($function(blah,
2))))varfunc(#var#, 33))(funcfunc($function(blah, 2),
#var2#))output((#var2#)(#var1#)))"
.... having it all on one line etc... Again I'm just going by what I have
seen in this thread - but doing that is a bad idea.

Also I don't like the idea of being able to change functions or variables
"on the go"... Changing a function can be TERRIBLE while it's running, and
changing a variable could lead to a crash without the proper precautions.
I personally would prefer to program in a test utility (to change
variables)... That way at least I can be sure nothing goes too wrong by a
mistaken key press.

But I have traveled away from this section of the thread - about the sayings
from the "converted"... Most programming languages can do anything - you
just have to think in the correct way for each one - if they find it's
easier to use one than the other - fine. Jut don't come to me saying one way
is "better" because you can change variables "on the fly" when you really
have no need to. Or changing functions "on the fly" where it'll have various
bizare effects all over your program because you didn't THINK about it
right. Or that you have CONTROL over the memory since you have to delete
objects etc (yes, I don't like the memory stuff in C++ completely - but I do
prefer it as it means you have control - instead of relying on something
else).

 

[Computer Whizz]

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)

Quite nice I suppose... Although I don't really mind adding those extra
+'s.... Then again I can't really imagine just adding alot of variables
together.

No need to look if there are other operators included. Anyway, if you need
to do a lot of math then don't hesitate to use a math module, so you can
write mathematical expressions like you are used to.

That everything in Lisp uses the prefix notation can also make it very
easy to learn. Some languages want a lot of syntax:
++c; c++; a+b;
But most functions are using prefix anyway:
f(x, y, z); or in Lisp
(f x y z)

That's horrible... What if 'x' was also a function name etc... It just
doesn't seem good to have the function name inside the ()'s to me.

and if you do in C f(x, y, g(z)); then you also need your brackets like
the Lisp version; f(x y (g z))

Having the function name inside AND outside ()'s... I'll stick to the most
common "always outside ()'s" thanks.

You don't need to remember stuff like "never put a semicolon after curly
braces... as long they did not close a struct", etc...

I don't remember that at all... I just put ','s in between the passed
parameters. Just emphasises the difference between a space and a change of
parameter.

Say I wanted this in C++
func(1, 2 + 3, a, "- b")
while in Lisp is seems it would be:
(func 1 (+ 2 3) a "- b")
but it's probably a tiny bit different. What if I had forgotten the ()'s
inside and just had "func 1 + 2 3 a..." ,'s just "seperate" the parameters.

 

[Alex Drummond]

C++ is like MOST other languages I have seen, top-down, functions with a
pretty stable syntax (some shortcuts like +=).
Lisp seems to be loads of functions all conversed about (+ function(*
function(a, b)), c) instead of just "a * b + c" ... Or something along
those lines.

Don't you think you should go so far as to actually learn the basic syntax
of Lisp before trashing it? Lisp syntax is trivially simple. Every
expressions is of the following form:

(function|macro|special_form arg1 arg2 arg3 ...)

Your examples of Lisp syntax are complete nonsense (function names outside
brackets, commas separating arguments, etc.)

Alex

 

[Alex Drummond]

My interest in programming is concerned with the products it creates.
[And as always, I remain at a loss as to why 'interactive' programming
appeals to people. If I have bugs I prefer to find them, rathger than
type at random and hope they go away.]

Erm yeah. That's what Lisp people do. They sit at their REPLs and type
randomly until they get a functioning program. They don't use the REPL to
set up a program state and test various components of the program quickly
and easily, or anything like that. No.


Alex

Try it and see. I came to Lisp rather late (age 44, after 17 years of
programming, the prior eight years in C at home and Vax Basic/Cobol in
tall buildings) and it was a revelation. No pointers, no manual memory
management, no syntax, interactive -- basically, all the crap was gone
and nothing but the fun of programming was left.

My interest in programming is concerned with the products it creates.
[And as always, I remain at a loss as to why 'interactive' programming
appeals to people. If I have bugs I prefer to find them, rathger than
type at random and hope they go away.]

They

You are right! This is because Lisp is usually discovered as a hobby
language, since almost no one uses it at work.

With all due respect, nobody who has not produced a substantial product
with Lisp is in a position to tout its superiority. This is not just an
issue with Lisp. All sorts of methodologies are pushed as the Next Big
Thing on these newsgroups. Almost invariably, the pusher hasn't shipped
even the smallest game.

I was a kitchen-table developer looking for a better way to develop the
next generation of a line of educational software done originally in C,
so I ended up Actually Using(tm) Lisp. It scales nicely to the real
world, and as you might imagine with anything powerful, the bigger the
task the bigger the payoff.

Then a friend asked me to do a rather huge business app (clinical drug
trial management). The kind big companies spend $100m on. We produced
something vastky better than the current state of the art on $1m. Screen
shots (which give zero idea of the underlying complexity of the problem)
are here (starting after "win32 gui samples"):

http://www.tilton-technology.com/cellophane-precursor.html

The screen shots don't tell me anything, really, as there is nothing
there that couldn't be implemented easily in MFC etc. I'll take your
word for it that the underlying data management system is a wonder. But
there's plenty wondrous stuff written in C++ too.

- Gerry Quinn