C++ sucks for games

[Pascal Bourguignon]

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.

That is, with the inability of management to advise lisp job in the
right place or to offer decent wages.

As you said, what went wrong had nothing to do with lisp.

 

[Svein Ove Aas]

That's because you haven't used the language lisp aspires to be:
unlambda ( http://en.wikipedia.org/wiki/Unlambda )

The last time I looked at that, I had never used any FP-capable language,
and I thought it was rather weird.

Now, I know better. I know it is in fact a decent representation, in a
Picassoan way, of some of the contortions I have had to use in such
languages.

So... does anyone want a nice, chewy monad?

 

[Matthew Danish]

Fine, if you want to be ANAL about it...

S = 1.0/2.0*a*sqr(t) + vi*t;

but your not adding anything to this thread...

And so goes a HUGE mistake that C and C++ programmers make all the
time: using floating point arithmetic where it is not called for. Why
do they do this? Because their language does not support rational
arithmetic. And in classic "New Jersey"[1]-fashion, instead of solving
the problem by doing the right thing, they just continue to repeat the
same old mistake.

In any case, anyone who thinks that "S = 1/2*a*sqr(t) + vi*t;" is
somehow "more normal" is speaking in a very subjective sense. If you
want a notation that might be considered more "standard", how about
ditching that ridiculous ASCII trash pretending to be math, and trying
this:

$ cat > math.tex <<EOF
\documentclass{article}
\begin{document}
$S=\frac{1}{2}at^{2} + v_{i}t$
\end{document}
EOF
$ latex math
$ dvips math.dvi -o
$ gv math.ps

THAT is what mathematical notation looks like. The garbage you
propose above, although widely adopted, is still a perversion.


[1] http://www.naggum.no/worse-is-better.html

 

[Jon Boone]

The bulk of people will stick with a language that understands infix
notation...

Ah, so you want dylan then...

You know, the *infix* syntax lisp.

--jon

 

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

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.

same in C:
f(xy, z);


André

 

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

"André Thieme" <[email protected]> wrote in

message news:[email protected] years go. All we could seem to do is have lots of brackets with calls
to functions embedded..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.

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.


This was just an example regarding infix operators. The most common use
for infix operators are functions which work on two arguments, like the
addition.
In CL the + has no special meaning like it has in C++, where it is an
operator - in CL it is just a name. The could have called it also "add".
Then it would look more common: add(100, 25);
To make it shorter they called it +:
+(100, 25);

Now remove the , and the ; and move the + inside the brackets and you
have CL.
That CL does not treat mathematical functions (which are usually written
infix) different has the disadvantage that you need two brackets if you
want to do it only one time, but on the other hand the advantage that it
is a function which accepts any amount of arguments and saves some typing.

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's horrible... What if 'x' was also a function name etc...

Image a C++ program where f and x are functions. What would happen if
you do:
f(x, y, z);
Something "horrible".
If you wanted to do f(x(), y, z); then it would be in Lisp: (f (x) y z)

It just doesn't seem good to have the function name inside the ()'s

to me.


This does not really mean much. In mathematics some people also write
everything postfix:
(x, y, z)f; [a "postfix C++"]
(x y z f) [a "postfix Lisp"]

Use this five days and you don't see anything bad about it. In fact it
is not the expression which is wrong.. it is the human brain which is so
slow with adopting that. Your computer will accept any expression when
you explain him how it is built. So in that way we can learn from our
machines ;-)

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.


As others pointed it out: it was a typo from my side.
The special thing about Lisp is, that if you know that (nearly always)
the first thing in brackets is the name of a function and the rest are
the arguments, then you nearly know all basics.

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.

Congrats to your first Lisp program! *g*

What if I had forgotten the ()'s

What if you had forgotten them in C++?
func(1, add 2, 3, a, "-b"); instead of
func(1, add(2, 3), a, "-b");

If you are not using an infix operator in an expression then C++ always
needs the same amout of brackets.
And Common Lisps way to make +, -, *, etc NOT an operator but just
normal functions is *good*.
Why? Because you can just pass it as arguments to other functions!
Imagine you have a function foo which accepts three arguments:
one function and two arguments which will be passed to that function.

