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 27878
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Gerry Quinn wrote:
|
| 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.
|
| Dude, write a good game in Lisp and that will impress us a lot more than
| a load of blather about how C++ is unsuitable for game programming. The
| thing is, we use C++ for game programming, so we know whether it is
| suitable or not. We've even seen a few games in our time that are
| written in Java, Delphi, Flash or VB. But from the Lispers, all we see
| is the same old hot air...
Please see:
for games written with Lisp, http://www.franz.com/success/custome...ughtydog.lhtml
what is it about Lisp, http://alu.cliki.net/RtL%20Highlight%20Film
Regards,
Jorge Tavares
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBfkqNKHEUoQoCFcIRAkTtAJ0R1RxJ3EQB6VKy4TCC3f oNCNa4jwCeKwup
UWXzHD90kcK+pL6984OEZMk=
=IVnR
-----END PGP SIGNATURE-----
Maahes wrote: We have our own memory management systems that are far better than garbage collectors because they don't fragment memory at all, which is critical on a console because you can't afford to run out of memory due to unforseen fragmentation.
I'll have to address this.
While I understand that you don't want to use GC on a console, where you
presumably want every scrap of performance you could possibly get, it isn't
true that GC fragments memory.
There is an entire class of copying collectors that, as a neccessary
consequence of copying, defragment memory on the fly. You don't need to
lose half your memory to the GC, either; while it's true that you can only
use N-1 segments of memory for actual data, N need not be 2.
Of course, if N *isn't* 2 then you need to combine the copying collector
with something like a mark-and-sweep collector, which is probably slow.
I'm mostly interested in this from the viewpoint of OS design, where the
slow collector can be run in the idle loop while a fast generational
collector takes care of low-memory situations if they should occur, so this
probably doesn't apply to your situation.
That said, there's nothing fundamental preventing you from doing your own
memory management (Arena allocation, say) in Lisp - you just need a Lisp
version that has a lot more GC/memory-controlling declarations than current
editions do. See Barking Dog.
End note:
GC-ed applications are probably no more a victim of fragmentation than
applications using malloc/free, and can be far less so.
You don't use malloc/free very much on a console, though, do you?
Maahes wrote: We have our own memory management systems that are far better than garbage collectors because they don't fragment memory at all, which is critical on a console because you can't afford to run out of memory due to unforseen fragmentation.
I'll have to address this.
While I understand that you don't want to use GC on a console, where you
presumably want every scrap of performance you could possibly get, it isn't
true that GC fragments memory.
There is an entire class of copying collectors that, as a neccessary
consequence of copying, defragment memory on the fly. You don't need to
lose half your memory to the GC, either; while it's true that you can only
use N-1 segments of memory for actual data, N need not be 2.
Of course, if N *isn't* 2 then you need to combine the copying collector
with something like a mark-and-sweep collector, which is probably slow.
I'm mostly interested in this from the viewpoint of OS design, where the
slow collector can be run in the idle loop while a fast generational
collector takes care of low-memory situations if they should occur, so this
probably doesn't apply to your situation.
That said, there's nothing fundamental preventing you from doing your own
memory management (Arena allocation, say) in Lisp - you just need a Lisp
version that has a lot more GC/memory-controlling declarations than current
editions do. See Naughty Dog.
End note:
GC-ed applications are probably no more a victim of fragmentation than
applications using malloc/free, and can be far less so.
You don't use malloc/free very much on a console, though, do you?
> 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)
Not really any different, that's just the basic syntax of Lisp. Even mini
languages like the loop macro are called the same way:
(loop for i from 0 to 10 collect i) ; Create a list of numbers from 0 to 10.
As are the less exotic macros:
(let ((lst 0))
(dotimes (i 11)
(push i lst))
(reverse lst)) ; Create a list of numbers from 1 to 10.
(Not intended to be sensible examples, Lisp gurus...) This syntax does not
in any way prevent you from doing long division ;) Sounds like you were
probably just not /taught/ the imperative features of Lisp, and got the
erroneous impression that it was all lists and recursive functions. Lisp
doesn't force you to use recursion any more than C++ does.
Alex
Maahes wrote: hmm. I remember vividly doing lisp at uni. I think the assignment was a simple long division problem. I remember that only a few people in the entire class managed to work out a way of achieving it... I problem that is a newbie would do in C without breaking a sweat.
Post the C version (or just give a fuller spec) and I'll try it in Lisp.
:) It was 15 years ago so I only have the vague memories and impressions left...
After that, no-one ever used lisp again...
..except the Jax & Daxter developers. Their game engine runs on an interpretted lisp platform (I believe) and has spawned some of the most impressive platformers I've ever seen...
So the moral is.... I don't know, but I won't be switching to Lisp any time soon... Maybe its good once you get the hang of it... But I think it may be too recursive & bottom-up programming for most brains to want to deal with...
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.
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)
Recursion takes a while to get the hang of, but not long and then it can be quite elegant.
kenny
Maahes wrote: hmm. I remember vividly doing lisp at uni. I think the assignment was a simple long division problem. I remember that only a few people in the entire class managed to work out a way of achieving it... I problem that is a newbie would do in C without breaking a sweat. Post the C version (or just give a fuller spec) and I'll try it in Lisp.
:) 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?
After that, no-one ever used lisp again...
..except the Jax & Daxter developers. Their game engine runs on an interpretted lisp platform (I believe) and has spawned some of the most impressive platformers I've ever seen...
So the moral is.... I don't know, but I won't be switching to Lisp any time soon... Maybe its good once you get the hang of it... But I think it may be too recursive & bottom-up programming for most brains to want to deal with...
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.
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)
You mean (+ 5 Speed), of course. And I guess that is just a made-up
example, because I do not recognize the physics.
How about S = 1/2at^2 + vi*t?
(defun distance (accel time initial-velocity)
(+ (* initial-velocity time)
(/ (* accel (expt time 2)) 2)))
Note that I just typed that in and may have unbalanced parens (or other
gaffes), but when writing Lisp my editor helps me with parens so much
that I never think about them (and did not after the first month of Lisp).
And one of the biggest ways the editor helps is by /automatically/
indenting expressions based on how I have nested my expressions. So if I
get careless, I hit carriage return and the autoindentation goes
someplace conspicuously whacky. But maybe the bigger win here is during
refactoring, where I can totally trash the indentation of a fat 50-line
function and re-indent the whole thing in one command.
I know VC6 handles auto-indenting nicely, too. I never tried it on a
large region of refactored code, but I imagine it handles that, too. My
point is that "lots of brackets" is not a minus for Lisp. In fact, it is
a plus because my editor also lets me select, copy, cut, and paste any
balanced chunk of code, so I now edit code, not text (if you get my drift).
As for the prefix notation, well, you /are/ used to that!:
finalStep( preCalc1( deeperCalc( x, y), deeperCalc2( y, z)));
Lisp is just being consistent in its syntax, which pays off big time in
higher-order programming (especially procedural macros).
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <cl**********@rena.mat.uc.pt>, ja**@dei.uc.pt says... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Gerry Quinn wrote: | | 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. | | Dude, write a good game in Lisp and that will impress us a lot more than | a load of blather about how C++ is unsuitable for game programming. The | thing is, we use C++ for game programming, so we know whether it is | suitable or not. We've even seen a few games in our time that are | written in Java, Delphi, Flash or VB. But from the Lispers, all we see | is the same old hot air...
Please see:
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. 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.
what is it about Lisp, http://alu.cliki.net/RtL%20Highlight%20Film
That's more an example of what I'm saying than a refutation of it. Lots
of gushing about Lisp, but hardly a mention of any shipped projects...
- Gerry Quinn
Hello!
Phlip <ph*******@yahoo.com> wrote: Recently, I researched using C++ for game programming and here is what I found:
As other industries using C++ - even for highly graphical, rich-content physics simulations - report fewer of these problems, the game programming culture itself might be to blame.
We have had enough memory management issues (both leaks as well as
corruption by access-after-free/delete) in our company.
They still want us to use C++, w/o gc. :-(
Of course they diminish by using "smart pointers" and similar devices,
but the performance advantages of C++ diminish alongside.
[...]
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.
Then don't use the static type system.
You won't really recommend C/C++ programmers to cast everything to
void*?
[...]
C++ programs can not "think" of new code at run-time, and plug that new code into themselves in compiled form. Not easily, anyway.
So, uh, use the scripting layer?
Which is usually less efficient than calling (funcall (compile nil ...))
in Lisp (or even storing the result of (compile nil ...) into some
data structure and using it over and over).
[...]
Kind regards,
Hannah.
Gerry Quinn wrote: In article <87************@yahoo.com>, ne********@yahoo.com says...
Hey
Recently, I researched using C++ for game programming and here is what I found:
[snip]
What is it about Lisp that makes novices fall in love with it?
Try it and see. I came to Lisp rather late (age 44, after 17 years of
programming, the prior eight years in C at home and Vax Basic/Cobol in
tall buildings) and it was a revelation. No pointers, no manual memory
management, no syntax, interactive -- basically, all the crap was gone
and nothing but the fun of programming was left.
They don't actually *produce* anything with it, mind you,...
You are right! This is because Lisp is usually discovered as a hobby
language, since almost no one uses it at work.
I was a kitchen-table developer looking for a better way to develop the
next generation of a line of educational software done originally in C,
so I ended up Actually Using(tm) Lisp. It scales nicely to the real
world, and as you might imagine with anything powerful, the bigger the
task the bigger the payoff.
Then a friend asked me to do a rather huge business app (clinical drug
trial management). The kind big companies spend $100m on. We produced
something vastky better than the current state of the art on $1m. Screen
shots (which give zero idea of the underlying complexity of the problem)
are here (starting after "win32 gui samples"): http://www.tilton-technology.com/cel...precursor.html
but they insist on telling the world how superior it is to every other language.
yeah, but this is as much an act of charity to fellow programmers stuck
dancing to the tune of Java and C/C++ compilers as it is an act of
obnoxiousness. :) Dude, write a good game in Lisp...
He cannot write a game until I finish my groovy (+ Lisp OpenGL
constraints physics-engine) development system: http://www.tilton-technology.com/cellophane.html
I developed the Light Panel just to help me figure out what various
OpenGL parameters actually did. 3d rocks! I have now incorporated OpenAL
as well.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Hannah Schroeter wrote: Of course they diminish by using "smart pointers" and similar devices,
Then don't use the static type system.
You won't really recommend C/C++ programmers to cast everything to void*?
Hmmm. Smart pointers and void pointers. Where have I heard of these before,
to give C++ dynamic typing? Hmmm...
Which is usually less efficient than calling (funcall (compile nil ...)) in Lisp (or even storing the result of (compile nil ...) into some data structure and using it over and over).
All big applications need a scripting layer, an efficient engine layer, and
back-end layers in assembler. There is no /a-priori/ way to guess where the
cutoff between them is, or what language to use in the scripting layer.
<a beat>
;-)
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
Hello!
Phlip <ph*******@yahoo.com> wrote: Hannah Schroeter wrote:
Of course they diminish by using "smart pointers" and similar devices,
>Then don't use the static type system.
You won't really recommend C/C++ programmers to cast everything to void*?
Hmmm. Smart pointers and void pointers. Where have I heard of these before, to give C++ dynamic typing? Hmmm...
Would only work if you "reparent" everything (except most basic
types) to a class Object, so you can have shared_ptr<Object> everywhere.
(with void*, the deletion after the last reference drops might not
call the needed destructors).
Yeah. Cool.
Especially as you then have to build wrappers around any standard
library class you might use "dynamically", kinda like
class String : public std::string, public Object {
};
Which is usually less efficient than calling (funcall (compile nil ...)) in Lisp (or even storing the result of (compile nil ...) into some data structure and using it over and over).
All big applications need a scripting layer, an efficient engine layer, and back-end layers in assembler. There is no /a-priori/ way to guess where the cutoff between them is, or what language to use in the scripting layer.
But... There are a few choices where the scripting layer could be
just the same as the engine implementation layer.
<a beat>
;-)
Kind regards,
Hannah.
Gerry Quinn wrote: what is it about Lisp, http://alu.cliki.net/RtL%20Highlight%20Film
That's more an example of what I'm saying than a refutation of it. Lots of gushing about Lisp, but hardly a mention of any shipped projects...
If you click on the name next to each "gush" you can read the full story
behind it. While I jokingly called them "Sound bites to die for", as one
who made the shift from C to Lisp I can assure you that what look like
gushes are actually simple, sober statements of fact. Lisp is that much
better.
As you can imagine, every author programs in all the usual languages as
well as Lisp. "no projects" is simply a measure of Lisp's current
miniscule (but growing) mindshare. The proof is that successful projects
such as paul graham's on-line store software got translated from Lisp to
(Java? C++? I forget) after Yahoo acquired it. I just learned another
successful product developed in Lisp got translated to java, probably to
be more marketable (I have not heard why, just that the java version is
/less/ capable than the Lisp version.)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Espen Vestre <espen@*do-not-spam-me*.vestre.net> wrote in message news:<kw************@merced.netfonds.no>... Petter Gustad <ne***********@gustad.com> writes:
And MS-DOS was first written in the early 80's.
That was my point...
I don't know what Tim Paterson used when he wrote the original QDOS in 6 weeks in 1980, but I very much doubt that it was C, which I think was still a rather experimental thing used by the strange cult of unixists at that time.
That's actually open to some controversy. I don't know whether it's
really accurate or not, but according to some of the people and
Digital Research, Tim didn't really write much new at all: he just
ported CP/M to the x86. A fair amount of CP/M was written in PL/M (a
PL/I variant) and source was (they claim) routinely distributed to
system integrators and such. There was a PL/M86 compiler (though I'm
not sure exactly when it became available), so a simple re-compile at
least sounds like a semi-plausible possibility. I never saw the source
code to it myself, so I can't really comment on how portable it was or
how much rewriting a port would have entailed.
If true, this would mean that the first versions of MS-DOS were
written in PL/M86, but it's only fair to point out that the people
making the claims had a fairly clear interest in those claims being
believed.
In any case, I would be exceptionally surprised if those versions of
MS-DOS were written in C++ or even C.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Espen Vestre wrote: Petter Gustad <ne***********@gustad.com> writes:
And MS-DOS was first written in the early 80's.
That was my point...
I don't know what Tim Paterson used when he wrote the original QDOS in 6 weeks in 1980, but I very much doubt that it was C, which I think was still a rather experimental thing used by the strange cult of unixists at that time.
you couldn't write an OS for the 8086 in C before atrocities like near,
far, huge, etc were invented, and that came later
hs
"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
"Phlip" <ph*******@yahoo.com> writes: All big applications need a scripting layer, an efficient engine layer, and back-end layers in assembler. There is no /a-priori/ way to guess where the cutoff between them is, or what language to use in the scripting layer.
That is a perfect argument for using Lisp, since your scripting layer is
simply the use of the operators defined in the engine layer. And, of
course, you can use your Lisp implementation's way of doing assembly
routines (using lisp macros :) to micro-optimize the really
performance-sensitive bits.
--
Rahul Jain rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"cr88192" <cr*****@remove.hotmail.com> writes: many of these issues may exist, but are not that big of a deal really, and there is the problem that higher-level languages often have a poor c interface and typically need interface stuff to be written to access c code (and thus most system api's, along with parts of the project likely being written in c).
Good thing he wasn't talking about the higher-level languages you often
see, then. :)
--
Rahul Jain rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Stewart Gordon <sm*******@yahoo.com> writes: Neo-LISPer wrote:
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.
Yes I can. I can write a module that runs one or two functions from the project as the whole program.
And where does the state of the game come from in that module?
--
Rahul Jain rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <rj***@nyct.net> wrote in message
news:87************@nyct.net... "cr88192" <cr*****@remove.hotmail.com> writes:
many of these issues may exist, but are not that big of a deal really, and there is the problem that higher-level languages often have a poor c interface and typically need interface stuff to be written to access c code (and thus most system api's, along with parts of the project likely being written in c).
Good thing he wasn't talking about the higher-level languages you often see, then. :)
yes, this is primarily a problem with interpreted languages...
with compiled languages there is a lot of variation in ffi quality.
M Jared Finder <ja***@hpalace.com> writes: Neo-LISPer wrote:
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.
I can't comment on this one way or the other, as I only have a few months experience with Lisp. My guess is that the implicit interface will prove similarly difficult to modify with Lisp as the static type system does with C++.
Any eXtreme Programming Lispers or C++-ers care to comment?
His point was not about the sum total of work needed. He specifically
emphasized "*test*". If you want to change something in your design in
C++, you need to propagate that change everywhere. In Lisp, you just
change the code and load it and play around with the bits you've
changed. When you want to play around with other parts, you start
changing them. If it looks like this is a bad idea, you can just revert
back to what's in source control and figure out a different way.
--
Rahul Jain rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist jc*****@taeus.com (Jerry Coffin) writes: I don't know what Tim Paterson used when he wrote the original QDOS in 6 weeks in 1980, but I very much doubt that it was C, which I think was still a rather experimental thing used by the strange cult of unixists at that time. That's actually open to some controversy. I don't know whether it's really accurate or not, but according to some of the people and Digital Research, Tim didn't really write much new at all: he just ported CP/M to the x86. A fair amount of CP/M was written in PL/M (a PL/I variant) and source was (they claim) routinely distributed to system integrators and such.
There are lots of versions of this story floating around, but in
any way there's a lot of truth to the joke that Windows 95 was
really CP/M 95 ;-)
In any case, I would be exceptionally surprised if those versions of MS-DOS were written in C++ or even C.
No doubt. The first time I even heard of C might have been as late
as in 1984(*), a friend of mine told me he had discovered this cool new
programming language C that was derived from BCPL :-) (1984 also
was the year of the first Macintosh, which had Pascal-centric
libraries).
(*) probably partly because I had just briefly heard of unix at that time,
I was used to TOPS-10/20 and VMS.
--
(espen)
Espen Vestre wrote: No doubt. The first time I even heard of C might have been as late as in 1984(*), a friend of mine told me he had discovered this cool new programming language C that was derived from BCPL :-) (1984 also was the year of the first Macintosh, which had Pascal-centric libraries).
(*) probably partly because I had just briefly heard of unix at that time, I was used to TOPS-10/20 and VMS.
Indeed C is much older and was primarly developed to get a fast higher-level
language for the development of unix- :)
--
To get my real email adress, remove the two onkas
--
Hendrik Belitz
- Abort, Retry, Fthagn? -
In article <t9********************@twister.nyc.rr.com>, kt*****@nyc.rr.com says... Gerry Quinn wrote:
what is it about Lisp, http://alu.cliki.net/RtL%20Highlight%20Film
That's more an example of what I'm saying than a refutation of it. Lots of gushing about Lisp, but hardly a mention of any shipped projects...
If you click on the name next to each "gush" you can read the full story behind it. While I jokingly called them "Sound bites to die for", as one who made the shift from C to Lisp I can assure you that what look like gushes are actually simple, sober statements of fact. Lisp is that much better.
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.
- Gerry Quinn
In article <Se********************@twister.nyc.rr.com>, kt*****@nyc.rr.com says... Gerry Quinn wrote: What is it about Lisp that makes novices fall in love with it? Try it and see. I came to Lisp rather late (age 44, after 17 years of programming, the prior eight years in C at home and Vax Basic/Cobol in tall buildings) and it was a revelation. No pointers, no manual memory management, no syntax, interactive -- basically, all the crap was gone and nothing but the fun of programming was left.
My interest in programming is concerned with the products it creates.
[And as always, I remain at a loss as to why 'interactive' programming
appeals to people. If I have bugs I prefer to find them, rathger than
type at random and hope they go away.]
They don't actually *produce* anything with it, mind you,... You are right! This is because Lisp is usually discovered as a hobby language, since almost no one uses it at work.
With all due respect, nobody who has not produced a substantial product
with Lisp is in a position to tout its superiority. This is not just an
issue with Lisp. All sorts of methodologies are pushed as the Next Big
Thing on these newsgroups. Almost invariably, the pusher hasn't shipped
even the smallest game.
I was a kitchen-table developer looking for a better way to develop the next generation of a line of educational software done originally in C, so I ended up Actually Using(tm) Lisp. It scales nicely to the real world, and as you might imagine with anything powerful, the bigger the task the bigger the payoff.
Then a friend asked me to do a rather huge business app (clinical drug trial management). The kind big companies spend $100m on. We produced something vastky better than the current state of the art on $1m. Screen shots (which give zero idea of the underlying complexity of the problem) are here (starting after "win32 gui samples"):
http://www.tilton-technology.com/cel...precursor.html
The screen shots don't tell me anything, really, as there is nothing
there that couldn't be implemented easily in MFC etc. I'll take your
word for it that the underlying data management system is a wonder. But
there's plenty wondrous stuff written in C++ too.
- Gerry Quinn
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?
Rahul Jain wrote: Stewart Gordon <sm*******@yahoo.com> writes:
Neo-LISPer wrote:
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.
Yes I can. I can write a module that runs one or two functions from the project as the whole program.
And where does the state of the game come from in that module?
I first thought the OP meant to bring the game into a specific state by
actually playing the game. Obviously, you'd bring it into a specific
state programmatically instead.
Stewart.
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)
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)
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))
You don't need to remember stuff like "never put a semicolon after curly
braces... as long they did not close a struct", etc...
André
--
Not easy to understand for non-germans: http://tinyurl.com/64x7y
"Thomas Schilling" <tj****@yahoo.de> wrote in message
news:op**************@news.cis.dfn.de... 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?
I haven't - but by the examples given in this thread alone I shudder to
think of it.
C++ is like MOST other languages I have seen, top-down, functions with a
pretty stable syntax (some shortcuts like +=).
Lisp seems to be loads of functions all conversed about (+ function(*
function(a, b)), c) instead of just "a * b + c" ... Or something along those
lines.
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.
Also I don't like the idea of being able to change functions or variables
"on the go"... Changing a function can be TERRIBLE while it's running, and
changing a variable could lead to a crash without the proper precautions.
I personally would prefer to program in a test utility (to change
variables)... That way at least I can be sure nothing goes too wrong by a
mistaken key press.
But I have traveled away from this section of the thread - about the sayings
from the "converted"... Most programming languages can do anything - you
just have to think in the correct way for each one - if they find it's
easier to use one than the other - fine. Jut don't come to me saying one way
is "better" because you can change variables "on the fly" when you really
have no need to. Or changing functions "on the fly" where it'll have various
bizare effects all over your program because you didn't THINK about it
right. Or that you have CONTROL over the memory since you have to delete
objects etc (yes, I don't like the memory stuff in C++ completely - but I do
prefer it as it means you have control - instead of relying on something
else).
--
=========
Comp Whizz
=========
(The C++ beginner)
"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.
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... It just
doesn't seem good to have the function name inside the ()'s to me.
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. 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. What if I had forgotten the ()'s
inside and just had "func 1 + 2 3 a..." ,'s just "seperate" the parameters.
André -- Not easy to understand for non-germans: http://tinyurl.com/64x7y
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <ol*********@hotmail.com> wrote: 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.
f(x, y, g(z)) must be written (f x y (g z)) in Lisp, not f(x y (g z)).
Lisp is very easy: After an open bracket the name is used as a function
name and all the rest are arguments.
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")
yes, this is right. But normally one would use keyword arguments, if
there are more parameters, with default values, if not provided, so
instead of writing:
HWND wnd = CreateWindow(
"myclass",
"Hello",
0,
0, 0,
100, 100,
NULL,
NULL,
hinstance,
NULL);
in Lisp it would look like:
(setf wnd (create-window :classname "myclass"
:windowname "Hello"
:width 100
:height 100
:hinstance hinstance))
--
Frank Buß, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Computer Whizz wrote: C++ is like MOST other languages I have seen, top-down, functions with a pretty stable syntax (some shortcuts like +=). Lisp seems to be loads of functions all conversed about (+ function(* function(a, b)), c) instead of just "a * b + c" ... Or something along those lines.
Don't you think you should go so far as to actually learn the basic syntax
of Lisp before trashing it? Lisp syntax is trivially simple. Every
expressions is of the following form:
(function|macro|special_form arg1 arg2 arg3 ...)
Your examples of Lisp syntax are complete nonsense (function names outside
brackets, commas separating arguments, etc.)
Alex
Gerry Quinn wrote: In article <Se********************@twister.nyc.rr.com>, kt*****@nyc.rr.com says... My interest in programming is concerned with the products it creates. [And as always, I remain at a loss as to why 'interactive' programming appeals to people. If I have bugs I prefer to find them, rathger than type at random and hope they go away.]
Erm yeah. That's what Lisp people do. They sit at their REPLs and type
randomly until they get a functioning program. They don't use the REPL to
set up a program state and test various components of the program quickly
and easily, or anything like that. No.
Alex Gerry Quinn wrote: > > What is it about Lisp that makes novices fall in love with it?
Try it and see. I came to Lisp rather late (age 44, after 17 years of programming, the prior eight years in C at home and Vax Basic/Cobol in tall buildings) and it was a revelation. No pointers, no manual memory management, no syntax, interactive -- basically, all the crap was gone and nothing but the fun of programming was left.
My interest in programming is concerned with the products it creates. [And as always, I remain at a loss as to why 'interactive' programming appeals to people. If I have bugs I prefer to find them, rathger than type at random and hope they go away.]
They > don't actually *produce* anything with it, mind you,...
You are right! This is because Lisp is usually discovered as a hobby language, since almost no one uses it at work.
With all due respect, nobody who has not produced a substantial product with Lisp is in a position to tout its superiority. This is not just an issue with Lisp. All sorts of methodologies are pushed as the Next Big Thing on these newsgroups. Almost invariably, the pusher hasn't shipped even the smallest game.
I was a kitchen-table developer looking for a better way to develop the next generation of a line of educational software done originally in C, so I ended up Actually Using(tm) Lisp. It scales nicely to the real world, and as you might imagine with anything powerful, the bigger the task the bigger the payoff.
Then a friend asked me to do a rather huge business app (clinical drug trial management). The kind big companies spend $100m on. We produced something vastky better than the current state of the art on $1m. Screen shots (which give zero idea of the underlying complexity of the problem) are here (starting after "win32 gui samples"):
http://www.tilton-technology.com/cel...precursor.html
The screen shots don't tell me anything, really, as there is nothing there that couldn't be implemented easily in MFC etc. I'll take your word for it that the underlying data management system is a wonder. But there's plenty wondrous stuff written in C++ too.
- Gerry Quinn
[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. 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.
That was a typo for (f x y (g z)).
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.
In Lisp there pretty much is no difference to emphasise.
-- fl****@flippac.org
In article <MP************************@news.indigo.ie>,
Gerry Quinn <ge****@DELETETHISindigo.ie> wrote: In article <t9********************@twister.nyc.rr.com>, kt*****@nyc.rr.com says... Gerry Quinn wrote:
>what is it about Lisp, >http://alu.cliki.net/RtL%20Highlight%20Film
That's more an example of what I'm saying than a refutation of it. Lots of gushing about Lisp, but hardly a mention of any shipped projects...
If you click on the name next to each "gush" you can read the full story behind it. While I jokingly called them "Sound bites to die for", as one who made the shift from C to Lisp I can assure you that what look like gushes are actually simple, sober statements of fact. Lisp is that much better.
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.
- Gerry Quinn
Argument by analogy...always fun! Now imagine (if you can) someone who
regularly and earnestly practices both Buddhism and Re-Baptism (if you
will) and is successful at both (prayers to God are answered, keeps
samsara at arm's length) and is simply bowled over by how much easier,
effective, elegant, and fun one practice is. What does that tell you?
(Don't ask me. You started it. <g>)
Seriously, Lisp vs C++ or Java or anything else is only religious if one
wants it to be; use any two languages for even tutorial exercises and
one will find real differences which really matter. More and more as one
undertakes more serious work.
And all that gushing is from real programmers who really were astonished
by the advantages of Lisp. And more than one was by someone who went in
with a negative attitude just to confirm their suspicion that Lisp was
nothing special:
http://alu.cliki.net/Pascal%20Costanza's%20Road%20To%20Lisp
That guy runs Lisp conferences now. :)
kenny
> Perhaps. But I've been right thus far.
No, your silly macho posturing over garbage collection has been shown to be
idiotic.
Alex
JKop wrote: Florian Bachmann posted:
JKop schrieb:While I agree that the OP was trolling by posting his article to c.l.c++, it is still my opinion that he was in many parts correct and the "inspired" response was nothing but a display of complete ignorance. Many of the issues raised by the OP are truly something you need to know about (if you don't already), regardless of which programming language you prefer, IMHO. Ignorance? Arrogance maybe? (no pun intended)
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. I myself am not retarded, so I've no need for "Garbage Collection". If, hypothetically speaking, I forsaw that I would temporarily become retarded (a golfclub to the head maybe), then I would make use of auto_ptr, but that has yet to happen.
Isn't great how we're all entitled to our own opinions! ;-P
-JKop
Garbage Collection is not just for the retarded -- it becomes sort of an requirement when dealing with lock-free collections, for example. And you are wrong to believe that your programs won't leak memory just because you aren't retarded.
Regards
Perhaps. But I've been right thus far.
-JKop
In article <cl**********@newsg3.svr.pol.co.uk>,
"Computer Whizz" <ol*********@hotmail.com> wrote: 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.
Yeah, but this generalizes in nice ways.
For example, if someone hands you a list of numbers (<list>),
you can compute its sum by simply doing:
(apply #'+ <list>)
And + behaves properly when handed *no* arguments:
(+) => 0
It returns the additive identity.
The fact that + does the "right thing" means that you
don't have to add a lot of special cases to your code.
For example, if someone hands you a list of numbers to
add (<list>) that happens in this case to be empty,
then these two properties combine as you would expect:
(apply #'+ <list>) ==> 0
More generally, when writing mathematical code in Common
Lisp, I find that it works the way my mathematical
intuitions tell me it should work. This probably
reflects the fact that one of the first killer apps of
Lisp was MACSYMA, the first symbolic mathematics
package, back in the early 1970s.
"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.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Alex Drummond posted: Perhaps. But I've been right thus far.
No, your silly macho posturing over garbage collection has been shown to be idiotic.
Alex
You misinterpret me.
Never have I neglected to put in a delete statement when one was
appropriate.
Even if I were to do this, I always check over my code once I've finished a
function, or a class, or a source file perhaps. In doing these checks, I
would look out for memory allocation that doesn't have a corresponding
deallocation. Hypothetically speaking, if I were to find such a mistake, I
would correct it.
Now, what part of "I don't need a Garabage Collector" do you not comprehend?
As regards "has been shown to be idiotic", now that's just stupid - perhaps
you could provide me with a link to that particular document/survey/whatever
the hell hole you pulled it out of. Did I mention that you come across as a
right shithead?
-JKop
In article <MP************************@news.indigo.ie>,
Gerry Quinn <ge****@DELETETHISindigo.ie> wrote: In article <Se********************@twister.nyc.rr.com>, kt*****@nyc.rr.com says... Gerry Quinn wrote: What is it about Lisp that makes novices fall in love with it? Try it and see. I came to Lisp rather late (age 44, after 17 years of programming, the prior eight years in C at home and Vax Basic/Cobol in tall buildings) and it was a revelation. No pointers, no manual memory management, no syntax, interactive -- basically, all the crap was gone and nothing but the fun of programming was left.
My interest in programming is concerned with the products it creates.
But what we are talking about is making it easier to build those
products -- that is why HLLs were invented, and structured programming
techniques, and OO. Carenters love nail guns. the do not want to go back
to hammers.
And if one has better tools, one can put more into the product.
[And as always, I remain at a loss as to why 'interactive' programming appeals to people. If I have bugs I prefer to find them, rathger than type at random and hope they go away.]
Your mental model of an interactive language does not include the actual
benefits:
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.
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.
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. They don't actually *produce* anything with it, mind you,... You are right! This is because Lisp is usually discovered as a hobby language, since almost no one uses it at work.
With all due respect, nobody who has not produced a substantial product with Lisp is in a position to tout its superiority. This is not just an issue with Lisp. All sorts of methodologies are pushed as the Next Big Thing on these newsgroups. Almost invariably, the pusher hasn't shipped even the smallest game.
Some things do not scale. Classic 4GL springs to mind. But everything
Lisp hobbyists rave about is confirmed by those who have applied it to
substantial products. Then a friend asked me to do a rather huge business app (clinical drug trial management). The kind big companies spend $100m on. We produced something vastky better than the current state of the art on $1m. Screen shots (which give zero idea of the underlying complexity of the problem) are here (starting after "win32 gui samples"):
http://www.tilton-technology.com/cel...precursor.html
The screen shots don't tell me anything, really, as there is nothing there that couldn't be implemented easily in MFC etc. I'll take your word for it that the underlying data management system is a wonder.
You have no idea. :) And the system must be configurable by
non-programmers to new trials in a man-month (and every trial is
different, with different rules and different forms. Lots of them. And
they change during a trial. And the data must know from which version of
a form it came from. As for MFC. nah, that is a homebrew GUI. Only the
window comes from the OS. All in Lisp.
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. :)
kenny
Rahul Jain wrote: Phlip writes:
All big applications need a scripting layer, an efficient engine layer,
and back-end layers in assembler. There is no /a-priori/ way to guess where
the cutoff between them is, or what language to use in the scripting layer.
That is a perfect argument for using Lisp
Oh, oh, I get it! Because I post to the C++ newsgroup, I'm expected to say
you should use it for everything from tying your shoes to dredding your
hair! Oh, oh, I'm sorry, I let a crack of opportunity for Lisp to get into
my preciouss C++ game!
Well Exeeeeeeeeeeyyyuuuuuuuuuuuuze Meeeeeeeeeeeheeeheeheeheeeee!
;-)
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
Sashank Varma <no**@vanderbilt.edu> writes: In article <cl**********@newsg3.svr.pol.co.uk>, "Computer Whizz" <ol*********@hotmail.com> wrote:
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.
Yeah, but this generalizes in nice ways.
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
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?
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.
I won't argue that it wouldn't be useful, but sbcl doesn't support that
option, although Slime does. Cmucl doesn't appear to do it either.
In my limited understanding of Lisp implementations, it would appear not to
be too hard, so why doesn't it? Alternately, which Lisps do?
> Never have I neglected to put in a delete statement when one was appropriate.
In that case I can only assume that either
a) You've never written a C++ program of significant complexity,
OR
b) You're a genius
OR
c) You're lying.
I'm personally inclined to believe either (a) or (c). However, if (b) is the
case, I can only suggest that you should consider the benefits of a GC for
those who lack your incredible intellectual powers. After all, even Hans
Boehm (who is really quite clever) thought it worthwhile to implement a GC
for C++ (http://www.hpl.hp.com/personal/Hans_Boehm).
Even if I were to do this, I always check over my code once I've finished a function, or a class, or a source file perhaps. In doing these checks, I would look out for memory allocation that doesn't have a corresponding deallocation. Hypothetically speaking, if I were to find such a mistake, I would correct it.
Only if the memory management problem was quite simple would there be a
one-to-one correspondence between malloc/new statements and delete/free
statements. Memory management isn't a trivial problem. That's why garbage
collection was invented.
Now, what part of "I don't need a Garabage Collector" do you not comprehend?
I comprehend it perfectly, and indeed agree with it. You don't need garbage
collector. But I'm not sure why you don't /want/ a garbage collector.
As regards "has been shown to be idiotic", now that's just stupid - perhaps you could provide me with a link to that particular document/survey/whatever the hell hole you pulled it out of.
Various posts. For example:
" Garbage Collection is not just for the retarded -- it becomes sort of
an requirement when dealing with lock-free collections, for example.
And you are wrong to believe that your programs won't leak memory just
because you aren't retarded."
Your response to this was "perhaps" and some vacuous statement about how
right you were.
Did I mention that you come across as a right shithead?
No, you didn't.
Alex
JKop wrote:
Alex Drummond posted:
Perhaps. But I've been right thus far.
No, your silly macho posturing over garbage collection has been shown to be idiotic.
Alex
You misinterpret me.
Never have I neglected to put in a delete statement when one was appropriate.
Even if I were to do this, I always check over my code once I've finished a function, or a class, or a source file perhaps. In doing these checks, I would look out for memory allocation that doesn't have a corresponding deallocation. Hypothetically speaking, if I were to find such a mistake, I would correct it.
Now, what part of "I don't need a Garabage Collector" do you not comprehend?
As regards "has been shown to be idiotic", now that's just stupid - perhaps you could provide me with a link to that particular document/survey/whatever the hell hole you pulled it out of. Did I mention that you come across as a right shithead?
-JKop
Gerry Quinn <ge****@DELETETHISindigo.ie> writes:
[Kenny Tilton:] If you click on the name next to each "gush" you can read the full story behind it. While I jokingly called them "Sound bites to die for", as one who made the shift from C to Lisp I can assure you that what look like gushes are actually simple, sober statements of fact. Lisp is that much better.
[Gerry Quinn:] 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.
If it turns out that Christianity is right[1] then that
truth will have considerable value for any Buddhist who
is prepared to heed it. And if it turns out that Christianity
is wrong then it isn't really a truth, even for people who
see it as one.
[1] i.e., there actually is a God, Jesus really was God
incarnate, following Jesus really leads to eternal
life, etc., etc., etc.
Of course, in matters of religion so much is either subjective
or very hard to ascertain that perhaps the sort of "personal
truth" you allude to is often the best one can get. But
software development isn't so woolly; some languages really
are, and can be shown to be, better for some tasks than other
languages. You simply can't write device drivers in Python,
and you'd be crazy to write theorem provers in Visual Basic.
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.
--
Gareth McCaughan
..sig under construc
On Mon, 25 Oct 2004 14:26:16 GMT, "Phlip" <ph*******@yahoo.com> wrote: "Neo-LISPer" <ne********@yahoo.com> wrote in message news:87************@yahoo.com... 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.
That's because educating someone to write low-risk C++ is difficult. Vendors have clogged our markets with low-quality languages that purport to allow inept programmers to write code at a lower risk than C++ provides.
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.
George
--
for email reply remove "/" from address
In article <kt***************************@nyctyp02-ge0.rdc-nyc.rr.com>, kt*****@nyc.rr.com says... [...] 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.
Indeed, this Lisp concept is so powerful that you'll find
a weak copy of offered for C++ in Visual Studio, namely
the "edit-and-continue" feature. Only Lisp does it better.
Christer Ericson
Sony Computer Entertainment, Santa Monica
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).
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.
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.
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?
Christer Ericson
Sony Computer Entertainment, Santa Monica
"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?). 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. > 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.
That was a typo for (f x y (g z)).
Ah - ok. Sorry. 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.
In Lisp there pretty much is no difference to emphasise.
-- fl****@flippac.org
Hmmm - I am probably going to have a hard time explaining myself out of my
own mess here... I guess it's just a matter of opinion and preference to the
syntax.
To each his own.
--
=========
Comp Whizz
=========
"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
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?
Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...
I really don't like that syntax at all!
--
=========
Comp Whizz
=========
(The C++ beginner)
"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.
/Jon
-- 'j' - a n t h o n y at romeo/charley/november com
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".
--
=========
Comp Whizz
=========
(The C++ beginner)
"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? 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: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
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: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |