C
Computer Whizz
Petter Gustad said:
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.
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.
M
Mario S. Mommer
Computer Whizz said:
Not on the surface, and at a first glance. Granted. But take my word
for it: once you get used to it, you see its beauty. Furthermore, you
may see in fact why it is actually the /right/ notation for
programs. Instead of writing programs in some fantasy notation that
only looks "natural" because it vaguely resembles what you are used to
from math books, you write in a notation that is actually closer to
the /meaning/ of the program, both for you and for the machine.
If a newbie takes two hours to understand the syntax and get a bit
used to a lisp-aware editor, he can really begin with the interesting
stuff, which is to actually write programs. In C++ he will have to
spend years to really know how to placate the parser.
P
Peter Lewerin
Computer Whizz said:
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?
I
Ingvar
{ Hrm, this is definitely veering away from games development and C++ }
It's possibly somewhat odd-looking in the beginning. It took me almost
an hour to get to grips with in, back when I started playing around
with lisp. C, well, was easy-ish, after Pascal. Until I started trying
to internalise the exact precedense rules of the operators. And the
somewhat opportunistic tokenisation (of C tokens, that is).
There's also some nice guarantees in parameter evaluation order in
Common Lisp not available in C.
(process-two-bytes (read-byte file) (read-byte file))
;; This will read one byte from the file, pass that as the first
;; parameter, then read another byte and pass that as the second.
process_bytes(getc(file), getc(file));
/* This will read two bytes from the file and pass them in any
random order, it will be consistent with each execution of the
statement, but not necessarily between different compilations,
nor between different compilers */
As an aside, though I *am* used to Lisp syntax, I don't find the C nor
the Lisp code *that* difficult to read.
//Ingvar
It's possibly somewhat odd-looking in the beginning. It took me almost
an hour to get to grips with in, back when I started playing around
with lisp. C, well, was easy-ish, after Pascal. Until I started trying
to internalise the exact precedense rules of the operators. And the
somewhat opportunistic tokenisation (of C tokens, that is).
There's also some nice guarantees in parameter evaluation order in
Common Lisp not available in C.
(process-two-bytes (read-byte file) (read-byte file))
;; This will read one byte from the file, pass that as the first
;; parameter, then read another byte and pass that as the second.
process_bytes(getc(file), getc(file));
/* This will read two bytes from the file and pass them in any
random order, it will be consistent with each execution of the
statement, but not necessarily between different compilations,
nor between different compilers */
As an aside, though I *am* used to Lisp syntax, I don't find the C nor
the Lisp code *that* difficult to read.
//Ingvar
G
Gerry Quinn
No, I am not among the saved. But every autumn its acolytes appear
proselytising on the doorsteps of games newsgroups, like creepy
Jehovah's Witnesses of the programming world. Tell you what - don't
call us, we'll call you.
- Gerry Quinn
G
Gerry Quinn
I don't dispute it. Self-modifying code is one example. But it's an
example that suggests to me that Lisp programmers are generally more
interested in programming than in shipping software. It's one of
several things that give me that impression. Another is the simple
enthusiasm of its advocates. There's nothing like an unfinished project
to generate enthusiasm for a programming language. You're doing the fun
stuff, not tidying up the loose ends.
If I feel the need to learn and use Lisp I will do so. So far I don't
see any good reason to interest myself in it. If that's my loss, so be
it.
- Gerry Quinn
G
Gerry Quinn
Well, if you say that most of it was written in their Lisp-based engine,
I will not argue the point. And you don't seem to dispute my point that
it's the one company that gets cited over and over...
<QUOTE>
While he called his Lisp techniques and programming practices
"revolutionary," others referred to them as "code encryption," since
only he could understand them. [--] Also, it took over a year to develop
the compiler, during which time the other programmers had to make do
with missing features, odd quirks, and numerous bugs.
</UNQUOTE>
I'm not hearing the touted benefits of Lisp here, folks. Here are some
briefer excerpts from 'What went wrong' - I'm sure you can put some spin
on them to say it's not really Lisp's fault, just the fault of the big
bad horrible world that doesn't love Lisp, or re-writes Lisp programs in
different languages as part of the big plot to keep it down:
"even now C++ has some advantages over GOAL...the compiler would be
unresponsive until the process had completed, sometimes taking as long
as 15 minutes...One of our greatest frustrations and loss of
productivity came from our slow turnaround time in making a change to a
level or animation and seeing that change in the actual game."
I'm not hearing the touted benefits of Lisp here. Correct me if I'm
wrong, but according to many posts in this thread, isn't Lisp supposed
to be the magical wand that fixes things like the above?
I am not ignoring them. I'm sure they are talented, and I won't dispute
your assertion that for reasons of objective language assessment,
cognitive dissonance, or useful publicity, they still prefer to continue
with Lisp. I take it they must have made some progress with
understanding the engine! The fact remains, though, they are just one
team. There are many equally talented teams that are having nothing to
do with Lisp. For very good reasons, as far as I can see. A language
without tools or programmers is IMO a *lousy* language for developing
games. I'm not moving to Lisp any time soon, Christer. Are you?
Ah, time for the old ad hominem! Yes, I post my opinions on various
subjects, just as you do - be it on the subject of programming languages
or algorithmic complexity order. People can take them or leave them,
and they can assess my credibility on the basis of what I say and what I
produce, just as they can with you or with Naughty Dog. Taking our
arguments, if they are wise, in conjunction with those of many others.
Have I criticised Naughty Dog? On the contrary, I merely pointed out
that they are just one team, and that ACCORDING TO THEM using a Lisp-
based engine was not exactly all beer and skittles. Even if they do
apparently want to go back for more. Seems to me I'm giving their
judgement of Lisp - the good and the bad - exactly as much credit as it
deserves.
If Lisp grows in popularity among those who are more interested in
products than in programming, I will likely take a look at it. [Or
indeed, if I feel the urge to mess around with a language of this type.]
Right now, though, it's just another familiar silver bullet of the kind
that's always supposedly multiplying productivity by a factor of five on
the current project. With all that increased productivity flying
around, you'd think the 'current project' would become the 'previous
project' more than once in a blue moon. You don't have to know anything
about any language to smell a rat.
Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers
G
Gerry Quinn
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.
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.
Especially when Lisp has been touted the same way for about twenty
years. I've got lots of time to get on the bandwagon...
- Gerry Quinn
P
Philippa Cowderoy
Bingo. It's the function being passed, not the result of the function.
You get used to it pretty quickly - if you're worried about the case where
x, y and z are complicated expressions there're things you can do to make
this easier to pick out - I commonly end up doing the equivalent of this:
(f x
y
z
)
for long x, y and z expressions.
A
Alex Drummond
No, it was the implementation of all those darned ()'s and spaces.
Brackets: Lisp function calls have exactly the same number of brackets as C
function calls, the only difference is that the function name is inside the
brackets. You only have "extra" brackets in cases where C provides an infix
operator for a particular operation (e.g. addition). Unless you're doing
lots of arithmetic, Lisp syntax is just as natural as C syntax regarding
brackets.
Spaces: I don't see your issue here. C also uses whitespace to separate
elements of a program. Why is it a big issue if Lisp uses whitespace to
separate function arguments? Note that this does /not/ cause ambiguity as
it might in C, because all Lisp expressions are explicitly grouped by
brackets.
Alex
Brackets: Lisp function calls have exactly the same number of brackets as C
function calls, the only difference is that the function name is inside the
brackets. You only have "extra" brackets in cases where C provides an infix
operator for a particular operation (e.g. addition). Unless you're doing
lots of arithmetic, Lisp syntax is just as natural as C syntax regarding
brackets.
Spaces: I don't see your issue here. C also uses whitespace to separate
elements of a program. Why is it a big issue if Lisp uses whitespace to
separate function arguments? Note that this does /not/ cause ambiguity as
it might in C, because all Lisp expressions are explicitly grouped by
brackets.
Alex
A
Alex Drummond
In the C version, I am typing straight out of my head in left -> right
No, the Lisp code and C code have exactly the same structure. First, a
declaration of the list variable (omitted in the C code). Then a loop
containing a single expression (push) and finally an instruction to reverse
the list. The only additional nesting in the Lisp version is caused by the
let, since the scope of local variables is deliniated explicitly in Lisp.
*Sigh* You're not sure because you don't know Lisp. let takes a list of
variable bindings as its first argument, so for example to bind two
variables:
(let ((a 0) (b 1))
...)
To be consistent, you don't eleminate the outer list if you're binding only
one variable.
Yes, you get used to it very quickly.
Sure. Complex expressions are hard to understand in any programming
language, C included. Lisp in fact makes it easier in some cases, because
there are no operator precedence issues. If you don't like big complex
expressions, you can just store lots of simple expressions in temporary
variables and build up the complex expression bit by bit.
Alex
No, the Lisp code and C code have exactly the same structure. First, a
declaration of the list variable (omitted in the C code). Then a loop
containing a single expression (push) and finally an instruction to reverse
the list. The only additional nesting in the Lisp version is caused by the
let, since the scope of local variables is deliniated explicitly in Lisp.
*Sigh* You're not sure because you don't know Lisp. let takes a list of
variable bindings as its first argument, so for example to bind two
variables:
(let ((a 0) (b 1))
...)
To be consistent, you don't eleminate the outer list if you're binding only
one variable.
Yes, you get used to it very quickly.
Sure. Complex expressions are hard to understand in any programming
language, C included. Lisp in fact makes it easier in some cases, because
there are no operator precedence issues. If you don't like big complex
expressions, you can just store lots of simple expressions in temporary
variables and build up the complex expression bit by bit.
Alex
M
Maahes
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();
List:
(let ((lst 0))
(dotimes (i 11)
(push i lst))
(reverse lst))
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.
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
complex line, with a dozen brackets, would be a major brainstrain to
comprehend.
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();
List:
(let ((lst 0))
(dotimes (i 11)
(push i lst))
(reverse lst))
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.
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
complex line, with a dozen brackets, would be a major brainstrain to
comprehend.
M
Maahes
It was 15 years ago so I only have the vague memories and impressions
I can't remember the exact problem. Only that most of the class had troubleWell I saw "newbie would do in C without breaking a sweat" so I thought
you could just toss off the solution in your mail editor.
What is the idea? Write an algorithm that works the way we work when we do
long division, complete with remainders? How do you want the answer? Just
the integer result and remainder as, in C, a second result returned in a
writable parameter?
with it and it had something to do with long division
Yeah, I've been trying to remember the name but I can't. It was about 1990
so whatever lisp was being used in uni's back then..
The examples I've seen posted show you should have no trouble doing anything
in Lisp without a lot of training...
Completely made up and not supposed to mean anythingI 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#
I believe that a program should be easily readable with a debugger or editor
to assist you.
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...
A
Alex Drummond
I don't dispute it. Self-modifying code is one example.
Lisp doesn't have self-mofifying code. It has eval and macros.
But there's lots of finished projects written in Lisp.
Alex
Lisp doesn't have self-mofifying code. It has eval and macros.
But there's lots of finished projects written in Lisp.
Alex
A
Alex Drummond
Well, if you say that most of it was written in their Lisp-based engine,
Just go to the website of a Lisp vendor and look at the "success stories"
section or equivalent. Lots of interesting real-world applications, e.g.
http://www.franz.com/success/customer_apps/bioinformatics/harvard.lhtml.
These are all problems with the hastily written /compiler/, not with Lisp.
If there was a mature Lisp compiler targetting PS these wouldn't have been
issues. So these are merely arguments against using Lisp on the PS, so far
as I can see. Clearly the arguments were not compelling enough to prevent
Naughty Dog from using the same technique again.
Because of course you can only get ahead in technology by copying what
everyone else is doing.
Regarding code obfuscation in Lisp, I think it's fair to say that Lisp
macros are just a bit easier to understand than template-metaprogramming in
C++. Also, if some guy decides to write some stupidly complex Lisp code,
that's not really Lisp's fault, is it? The stock response to criticism of
C++ seems to be "that wouldn't happen if you coded sensibly".
Alex
Just go to the website of a Lisp vendor and look at the "success stories"
section or equivalent. Lots of interesting real-world applications, e.g.
http://www.franz.com/success/customer_apps/bioinformatics/harvard.lhtml.
These are all problems with the hastily written /compiler/, not with Lisp.
If there was a mature Lisp compiler targetting PS these wouldn't have been
issues. So these are merely arguments against using Lisp on the PS, so far
as I can see. Clearly the arguments were not compelling enough to prevent
Naughty Dog from using the same technique again.
Because of course you can only get ahead in technology by copying what
everyone else is doing.
Regarding code obfuscation in Lisp, I think it's fair to say that Lisp
macros are just a bit easier to understand than template-metaprogramming in
C++. Also, if some guy decides to write some stupidly complex Lisp code,
that's not really Lisp's fault, is it? The stock response to criticism of
C++ seems to be "that wouldn't happen if you coded sensibly".
Alex
Gerry said:
F
Frank Buss
I don't think that one language is better than the other, it depends on
many factors, like available programmers and good compilers for the
platform you want to write for, but perhaps someone is interested in Lisp,
so I'll try to correct bad Lisp examples.
you mean "Lisp".
this must be (lst nil)
your Lisp example is not the same as the C example, because in your C code
you didn't wrote the initialization of the "list" variable. In Lisp the
"let" is used for local variable bindings, which are visible in the block
after the variable declarations (and in closures). If you want a global
list variable, you can write it like this (*name* is the convention in Lisp
for global variables, but you don't need to write it like this):
(defparameter *list* nil)
(loop for i from 0 to 10 do (push i *list*))
(setf *list* (nreverse *list*))
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)))))
most Lisp implementations optimizes the tail-recursion to a jump, so
chances are good, that it is as fast as a normal loop.
If you don't like recursions, there are many other ways to create a list
from 10 to 0. I think the simplest one is this:
(loop for i from 10 downto 0 collect i)
you have 2 brackets, because you can initialize more than one variable:
(let ((x 1)
(y 2))
(+ x y))
many factors, like available programmers and good compilers for the
platform you want to write for, but perhaps someone is interested in Lisp,
so I'll try to correct bad Lisp examples.
Maahes said:
you mean "Lisp".
this must be (lst nil)
your Lisp example is not the same as the C example, because in your C code
you didn't wrote the initialization of the "list" variable. In Lisp the
"let" is used for local variable bindings, which are visible in the block
after the variable declarations (and in closures). If you want a global
list variable, you can write it like this (*name* is the convention in Lisp
for global variables, but you don't need to write it like this):
(defparameter *list* nil)
(loop for i from 0 to 10 do (push i *list*))
(setf *list* (nreverse *list*))
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)))))
most Lisp implementations optimizes the tail-recursion to a jump, so
chances are good, that it is as fast as a normal loop.
If you don't like recursions, there are many other ways to create a list
from 10 to 0. I think the simplest one is this:
(loop for i from 10 downto 0 collect i)
you have 2 brackets, because you can initialize more than one variable:
(let ((x 1)
(y 2))
(+ x y))
A
Alex Drummond
Maahes said:
Yes, it is tricky to keep count of the brackets. The good news is that you
don't have to
You can just use a good editor (e.g. emacs) which matchesup pairs of brackets. When you're reading the code, you rely on the
indentation more than the brackets, so there's no need to count then,
either.
Alex
F
Frank Buss
Maahes said:
As far as I know sqr is not a standard C++ function. If you write it as a
function, you can write it like this:
float distance(float a, float t, float vi) {
return 1/2*a*t*t + vi*t;
}
But this doesn't work, because 1/2 is always 0 in C++, but you can use
0.5. To avoid a warning for converting from double to float, you need to
append a "f":
float distance(float a, float t, float vi) {
return 0.5f*a*t*t + vi*t;
}
Ok, now the Lisp function (I've changed "t" to "time", because "t" is
global symbol in Lisp):
(defun distance (a time vi)
(+ (* 0.5 a time time)
(* vi time)))
Doesn't look much different. But you can write it in infix, too, with a
reader macro like this:
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html
Then you can write the function like this:
(defun distance (a time vi)
#I "0.5*a*time*time + vi*time")
The nice thing is, that it doesn't require any runtime time, because the
macro creates the usual Lisp prefix form at compile-time (more exact: at
read time). You can take a look at the interactive REPL how it would
look like, just type in this:
(macroexpand '#I "0.5*a*time*time + vi*time")
and it prints this:
(+ (* 0.5 A TIME TIME) (* VI TIME))
Would be nice sometimes for C-macros to have such an interactive test of
macros, for example for the Microsoft MFC ones
M
Maahes
No disrespect to Naughty Dog.. Awesome engine and excellent game produced
from it...
but it did take them 3 years to make the game...
That's a luxury most of us console developers don't have.
So, I'd say the Jax & Daxter engine is a proof-of-concept... It proves Lisp
CAN be used to make a cutting edge engine...
It doesn't proove its the most efficient way for developers to work...
In 20years of writing games, Naughty Dog is the first company I've seen to
make a top game from Lisp, and I'd say thats because they have top
programmers and designers who could have made the same game in C if they had
applied the same algorithms... and it might have been made in less than 3
years...who will ever know?
J
JKop
1.0 / 2.0
-JKop