Something similar happens in quicksort() functions. You give them an
array of objects (of a class) to sort and a function which does decide
which object is "bigger" and which one is "smaller".
But back to the "+" example: if you want to call foo with an addition
function and two numbers in Lisp you could simply do that:
(foo '+ 10 15)

But imagine to do this in C++:
foo(+, 10, 15);

inside and just had "func 1 + 2 3 a..." ,'s just "seperate" the

parameters.


Spaces also separate them. Look at this:

inta;
int,a;
int a;


André

 

[Pascal Bourguignon]

S = 1.0/2.0*a*sqr(t) + vi*t;

$S=\frac{1}{2}at^{2} + v_{i}t$

I write:
(= S (+ (* 1/2 a (^ t 2)) (* (v i) t)))


I don't see much difference between these forms.

THAT is what mathematical notation looks like. The garbage you
propose above, although widely adopted, is still a perversion.

Anything from:
ftp://publications.ai.mit.edu/ai-publications/0-499/AIM-145.ps
to:
http://www-sop.inria.fr/lemme/Loic.Pottier/ei98.ps

So you'd want to program like this:

(deformula "
1 2
S = --- a t + v t
2 i
")

Note that in ASCII-art, it's still quite parseable.

 

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

Ha-ha... : )
No, it was the implementation of all those darned ()'s and spaces.
I like the more natural way than that used in Lisp - that's all.
It had nothing to do with Complex.

You already showed in one example that you used the correct syntax. So
if it was difficult for you this time that you probably did not look at
it like you did before.

(+ 2/3 2/3 1/3) is in C++:
2./3. + 2./3. + 1./3. or also:
(float)2/(float)3 + (float)2/(float)3 + (float)1/(float)3;

Now *that* is not so natural, is it? ;-)

In Lisp you not only have integers or floats, you also have rationals
which are always accurate (but slower because they don't use the
floating point unit) and even complex numbers.
Complex numbers need some special way to write them down. This is
similar to C where you need to say that 2 is a float by writing it
either 2. or 2.0 or (float)2 or maybe float(2)
C++ does not have complex numbers, Lisp does, and you write them down
this way:
#C(real i)
for example #C(3 3)
Of course + does work on complex numbers too. And you don't have to do
explicit operator overloading and you are lucky, you don't need to write
a class "Complex", *cheers*


André

 

[Kenneth Tilton]

I'm listening. But it'll take more than a few apparently successful
Lisp projects to convince me. Maybe I'm over-conservative, but even if
Lisp is all you say, the benefits of being an early adopter are dubious.

Agreed. Most IDEs are primitive compared to C/C++/Java IDEs. Libraries
are scarcer, though that is beginning to improve a little.

