C++ sucks for games

[Rahul Jain]

Yes - but "our" buildings have walls between the rooms.

So do ours. I hope you see that the elements of the form are separated
by somehow...

(OK - I sound like an ass a little there... Still, Lisp programmers seem all
happy and ine saying "I can read Lisp code OK" when it's not you - but the
editor reading it out for you.
I might use a simple syntax highlisghter to show variables/functions/static
text but I can just as easily judge and evaluate raw C/C++/most other
languages - even if they've been typed by a monkey with no actual use of the
tab key... )

That's not a problem. I have an editor that can indent properly. But how
easily do you spot the
if (foo());
do_whatever();
something_else();
problem?

That's where they differ more prominently! C/C++/whatever IS (at least in my
mind) very similar to English. It has words following each other in a
"flow".

You mean that there's no nesting? No well-defined structure? Lisp code
flows. You just look at the banks of the river and ignore the actual
river that's flowing. The banks merely shape the flow of the river.
Don't stare at them.

 

[Rahul Jain]

That sounds like the editor is inserting stuff to me.

It probably wasn't clear: I was talking about selection. But I do have
automated code generation scripts in my editor because there's so much
noise in the syntax. Effectively, those scripts are a decompression
algorithm to decompress my ideas into the masses of Java code needed to
express a simple pattern.

 

[Rahul Jain]

A + (B * C / D) - (E * F)

so that there is no misunderstanding of your code. Certainly not needed, but
makes it easier to read at a glance, which is what I would say is the
highest priority when designing a language to be used in a team
environment..

Ah, so Lisp is designed to make sure there is no misunderstanding of
your code, and is therefore excellent for use in a team environment.

Gee, I just love this thread... Will it ever end. I can see this stuff going
round in circles for weeks

 

[Rahul Jain]

Hmm...your definition of "hidden" seems to be a strange one.

Are you familiar with the principle of least surprise? That's what we're
trying to convey here.

 

[Peter Lewerin]

What is this? are you saying that the class rabbit has a static member
function that takes a rabbit and a 3? I'm not sure why you would want
such a thing..

Most likely you wouldn't, but if you wanted it, that's how it would
look like. Maybe I should have just written f(a, b) / a.f(b) /
T::f(a, b), but I kind of wanted to go with the "rabbit jump" thing.

Also are you saying in lisp when I write (jump rabbit 3) it's impossible
to tell if I'm calling a member function of Rabbit that takes a single
parameter, or a general function that takes two parameters?

No, that's not how it works.

To begin with, the method call actually takes two parameters; the
types of each parameter is matched against the set of available
methods with the same name and the best match is called. There is no
such thing as a member function of a class, but there may be a method
that's ready and willing to handle calls involving an instance of
Rabbit in the first parameter place.

This way, methods taking any type of object and methods specifically
taking only certain types of objects can co-exist peacefully.

 

[JKop]

Jon Boone posted:

Let me start by thanking you for your honest and thoughtful
response. I appreciate the opportunity to learn more about how
others program.



So, unless I misunderstand the symantics of the 'protected'
specifier, thinks marked this way are accessible to the class and
any sub-classes, but no one else. Is that correct?

Correct:

class Base
{
protected:

int k;
};

class Derived : public Base
{
Derived()
{
k = 4;
//This is perfectly legal
}
};


int main()
{
Base monkey;

monkey.k = 4;
//This is illegal
}

I believe items declared 'public' are accessible to anyone, as
they would be in C. If one does not declare an specifier, do they
not default to 'public'?

They default to private.

Writing:

class Blah
{
int k;
};


is the same as writing:

class Blah
{
private:
int k;
};


Conversly, if you opt for the "struct" keyword, things default to public,
ie:

struct Blah
{
int k;
};


is the same as:


struct Blah
{
public:
int k;
};

Again, IIRC, 'private' items are inaccessible to everyone except
the class itself. Have I misunderstood the semantics?

Correct. Private items are even inaccesible to dervied classes.


-JKop

 

[JKop]

What are access specifiers for again?

Here's how I go about things:


1) I'm writing a class.

2) I want an object in the class to store some data.

3) I decide whether the user needs to know anything about this data.

4) If so, I make it "public", if not I make it "private".


Why make it private? I consider it to be a synonym for "Hey user, you don't
need to read up on this bit, it's just the internal guts of my class, you
don't have to worry about it, it doesn't affect how you use the class, ie.
the interface".


