C++ sucks for games

[Rene de Visser]

I'm not trolling - this is a serious if nasty question: could it be that
the reason the majority of C programmers reject 'idiomatic Lisp' is
because they see what you call 'idiomatic Lisp' as simply bad
programming practice?

I have programming experience in a number of programming languages including
C, C++ and Common Lisp among others.

I think that there a number of reasons C programmers reject 'idiomatic
Lisp'.

a) The formatting. It took me a couple of weeks to get past how Lisp code
looks like because of the formatting and parenthese.
b) Learning curve. I found this to be quite steep. There are a lot of in
built functions and macros, etc in common lisp. At the beginning of learning
C++ versus learning common lisp it was a lot easier for me to read a 30 000
line C++ program compared to a 10 000 line lisp program. To read the
Lisp program you need to know the ANSI standard fairly well, and learn to
pick out the standard stuff compared to the program specific constructions.
Often Common Lisp is more compact. At the beginning this is a learning
disadvantage, at least for working your way into the language with existing
code.
c) In combination of a) and b) above and the lack of strong motivating
reasons to learn Lisp (such as good job opportunities), I think are the main
reasons for the rejection.

I would think that 90% C programmers that reject Lisp don't get far enough
that they could recognize good or bad programming practice in Lisp programs.

Rene.

 

[Gerry Quinn]

I am certainly all for that statement. However the world is run with help
from the silver bullet merchants. When C++ was just starting out it was the
silver bullet advocates that got it going. About 1993 we started working
with the first beta version of the DEC VMS C++ compiler, because someone
advocated for it to management. They convinced them things would be more productive
and would allow code reuse. (Neither of which came true).

Yes. I suppose the other extreme is when you have to be dragged kicking
and screaming to new technology!

I tend to believe that
the majority of the Lisp users are mature enough to not make exaggerated promises
and that may be part of the problem. Many people do not wish to hear the unvarnished
truth, they want to hear things like "Free software will solve the world's woes".
The silver bullet merchants are the myth promoters and as a programmer who would prefer
to use Lisp it is crappy that it has been painted it with too many falsehoods.

I would say that when Lisp did not deliver during the AI boom (no language could
of delivered the (now) outlandish claims) it got targeted for all the
political reasons. Thankfully the people involved are either leaving or forgetting.

Although Lisp seems uniquely prone to the myth of "If I just make this
program complicated and recursive enough, miracles will emerge!"
Douglas Hofstadter, you have much to answer for...

- Gerry Quinn

 

[Svein Ove Aas]

Although Lisp seems uniquely prone to the myth of "If I just make this
program complicated and recursive enough, miracles will emerge!"
Douglas Hofstadter, you have much to answer for...

The problem is, miracles frequently do emerge.
Oh, the embarassment.

 

[John Thingstad]

I would think that 90% C programmers that reject Lisp don't get far
enough
that they could recognize good or bad programming practice in Lisp
programs.

Rene.

I second that.
You really need to know a great deal about lisp to read Lisp programmes.
In the beginning exceptions, multiple-value-bind and destructuring-bind
really put me off because of the complexity.
Then there is the special forms.
In Python you can be reasonably productive in a week.
In Lisp it takes considerably longer.
The arguments about Lisp being so productive may actually hurt
because if you try it without being experienced you will be
less productive. So they figure the rest is hype from language
advocates with a inferiority complex.
The best best cure I have seen is Peter Seibel's book
'Practical Common Lisp'. (Thanks Peter)
This hands on, yet nontrivial, tour of common Lisp thoroghly
introdudes the uniqueness of the Lisp programming language.
(PAIP by Peter Norvig should perhaps also be mentioned)

 

[Peter Ashford]

C++ is not a C variant, unless you just mean syntax. So I'm not quite
sure what you mean by the "C programmers" who you said were programming
in C++.




Although it could be argued that a language (here you seem to be talking
about C) that everyone can use is better than a language that only some
can use. However, that aside, a certain possiblility arises...

I'm not trolling - this is a serious if nasty question: could it be that
the reason the majority of C programmers reject 'idiomatic Lisp' is
because they see what you call 'idiomatic Lisp' as simply bad
programming practice?

After all, some people seem to have a 'spaghetti' gene, and can code
stuff that works after a fashion, but which lesser mortals can't
understand or maintain. Maybe Lisp is on the same chromosome.

- Gerry Quinn

I tend to think the OP is probably on to something. I'm no expert LISP
programmer, but I am an expert at C and Java, and I have seen many C
(and C++) programmers write bad Java then blame the language when it
doesn't run well.

 

[Peter Ashford]

