Hey
Recently, I researched using C++ for game programming and here is what
I found:
C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
Unsurprisingly, there is a very high failure rate among projects using
C++ for modern game development.
You can not even change function definitions while the program is
running and see the effects live (the ultimate debugging tool).
Alternatively, you can't execute a small portion of the program
without compiling and linking the whole thing, then bringing your game
into a specific state where your portion of the code is being executed.
The static type system locks you into a certain design, and you can't
*test* new ideas, when they come to you, without redesigning your
whole class hierarchy.
C++ is so inflexible, even those who do use it for games, have to
write their game logic in some other language (usually very slow,
inexpressive and still garbage collected). They also have to interface
the two languages.
C++ lacks higher-order functions. Function objects emulate them
poorly, are slow and a pain to use. Additionally, C++ type system does
not work well with function objects.
C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.
C++ coding feels very repetitive, for example, when writing class
accessors, you often have to write const and non-const methods with
completely identical function bodies. Just look at STL.
When programming in C++ you feel like a blind person trying to draw
something. You don't _see_ the data structures that your procedures
will operate on. Lisp programming is much more visual.
Constructors and smart pointers make it hard to tell cheap operations
from expensive ones.
C++ lacks automatic memory management and so it encourages copying
objects around to make manual memory management manageable.
Reference-counting schemes are usually slower than modern garbage
collectors and also less general.
Most important, C++ syntax is irregular, and you often find yourself
typing repetitive patterns again and again - a task easily automated
in languages with simpler syntax. There are even books on C++
patterns, and some C++ experts take pride in being able to execute
those patterns with computer-like precision - something a computer
should be doing to begin with.
C++ programs are slow: even though the compilers are good at
micro-optimizing the code, programmers waste their time writing
repetitive patterns in C++ and debugging memory corruption instead of
looking for better algorithms that are far more important for speed
than silly micro-optimizations.
It's hard to find good programmers for C++ projects, because most of
the good programmers graduated to languages like Lisp or avoided C++
altogether. C++ attracts unimaginative fellows with herd mentality.
For creative projects, you want to avoid them like a plague.
It is my opinion that all of the above makes C++ a very bad choice for
commercial game development.
Jul 22 '05
761  27913 
"Petter Gustad" <ne***********@gustad.com> wrote in message
news:m3************@scimul.dolphinics.no... "Computer Whizz" <ol*********@hotmail.com> writes:
"Petter Gustad" <ne***********@gustad.com> wrote in message
news:m3************@scimul.dolphinics.no... > Sashank Varma <no**@vanderbilt.edu> writes:
>
>
> Not only that, + works when the numbers are complex as well:
>
> (+ (complex 3 3) (complex 3 -3) 3) => 9
>
> or even rational numbers
>
> (+ 2/3 2/3 1/3) => 5/3
Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...
What was the difficult part? Did I confuse you with =>? => is not a
part of Common Lisp, it's just a common way of showing the result of
the function call.
I really don't like that syntax at all!
It's the same /syntax/ as others have explained to you, e.g. (function
arg1 arg2 ...). I just introduced a new function called /complex/
which will return a complex number given the real and imaginary part
as argument.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
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.
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <ol*********@hotmail.com> writes: 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".
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.
"Computer Whizz" <ol*********@hotmail.com> wrote: It makes sense to me to have:
"output this "gfgf" #variable# $function(blah, 2)
change #variable#
call $function(blah, 2) again into #var2#
output #var2# #variable1#"
then to have:
"(((output(outfunc((("dfgg")varfunc(#var#))funcfun c($function(blah,
2))))varfunc(#var#, 33))(funcfunc($function(blah, 2),
#var2#))output((#var2#)(#var1#)))"
... having it all on one line etc... Again I'm just going by what I have
seen in this thread - but doing that is a bad idea.
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?
"Computer Whizz" <ol*********@hotmail.com> writes:
{ Hrm, this is definitely veering away from games development and C++ } "jayessay" <no****@foo.com> wrote in message
news:m3************@rigel.goldenthreadtech.com... "Computer Whizz" <ol*********@hotmail.com> writes:
> Ever used Lisp?
I haven't - but <a pretty sad diatribe>
Do you have any idea how stupid this makes you look? Why do people
who are totally uninformed about something (here you even admit it)
insist on pontificating on it anyway by means of a stream of pathetic
nonsense? It's embarrassing in the same sad way as an untalented pop
star wannabe making a fool of himself on stage or a public figure
trying to act hip but getting the vernacular and all the idioms wrong.
[SNIP] 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".
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
--
Warning: Pregnancy can cause birth from females
In article <op**************@news.cis.dfn.de>, tj****@yahoo.de says... Gerry Quinn wrote:
Sober statements of fact of the same kind as "When Jesus came into my
life, I was saved." It may well be a coruscating central truth for the
person saying it, but its truth is of a kind that will have limited
value for (say) a Buddhist.
Ever used Lisp?
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
In article <87************@g.mccaughan.ntlworld.com>, ga**************@pobox.com says... There's still a strong element of subjectivity: as well as
some languages being better for some *tasks*, some are better
for some *people*. I find that (to take three somewhat different
examples) C, Python and Lisp fit my brain a bit more naturally
than C++, Perl and ML. So if I say "Perl is a mess" or "C++
is too easy to screw yourself with" you can, I suppose, put it
down to my idiosyncrasies. But if I say "Lisp's macros make it
easy to do things that are unbearably painful in C++", that's
a verifiable (or falsifiable, though as it happens it's true)
statement that anyone can check given a little time and an
open mind.
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
In article <MP************************@news.verizon.net>, ch**************@NOTplayTHISstationBIT.sony.com says... In article <MP************************@news.indigo.ie>,
ge****@DELETETHISindigo.ie says... for games written with Lisp,
http://www.franz.com/success/custome...ughtydog.lhtml
Yes, one team wrote parts of some of their games in Lisp, and that one
example has been trumpeted to the rooftops ever since.
Parts? Pretty much everything was written in Lisp (GOAL); except
for certain parts that were written in assembly (such as PS2
microcode for the PS2 equivalent of vertex shaders).
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...
Read their
'post-mortem' on Gamasutra and you'll find that the benefits were far
more ambiguous than you would think to listen to the Lisp boosters. To
put it briefly, it featured strongly in both the "what went right" and
"what went wrong" sections.
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.
<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 know several of the programmers at Naughty Dog (who are just a
stone's throw down the street from here). And they think Lisp (GOAL)
is better than C++. Furthermore, these are incredibly talented
programmers, and only fools would not pay attention to what
they're saying.
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?
You said: "What is it about Lisp that makes novices fall in love
with it? They don't actually *produce* anything with it, mind
you, but they insist on telling the world how superior it is to
every other language."
Let's turn that on its end shall we. The guys at Naughty Dog
are clearly more experienced than you are, making you the novice.
They have _constentently_ produced some of the best sellers on
the PS1 and PS2. You have produced some small shareware games
that at worst would take a programmer a week or two to hack
together. You have in the past admitted you have no experience
with functional languages, yet you insist on telling the world
how you (the novice) know better, putting C++ ahead of Lisp.
Isn't that special?
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
In article <kt***************************@nyctyp02-ge0.rdc-nyc.rr.com>, kt*****@nyc.rr.com says... In article <MP************************@news.indigo.ie>,
Gerry Quinn <ge****@DELETETHISindigo.ie> wrote: But
there's plenty wondrous stuff written in C++ too.
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
On Thu, 28 Oct 2004, Computer Whizz wrote:
"Philippa Cowderoy" <fl****@flippac.org> wrote in message
news:Pine.WNT.4.53.0410271456270.1840@SLINKY...
[Note that I'm not a Lisp fan - I largely hack in Haskell and happen to be
hanging around on cgdpm]
On Wed, 27 Oct 2004, Computer Whizz wrote:
> That everything in Lisp uses the prefix notation can also make it very
> easy to learn. Some languages want a lot of syntax:
> ++c; c++; a+b;
> But most functions are using prefix anyway:
> f(x, y, z); or in Lisp
> (f x y z)
That's horrible... What if 'x' was also a function name etc... It just
doesn't seem good to have the function name inside the ()'s to me.
If x is a function, then (f x y z) passes the function x to f. There's
nothing wrong with this in Lisp, or in many other programming languages -
it allows you to write things like map, the function that applies another
function pointwise to every element in a list.
Yes... While x has no parameters passed (or does it?).
Bingo. It's the function being passed, not the result of the function.
Does forgetting the
space (or common typo) mean that (f xy z) causes an error. A quick scan
through the file wouldn't really show it up as well as f(x, y, z) IMO - but
to each his own.
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.
-- fl****@flippac.org
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.
"Rahul Jain" <rj***@nyct.net> wrote in message
news:87************@nyct.net... "Maahes" <ma****@internode.on.net> writes:
But I think it may be too recursive & bottom-up programming for most
brains
to want to deal with...
Your code may be, but my Lisp code isn't.
Bottom-up is useful when you're trying to build a system that has
certain behaviors and then gradually link up those behaviors into a
program as you figure out what the program should do. E.g., first build
the physics engine and then build the game logic once the game designers
have figured out how the gameplay should be.
--
Rahul Jain
rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>> :) It was 15 years ago so I only have the vague memories and impressions left...
Well 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?
I can't remember the exact problem. Only that most of the class had trouble
with it and it had something to do with long division :)
I wonder which Lisp you were using. The modern Common Lisp has all kinds
of ways to iterate, some simple, some complex, and one (LOOP) which is
effectively a built-in iteration mini-language. So no one is forced to
do recursion, and many Lispniks frown on it style-wise if an iterative
approach would work.
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...
You mean (+ 5 Speed), of course. And I guess that is just a made-up
example, because I do not recognize the physics.
:) Completely made up and not supposed to mean anything
How about S = 1/2at^2 + vi*t?
(defun distance (accel time initial-velocity)
(+ (* initial-velocity time)
(/ (* accel (expt time 2)) 2)))
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#
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...
> 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.
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
Computer Whizz wrote:
"Petter Gustad" <ne***********@gustad.com> wrote in message
news:m3************@scimul.dolphinics.no... "Computer Whizz" <ol*********@hotmail.com> writes:
"Petter Gustad" <ne***********@gustad.com> wrote in message
news:m3************@scimul.dolphinics.no...
> Sashank Varma <no**@vanderbilt.edu> writes:
>
>
> Not only that, + works when the numbers are complex as well:
>
> (+ (complex 3 3) (complex 3 -3) 3) => 9
>
> or even rational numbers
>
> (+ 2/3 2/3 1/3) => 5/3
Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...
What was the difficult part? Did I confuse you with =>? => is not a
part of Common Lisp, it's just a common way of showing the result of
the function call.
I really don't like that syntax at all!
It's the same /syntax/ as others have explained to you, e.g. (function
arg1 arg2 ...). I just introduced a new function called /complex/
which will return a complex number given the real and imaginary part
as argument.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
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.
> 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.
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.
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.
*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.
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.
Yes, you get used to it very quickly.
I would imagine a far more
complex line, with a dozen brackets, would be a major brainstrain to
comprehend.
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
Maahes wrote:
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.
"Rahul Jain" <rj***@nyct.net> wrote in message
news:87************@nyct.net... "Maahes" <ma****@internode.on.net> writes:
But I think it may be too recursive & bottom-up programming for most
brains
to want to deal with...
Your code may be, but my Lisp code isn't.
Bottom-up is useful when you're trying to build a system that has
certain behaviors and then gradually link up those behaviors into a
program as you figure out what the program should do. E.g., first build
the physics engine and then build the game logic once the game designers
have figured out how the gameplay should be.
--
Rahul Jain
rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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.
"Maahes" <ma****@internode.on.net> wrote: For instance (an example someone posted).
C:
for (int i=0; i<=10; i++) list.push(i);
list.reverse();
List:
you mean "Lisp".
(let ((lst 0))
this must be (lst nil)
(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.
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)
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.
you have 2 brackets, because you can initialize more than one variable:
(let ((x 1)
(y 2))
(+ x y))
--
Frank Buß, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
> I don't dispute it. Self-modifying code is one example.
Lisp doesn't have self-mofifying code. It has eval and macros. 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.
But there's lots of finished projects written in Lisp.
Alex
Gerry Quinn wrote:
In article <87************@g.mccaughan.ntlworld.com>,
ga**************@pobox.com says...
There's still a strong element of subjectivity: as well as
some languages being better for some *tasks*, some are better
for some *people*. I find that (to take three somewhat different
examples) C, Python and Lisp fit my brain a bit more naturally
than C++, Perl and ML. So if I say "Perl is a mess" or "C++
is too easy to screw yourself with" you can, I suppose, put it
down to my idiosyncrasies. But if I say "Lisp's macros make it
easy to do things that are unbearably painful in C++", that's
a verifiable (or falsifiable, though as it happens it's true)
statement that anyone can check given a little time and an
open mind.
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. c
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
"Maahes" <ma****@internode.on.net> wrote: How about S = 1/2at^2 + vi*t?
(defun distance (accel time initial-velocity)
(+ (* initial-velocity time)
(/ (* accel (expt time 2)) 2)))
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;
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/pro...x/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 :-)
--
Frank Buß, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de But this doesn't work, because 1/2 is always 0 in C++
1.0 / 2.0
-JKop Let's turn that on its end shall we. The guys at Naughty Dog
are clearly more experienced than you are, making you the novice.
They have _constentently_ produced some of the best sellers on
the PS1 and PS2. You have produced some small shareware games
that at worst would take a programmer a week or two to hack
together. You have in the past admitted you have no experience
with functional languages, yet you insist on telling the world
how you (the novice) know better, putting C++ ahead of Lisp.
Isn't that special?
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?
Christer Ericson
Sony Computer Entertainment, Santa Monica
> 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...
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/custome.../harvard.lhtml.
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:
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.
If Lisp grows in popularity among those who are more interested in
products than in programming, I will likely take a look at it.
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 Quinn wrote:
In article <MP************************@news.verizon.net>,
ch**************@NOTplayTHISstationBIT.sony.com says... In article <MP************************@news.indigo.ie>,
ge****@DELETETHISindigo.ie says... > > for games written with Lisp,
> >
http://www.franz.com/success/custome...ughtydog.lhtml >
> Yes, one team wrote parts of some of their games in Lisp, and that one
> example has been trumpeted to the rooftops ever since.
Parts? Pretty much everything was written in Lisp (GOAL); except
for certain parts that were written in assembly (such as PS2
microcode for the PS2 equivalent of vertex shaders).
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...
> Read their
> 'post-mortem' on Gamasutra and you'll find that the benefits were far
> more ambiguous than you would think to listen to the Lisp boosters. To
> put it briefly, it featured strongly in both the "what went right" and
> "what went wrong" sections.
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.
<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 know several of the programmers at Naughty Dog (who are just a
stone's throw down the street from here). And they think Lisp (GOAL)
is better than C++. Furthermore, these are incredibly talented
programmers, and only fools would not pay attention to what
they're saying.
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?
You said: "What is it about Lisp that makes novices fall in love
with it? They don't actually *produce* anything with it, mind
you, but they insist on telling the world how superior it is to
every other language."
Let's turn that on its end shall we. The guys at Naughty Dog
are clearly more experienced than you are, making you the novice.
They have _constentently_ produced some of the best sellers on
the PS1 and PS2. You have produced some small shareware games
that at worst would take a programmer a week or two to hack
together. You have in the past admitted you have no experience
with functional languages, yet you insist on telling the world
how you (the novice) know better, putting C++ ahead of Lisp.
Isn't that special?
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
> How about S = 1/2at^2 + vi*t?
(defun distance (accel time initial-velocity)
(+ (* initial-velocity time)
(/ (* accel (expt time 2)) 2)))
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!
JKop <NU**@NULL.NULL> writes: But this doesn't work, because 1/2 is always 0 in C++
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.
I think you might have missed the point... How about S = 1/2at^2 + vi*t?
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...
> 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" <ma****@internode.on.net> wrote: I think you might have missed the point...
How about S = 1/2at^2 + vi*t?
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.
--
Frank Buß, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de 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!
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...
Maahes wrote: 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.
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 matches
up 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 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" <ma****@internode.on.net> writes: 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.
"Maahes" <ma****@internode.on.net> wrote: 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 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.
--
Frank Buß, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
"Maahes" <ma****@internode.on.net> writes: 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'.
--
Steven E. Harris
On Thu, 28 Oct 2004 23:09:26 +1000, Maahes wrote: 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))
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.
--
Succumb to natural tendencies. Be hateful and boring.
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
"Computer Whizz" <ol*********@hotmail.com> writes: [.....]
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)
....
..
In comp.lang.lisp Mario S. Mommer <m_******@yahoo.com> wrote: 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).
--
Karl A. Krueger <kk******@example.edu> { s/example/whoi/ }
Every program has at least one bug and can be shortened by at least one line.
By induction, every program can be reduced to one line which does not work. 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 gi****@csl.sri.com
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
"Peter Lewerin" <pe***********@swipnet.se> wrote in message
news:b7**************************@posting.google.c om... "Computer Whizz" <ol*********@hotmail.com> wrote:
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...
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <ol*********@hotmail.com> wrote in message news:<cl**********@news6.svr.pol.co.uk>... 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 )
"Maahes" <ma****@internode.on.net> writes: 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...
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
[snips]
On Wed, 27 Oct 2004 14:33:01 +0000, Kenneth Tilton wrote: 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... there's plenty wondrous stuff written in C++ too.
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.
[snips]
On Mon, 25 Oct 2004 14:42:38 +0000, JKop wrote: 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?
"Maahes" <ma****@internode.on.net> writes: [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.
--
Jock Cooper www.fractal-recursions.com
Carl Muller wrote: "Computer Whizz" <ol*********@hotmail.com> wrote in message
news:<cl**********@news6.svr.pol.co.uk>... 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 )
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?
Christer Ericson <ch**************@NOTplayTHISstationBIT.sony.com > writes: 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.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
"Maahes" <ma****@internode.on.net> writes: 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!
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
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
> 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
Kelsey Bjarnason wrote:
[snips]
On Wed, 27 Oct 2004 14:33:01 +0000, Kenneth Tilton wrote:
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...
there's plenty wondrous stuff written in C++ too.
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.
"Maahes" <ma****@internode.on.net> writes: 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
Computer Whizz schrieb: If x is a function, then (f x y z) passes the function x to f. There's
nothing wrong with this in Lisp, or in many other programming languages -
it allows you to write things like map, the function that applies another
function pointwise to every element in a list.
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é
-- http://nase.black-entity.de/?nasigoreng
Computer Whizz schrieb: "André Thieme" <ad****************************@justmail.de> wrote in
message news:cl**********@ulric.tng.de... Maahes schrieb:
Well, sounds like its probably very different to the lisp we used
15 years go. All we could seem to do is have lots of brackets with calls
to functions embedded..
2*(5+Speed)+Velocity
looked something like:
(+ (* 2 (5 Speed +)) Velocity)
One might easily think that Lispers accepted the brackets but still
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.
What if you want to compute something like that:
a + b + c + d + e + f + g + h + i + j + k + l;
(with usefull names)
Here Lisp only needs one +:
(+ a b c d e f g h i j k l)
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.
No need to look if there are other operators included. Anyway, if
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 everything in Lisp uses the prefix notation can also make it
very easy to learn. Some languages want a lot of syntax: ++c; c++; a+b;
But most functions are using prefix anyway:
f(x, y, z); or in Lisp
(f x y z)
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 ;-)
and if you do in C f(x, y, g(z)); then you also need your brackets
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.
You don't need to remember stuff like "never put a semicolon after
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é
--
What might be behind that url? http://tinyurl.com/64x7y
Kelsey Bjarnason posted: [snips]
On Mon, 25 Oct 2004 14:42:38 +0000, JKop wrote:
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?
Is that directed toward myself? If so, then that's exactly what I've
been arguing.
-JKop
A question:
Why do people still talk about C?
As far as I'm aware, C++ is and can do everything that C can do, but has
more features. Would anyone be able to inform me of any reason why
people still programme in C, or why they even talk about it?
-JKop
Szymon <r5**********@o2.pl> writes: [.....]
and type system... (DEFTYPE & stuff)
..
On Fri, 29 Oct 2004 08:51:02 GMT, JKop wrote: A question:
Why do people still talk about C?
As far as I'm aware, C++ is and can do everything that C can do, but has
more features. Would anyone be able to inform me of any reason why
Yes. Obligatory car analogy: C is a Ferrari. C++ is a Ferrari with
helicopter rotors, 18" naval guns, and those 8 foot diameter wheels.
people still programme in C, or why they even talk about it?
For one thing, you can link to it from other languages without wanting
to tear your hair out.
--
Succumb to natural tendencies. Be hateful and boring.
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>")) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Peter Lewerin |
last post by:
peter.lewerin@swipnet.se (Peter Lewerin) wrote
> There is a paradigm
> difference between CLOS and non-OOP Lisp code, but the language is the
> same, and it's quite possible to mix the two.
...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
