C++ sucks for games

[Philippa Cowderoy]

In short, if you think I'm saying generic programming is not useful for
making STL extensions, you are misreading me. What I'm saying is that
there are no paradigms that are "[compared to OO] equally useful and
valid general-purpose approaches to the programming and design of non-
niche software".

Functional reactive programming is the silver bullet OO wanted to be
(and it even makes OO better):

http://www.haskell.org/frp/
http://www-sop.inria.fr/meije/esterel/esterel-eng.html
http://www.tilton-technology.com/cells_top.html

I hope your work on frp proves useful. But I'll believe it's the silver
bullet when I see it...

I've seen a number of indications that it may well be - one of my "when I
get round to it" projects is to hook yampa (an FRP lib) up to some SDL and
OGL bindings and knock up a simple game engine. That said, it would still
frequently help in an FRP situation to have some of the features more
commonly found in OO type systems.

You might find a paper called "The Yampa Arcade" interesting though - some
of it does look a little like reinventing OO, and I've said as much to one
of the authors, but the rest is seriously nice.

I think you're right, OO will be incorporated into the Next Big Thing.
Where we differ is that I got fed up with OO a while back and started
looking for it

 

[Steven E. Harris]

the win from templates only kicks in when massive reuse is expected

I find that writing template code is often easier. Push the type
concerns onto your callers. Plenty of functions or classes make
perfect sense to write without concern for the specific types they
operate on. Having to choose a type to inject into that function adds
complexity by mixing what are often orthogonal concerns. Concepts and
operations are more important than types, and templates allow us to
take advantage of that distinction.

 

[Kenneth Tilton]

What I'm saying is that
there are no paradigms that are "[compared to OO] equally useful and
valid general-purpose approaches to the programming and design of non-
niche software".

So your absolutely sure that nothing has ever or will come along that will
be better than OO (and you probably mean a particular type of OO) that will
ever be better?

I think anything that supersedes OO will build on OO, rather than
replace it.

Yep: http://www.tilton-technology.com/cells_top.html

(as long as we are advertising our sites. <g>)

kt

 

[Kenneth Tilton]

In short, if you think I'm saying generic programming is not useful for
making STL extensions, you are misreading me. What I'm saying is that
there are no paradigms that are "[compared to OO] equally useful and
valid general-purpose approaches to the programming and design of non-
niche software".

Functional reactive programming is the silver bullet OO wanted to be
(and it even makes OO better):

http://www.haskell.org/frp/
http://www-sop.inria.fr/meije/esterel/esterel-eng.html
http://www.tilton-technology.com/cells_top.html

I hope your work on frp proves useful.

