C++ sucks for games

[Frank Buss]

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

f(x, y, g(z)) must be written (f x y (g z)) in Lisp, not f(x y (g z)).
Lisp is very easy: After an open bracket the name is used as a function
name and all the rest are arguments.

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

yes, this is right. But normally one would use keyword arguments, if
there are more parameters, with default values, if not provided, so
instead of writing:

HWND wnd = CreateWindow(
"myclass",
"Hello",
0,
0, 0,
100, 100,
NULL,
NULL,
hinstance,
NULL);

in Lisp it would look like:

(setf wnd (create-window :classname "myclass"
:windowname "Hello"
:width 100
:height 100
:hinstance hinstance))

 

[Alex Drummond]

Perhaps. But I've been right thus far.

No, your silly macho posturing over garbage collection has been shown to be
idiotic.

Alex

 

[Kenneth Tilton]

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

Argument by analogy...always fun! Now imagine (if you can) someone who
regularly and earnestly practices both Buddhism and Re-Baptism (if you
will) and is successful at both (prayers to God are answered, keeps
samsara at arm's length) and is simply bowled over by how much easier,
effective, elegant, and fun one practice is. What does that tell you?

(Don't ask me. You started it. <g>)

Seriously, Lisp vs C++ or Java or anything else is only religious if one
wants it to be; use any two languages for even tutorial exercises and
one will find real differences which really matter. More and more as one
undertakes more serious work.

And all that gushing is from real programmers who really were astonished
by the advantages of Lisp. And more than one was by someone who went in
with a negative attitude just to confirm their suspicion that Lisp was
nothing special:

http://alu.cliki.net/Pascal Costanza's Road To Lisp

That guy runs Lisp conferences now.

kenny

 

[Philippa Cowderoy]

[Note that I'm not a Lisp fan - I largely hack in Haskell and happen to be
hanging around on cgdpm]

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.

If x is a function, then (f x y z) passes the function x to f. There's
nothing wrong with this in Lisp, or in many other programming languages -
it allows you to write things like map, the function that applies another
function pointwise to every element in a list.

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

That was a typo for (f x y (g z)).

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.

In Lisp there pretty much is no difference to emphasise.

 

[Sashank Varma]

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

Yeah, but this generalizes in nice ways.

For example, if someone hands you a list of numbers (<list>),
you can compute its sum by simply doing:
(apply #'+ <list>)
And + behaves properly when handed *no* arguments:
(+) => 0
It returns the additive identity.

The fact that + does the "right thing" means that you
don't have to add a lot of special cases to your code.
For example, if someone hands you a list of numbers to
add (<list>) that happens in this case to be empty,
then these two properties combine as you would expect:
(apply #'+ <list>) ==> 0

More generally, when writing mathematical code in Common
Lisp, I find that it works the way my mathematical
intuitions tell me it should work. This probably
reflects the fact that one of the first killer apps of
Lisp was MACSYMA, the first symbolic mathematics
package, back in the early 1970s.

 

[Kenneth Tilton]

My interest in programming is concerned with the products it creates.

But what we are talking about is making it easier to build those
products -- that is why HLLs were invented, and structured programming
techniques, and OO. Carenters love nail guns. the do not want to go back
to hammers.

And if one has better tools, one can put more into the product.

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

Your mental model of an interactive language does not include the actual
benefits:

1. While working I can simply compile a changed (fixed or improved)
five-line function and re-run. Better, if this is an interactive
application which pauses for user input, I can do this during a pause,
then return to the application window and offer new input and see the
new code run. Or if I land in the debugger because of a bug in some
function, I can fix the function and then tell the debugger to
re-execute the stack frame which failed. Where the bug was actually in
some caller arbitrarily high up the call chain, I can tell the debugger
to restart /that/ frame.

2. Some bugs are not so obvious. The code looks fine, but they are
working on data which does not look right. My applications are modelled
in part with trees of long-lived instances. If I land in the debugger
while processing node X, I can have the debugger "return" the node to an
interactive command-line as a value I can then play with, say by passing
it to a custom bit of code which will traverse the tree looking for
anomalies. This can include developing new diagnostic code to traverse
the tree, all while my application is patiently waiting at the debug
prompt. I have many a time done this, found the problem, and not just
fixed a bug but refactored massively, including changing the class
hierarchy, and then discovered after hours of work that the debugger was
still waiting at the point where the application failed. And often it is
possible to simply say "try that again" and the application resumes
successfully.

3. Hard bugs are hard bugs. We do not just find them, because all the
usual suspects had alibis. They seem impossible. I joke about having a
thousand monkeys typing, but in reality the many runs made sometimes
simply to make the bug reproducible are guided by decades of general
programming experience and complete knowledge of my design and it still
feels like monkeys typing. At unpleasant times like these, even a
twenty-second wait to recompile and link becomes an onerous burden to
anyone who has done development in an interactive environment.

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.

Some things do not scale. Classic 4GL springs to mind. But everything
Lisp hobbyists rave about is confirmed by those who have applied it to
substantial products.

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.

You have no idea. And the system must be configurable by
non-programmers to new trials in a man-month (and every trial is
different, with different rules and different forms. Lots of them. And
they change during a trial. And the data must know from which version of
a form it came from. As for MFC. nah, that is a homebrew GUI. Only the
window comes from the OS. All in Lisp.

But
there's plenty wondrous stuff written in C++ too.

Hang on. Don't say "so what?". /You/ said you would not listen to anyone
who had not done a serious project. I did a serious project (several,
actually). Now you have to listen to me.

kenny

 

[JKop]

Alex Drummond posted:

No, your silly macho posturing over garbage collection has been shown
to be idiotic.

Alex

You misinterpret me.


Never have I neglected to put in a delete statement when one was
appropriate.

Even if I were to do this, I always check over my code once I've finished a
function, or a class, or a source file perhaps. In doing these checks, I
would look out for memory allocation that doesn't have a corresponding
deallocation. Hypothetically speaking, if I were to find such a mistake, I
would correct it.

Now, what part of "I don't need a Garabage Collector" do you not comprehend?

As regards "has been shown to be idiotic", now that's just stupid - perhaps
you could provide me with a link to that particular document/survey/whatever
the hell hole you pulled it out of. Did I mention that you come across as a
right shithead?


-JKop

 

[Phlip]

That is a perfect argument for using Lisp

Oh, oh, I get it! Because I post to the C++ newsgroup, I'm expected to say
you should use it for everything from tying your shoes to dredding your
hair! Oh, oh, I'm sorry, I let a crack of opportunity for Lisp to get into
my preciouss C++ game!

Well Exeeeeeeeeeeyyyuuuuuuuuuuuuze Meeeeeeeeeeeheeeheeheeheeeee!

;-)

 

[jayessay]

I haven't - but <a pretty sad diatribe>

Do you have any idea how stupid this makes you look? Why do people
who are totally uninformed about something (here you even admit it)
insist on pontificating on it anyway by means of a stream of pathetic
nonsense? It's embarrassing in the same sad way as an untalented pop
star wannabe making a fool of himself on stage or a public figure
trying to act hip but getting the vernacular and all the idioms wrong.


/Jon

 

[Petter Gustad]

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.

Yeah, but this generalizes in nice ways.[/QUOTE]

Not only that, + works when the numbers are complex as well:

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

or even rational numbers

(+ 2/3 2/3 1/3) => 5/3


Petter

 

[Alex Drummond]

Never have I neglected to put in a delete statement when one was

appropriate.

In that case I can only assume that either
a) You've never written a C++ program of significant complexity,
OR
b) You're a genius
OR
c) You're lying.

I'm personally inclined to believe either (a) or (c). However, if (b) is the
case, I can only suggest that you should consider the benefits of a GC for
those who lack your incredible intellectual powers. After all, even Hans
Boehm (who is really quite clever) thought it worthwhile to implement a GC
for C++ (http://www.hpl.hp.com/personal/Hans_Boehm).

Even if I were to do this, I always check over my code once I've finished
a function, or a class, or a source file perhaps. In doing these checks, I
would look out for memory allocation that doesn't have a corresponding
deallocation. Hypothetically speaking, if I were to find such a mistake, I
would correct it.

Only if the memory management problem was quite simple would there be a
one-to-one correspondence between malloc/new statements and delete/free
statements. Memory management isn't a trivial problem. That's why garbage
collection was invented.

Now, what part of "I don't need a Garabage Collector" do you not
comprehend?

I comprehend it perfectly, and indeed agree with it. You don't need garbage
collector. But I'm not sure why you don't /want/ a garbage collector.

As regards "has been shown to be idiotic", now that's just stupid -
perhaps you could provide me with a link to that particular
document/survey/whatever the hell hole you pulled it out of.

Various posts. For example:
" Garbage Collection is not just for the retarded -- it becomes sort of
an requirement when dealing with lock-free collections, for example.
And you are wrong to believe that your programs won't leak memory just
because you aren't retarded."

Your response to this was "perhaps" and some vacuous statement about how
right you were.

Did I mention that you come across as a right shithead?

No, you didn't.


Alex

 

[Svein Ove Aas]

1. While working I can simply compile a changed (fixed or improved)
five-line function and re-run. Better, if this is an interactive
application which pauses for user input, I can do this during a pause,
then return to the application window and offer new input and see the
new code run. Or if I land in the debugger because of a bug in some
function, I can fix the function and then tell the debugger to
re-execute the stack frame which failed. Where the bug was actually in
some caller arbitrarily high up the call chain, I can tell the debugger
to restart /that/ frame.

I won't argue that it wouldn't be useful, but sbcl doesn't support that
option, although Slime does. Cmucl doesn't appear to do it either.

In my limited understanding of Lisp implementations, it would appear not to
be too hard, so why doesn't it? Alternately, which Lisps do?

 

[Gareth McCaughan]

[Kenny Tilton:]
[Gerry Quinn:]

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.

If it turns out that Christianity is right[1] then that
truth will have considerable value for any Buddhist who
is prepared to heed it. And if it turns out that Christianity
is wrong then it isn't really a truth, even for people who
see it as one.

[1] i.e., there actually is a God, Jesus really was God
incarnate, following Jesus really leads to eternal
life, etc., etc., etc.

Of course, in matters of religion so much is either subjective
or very hard to ascertain that perhaps the sort of "personal
truth" you allude to is often the best one can get. But
software development isn't so woolly; some languages really
are, and can be shown to be, better for some tasks than other
languages. You simply can't write device drivers in Python,
and you'd be crazy to write theorem provers in Visual Basic.

There's still a strong element of subjectivity: as well as
some languages being better for some *tasks*, some are better
for some *people*. I find that (to take three somewhat different
examples) C, Python and Lisp fit my brain a bit more naturally
than C++, Perl and ML. So if I say "Perl is a mess" or "C++
is too easy to screw yourself with" you can, I suppose, put it
down to my idiosyncrasies. But if I say "Lisp's macros make it
easy to do things that are unbearably painful in C++", that's
a verifiable (or falsifiable, though as it happens it's true)
statement that anyone can check given a little time and an
open mind.

 

[George Neuner]

That's because educating someone to write low-risk C++ is difficult. Vendors
have clogged our markets with low-quality languages that purport to allow
inept programmers to write code at a lower risk than C++ provides.

You forgot to say that junior colleges and technical training schools
have flooded the market with low to mediocre skilled programmers who
know only the language du jour and nothing of software engineering
practices.

George

 

[Christer Ericson]

[...]
1. While working I can simply compile a changed (fixed or improved)
five-line function and re-run. Better, if this is an interactive
application which pauses for user input, I can do this during a pause,
then return to the application window and offer new input and see the
new code run. Or if I land in the debugger because of a bug in some
function, I can fix the function and then tell the debugger to
re-execute the stack frame which failed. Where the bug was actually in
some caller arbitrarily high up the call chain, I can tell the debugger
to restart /that/ frame.

Indeed, this Lisp concept is so powerful that you'll find
a weak copy of offered for C++ in Visual Studio, namely
the "edit-and-continue" feature. Only Lisp does it better.


Christer Ericson
Sony Computer Entertainment, Santa Monica

 

[Christer Ericson]

Yes, one team wrote parts of some of their games in Lisp, and that one
example has been trumpeted to the rooftops ever since.

Parts? Pretty much everything was written in Lisp (GOAL); except
for certain parts that were written in assembly (such as PS2
microcode for the PS2 equivalent of vertex shaders).

Read their
'post-mortem' on Gamasutra and you'll find that the benefits were far
more ambiguous than you would think to listen to the Lisp boosters. To
put it briefly, it featured strongly in both the "what went right" and
"what went wrong" sections.

Read it again. The drawbacks with Lisp (GOAL) listed in the "what
went wrong" section have almost nothing to do with Lisp as a language,
but to do with the immaturity of their tools (often a problem with
proprietary tools), and the difficulty of finding employees who
grok Lisp.

I know several of the programmers at Naughty Dog (who are just a
stone's throw down the street from here). And they think Lisp (GOAL)
is better than C++. Furthermore, these are incredibly talented
programmers, and only fools would not pay attention to what
they're saying.

You said: "What is it about Lisp that makes novices fall in love
with it? They don't actually *produce* anything with it, mind
you, but they insist on telling the world how superior it is to
every other language."

Let's turn that on its end shall we. The guys at Naughty Dog
are clearly more experienced than you are, making you the novice.
They have _constentently_ produced some of the best sellers on
the PS1 and PS2. You have produced some small shareware games
that at worst would take a programmer a week or two to hack
together. You have in the past admitted you have no experience
with functional languages, yet you insist on telling the world
how you (the novice) know better, putting C++ ahead of Lisp.
Isn't that special?


Christer Ericson
Sony Computer Entertainment, Santa Monica

 

[Computer Whizz]

[Note that I'm not a Lisp fan - I largely hack in Haskell and happen to be
hanging around on cgdpm]

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.

If x is a function, then (f x y z) passes the function x to f. There's
nothing wrong with this in Lisp, or in many other programming languages -
it allows you to write things like map, the function that applies another
function pointwise to every element in a list.

Yes... While x has no parameters passed (or does it?). Does forgetting the
space (or common typo) mean that (f xy z) causes an error. A quick scan
through the file wouldn't really show it up as well as f(x, y, z) IMO - but
to each his own.

That was a typo for (f x y (g z)).

Ah - ok. Sorry.

In Lisp there pretty much is no difference to emphasise.

Hmmm - I am probably going to have a hard time explaining myself out of my
own mess here... I guess it's just a matter of opinion and preference to the
syntax.
To each his own.

 

[Computer Whizz]

Not only that, + works when the numbers are complex as well:

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

or even rational numbers

(+ 2/3 2/3 1/3) => 5/3


Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...
I really don't like that syntax at all!

 

[Computer Whizz]

Do you have any idea how stupid this makes you look? Why do people
who are totally uninformed about something (here you even admit it)
insist on pontificating on it anyway by means of a stream of pathetic
nonsense? It's embarrassing in the same sad way as an untalented pop
star wannabe making a fool of himself on stage or a public figure
trying to act hip but getting the vernacular and all the idioms wrong.


/Jon

I am also pointing out the fact that if Lisp is supposed to be good for the
"newbie" then how come it looks WORSE off than every other programming
language that I have "gazed" upon?
It even looks worse than Assembler IMHO. Very confusing indeed.
And I do try to be fair in my assessment, I do not want to attack Lisp's
power etc in any way - just point out that the syntax isn't exactly "nice".

 

[Petter Gustad]

Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...

What was the difficult part? Did I confuse you with =>? => is not a
part of Common Lisp, it's just a common way of showing the result of
the function call.

I really don't like that syntax at all!

It's the same /syntax/ as others have explained to you, e.g. (function
arg1 arg2 ...). I just introduced a new function called /complex/
which will return a complex number given the real and imaginary part
as argument.

Petter