The first Lisp IDE I used did not have an automatic project manager. But
there are a couple of Lisp "make" tools, and my IDE was hackable (in
Lisp), so I kinda just rolled my own project manager in a few hours. And
now it is something I can tweak as I like, which is mad cool and also a
traditional Lisp thing (building one's own little IDE).

And any time I want a library, I lose a few hours globally editing a C
header file until it turns into a set of Lisp bindings to that library.
Using a C++ library also means writing some C glue so Lisp can talk to
it.

But those are finite tasks, and then I am back up to full speed using
Lisp for months on end.

Especially when Lisp has been touted the same way for about twenty
years. I've got lots of time to get on the bandwagon...

Yep. I found Lisp when looking for A Better Way than C to do version two
of my commercial app. Something that would let me be vastly more
productive, enough to make up for the occasional one-time effort.
Believe me, Lisp roolz.

kt

 

[Kenneth Tilton]

[snips]

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.

This is not a language issue; this is a _tools_ issue. This is a question
of whether or not your _debugger_ allows you to do this sort of thing;
nothing in the C or C++ language specs prevents it.

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.

Again, you're discussing _tool_ issues, not _language_ issues.

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.

And again...

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.

Sure, if you give us something that suggests there's a benefit to the
language. So far, you haven't.

Why is Chevy better than Ford? Well, see, if I use Michelin radials, I
get better road grip. Umm... so? That's a *tires* issue, has nothing
whatsoever to do with why one car is better than the other. You keep
giving us tires, while making claims about the cars.

I was responding to something someone wrote about not seeing the
advantages of an interactive language. Come to think of it, I thought
everyone liked interactive languages. Not sure why it needs explaining.
The appeal gave birth to Python, and is giving birth to Groovy, which is
Java's attempt at an interactive extension.

I have heard that some C/C++ tools make brave attempts at interactivity.
If so, great. But I was just explaining to that one person why I liked
an interactive language.

Ah, just thought of another one. Component Workshop. A now-deceased
interactive C++.

As for language benefits: garbage collection, macros, special variables,
untyped variables/typed data; the list datastructure; multimethods,
editing-with-parentheses (shocked?); multiple-inheritance done right;
the meta-object protocol; lexical scoping; closures; first-class
functions; lack of syntax; native-compiled speed; reflection ala RTTI;
the loop macro; &rest, keyword and optional arguments to functions;
different kinds of method combinations; destructuring-bind (long
story);...

kenny

 

[Frank Buss]

C++ does not have complex numbers, Lisp does, and you write them down
this way:
#C(real i)
for example #C(3 3)

C++ has complex numbers, defined as a template:

http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html

 

[Frank Buss]

But imagine to do this in C++:
foo(+, 10, 15);

you can do something like this in C++ with templates and predicates, but it
doesn't look so simple as in Lisp:

http://www.devx.com/tips/Tip/12955

 

[Maahes]

I'm sure you're quite happy dealing with nested parens when writing

arithemtic. Is there some reason why parens around code is different?

absolultely NOT. Sometimes its unavoidable, especially complex IF
statements, but its never a good thing when we have to do a line with lots
of brackets, because its hard to read at a glance.

Can they handle the semicolons? If so, parentheses won't present any
additional difficulty. But by all means, even if you don't use it at

I'll leave you to rethink that first statement coz I don't think it
justifies an argument.

work, spend some time learning Lisp- it will certainly make you a
better C/C++/Java programmer.

entirely possible.

 

[Greg Menke]

absolultely NOT. Sometimes its unavoidable, especially complex IF
statements, but its never a good thing when we have to do a line with lots
of brackets, because its hard to read at a glance.

You may rest assured that no-one who has become familiar with writing
Lisp code has trouble with parentheses- which is what they are called-
not brackets. Likewise, anyone who has become familiar with C doesn't
have trouble with semicolons and curly braces.

I'll leave you to rethink that first statement coz I don't think it
justifies an argument.

I think it does. You see parentheses as problematic when it comes to
understanding Lisp. I say semicolons are the same with C. Obviously
you don't have trouble with semicolons, or braces for that matter-
because you know C-like languages. My point is that semicolons,
braces, parentheses are syntactical stuff that you learn quickly. I
think the bigger problem you'll face is unlearning C, meaning,
identifying and overcoming some of the unconscious design rules you've
picked up about how software "should" be. Lisp takes a fundamentally
different view in some respects- not as different as something like
Prolog, but if you really want to start grokking Lisp, you'll end up
having to relearn some things.

entirely possible.

You'll look at programming differently afterwards.. good luck!

Gregm

 

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

I think you might have missed the point...




is basically already in C.

The lisp version requires some mental gymnastics...

The bulk of people will stick with a language that understands infix
notation...

After all, C's infix is compiled to a lisp like bytecode in order to
assemblerise it, but people don't want to have to program at that level...

For a beginner it might be mental gymnastics. Like with gymnastics your
brain gets trained. After some time you have no problems to use prefix
notation for things for which you usually use infix notation.
As someone already mentioned, if you want you can get infix notation.
But if you want to get everything with prefix notation in C++... how
would you then do that? ;-)


André

 

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

C++ has complex numbers, defined as a template:

http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html