As far as I know, there are not a lot of tools and library support
specifically for writing games in Lisp. What you fail to appreciate
is the contention on the part of most Lisp programmers that because Lisp
is such a superior language, appropriate tool chains are easy to create,
relative to languages like C++. So if people were interested in using
Lisp for games, they would do that. (This "roll your own" outlook,
which has its dual aspects, is based on different set of assumptions
than most software engineers have.)

Hmmm... I think you misunderstand just how much work is being done by
middleware in games these days. It's not just a matter of libraries
which you can link to with a FFI, middleware like physics engines
provide C++ code that can be inserted into your codebase in a number of
ways, intercepted at a number of levels by virtue of exposing a large
part of the C++ API. *NO* foreign code is going to be able to acccess
that very well - not just LISP - *any* non C++ language at all.

"Appropriate tool chains" are NOT easy to create. That's the reason
that there are specialists in physics, character animation, graphics
engines etc...

If all you were talking about was simply linking to a trivial library
and executing a script or two, then fine, but if that's your idea of
what middleware is, you're well off the mark I'm afraid.

 

[Peter Ashford]

Pedant?

"1. One who pays undue attention to book learning and formal rules.
2. One who exhibits one's learning or scholarship ostentatiously."

Lemme help, I think you want "proselytize". (Now /that/ is being
pedantic, tho you started it with all the big words.)

LOL

 

[David Steuber]

And is the pronounced tendency of even successful Lisp projects to
get re-written in another language *entirely* due to PHBs who are
afraid of not being able to hire Lisp users?

What other reasons could there be? As the Dilbert strip illustrates,
PHBs are idiots by definition.

Also, while this has happened, how common is it to re-implement a
successful system in another language? Do you think ITA will do it to
Orbitz?

 

[Ray Blaak]

The problem is, miracles frequently do emerge.
Oh, the embarassment.

While miracles often happen, it is most certainly *not* because of increased
complexity and undue amounts of recursion.

It is because the code describes the solution in a cleaner way, with a greater
economy of expression.

Increased complexity is almost always a bad sign. We should choose solutions
that reduce it, not increase it. If that means C++, then that is the logical
choice. If that means lisp, then there you go.

Unfortunately, in real life, the situation is not that simple either:
politics, programmer availability, experience, etc., all come into play.

[Followups broken, since the intended audience is in fact more than just c.l.l]

 

[William Bland]

I wasn't talking about "excellence". I was talking about "good practice".
They are different things.

Yup, agreed. In my experience people use the terms "good practice" and
"best practice" to mean "average practice", i.e. what everyone else is
doing (if I remember correctly, Paul Graham makes the same observation in
his book Hackers And Painters).

You are welcome to your "good practices". I prefer something better than
the average.

Cheers,
Bill.

 

[Raghar]

Personally I think my point about the tool chain and knowledge
investment in C++ is a large part of why *any* other language
will have a hard time changing the way things are.

Perhaps the reason is a code readability. It's very high in Java,
somewhat high in LISP, a little higher in un camuflaged C# and
completely unreadable for amateurs in C++ (If there was
communication between two different code bases) As a result your
chief could be uneducated*1 (idiot) and talk too much into your
work.

*1 change uneducated into university educated that forgot brain if
he had one.

My news server is down so it will be interesting if this will
appear

 

[Christopher C. Stacy]

"Appropriate tool chains" are NOT easy to create. That's the reason
that there are specialists in physics, character animation, graphics
engines etc...

How many times have you done this in Lisp?

 

[Steven E. Harris]

If by the above you mean - and I suspect you do - those programmers
whose obsession with 'generic programming' has caused them to lose sight
of the basics of object orientation,

Since when was C++ concerned with or even aspiring to reach this
summit, "the basics of object orientation?" Modern, idiomatic C++ is
best characterized by full exploitation of all its language facilities
and use of certain conventions to make library building and reuse
easier. None of that has anything to do with object orientation, and
none of that effort is suffering for lack of such concern.

the Lisp community is welcome to them as far as I am concerned.

You're not even cheerleading for C++ as it lives today, but building a
moat around your own stunted idea of what it should be.

 

[Kenny Tilton]

How many times have you done this in Lisp?

Just for fun I downloaded OpenSG, a C++ scene graph manager. A little
over 3500 or so files. I was just wondering what it would be like to
translate something like that to Lisp.

My first thought was, cool, 1500 or so are headers, I am 42% done.

And of course 90% of everything is pretty small, so probably 10% of the
lines go to the copyright/license stuff. Now I am halfway home. Jacek
says my result will be ten to twenty times smaller, so that means I am
97.5% done. Start icing the champagne. Now what about the last 250
points (2.5%)?