Ofcourse my user can just open the header file, replace private with public
and alter my private objects willy-nilly. To this I say:

"I warned you. You're messing with the internals of the class. I haven't
documented how the internals works so either A) You've figured it out by
reading my code, or B) You're messing. Either way I assume no liablility. I
gave you a user-friendly easy-to-use class, end of story."


Similarly, when I've been given a class written by some-one else, I don't
read through the private section, why... because I don't need to! All I'm
worried about is reading the "public" section, because that's the stuff I'll
work with to get what I want out of the class.


-JKop

 

[Pascal Costanza]

Here's how I go about things:

Same here:

1) I'm writing a package.

2) I want a variable in the package to store some data.

3) I decide whether the user needs to know anything about this data.

4) If so, I export it from the package, if not I don't.


Why no export? I consider it to be a synonym for "Hey user, you don't
need to read up on this bit, it's just the internal guts of my package,
you don't have to worry about it, it doesn't affect how you use the
package, ie. the interface".

Of course my user can just use the variable with a special qualified
access and alter my non-exported variables willy-nilly. To this I say:

"I warned you. You're messing with the internals of the package. I
haven't documented how the internals works so either A) You've figured
it out by reading my code, or B) You're messing. Either way I assume no
liablility. I gave you a user-friendly easy-to-use package, end of story."

Similarly, when I've been given a package written by someone else, I
don't read through the non-exported symbols. Why? Because I don't need
to! All I'm worried about is reading the exported symbols, because
that's the stuff I'll work with to get what I want out of the package.

+++++++++++++++++++

In Common Lisp, access control and the object system are orthogonal
concepts.


Pascal

 

[Gerry Quinn]

On one hand, I agree with you. But all significant programs
develop their own "vocabulary," one that matches the domain
at hand. The hard part about understanding a large program
is rarely mastering the details of the language in which it
is written. Rather, it is understanding the underlying
model of the domain scattered throughout its functions,
methods, classes, etc.

On the other hand, though, I disagree. Someone once claimed
that Lisp is a "programmable programming language". It is
the best available tool for building new domain-specific
languages. Why settle for a tool that is less-featured in
this regard. (This is the heart of the admittedly trollish
tenth rule of programming due to Greenspun.)

Of course, we can respectfully disagree about whether this
is the right approach to building large programs. Perhaps
it is a defining characteristic of the Lisp community that
they think this way: When faced with a complex domain, one
"grows Lisp up" to meet it.

Fair comment. But put this way, whichever side you prefer, you can
hardly see it as an especially important or 'life-changing' advantage of
Lisp, can you?

- Gerry Quinn

 

[Gerry Quinn]

Let me start by thanking you for your honest and thoughtful
response. I appreciate the opportunity to learn more about how
others program.



So, unless I misunderstand the symantics of the 'protected'
specifier, thinks marked this way are accessible to the class and
any sub-classes, but no one else. Is that correct?
Yes.

I believe items declared 'public' are accessible to anyone, as
they would be in C. If one does not declare an specifier, do they
not default to 'public'?

No, private. [Although C++ retains the 'struct' keyword from C, and
members of a struct default to public.]

My habit is to start a class definition with:

class MyClass
{
public:
// member data
protected:
// member data
public:
// member functions
protected:
// member functions
};

(only without the comments). Ideally the first category should be
empty, and typically the fourth is biggest. Often I move stuff around
during development.

One minor dilemma I often encounter is whether to use accessor functions
to get at protected data. Ideally, I suspect, a class should have its
own internal accessors, but that is too much typing, so it remains
conceptual! I do sometimes implement it in a small way, i.e. with a
public const accessor, and a protected non-const accessor/mutator.

Again, IIRC, 'private' items are inaccessible to everyone except
the class itself. Have I misunderstood the semantics?

No, that is correct. (You can use the 'friend' keyword to make
exceptions in special cases.)

- Gerry Quinn

 

[Gerry Quinn]

Didn't we just discuss why CL is bad and C++ is good because C++
_trusts_ the programmer to do his memory management and pointer
arithmetic perfectly?

Do you use a garbage collector and disable pointers when you are working
in a project team? If so, what's the magic compiler flag?

No, *we* didn't discuss that. But there's a difference, in any case.
Garbage is a very global issue. And pointer arithmetic is a very non-
global issue. A class doesn't use either to mess with the internals of
a different class.