Thx. But it already has! Have you been to my sight and seen what I have
done with it, yes? These are /all/ Cells-driven (in all respects, GUI as
well as abstract model and in the business app even the database, which
is persistent CLOS:

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

But I'll believe it's the silver
bullet when I see it...

Thx. But I think you will not believe it until you download it (and the
AllegroCL Trial Edition and Peter's book).

http://www.tilton-technology.com/cells_top.html
http://www.franz.com/products/
http://www.gigamonkeys.com/book/

kenny

 

[mikel]

I simply think that because of the complexity and obscurity of such
code, the win from templates only kicks in when massive reuse is
expected, and that would rarely apply at an individual project level.

I don't quite buy this argument, because of experience. I don't dislike
C++, and I've worked in it quite a bit for a long time (for example, I'm
one of the implementors of the QuickTime Movie Player, which is written
in C++).

However, I'm suspicious of templates; not that they are intrinsically
bad, just that you have to think through their uses rather carefully to
avoid hurting yourself. In a recent large commercial product with which
I'm associated, the decision was made to retroactively strip out all
uses of templates because it turned out to be too easy to produce
unanticipated memory and performance problems, and too difficult to
predict them. This rather expensive decision was made by a very smart
and commercially successful group of programmers, some of whom have
produced some other familiar technologies; it's not an ignorant whim.

As I said, I don't dislike C++, but I also don't love it. I do love
Lisp. There used to be a common saying about C that these days seems to
be true of C++, at least among the experienced programmers with whom
I've worked: it's no one's favorite language, but it's everyone's second
choice, and that's why it gets used.

 

[Svein Ove Aas]

Yep: http://www.tilton-technology.com/cells_top.html

(as long as we are advertising our sites. <g>)

Does it still only work in ACL and Lispworks, or can I give it a try with
SBCL/Linux now?

I tried asdf-installing it, but got naught but compilation errors; that
might be a problem on my side, though, as series isn't working either.


On a sidenote, the asdf-install package didn't put anything
in .sbcl/systems, nor did it (apparently) attempt to compile it. That
should be easily fixable, I suppose.

 

[Gerry Quinn]

You might find a paper called "The Yampa Arcade" interesting though - some
of it does look a little like reinventing OO, and I've said as much to one
of the authors, but the rest is seriously nice.

A signal is a function from time to a value... signals were given
names... I can see where you might have gotten that impression!

And after writing the above I read on a little to find "signals
accumulate internal state"...

Was it a good game?

- Gerry Quinn

 

[Gerry Quinn]

Thx. But it already has! Have you been to my sight and seen what I have
done with it, yes? These are /all/ Cells-driven (in all respects, GUI as
well as abstract model and in the business app even the database, which
is persistent CLOS:

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

Your 'cells' concept looks interesting, though it would tend to go on my
list of "interesting architecture idea" rather than "reason to change
language".

Am I right in thinking that their main function is to bring functional
programming into realms where objects currently stand supreme?

- Gerry Quinn

 

[Philippa Cowderoy]

A signal is a function from time to a value... signals were given
names... I can see where you might have gotten that impression!

And after writing the above I read on a little to find "signals
accumulate internal state"...

Now take a look at things like how the physics code is written, and how
the system deals with new entities or entities changing their paths.
That's the bit that's nice IMO - the rest's theoretical framework showing
how this all works.

The accumulation of state is done in a somewhat ugly way at present (the
bit that looks like reinventing OO badly), and I can understand some
skepticism about how well things scale. One of the reasons I'd like to
play around myself is that I think I know how to go about it in Haskell
with GHC's extended featureset (much of which is supported elsewhere),
though I won't know for certain until I've hacked it up. It should be
noted that if it's a problem this has more to do with the shortcomings of
Haskell's type system than it does FRP - in fact, it occurs to me that a
good environment for FRP might actually be a language like Smalltalk.

Was it a good game?

The game itself was YA simple 2D shooter, as the whole thing was an
academic exercise (I saw the mailing list posting referred to at the start
of the paper). Of course, there's no reason the game couldn't be polished
further.

 

[jayessay]

What I'm saying is that
there are no paradigms that are "[compared to OO] equally useful and
valid general-purpose approaches to the programming and design of non-
niche software".

So your absolutely sure that nothing has ever or will come along that will
be better than OO (and you probably mean a particular type of OO) that will
ever be better?

I think anything that supersedes OO will build on OO, rather than
replace it.

Amazing. In one sentence you manage to be wrong on two counts.

/Jon

 

[Kenneth Tilton]

Your 'cells' concept looks interesting, though it would tend to go on my
list of "interesting architecture idea" rather than "reason to change
language".

Am I right in thinking that their main function is to bring functional
programming into realms where objects currently stand supreme?

- Gerry Quinn

That is a good way of putting it, at a low level of abstraction. ie,
yes, we now have functional slots (data members?) on instances.

At a higher level of abstraction a dataflow paradigm emerges, and the
long-lived state used to model an application acts like a spreadsheet.

Great fun, btw. And it is not just a curiosity. Lots of folks have done
things like this, and everyone who does or uses them loves the power.

Btw, I once did a proof-of-concept port of a small part of the
functionality in C++ (and Java and Python).

kt

 

[Gerry Quinn]

["The Yampa Arcade"]

Now take a look at things like how the physics code is written, and how
the system deals with new entities or entities changing their paths.
That's the bit that's nice IMO - the rest's theoretical framework showing
how this all works.

To be honest, I don't see a win over an object-oriented system.
Obviously Haskell gives you nice functions if you want to put in a lot
of physics, but one could do it in other ways. (Game physics often owes
more to Aristotle than to Newton anyway.)

In their conclusions they do mention problems with event ordering and
mutually recursive effects in OO systems, which is fair enough - but
reading on it's clear that in Yampa singularities tend to appear instead
in the same situations! Which is better, quirky object behaviour -
which is often fun - or a complete crash? I suppose it could be argued
that at least the crash will force you to fix it - but when you unbind
some of the recursive effects, your physics will also depart from
rigour.

- Gerry Quinn

 

[Gerry Quinn]

Amazing. In one sentence you manage to be wrong on two counts.

Which are?

- Gerry Quinn

 

[Neo-LISPer]

I don't think Lisp is going to take over from VB any time soon...

I ask again -

I think anything that supersedes OO will build on OO, rather than
replace it.

Gerry Quinn, I'll be sure to let you know when Common Lisp for Complete
Idiots hits the stores. You will then be able to partake in all of the
offerings of the language. There is no need to worry your head about this
Lisp thing just yet. Until then, PLONK.

 

[Gerry Quinn]

Gerry Quinn, I'll be sure to let you know when Common Lisp for Complete
Idiots hits the stores. You will then be able to partake in all of the
offerings of the language. There is no need to worry your head about this
Lisp thing just yet. Until then, PLONK.

So, what have you achieved using Lisp? (Other than masturbatory
fantasies about controlling the Matrix.)

- Gerry Quinn

 

[Coby Beck]

So, what have you achieved using Lisp? (Other than masturbatory
fantasies about controlling the Matrix.)

Seriously, Gerry... the answer is nothing. None of us has achieved anything
with Lisp. You've seen and scoffed at all the links to the measly and
pathetic accomplishments we can boast of and you have understood and seen
right through all the "emperor's clothing" -the macros, the MOP, the dynamic
types, the tack-on, clumsy excuse for object orientation we call CLOS etc.
You do not need to learn anything about Lisp.

So move on already.

 

[Peter Ashford]

Seriously, Gerry... the answer is nothing. None of us has achieved anything
with Lisp. You've seen and scoffed at all the links to the measly and
pathetic accomplishments we can boast of and you have understood and seen
right through all the "emperor's clothing" -the macros, the MOP, the dynamic
types, the tack-on, clumsy excuse for object orientation we call CLOS etc.
You do not need to learn anything about Lisp.

So move on already.

In a game development list, it is valid to ask "what have you achieved"
and being given some game projects as an answer (Naughty Dog and Abuse
are two answers I can think of that would have done, for example).

Answering with features of the languages as achievements won't help
someone who wants to know what a language can do for them, external to
the inheirent joy of the language itself )

 

[Gerry Quinn]

Answering with features of the languages as achievements won't help
someone who wants to know what a language can do for them, external to
the inheirent joy of the language itself )

Let me note that my post above was directed specifically at the
insulting troll with the revealing name.

- Gerry Quinn

 

[John Thingstad]

Answering with features of the languages as achievements won't help
someone who wants to know what a language can do for them, external to
the inheirent joy of the language itself )

Don't as what has been done in the language.
Ask 'what can the language do for you?'
http//www.gigamonkeys.com/book might give you some clues.

 

[Peter Seibel]

Don't as what has been done in the language. Ask 'what can the
language do for you?' http//www.gigamonkeys.com/book might give you
some clues.

And note that all the code in that book (spam filter, ID3 parser,
Shoutcast server, and more) was written by one programmer at the same
time as he was writing the book itself. Total time spent on all the
code was maybe about two months. In the meantime he also wrote code to
generate the web site, including the PDFs and the figures used in the
book[1] in Common Lisp.

-Peter

[1] Thanks to Marc Battyani's excellent cl-typesitting and cl-pdf libraries.