I went looking for some beef. Figured the code which loaded models must
be meaty. Turned out to be a lot of greenspun (can we just add that to
the language to make the next five years transitioning to Lisp a little
easier?).

It occurred to me at this point that a straight translation would be
impossible, since ripping out the greenspun puts one on a slippery slope
to a rewrite. During which an extraordinary effort goes into deciding
what is beef and what is gristle. (And to think I am a vegetarian.)

Then I looked over at "Real-Time Rendering" by Moller and Haines sitting
on my desk. They give all the math and theory for a lot of the
functionality provided by OpenSG. Translating /that/ to CL would be a
lot faster and more fun.

Which brings me back to my theory: the game industry has labored
mightily with C++ and produced a mouse. Lisp will run it down with a
year or two of serious effort. Game over, as they say.

kt

 

[Trent Buck]

Up spake Kenny Tilton:

I went looking for some beef. Figured the code which loaded models must
be meaty. Turned out to be a lot of greenspun (can we just add that to

^^^^^^^^^

Excuse my ignorance, but what is this word? Is it a pejorative?

 

[Kenny Tilton]

Up spake Kenny Tilton:


^^^^^^^^^

Excuse my ignorance, but what is this word? Is it a pejorative?

Yes and no. From the man himself http://philip.greenspun.com/research/:

"Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C
or Fortran program contains an ad-hoc, informally-specified bug-ridden
slow implementation of half of Common Lisp."

"I've seen this in .signatures on USENET postings but I can no longer
remember where I wrote it originally. On the Squeak discussion group,
Vassili Bykov helpfully explained the meaning: "that complex systems
implemented in low-level languages cannot avoid reinventing and/or
reimplementing (poorly on both counts) the facilities built into
higher-level languages. Like garbage collection in OLE or keyword
arguments in X."
;;------------------------------------------------------

It is not a pejorative because, well, linked lists are useful data
structures and if your language does not have built-ins for that it is a
good idea to implement them. As best you can.

It is a pejorative because it is a slam on non-Lisp languages for not
providing the built-ins. Well, and maybe the programmer for not choosing
Lisp. But hey, not too many people have been clued into Lisp.

kt

 

[Peter Seibel]

Up spake Kenny Tilton:
^^^^^^^^^

Excuse my ignorance, but what is this word? Is it a pejorative?

It's from this:

Greenspun's Tenth Rule of Programming:

Any sufficiently complicated C or Fortran program contains an
ad-hoc, informally-specified bug-ridden slow implementation of
half of Common Lisp.

I recently defined my own corollary to Greenspun's 10th:

Seibel's Corollary to Greenspun's 10th

Any sufficently complicated Java program requires a programmable
IDE to make up for the half of Common Lisp not implemented in the
program itself.

-Peter

 

[Gerry Quinn]

[restored for context]

Yup, agreed. In my experience people use the terms "good practice" and
"best practice" to mean "average practice", i.e. what everyone else is
doing (if I remember correctly, Paul Graham makes the same observation in
his book Hackers And Painters).

You are welcome to your "good practices". I prefer something better than
the average.

Your post is without relevance given the entirely different context of
the word 'excellence'.

- Gerry Quinn

 

[Gerry Quinn]

Since when was C++ concerned with or even aspiring to reach this
summit, "the basics of object orientation?"

Given your name, I would expect you to be capable, at least, of
idiomatic English. "Losing sight of the basics of X [where X is
expected to be known]" does not equate to "Aspiring to understand the
basics of X".

Modern, idiomatic C++ is
best characterized by full exploitation of all its language facilities
and use of certain conventions to make library building and reuse
easier. None of that has anything to do with object orientation, and
none of that effort is suffering for lack of such concern.


You're not even cheerleading for C++ as it lives today, but building a
moat around your own stunted idea of what it should be.

Since the cap seems to fit, I suggest you wear it.

- Gerry Quinn

 

[Gerry Quinn]

It doesn't look like anyone has. But of course using Lisp it's
incredibly easy by definition, so there's no need to actually do it.

Then I looked over at "Real-Time Rendering" by Moller and Haines sitting
on my desk. They give all the math and theory for a lot of the
functionality provided by OpenSG. Translating /that/ to CL would be a
lot faster and more fun.

Which brings me back to my theory: the game industry has labored
mightily with C++ and produced a mouse. Lisp will run it down with a
year or two of serious effort. Game over, as they say.

To say that before you even start playing shows confidence. Or
something.

- Gerry Quinn