- Gerry Quinn

 

[Gerry Quinn]

Gerry Quinn <[email protected]> wrote in message news:<[email protected]>...

By manipulating the class definition, we can introduce names into the
scopes of function bodies that are located away from that definition,
and we can seriously alter their meaning.

Not a problem, because functions are bound to classes. 'Away' is a
matter of definition. Lispers have been going on about how closing
parentheses half a mile away from their opening parentheses don't
matter. Likewise, there's a trail from function to class definition.

This is a critical language design mistake; it's in no way necessary
for ``class scope'' to exist in an object system.

Nonsense. There is every reason.

Lisp has multiple dispatch so that there isn't even a self object. A
method with three specializable parameters has three ``self'' objects.
They are explicitly named as parameters, nothing is hidden. Class
scope imposed into the Lisp paradigm would wreak even greater havoc,
because there would be clashes between identically named members from
the different classes.

That's because whatever 'class' functions you bolt on to Lisp, the
language is not object-oriented and never will be, except maybe at
package level. Deal with it.

- Gerry Quin

 

[Philippa Cowderoy]

Fair comment. But put this way, whichever side you prefer, you can
hardly see it as an especially important or 'life-changing' advantage of
Lisp, can you?

Not as a lisp-only feature, but I'm certainly finding that level of thing
highly useful in Haskell - and it's having a serious effect on my
day-to-day programming.

 

[Brian Downing]

That's because whatever 'class' functions you bolt on to Lisp, the
language is not object-oriented and never will be, except maybe at
package level. Deal with it.

It sounds like you're claiming that encapsulation is a integral part of
"object orientation". This comes up a lot in discussions of CLOS.

We (Common Lispers) don't think encapsulation is an integral part of OO.
Instead we have a separate language feature (packages) that handle
encapsulation. ``CLOS'' is left to deal with inheritance and
polymorphism (which, incidentally, are far more powerful than their C++
counterparts).

This is a difference of opinion.

-bcd

 

[Svein Ove Aas]

Not a problem, because functions are bound to classes. 'Away' is a
matter of definition. Lispers have been going on about how closing
parentheses half a mile away from their opening parentheses don't
matter. Likewise, there's a trail from function to class definition.

I agree with this, and Lisp methods tend to be located even further from the
class definition, for that matter.
Besides, most C++ IDEs have something similar to M-., which lets you move
directly from the invocation or declaration of a function to its
definition.

On the subject of Lisp, though, I'd hope that most Lispers *don't* think
having closing parantheses a long way from their opener is a good thing.
Personally I always try to keep functions below a screenful, so I can see
all of it at once.

I keep telling friends not to do that in C, though, and they keep not
listening to me - even adding vertical whitespace where none is needed - so
I wouldn't be surprised at all if I someday see a 200-line Lisp function.
They probably have better memory than I do.

Nonsense. There is every reason.

If you're basing it on a message-passing paradigm, then there is. If you
have multiple dispatch then it doesn't make sense. Design choice, there.

Which one of those is best is a different discussion, but *for C++*, class
scope is reasonable. *For Lisp*, it isn't.

Class scope tends to play havoc with multiple inheritance, though, if that
includes automatically binding variables to the instance/class slots.

That's because whatever 'class' functions you bolt on to Lisp, the
language is not object-oriented and never will be, except maybe at
package level. Deal with it.

Packages are namespaces, classes are... well, classes. They're entirely
different concepts: although class/instance slots can in some ways be said
to be in a separate namespace, in reality they are just in a separate
lexical scope.

That's true for C++ too, it's just slightly harder to see because function
definitions don't have to be inside the class-definiton braces.[1] In Java
they do, IIRC.


Now, then. How can you possibly say that Lisp isn't object-oriented, when
you can even specialize methods on built-in primitive types such as lists
(okay, conses) and numbers? (And fixnums, bignums, integers, floats, and so
on.)

It was *designed* to be an object-oriented language; the Common Lisp ANSI
standard was the first object-oriented language to be standardized.

Other people have already said this, though. Why, then, do you keep claiming
this? What does Lisp lack, that stops it from being object-oriented?


1: Hmm, can you still call it a lexical scope, then? I was pretty sure the
idea of a lexical scope involved the look of the source code;
myclass::function is inside myclass's lexical scope, but it isn't actually
*written* there.

 

[Svein Ove Aas]

