C++ sucks for games

[Fred Bayer]

I have to say, I think the original line looks easier to understand. In C
this would be:

S = 1/2*a*sqr(t) + vi*t;

I think all your brackets will put off most people wanting to experiment
with Lisp after using C/C++/Java/C#

and your object will never accelerate!

 

[Mario S. Mommer]

1.0 / 2.0

Fair enough.

Anyway, this is a nice counter example to the (rather outrageous, IMO)
claim that C++ has a natural syntax. You write 1/2 and it actually
means... zero.

 

[Maahes]

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

 

[Maahes]

But of course, no Lisp programmer would write it this way. If you want a

list, which contains all elements from n to 0, you can write it like this:

(defun make-down-list (n)
(when (>= n 0)
(cons n (make-down-list (1- n)))))

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

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

 

[Maahes]

and your object will never accelerate!

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

 

[Frank Buss]

I think you might have missed the point...


is basically already in C.

no, the ^-operator means xor in C.

The lisp version requires some mental gymnastics...

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

at least for me the prefix notation is easier to understand, if properly
indented, because it is always the same, without operator precedence. But
for long fomulas it might be useful to use the #I macro to have the usual
mathematical notation:

(defun distance (a time vi)
#I "0.5*a*time*time + vi*time")

It is no problem in Lisp to mix languages like you want.

 

[Mario S. Mommer]

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

IMO, there is only one way around the brackets that really makes
sense: use a Lisp aware editor like emacs. After a short while, you
pretty much don't see the parentheses any longer, or at least they
don't look threatening at all. It's true.

Minimally 'Lisp aware' includes not only paren-matching but also
automatic reindentation of code (just as in any other language, in
Lisp you rely on indentation to make things clear). In emacs, this is
<ESC> C-q.

I think there are similar facilities for vim, but I don't know for
sure.

 

[Frank Buss]

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

I don't want to convert anyone, I'm using C++ and Java, too, but I plan
to use more Lisp. I've tried it some months ago for the first time and
for me it is more flexible than any other language I know.

Of course, there are some projects, where you don't have a chance to use
Lisp, because all other programmers knows Java or C++ and you can't say
the project manager, that they have to learn Lisp, or there are no good
compiler for the platform you need and you don't want to write one. But
there are other projects, perhaps small ones, which you can do alone,
where the customer is not interested in the language you use, as long as
the program does what it should do.

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

you should not handle it manually. I can't write Lisp code without a nice
editor, which shows me the opening bracket for every closing bracket I
type or I move the cursor over. And the editor should have a good Lisp
auto-indent mode, because the right indention is most important to write
readable Lisp programs.

 

[Steven E. Harris]

those three lines look very complex to a C program, simply because
of the 5 brackets at the end of the last line.

Funny, I hadn't even seen them, and I never would when writing or
reading any Lisp source. It may be hard to believe, but with
experience those parentheses simply disappear.

To alleviate concern about producing such code, most Lisp programmers
never even type those closing parentheses. In my editor, every press
of '(' inserts a balanced pair of '(' and ')'¹, so no dangling cases
arise.


Footnotes:
¹ Really, I press '[' to get this behavior (`insert-parentheses'),
leaving '(' alone for use just in case. Symmetrically, I have ']'
bound to `move-past-close-and-reindent'.

 

[Paul Foley]

By bottom-up, I mean, your grouping all your lowest expression together and
then operating on them, and then operating on the result of that.

For instance (an example someone posted).

C:
for (int i=0; i<=10; i++) list.push(i);
list.reverse();


(let ((lst 0))
(dotimes (i 11)
(push i lst))
(reverse lst))

Bah. Using "lst" instead of "list" indicates that it's written by a
Schemer who can't get to grips with multiple namespaces

Presumably the 0 is a misreading of () -- 0 isn't a list.
[Style note: '() would be better]

In the C version, I am typing straight out of my head in left -> right
fashion and appending new work as I go along. In the Lisp one, it seems you
have to group the (push i lst), the (i 11), as they are the bottom level
actions. Then wrap that in a (dotimes a b) framework, then wrap that in a
let (a b) framework. I'm not even sure why there are 2 brackets around the
lst 0. This seems to make a mockery of Lisp having consistent syntax.

(dotimes (i 11) ...) is just how you write for (int i=0; i<=10; ++i) {...}
in Lisp; you left out the declaration of "list" in the C version,
corresponding to the LET in Lisp, otherwise the structure of the two is
exactly the same. ["In the C one, it seems you have to group the
list.push(i) and the int i=0 and the i<=10 and the ++i, as they are
the bottom level actions. Then wrap that in a for () ; framework"]

FWIW, you can just write

(loop for i upto 10 collect i)

in CL.


The syntax of LET is (LET <bindings> <body...>), where <bindings> is a
list of variables to be bound, and a list is written (elt1 elt2 ...);
if you write

(let (a b c) ...)

that causes variables A, B and C to be bound to the value NIL
(equivalent to

{
some_type a;
some_possibly_different_type b;
yet_another_type c;

...
}

in C-based languages); if you want to specify the value you can write
another list, (<variable> <value>), as an element of the bindings
list, so

(let ((a 1) (b "foo") c) ...)

binds A to 1, B to "foo" and C to the default value (NIL) again.
That's why are two parentheses.

On top of all that, there are so many darn brackets there that I find that
it takes me a few seconds to match them up in my head to see which groups
are arguments to which functions, though I expect your quite used to the
indenting so it makes instant sense to you. I would imagine a far more

Yeah, indentation (formatting, more generally) is key; Lispers don't
usually even notice the parentheses, let alone try to match them up,
unless there's something wrong.

 

[Karl A. Krueger]

Minimally 'Lisp aware' includes not only paren-matching but also
automatic reindentation of code (just as in any other language, in
Lisp you rely on indentation to make things clear). In emacs, this is
<ESC> C-q.

I think there are similar facilities for vim, but I don't know for
sure.

There most certainly are.

vim has a Lisp mode, which can be turned on automatically when you open
a file that vim recognizes as being Lisp code. It includes paren
matching (the "%" command), syntax highlighting, auto-indenting (placing
the cursor when you press enter), and reindenting of expressions (the
"==" command).

 

[Szymon]

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

Read this:

[ http://srfi.schemers.org/srfi-49/srfi-49.txt ]

It's proposition for python-like (optional) synatax for Scheme (Scheme is
dialect (it forked (afaik) in ~1975) of LISP).

....

defun (fac x)
if (zerop x) 1
* x
fac (1- x)

....

..

 

[Fred Gilham]

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.

Major 4 year institutions have also put out many of these kinds of
people. In my pre-cs-higher-education days, when I was a self-taught
hacker type, I wandered through some cubicles in the place I worked
asking, "What does a semaphore do?" The real question was "Can I do
what I want with semaphores?" The closest to an answer I got from A
ROOM FULL OF CS DEGREED ENGINEERS was, "I heard about them in college
once."

I promptly went out and, using semaphores, wrote a poor emulation of a
print spooling system that would freeze the entire system when someone
took a printer off line. But I at least had an excuse.

--
Fred Gilham (e-mail address removed)
When I was growing up, I found that the main argument against
laissez-faire, and for socialism, was that socialism and communism
were inevitable: "You can't turn back the clock!" they chanted, "you
can't turn back the clock." But the clock of the once-mighty Soviet
Union, the clock of Marxism-Leninism, a creed that once mastered half
the world, is not only turned back, but lies dead and broken forever.
-- Murray Rothbard

 

[Computer Whizz]

Actually, a pseudo-Lisp of the above would probably be something like:

(output "gfgf" variable (func blah 2))
(change variable)
(setf var2 (func blah 2))
(output var2 variable1)

"function" is an actual function name in Lisp, so I changed it to
"func" for this example.

That wasn't so horrible, was it?

Thanks very much.
- True, it's better than what I misguidedly wrote...

 

[Carl Muller]

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

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

 

[Greg Menke]

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

Your C++ example would look like magic to someone who wasn't
conversant with the stl- if thats in fact what you're using. If it
isn't, then I think your example is oversimplified.

I'm sure you're quite happy dealing with nested parens when writing
arithemtic. Is there some reason why parens around code is different?

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

C and C++ wouldn't be so bad if it weren't for all the semicolons.

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

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
work, spend some time learning Lisp- it will certainly make you a
better C/C++/Java programmer.

Gregm

 

[Kelsey Bjarnason]

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

 

[Jock Cooper]

[snip]

This is not to say that Lisp, in the hands of an expert, is not an
incredibly powerful language which is fast and easy to program... But I
can't see it getting many converts from the land of C programmers...

I am one C (and Perl) programmer who switched to lisp; mainly because
of lambdas/closures and macros. As someone who used to use pass
around function pointers frequenty in order to customize the behavior
of other functions, a Lisp closure is for me a huge huge win. And
macros can save a huge amount of typing and code duplication; sure a
function can often do the trick but there are cases when only a macro
will do. The result of all this is extremely consise and clear code.
Complaining about 'all those parentheses' is like saying XML would be
great if it didn't have all those damn tags everywhere.

At least in my case I didn't come to Lisp until I was fed up with
fighting with C to get it to do what I wanted it to. Early in my
C career I hadn't had enough of these fights to realize yet why
something like a closure or special var can be so useful. As far
as macros, well I always had used C macros a lot; and of course a
Lisp macro is an order of magnitude more powerful than a C macro.

 

[Kelsey Bjarnason]

[snips]

As for the issues raised being truly something you need to know about... do
you need to tell a child not to eat its own excrement? No. Why? It figures
that out for itself. If you're writing code and you have "new" all over the
place and you've no "delete"'s, then you'll figure out the aim of the whole
"Garbage Collection" ideal.

To hand-hold people who aren't bright enough to free memory they no longer
need?

 

[Alex Drummond]

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.

It's partly a language issue. Being dynamically typed makes certain kinds of
alterations possible during runtime in Lisp that aren't possible in C++.
Also, the concept of evaluating a general expression in a running C
environment is pretty alien to the language; I doubt it would be at all
easy to implement a C/C++ system which allowed this.

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

Have you been reading the thread? Anyway, here's my list.
* Closures
* Macros (ability to add your own control structures, etc.)
* More sophisticated OO system (multiple dispatch, etc.)
* Garbage collection.
* More sophisticated exception handling system (allows restarts).
* Better idioms for resource control (e.g. unwind-protect).
* More paradigms suppported: Imperative, OO, functional, logic (if you use a
library like Screamer).

And those are only (some of) the advantages of the language. The advantages
of the tools shouldn't be dismissed either.


Alex

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