Yes, that's right. However, they are still not so easy accessible like
the infix operators in our earlier discussions. Therefore complex
numbers would need to be included in the base language. If you need them
for just one part in your program, then do this in C++:
(+ #C(3 4) 25)

Just look at the example program on the site you posted.

Have fun


André

 

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

you can do something like this in C++ with templates and predicates, but it
doesn't look so simple as in Lisp:

http://www.devx.com/tips/Tip/12955

Noone said that such a thing is not possible in a turing complete
programming language. We are discussing about how complicate Lisp is,
because you usually don't write 10*3+4 but (+ (* 10 3) 4). If this is
complicated, what is foo(+, 10, 15) in that case?


André

 

[David Steuber]

No, it was the implementation of all those darned ()'s and spaces.
I like the more natural way than that used in Lisp - that's all.
It had nothing to do with Complex.

I notice that in the above paragraph, you mostly use spaces to
separate symbols. A comma only appears once. More generally, white
space seems to be the standard seperator for symbols in lists:

Shopping list:

lettuce
bacon
tomatoes
bread
mayonnaise
chips
dip

You also seem to be used to prefix notation for function calls:

foo(x);

Well, (foo x) is hardly any different. It has the same number of
parens and does not require a statement terminator. The advantage of
Lisp's notation becomes most evident when you need to write a macro.
Lisp code is expressed as Lisp lists. The full power of Lisp is
available to manipulate lists so that you can write arbitrarily
complex macros. This is not the case with macro systems that only
manipulate text.

The simple syntax also means that editors can provide more assistance
to the programmer. If you type something out of whack, it often shows
up clearly in the editor.

Best of all, Lisp can express programs with less code than most other
languages. This is less code to write, read, and debug. Programming
is more productive. Python programmers make the same argument when
comparing Python to, say, Java. The difference is, Lisp does not
suffer the performance penalty that Python does even though the code
is just about as concise.

 

[Karl A. Krueger]

You may rest assured that no-one who has become familiar with writing
Lisp code has trouble with parentheses- which is what they are called-
not brackets. Likewise, anyone who has become familiar with C doesn't
have trouble with semicolons and curly braces.

That's a dialect difference, not an error.

British usage (as I understand it, at least) refers to brackets, square
brackets, and curly brackets where American usage refers to parentheses,
brackets, and braces.

 

[David Steuber]

I'll stress one last time - IMHO, the reason your not getting any converts
to Lisp from this thread is that those three lines look very complex to a C
program, simply because of the 5 brackets at the end of the last line. If I
wrote an IF statement with that many brackets, I have to be very careful
with it.. and I certainly wouldn't want to deal with that on every one of my
statements...

Usually you use a Lisp aware editor like Emacs (or even Vi) to take
care of the parens for you. You can even write functions that look a
lot like C functions:

[31]> (defun fac (n)
(let ((f 1))
(loop for i from 1 to n
do (setf f (* f i))
finally return f)))
FAC
[32]> (fac 3)
6
[33]> (fac 5)
120
[34]> (fac 0)
1
[35]> (fac 1000)
402387260077093773543702433923003985719374864210714632543799910429938512398629020592044208486969404800479988610197196058631666872994808558901323829669944590997424504087073759918823627727188732519779505950995276120874975462497043601418278094646496291056393887437886487337119181045825783647849977012476632889835955735432513185323958463075557409114262417474349347553428646576611667797396668820291207379143853719588249808126867838374559731746136085379534524221586593201928090878297308431392844403281231558611036976801357304216168747609675871348312025478589320767169132448426236131412508780208000261683151027341827977704784635868170164365024153691398281264810213092761244896359928705114964975419909342221566832572080821333186116811553615836546984046708975602900950537616475847728421889679646244945160765353408198901385442487984959953319101723355556602139450399736280750137837615307127761926849034352625200015888535147331611702103968175921510907788019393178114194545257223865541461062892187960223838971476088506276862967146674697562911234082439208160153780889893964518263243671616762179168909779911903754031274622289988005195444414282012187361745992642956581746628302955570299024324153181617210465832036786906117260158783520751516284225540265170483304226143974286933061690897968482590125458327168226458066526769958652682272807075781391858178889652208164348344825993266043367660176999612831860788386150279465955131156552036093988180612138558600301435694527224206344631797460594682573103790084024432438465657245014402821885252470935190620929023136493273497565513958720559654228749774011413346962715422845862377387538230483865688976461927383814900140767310446640259899490222221765904339901886018566526485061799702356193897017860040811889729918311021171229845901641921068884387121855646124960798722908519296819372388642614839657382291123125024186649353143970137428531926649875337218940694281434118520158014123344828015051399694290153483077644569099073152433278288269864602789864321139083506217095002597389863554277196742822248757586765752344220207573630569498825087968928162753848863396909959826280956121450994871701244516461260379029309120889086942028510640182154399457156805941872748998094254742173582401063677404595741785160829230135358081840096996372524230560855903700624271243416909004153690105933983835777939410970027753472000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Oh, I guess C an Java might have one minor problem with not properly
dealing with numbers that don't fit into a machine word.

I'll probably go off and learn some more lisp now, since all these posts
have made me think there might be a fabulous language there if you can get
past the excessive use of brackets...

And its certainly a simple enough language to write your own compiler so
maybe I can play with that for a game. I doubt I'd have any luck convincing
anyone at work that our scripting language should be Lisp though... I don't
think most of our designers could handle all those brackets...

Scheme is something you could write a compiler for in a reasonable
time. Common Lisp is a bit more complex.