It sounds like you're claiming that encapsulation is a integral part of
"object orientation". This comes up a lot in discussions of CLOS.

We (Common Lispers) don't think encapsulation is an integral part of OO.
Instead we have a separate language feature (packages) that handle
encapsulation. ``CLOS'' is left to deal with inheritance and
polymorphism (which, incidentally, are far more powerful than their C++
counterparts).

This is a difference of opinion.

I might add that you do have encapsulation, if you decide to use slot-value
for "private" slots and accessors for public slots. That probably isn't a
good idea, though, since slots might go away at some point while accessors
can be redefined to emulate the slot some other way. The canonical example
may be storing a vector as magnitude+direction vs. x-pos, y-pos and so on.

One way that works, then, is by naming private functions as "%function%",
and public functions as "function".

It works for me, and although it's just a difference in syntax, we've
already established that that's true for C++ as well. People won't be
calling %internal-method% without noticing the %'s.

 

[Svein Ove Aas]

(e-mail address removed) says...
[snip]

I believe items declared 'public' are accessible to anyone, as
they would be in C. If one does not declare an specifier, do they
not default to 'public'?

No, private. [Although C++ retains the 'struct' keyword from C, and
members of a struct default to public.]

My habit is to start a class definition with:

class MyClass
{
public:
// member data
protected:
// member data
public:
// member functions
protected:
// member functions
};

(only without the comments). Ideally the first category should be
empty, and typically the fourth is biggest. Often I move stuff around
during development.

One minor dilemma I often encounter is whether to use accessor functions
to get at protected data. Ideally, I suspect, a class should have its
own internal accessors, but that is too much typing, so it remains
conceptual! I do sometimes implement it in a small way, i.e. with a
public const accessor, and a protected non-const accessor/mutator.

There's an advantage of Lisp right there, then. It's very, very easy to
define accessor methods (or separate reader and writer methods, if that
fits better), and if you later change the contents of the slot (or remove
it), you can just remove the accessor declaration and define your own to
fit the new slot.

It's what I suspect you wanted to do, and the compiler is smart enough that
accessor calls don't neccessarily involve function calls, especially if you
use type declarations.

 

[Sashank Varma]

Fair comment. But put this way, whichever side you prefer, you can
hardly see it as an especially important or 'life-changing' advantage of
Lisp, can you?

Well it's life-changing for those whose life it changed.

I know, that's a bit circular. Most programmers come
to Lisp after having mastered more mainstream languages.
In my days, the natural progression was Basic->Pascal->C.
I don't know what it is these days - perhaps Visual Basic
->Java->C++? Those that "convert" to Lisp wonder why
others do not. There are of course pragmatic reasons
(i.e., number of jobs) and matters of taste (i.e., do
you resonate with the material in Graham's "On Lisp"?).
But to a convert -- at least to this convert -- some of
the reasons seems merely conservative or reactionary.

An additional problem is that relatively few programmers
make the reverse progression, from Lisp-like languages
to more mainstream languages. I'm not speaking here of
those who were exposed to Scheme in an introductory class
and found it weird. I'm speaking of people who spent a
few years immersed in Lisp, mastered its idioms, and
moved on to more mainstream languages because they
thought them techically superior. (Ray Blaack, who was
participating in this thread, indicated that he is one of
the few exceptions in this regard.)

These are some of the reasons why advocacy debates between
Lispers and users of more mainstream languages rarely
yield new converts for either side.

 

[Ray Blaak]

I'm speaking of people who spent a few years immersed in Lisp, mastered its
idioms, and moved on to more mainstream languages because they thought them
techically superior. (Ray Blaack, who was participating in this thread,
indicated that he is one of the few exceptions in this regard.)

Actually, I in fact think Lisp *is* techically superior. I just don't use it
in my job. I wish I could.

I use Java and C# instead. I avoid C++ like the plague and only use it if
forced to maintain a legacy project. I avoid VB as well.

It would be great to be able to use Common Lisp, Scheme, Dylan, etc on real
projects. For that matter, it would also be great to be a games developer.

PS: its "Blaak". "Blaack" sounds like spitting up a hairball .

 

[Szymon]

[.....]

Types are defined using defclass.

Scopes are created using let/lambda.

What about PROGV? Does it qualify here? I think it does.

I'm just curious...

Btw, why do you omit FLET?

Namespaces are created using defpackage.

[.....]

Regards, Szymon.