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.
Neo-LISPer wrote:
<snip>
Yes, it does suck -- however it sucks a lot less than a majority of the other
available languages.
If you ever decide to come out of your cave and re-join society in a beneficial
manner, you should probably consider thoroughly studying the topic of languages
and posting a comprehensive comparison of them w/ respect to a particular
task/topic (such as game programming).
Neo-LISPer wrote:
> Hey
>
> Recently, I researched using C++ for game programming and here is what
> I found:
While I personally prefer Lisp for my side projects, C++ is not an
absolutely horrid language for game development. It is definitely much
better than C; overloading operators and templates allow a "weak man's
macro system" and virtual functions provide some much-needed dynamicness.
> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.
Why must both sides of the garbage collection debate go to such extremes?
Pro-garbage collectors say that garbage collection prevents all resource
leaks. I know that this is not true as I have seen many resource
"leaks" occurring because the programmer forgot that some part of the
code would hold a reference to some data.
Anti-garbage collectors say that garbage collection is fast, but with
unreliable slowdowns. While this is true, I have found that in
application development, the slowdown is not noticeable at all. I view
arena allocation and deallocation as a more game-centric garbage
collector, which works quite well in many games.
On the whole, I find that I rarely need garbage collection in my
programs. But when I do need garbage collection, I *really* need it. I
think Lisp is right here to default to the more general solution
(garbage collection) unless you explicitly tell it otherwise.
> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.
There is a very high failure rate among modern game development
projects, period. I don't think this has as much to do with the
programming language as it does with insane schedules/no real
direction/increased expectations. This is improving. Supposedly.
That doesn't mean that using a more high level language wouldn't speed
up development -- it would.
> 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.
A REPL debugging mechanism allowing function definitions is extremely
cool. If it had an integrated unit-test tester, that would be super
good. It's so good that I find myself implementing a half-assed REPL
test loop for any language which doesn't have a built in one. In C++ it
looks like this:
void functionToTest( int a, string& b );
int main() {
int a;
string b;
while( true ) {
BKPT();
functionToTest( a, b );
}
}
Every reasonable debugger will let me change the values of a and b.
It's a Read, Eval, Print Loop with out the Reading. :P
> 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?
> 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.
This is a very valid point. Game logic is one of the most obvious
applications of a REPL and function redefinition at runtime, which is
why many games use a language such as Python that supports such
features. As stated above, this is a great feature for *any* part of
development.
> 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.
Really? I find that function object emulate higher order functions
extremely well. It would be nice if the dispatch on them could be
either static (using templates and overloading) or dynamic (using
virtual functions), but it's simple to create such a library.
The main problem I have with function objects is that writing a separate
class is distributing logic in a way that's both confusing and annoying.
I should not have to write a separate class for this one function when
all the logic for that class is available to the compiler.
I already know about Boost.Lambda and I have found it to be impossible
to use. Every time I make a little change in my lambda function, I get
tons upon tons of errors. I last tried to use Boost.Lambda about a year
ago; has it improved its usability?
> C++ programs can not "think" of new code at run-time, and plug that
> new code into themselves in compiled form. Not easily, anyway.
I assume you are thinking about closures like cl-ppcre uses. While this
is doable in C++ using template meta-programming, it's so convoluted to
not be usable. C++ really needs a macro system like Lisp's.
> 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.
A better macro system would help here again. I know that I'd much
rather write:
DEF_ACCESSOR( int foo(), { /* code */ } );
than
int foo_impl() const { /* code */ };
int foo() const { return foo_impl(); }
int foo() { return foo_impl(); }
The first is just more to the point.
> 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.
I have no idea what you are saying here. Can you give an example of a
problem where the solution in Lisp is much more visual than in C++?
> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.
Any language with flexible abstractions is going to have this problem.
Can you tell me if foo() is faster or slower to execute than bar(a,b)?
> 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.
See above for my feelings on garbage collection.
> 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.
I agree here as well. C++'s syntax is awful, and its deduction rules
are even worse. This made Boost.Lambda to be such a pain to use. A
good macro system would help here as well.
> 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.
As stated before, macros would be nice. Unlike template meta
programming, I find that quasi quotation macros make sense.
> 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 seems to be quite easy to find good programmers for C++ projects.
It's hard to find great C++ programmers; the kind that think outside the
proverbial box. Lisp seems to encourage such thinking by its very
nature of being a programmable programming language. They're there, but
they are also much more rare.
If this is a good or bad thing is left to the company
> It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.
Since you stated many strengths of Lisp, it is natural that on most of
these statements, Lisp is better. On the whole, Lisp and C++ are very
similar (except with regards to macros), Lisp and Python/Java/C#/your
favorite dynamic language even more so. Lisp and C++ just take
different approaches to what the default assumption should be:
Lisp tries to assume the most general, and let the programmer specify
specifics when the generic solution is too slow. Lisp prematurely
pessimizes.
C++ tries to assume the fastest possible thing, and let the programmer
specify generics when needed. C++ prematurely optimizes.
So which is worse? Premature optimization is the root of all evil, but
premature pessimization is the leaf of no good. I prefer to start with
the general case and then optimize the hell out of it if needed, but
other programmers differ.
-- MJF
M Jared Finder <·····@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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
just for the sake of those out there who are actually interested in the
possiblilty of using or not using c++ for their games, let me correct
some of the bullshit misinformation here. i have removed comp.lang.c++
from the post list, because to them, this is all basic knowledge. i left
comp.lang.lisp in because i do not know their posting rules, so this may
be relevant there. if not, i apologize.
my only experience with lisp is autolisp in autocad. it was ok, but
personally, i lean more to python. to each his own.
Neo-LISPer wrote:
> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.
*NON-STATEMENT*
i seriously doubt that. i would bet c++ programmers spend the bulk of
their time designing and testing - this is what separates professionals
from hobbyists. i have no numbers to back my claim up, but neither does
the op.
does anyone have any data on how c++ or lisp programmers divide their time?
> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.
*NON-STATEMENT*
again, no numbers. but the fact that there are a lot of failed c++-based
projects is probably most likely due to the fact that there are a lot of
c++-based projects.
> You can not even change function definitions while the program is
> running and see the effects live (the ultimate debugging tool).
*BULLSHIT*
actually, i'm sure you can with some tools (it wouldn't be hard to do),
but i don't really see that as the ultimate debugging tool. more likely
a crutch for programmers who don't know what they're doing and have to
program by trial and error. but that's just opinion.
> 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.
*BULLSHIT*
the very nature of the c++ compile-link model is designed to allow you
to work in modules. poor design could force you to recompile the whole
thing for a trivial change, but that's not the language's fault, it's
the programmer's.
as for specificially executing a small portion, look up unit testing.
> 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.
*SURREAL BULLSHIT*
there is so little sense in this statement that i don't even know how to
argue it. suffice it to say that every statement in the above is at
least mostly false.
> 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.
*SOMEWHAT TRUE, BUT MISSES POINT*
firstly, the line: "those who do use it for games, have to write their
game logic in some other language" is bullshit. no-one "has" to do
anything in c++, or lisp i imagine. still many choose to voluntarily.
this statement also undermines the op's point (assuming he had any). if
c++ is so awful, why do people use it anyway, and go through the effort
of interfacing it with other languages? and are you saying that c++ is
fast and expressive, cause that seems contradictory to the rest of your
"argument"?
one of the fundamental tenets of design is to separate data from logic.
"game" logic is not the same as "program" logic. simply put, program
logic describes how the program works, and game logic describes how the
game works. good design would suggest that you could make a game engine
then use that same engine to run many different types of games. the game
engine is the program logic, and the game logic is part of the actual game.
here's an example. say i write a wicked fps game engine. the program
logic is how the engine interacts with the sound, graphics and input
hardware. now i make a game for that engine. some of the stuff i'll have
to add includes things like sound and graphics data, but i'll also be
adding game logic, like the flow of the game (ex. once you get into the
hangar, you then start the second chapter, the search for the
laboratory), descriptions of sub-quests (ex. to get the medal of honour,
you must destroy the missle launch computers before any of them fire)
and even the ai (ex. search for cover if any is available, otherwise
just bum rush the player). those things can change from game to game, so
they should be separate from the main engine.
the other important thing to consider is that proper programming
practice requires that if you change any part of a module, you have to
retest the whole thing. so if i were to include the game logic in the
game engine, and i wanted to make the ninjas more agressive, i'd have to
retest the whole game engine. that's just idiotic. so i make the game
logic separate.
so that's why the game logic is separate, but why make it in another
language? because c++ is a very complicated language, and using it to
write a ninja's ai is like using a backhoe to plant a tulip. also, like
any powerful tool, if used incorrectly, you can take a limb off. the
power of c++ is not required when making game logic (most of the time,
there are exceptions). so instead, make your game logic in a simple
language so that the artists and game designers can understand it. that
way, valuable programmer time isn't diverted from optimizing and testing
the engine, and the game designers and artists get more control over the
game, which is what they want i imagine.
in summary: c++ is *so* flexible that it allows you to interface with
other langauges that are less powerful, but simpler. doing this allows
you to delegate non-critical sections of non-engine code to be written
in languages more easily learned and used by non-programmers.
> 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.
*SURREAL BULLSHIT*
wha? the only thing i can partly understand there is that function
objects are a pain to use. fair enough. but that's a matter of opinion.
and as c++ compilers become more standards compliant, we'll be able to
take more advantage of thinks like Boost.Lambda, which mostly negates
the issue.
every other statement above is nonsense.
> C++ programs can not "think" of new code at run-time, and plug that
> new code into themselves in compiled form. Not easily, anyway.
*BULLSHIT*
of course they can. and as easily as any other language's program too.
they can even be jit compiled, if you want, but they're so fast by
default that there isn't much interest in it.
> 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.
*TRUE*
power comes at a price.
> 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.
*OPINIONATED BULLSHIT*
i see my code and data perfectly well, thank you.
> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.
*IRRELEVANT BULLSHIT*
then rtfm to find out which operations are expensive. furthermore, you
can't accidently call a constructor (unless you really don't know what
you're doing) - constructor calls are blatantly obvious.
as for smart pointers, if your smart pointer is expensive to use, get a
better one. making an expensive smart pointer is not smart at all - in
fact, it's dumber than making an expensive 3d vector class (which is
remarkably stupid).
> 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.
*SURREAL BULLSHIT*
c++ has automatic memory management. it's called the stack. as for
whether c++ "encourages" unnecessary object copying, considering the
many mechanisms c++ includes for avoiding it i'd have to say that's a
bit of a stretch. of course, if you *want* to manually manageme memory,
you're free to do so.
also... garbage collection requires reference counting, einstein. and
even if it didn't you can implement garbage collection in c++.
> 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.
*UNCLEAR BULLSHIT*
i'm not 100% sure what you're talking about here. if you're talking
about repetetive syntax, i already conceded that above. but if you're
talking about *design patterns*, then you don't have a clue what you're
talking about.
design patterns are constructs used to model the behaviour of code. they
are not literal patterns of code.
> 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.
*BULLSHIT*
complete crap.
> 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.
*FUNNY BULLSHIT*
moo.
this is the first time i've been compared to a plague.
> It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.
i'm sure john carmack would love your input.
my own opinion is that any given game could be done in c++ alone with
not much problem. the same is true for lisp. however, combining the
strengths of the two would lend more power to the game programmer to
make better games with less work in less time. can't we all just get along?
indi
Mark A. Gibbs wrote:
>> 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.
>
>
> *UNCLEAR BULLSHIT*
> i'm not 100% sure what you're talking about here. if you're talking
> about repetetive syntax, i already conceded that above. but if you're
> talking about *design patterns*, then you don't have a clue what you're
> talking about.
>
> design patterns are constructs used to model the behaviour of code. they
> are not literal patterns of code.
But there is no reason they can't be. After all, structures are pattern
with all the following properties:
* (Speed)
You can access all the members of a structure in constant time.
* (Atomicness)
Given a pointer to a structure, you can access all of the members.
* (Heterogeneous)
A structure's members can hold different types
Given these requirements, its trivial to write a quasi quotation macro
that has all these properties; just place the members down in sequential
positions in memory. Why not automate that?
This is where Lisp macros shine; they allow you to express design
patterns *as code*, making describing them much more explicit, and using
them much easier. Templates somewhat serve this purpose, but I find
template meta programming to be way to confusing compared to the simpler
and more direct quasi quotation system. Compare the template meta
programming examples in Alexadrescu's "Modern C++ Design" to the quasi
quotation examples in Graham's "On Lisp".
-- MJF
Mark A. Gibbs wrote:
> the very nature of the c++ compile-link model is designed to allow you
> to work in modules. poor design could force you to recompile the whole
> thing for a trivial change, but that's not the language's fault, it's
> the programmer's.
>
> as for specificially executing a small portion, look up unit testing.
What if you make a change to a module that every other module depends on?
Then you have to recompile the whole program, which you wouldn't always
have to do in Lisp. Unit testing is not a pratical replacement for a REPL.
If you just want to (say) play around with some standard library functions
to prototype some new code, you cannot do that with a unit testing
framework. The Lisp philosophy is that if you want to execute some bit of
code, you should just be able to say: "execute this bit of code". There
should not be a unit testing framework complicating such a simple action.
>> 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.
>*SURREAL BULLSHIT*
>there is so little sense in this statement that i don't even know how to
>argue it. suffice it to say that every statement in the above is at
>least mostly false.
It's semi-bullshit. Static type systems can make refactoring more tricky.
Ocasionally you might have to redesign your class hierachy. OP is just
exaggerating here.
> [discussion of game engine/logic separation]
Writing different modules of a program in a different language is not an
optimal modularisation technique. Ideally you would be able to write all
modules of your program in the same language (while still keeping them
entirely separate, if you wished). C++ makes this difficult in some cases.
The idea that high-level scripting languages are less powerful than C++ is
pretty absurd, given that they tend to have much better abstraction
features. The reason they are needed is that they are more powerful (at
least in the sense of fewer lines of code for the same bang).
Alex
Alex Drummond wrote:
>>the very nature of the c++ compile-link model is designed to allow you
>>to work in modules. poor design could force you to recompile the whole
>>thing for a trivial change, but that's not the language's fault, it's
>>the programmer's.
>>
>>as for specificially executing a small portion, look up unit testing.
>
>
> What if you make a change to a module that every other module depends on?
> Then you have to recompile the whole program, which you wouldn't always
false. interface and implementation are separated by a bright line in c++.
if you change the *interface*, then yes, you have to recompile
everything. i don't know lisp, but i cannot believe that the same is not
true there.
if you change the *implementation* then you only have to recompile that
module and relink.
> If you just want to (say) play around with some standard library functions
> to prototype some new code, you cannot do that with a unit testing
> framework.
why not?
> The Lisp philosophy is that if you want to execute some bit of
> code, you should just be able to say: "execute this bit of code". There
> should not be a unit testing framework complicating such a simple action.
fair enough, but this is just a difference in philosphy. i don't see how
executing isolated "bits" of code is useful for any purpose but testing.
hence, unit testing.
>>>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.
>
>
>>*SURREAL BULLSHIT*
>>there is so little sense in this statement that i don't even know how to
>>argue it. suffice it to say that every statement in the above is at
>>least mostly false.
>
>
> It's semi-bullshit. Static type systems can make refactoring more tricky.
> Ocasionally you might have to redesign your class hierachy. OP is just
> exaggerating here.
and making a pointless arguement. enough redesign will lead to complete
rewrites in any language. refactoring can always be tricky. about the
only point of contention is how much redesign and refactoring causes
problems in a given language, compared to another language. how would
you measure such a nebulous concept? if it can't be measured, it
shouldn't be argued.
besides, the argument can easily be turned around. static typing means
design locks, therefore looser typing ambiguates code because changes
may have unintended side-effects that stricter typing could avoid. there
is no point in making a comparison on a point like that.
>>[discussion of game engine/logic separation]
>
> Writing different modules of a program in a different language is not an
> optimal modularisation technique.
i never claimed it was optimal. i stated that every language has it's
strengths and weaknesses, and if you are going to be modularizing
anyway, and one module would be better to be done in another language,
go for it.
> Ideally you would be able to write all
> modules of your program in the same language (while still keeping them
> entirely separate, if you wished). C++ makes this difficult in some cases.
false. of course it's true that in a perfect world it would be best to
write a program all in one perfect language that does everything well.
nothing i have said suggests that that's not a good idea. however, as i
explained, game logic is not program logic, it is actually program data.
therefore, it is not a *module* of the program, it is *input* to that
program.
given that the game logic is so conceptually separate from the game
program itself, it's not really such a big step to do it in another
language that is simpler to interpret at runtime. as a bonus, you can
also choose a language that is easier on non-programmers so that more
people can make content for your game.
in fact - if your game is *really* kick-ass, it might be able to handle
game logic written in several languages, so that content creators can
choose what they like best.
as for your claim that c++ makes interfacing with other langauges
difficult in some cases - c++ has been interfaced with thousands of
other langauges. explain which cases you mean.
> The idea that high-level scripting languages are less powerful than C++ is
> pretty absurd, given that they tend to have much better abstraction
> features. The reason they are needed is that they are more powerful (at
> least in the sense of fewer lines of code for the same bang).
i usually avoid using the word "powerful" in this context, because it
leads to idiotic discussion. if i slipped it in this time, mea culpa.
"power" is nonsense in terms of a programming language. you claim that
power means better abstraction facilities. i could just as rightly claim
that it means performance.
in the general case, good abstraction negates good performance. why? you
said it yourself: "fewer lines of code for the same bang (ie, it does
more, i guess)". simplifying you get: "each line of code does more".
considering that "doing" anything "costs" in terms of speed and/or
memory, i could say: "each line of code costs more". therefore higher
abstraction is more expensive. qed.
now, if you need better abstraction and you are willing to sacrifice
performance, then by all means, use a high-level scripting language.
such is the case for game logic - it's not necessarily time critical,
and the more people that can contribute with greater ease, the better.
but don't ever waste my time by trying to argue that high-level
scripting languages are perfect for every job. no language is.
indi
Mark A. Gibbs wrote:
> false. interface and implementation are separated by a bright line in c++.
>
> if you change the *interface*, then yes, you have to recompile
> everything. i don't know lisp, but i cannot believe that the same is not
> true there.
>
> if you change the *implementation* then you only have to recompile that
> module and relink.
OK, mostly true. There are some exceptions though, for example relating to
the dynamic nature of CLOS and the types of sequences (e.g. replace a list
with a vector at runtime, and if your code only uses generic sequence
operations it won't break). Also, there need not be any recompiling in lisp
as such. You can recompile individual functions, or change the values of
individual variables. This can be a real help.
> fair enough, but this is just a difference in philosphy. i don't see how
> executing isolated "bits" of code is useful for any purpose but testing.
> hence, unit testing.
I really don't know what to say. I thought everyone found REPLs useful (but
perhaps not worth the trouble of implementing for a particular language, of
course). You can do the same stuff with unit testing, sure. It's like the
difference between the following two scenarios.
1) I want some bread. I go to the shop, buy some bread.
2) I want some bread. I create a shopping list containing the single item
"bread", the name of the shop and the expected result of the expedition
(i.e. I will have obtained some bread). I then go to the shop to buy the
bread, afterwards checking against the shopping list that I have indeed
bought bread.
It's very useful to be able to get the value of an expression in a few
seconds without having to edit and/or compile a file. I do it all the time
when I'm writing Lisp programs, and unit tests would be the Wrong Thing.
You should not be writing tests for prototypical code -- only
classes/functions/whatever which have stable interfaces. The last thing you
want is to have lots of throwaway legacy test code hanging around.
> besides, the argument can easily be turned around. static typing means
> design locks, therefore looser typing ambiguates code because changes
> may have unintended side-effects that stricter typing could avoid. there
> is no point in making a comparison on a point like that.
Yes fair point. Although it should be pointed out that C++'s static type
system is pretty gross compared to the state of the art (i.e. ML, Haskell,
etc.)
> i never claimed it was optimal. i stated that every language has it's
> strengths and weaknesses, and if you are going to be modularizing
> anyway, and one module would be better to be done in another language,
> go for it.
Yes I agree.
> false. of course it's true that in a perfect world it would be best to
> write a program all in one perfect language that does everything well.
> nothing i have said suggests that that's not a good idea. however, as i
> explained, game logic is not program logic, it is actually program data.
> therefore, it is not a *module* of the program, it is *input* to that
> program.
>
> given that the game logic is so conceptually separate from the game
> program itself, it's not really such a big step to do it in another
> language that is simpler to interpret at runtime. as a bonus, you can
> also choose a language that is easier on non-programmers so that more
> people can make content for your game.
Mostly fair points. However in Lisp you could actually compile the game
logic code at runtime, and use it as an input to the game engine program
without having to write an interpreter. All I'm saying is that this is a
very attractive alternative to having a separate script language, and in
Lisp you would still have the possibility of implementing a separate script
language, just as in C++.
> in the general case, good abstraction negates good performance. why? you
> said it yourself: "fewer lines of code for the same bang (ie, it does
> more, i guess)". simplifying you get: "each line of code does more".
> considering that "doing" anything "costs" in terms of speed and/or
> memory, i could say: "each line of code costs more". therefore higher
> abstraction is more expensive. qed.
Rather depends on how efficient each line of code is, and whether you end up
with the same number of lines, but I don't want to pick an argument on this
topic; I think we basically agree.
> now, if you need better abstraction and you are willing to sacrifice
> performance, then by all means, use a high-level scripting language.
> such is the case for game logic - it's not necessarily time critical,
> and the more people that can contribute with greater ease, the better.
> but don't ever waste my time by trying to argue that high-level
> scripting languages are perfect for every job. no language is.
I really wouldn't argue that. I'd argue that in Lisp you could have the
convenience of loading and compiling game logic code at runtime /and/ the
performance of a mature compiled language. No sacrifices necessary ;)
Alex
>
> Alex Drummond wrote:
>
>>>the very nature of the c++ compile-link model is designed to allow you
>>>to work in modules. poor design could force you to recompile the whole
>>>thing for a trivial change, but that's not the language's fault, it's
>>>the programmer's.
>>>
>>>as for specificially executing a small portion, look up unit testing.
>>
>>
>> What if you make a change to a module that every other module depends on?
>> Then you have to recompile the whole program, which you wouldn't always
>
> false. interface and implementation are separated by a bright line in c++.
>
> if you change the *interface*, then yes, you have to recompile
> everything. i don't know lisp, but i cannot believe that the same is not
> true there.
>
> if you change the *implementation* then you only have to recompile that
> module and relink.
>
>> If you just want to (say) play around with some standard library
>> functions to prototype some new code, you cannot do that with a unit
>> testing framework.
>
> why not?
>
>> The Lisp philosophy is that if you want to execute some bit of
>> code, you should just be able to say: "execute this bit of code". There
>> should not be a unit testing framework complicating such a simple action.
>
> fair enough, but this is just a difference in philosphy. i don't see how
> executing isolated "bits" of code is useful for any purpose but testing.
> hence, unit testing.
>
>>>>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.
>>
>>
>>>*SURREAL BULLSHIT*
>>>there is so little sense in this statement that i don't even know how to
>>>argue it. suffice it to say that every statement in the above is at
>>>least mostly false.
>>
>>
>> It's semi-bullshit. Static type systems can make refactoring more tricky.
>> Ocasionally you might have to redesign your class hierachy. OP is just
>> exaggerating here.
>
> and making a pointless arguement. enough redesign will lead to complete
> rewrites in any language. refactoring can always be tricky. about the
> only point of contention is how much redesign and refactoring causes
> problems in a given language, compared to another language. how would
> you measure such a nebulous concept? if it can't be measured, it
> shouldn't be argued.
>
> besides, the argument can easily be turned around. static typing means
> design locks, therefore looser typing ambiguates code because changes
> may have unintended side-effects that stricter typing could avoid. there
> is no point in making a comparison on a point like that.
>
>>>[discussion of game engine/logic separation]
>>
>> Writing different modules of a program in a different language is not an
>> optimal modularisation technique.
>
> i never claimed it was optimal. i stated that every language has it's
> strengths and weaknesses, and if you are going to be modularizing
> anyway, and one module would be better to be done in another language,
> go for it.
>
>> Ideally you would be able to write all
>> modules of your program in the same language (while still keeping them
>> entirely separate, if you wished). C++ makes this difficult in some
>> cases.
>
> false. of course it's true that in a perfect world it would be best to
> write a program all in one perfect language that does everything well.
> nothing i have said suggests that that's not a good idea. however, as i
> explained, game logic is not program logic, it is actually program data.
> therefore, it is not a *module* of the program, it is *input* to that
> program.
>
> given that the game logic is so conceptually separate from the game
> program itself, it's not really such a big step to do it in another
> language that is simpler to interpret at runtime. as a bonus, you can
> also choose a language that is easier on non-programmers so that more
> people can make content for your game.
>
> in fact - if your game is *really* kick-ass, it might be able to handle
> game logic written in several languages, so that content creators can
> choose what they like best.
>
> as for your claim that c++ makes interfacing with other langauges
> difficult in some cases - c++ has been interfaced with thousands of
> other langauges. explain which cases you mean.
>
>> The idea that high-level scripting languages are less powerful than C++
>> is pretty absurd, given that they tend to have much better abstraction
>> features. The reason they are needed is that they are more powerful (at
>> least in the sense of fewer lines of code for the same bang).
>
> i usually avoid using the word "powerful" in this context, because it
> leads to idiotic discussion. if i slipped it in this time, mea culpa.
>
> "power" is nonsense in terms of a programming language. you claim that
> power means better abstraction facilities. i could just as rightly claim
> that it means performance.
>
> in the general case, good abstraction negates good performance. why? you
> said it yourself: "fewer lines of code for the same bang (ie, it does
> more, i guess)". simplifying you get: "each line of code does more".
> considering that "doing" anything "costs" in terms of speed and/or
> memory, i could say: "each line of code costs more". therefore higher
> abstraction is more expensive. qed.
>
> now, if you need better abstraction and you are willing to sacrifice
> performance, then by all means, use a high-level scripting language.
> such is the case for game logic - it's not necessarily time critical,
> and the more people that can contribute with greater ease, the better.
> but don't ever waste my time by trying to argue that high-level
> scripting languages are perfect for every job. no language is.
>
> indi
On Mon, 25 Oct 2004 21:02:43 +0000, Alex Drummond wrote:
> I really don't know what to say. I thought everyone found REPLs useful (but
> perhaps not worth the trouble of implementing for a particular language, of
> course). You can do the same stuff with unit testing, sure. It's like the
> difference between the following two scenarios.
>
> 1) I want some bread. I go to the shop, buy some bread.
> 2) I want some bread. I create a shopping list containing the single item
> "bread", the name of the shop and the expected result of the expedition
> (i.e. I will have obtained some bread). I then go to the shop to buy the
> bread, afterwards checking against the shopping list that I have indeed
> bought bread.
>
> It's very useful to be able to get the value of an expression in a few
> seconds without having to edit and/or compile a file. I do it all the time
> when I'm writing Lisp programs, and unit tests would be the Wrong Thing.
> You should not be writing tests for prototypical code -- only
> classes/functions/whatever which have stable interfaces. The last thing you
> want is to have lots of throwaway legacy test code hanging around.
This is interesting. I thoroughly agree with you of course, the REPL is
invaluable.
The interesting thing is, I see my unit tests as a serialisation of my
REPL sessions... because that's literally what they are. I wrote an ELisp
function that takes a buffer full of my interactions with beanshell (a
Java interpreter), and creates a new buffer containing source for a
collection of unit tests that JUnit can execute. Each test simply
executes the code that I typed in the REPL, line-by-line, and checks that
any values returned are the same as they were when I was using the REPL.
The only caveat is, of course, dealing with unprintable values. That's
usually pretty easy to fix with just a little manual editing of the
resulting tests though.
It's been a long while since I wrote a unit test by hand - these days I do
them all this way. I don't think it's a coincidence that I have much
higher test coverage than any of my colleagues who write all their tests
by hand.
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> if you change the *interface*, then yes, you have to recompile
> everything. i don't know lisp, but i cannot believe that the same is not
> true there.
The details of the interface can be determined by the compiler instead
of the programmer having to insert the details everywhere and then
change those details everywhere when they change on one end of the
system. The plethora of trivially different implementations of many
methods is a symptom of this problem. Sometimes templates help, but
sometimes they're just plain unnecessary baggage for the system to deal
with, because they require re-analysis of all the functions that might
be invoked for this one specific case.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Mon, 25 Oct 2004, Mark A. Gibbs wrote:
> c++ has automatic memory management. it's called the stack.
And won't manage your memory unless you fit a certain usage pattern, but
hey.
> also... garbage collection requires reference counting, einstein. and
> even if it didn't you can implement garbage collection in c++.
>
It doesn't require reference counting, and reference counting is severely
flawed as GC systems go - the only real advantage being the predictable
performance. You can at best implement conservative GC for a C++ program.
A proper garbage collector needs to know more about the structures it's
working on than a C++ implementation can hope to discover about arbitrary
data.
--
······@flippac.org
Philippa Cowderoy <······@flippac.org> wrote in message news:<································@SLINKY>...
> On Mon, 25 Oct 2004, Mark A. Gibbs wrote:
>
> > c++ has automatic memory management. it's called the stack.
>
> And won't manage your memory unless you fit a certain usage pattern, but
> hey.
>
> > also... garbage collection requires reference counting, einstein. and
> > even if it didn't you can implement garbage collection in c++.
> >
>
> It doesn't require reference counting, and reference counting is severely
> flawed as GC systems go - the only real advantage being the predictable
> performance.
Predictable? Not so!
You can't always be sure how much the next Release() call is going to
cost!
Sometimes you drop the last reference on some object which is holding
on to a bunch of last references to other objects which are holding on
to more last references to yet more objects ...
Kaz Kylheku wrote:
> Philippa Cowderoy <······@flippac.org> wrote in message
> news:<································@SLINKY>...
>> On Mon, 25 Oct 2004, Mark A. Gibbs wrote:
>>
>> > c++ has automatic memory management. it's called the stack.
>>
>> And won't manage your memory unless you fit a certain usage pattern, but
>> hey.
>>
>> > also... garbage collection requires reference counting, einstein. and
>> > even if it didn't you can implement garbage collection in c++.
>> >
>>
>> It doesn't require reference counting, and reference counting is severely
>> flawed as GC systems go - the only real advantage being the predictable
>> performance.
>
> Predictable? Not so!
>
> You can't always be sure how much the next Release() call is going to
> cost!
>
> Sometimes you drop the last reference on some object which is holding
> on to a bunch of last references to other objects which are holding on
> to more last references to yet more objects ...
Well, you could always have release() stop working after a specific number
of objects have been released, and save the list of current workees so it
can continue the next time it's called...
That's incremental collection, and it has a cost. It does show the
possibility, though, even if I wouldn't want to use reference-counting for
it.
(Not by itself, anyway - it can be useful when the references are to data on
a disk. But I digress.)
On Tue, 25 Oct 2004, Kaz Kylheku wrote:
> Predictable? Not so!
>
> You can't always be sure how much the next Release() call is going to
> cost!
>
> Sometimes you drop the last reference on some object which is holding
> on to a bunch of last references to other objects which are holding on
> to more last references to yet more objects ...
>
Sure, but at least you can predict things like total runtime. It's just
about possible to use reference counting in a realtime situation, it's not
possible for a large number of other algorithms.
--
······@flippac.org
On Tue, 26 Oct 2004, Ingvar wrote:
> Philippa Cowderoy <······@flippac.org> writes:
>
> > On Tue, 25 Oct 2004, Kaz Kylheku wrote:
> >
> > > Predictable? Not so!
> > >
> > > You can't always be sure how much the next Release() call is going to
> > > cost!
> > >
> > > Sometimes you drop the last reference on some object which is holding
> > > on to a bunch of last references to other objects which are holding on
> > > to more last references to yet more objects ...
> > >
> >
> > Sure, but at least you can predict things like total runtime. It's just
> > about possible to use reference counting in a realtime situation, it's not
> > possible for a large number of other algorithms.
>
> Most GC algorithms can (in theory, at least) provide an upper bound on
> how much time the GC will take.
Sure. It's easier to spot how often the GC's going to be run with
refcounting though.
> A GC that is specifically tuned
> to the problem area (allocate known-to-live-short things from a
> separate arena and at a suitable time, scrap the whole arena) can be
> very *very* fast, but requires a problem set that is well-suited for
> taht sort of thing (any per-frame-allocated data would be a good
> starting point, from a game programming POV).
>
Right, this is the kind of thing I had in mind in one of my other posts.
I'm also fond of the region inference stuff mentioned in another post,
would like to play around with building something similar sometime.
> Alas, I don't have time to write games right at the moment, I'm busy
> writing traffic analysis tools in Common Lisp. I'll be crunching,
> aggregating and analysing somewhere around 1.5-7.5 GB per hour, is the
> thought. Not quite there, but the latest optimization cut the run-time
> by a factor of about 4.4. I'm almost at a opint where I can do 1.5 GB/h
> in real-time.
>
Fun. Remind me to mention my latest hacks to you on #afp sometime (though
I'll be AFK most of tonight).
--
······@flippac.org
Philippa Cowderoy <······@flippac.org> writes:
> Sure. It's easier to spot how often the GC's going to be run with
> refcounting though.
GC will potentially be done with refcounting when you decrement a
refcount. GC will potentially be done with good GC algorithms when you
allocate an object. How is one easier to spot than the other?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Philippa Cowderoy <······@flippac.org> writes:
> reference counting is severely flawed as GC systems go - the only real
> advantage being the predictable performance
Predictably slow, maybe...
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> Philippa Cowderoy <······@flippac.org> writes:
>
> > reference counting is severely flawed as GC systems go - the only real
> > advantage being the predictable performance
>
> Predictably slow, maybe...
Referencing counting does not actually give predictable performance. Usages
patterns of access can still vary widely, and freeing a particular usage can
cause a cascade of collecting as one release frees the next and on down the
chain.
Referencing counting actually tends to give "spikes" of garbage collecting.
A proper GC tends to spread out the collections over time, giving better and
more consistent peformance.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
I'd like to say, that for any action oriented game, this whole discussion is
moot.
I don't think much of games programmers that are doing memory allocations /
frees in time critical parts of the games! Unless your loading up more
resources from disk, you shouldn't be allocated or freeing memory!
Don't you people ever write 60fps games?
And if your exitting a level to load another level, you should be using a
mark & release memory model that frees all level memory in a cycle and
allocs take a cycle since they are just an add to the current alloc
location.
On Thu, 28 Oct 2004, Maahes wrote:
> I'd like to say, that for any action oriented game, this whole discussion is
> moot.
>
> I don't think much of games programmers that are doing memory allocations /
> frees in time critical parts of the games! Unless your loading up more
> resources from disk, you shouldn't be allocated or freeing memory!
>
> Don't you people ever write 60fps games?
>
I find myself thinking of things like Unreal and Unrealscript here. You
shouldn't be doing many OS-level allocates, but you're going to be
grabbing spare list nodes from pools and so forth. GC is perfectly
compatible with such a system.
But yeah, a number of people in here don't write 60fps games, they write
as-fast-as-the-monitor-goes.
--
······@flippac.org
> I find myself thinking of things like Unreal and Unrealscript here. You
> shouldn't be doing many OS-level allocates, but you're going to be
> grabbing spare list nodes from pools and so forth. GC is perfectly
> compatible with such a system.
Grabbing a node from a pool is not an allocation and has nothing to do with
GC or memory allocations.. HENCE ITS A POOL!!!!
>
> But yeah, a number of people in here don't write 60fps games, they write
> as-fast-as-the-monitor-goes.
>
cute. Obviously your not a games console programmer..
> Grabbing a node from a pool is not an allocation and has nothing to do
> with GC or memory allocations.. HENCE ITS A POOL!!!!
Yeah fair enough, but UnrealScript must GC sometimes, right? Lua is quite
popular for games scripting, and that definitely GCs.
Alex
Maahes wrote:
>
>> I find myself thinking of things like Unreal and Unrealscript here. You
>> shouldn't be doing many OS-level allocates, but you're going to be
>> grabbing spare list nodes from pools and so forth. GC is perfectly
>> compatible with such a system.
>
> Grabbing a node from a pool is not an allocation and has nothing to do
> with GC or memory allocations.. HENCE ITS A POOL!!!!
>
>>
>> But yeah, a number of people in here don't write 60fps games, they write
>> as-fast-as-the-monitor-goes.
>>
>
> cute. Obviously your not a games console programmer..
On Fri, 29 Oct 2004, Maahes wrote:
>
> > I find myself thinking of things like Unreal and Unrealscript here. You
> > shouldn't be doing many OS-level allocates, but you're going to be
> > grabbing spare list nodes from pools and so forth. GC is perfectly
> > compatible with such a system.
>
> Grabbing a node from a pool is not an allocation and has nothing to do with
> GC or memory allocations.. HENCE ITS A POOL!!!!
>
Nodes could quite conceivably be GCed back into the pool. The OS's memory
management, your memory management, what difference does it make? If this
sounds silly, consider that GCed language runtimes sometimes allocate a
heap at the start of execution and then do everything internally.
> >
> > But yeah, a number of people in here don't write 60fps games, they write
> > as-fast-as-the-monitor-goes.
> >
>
> cute. Obviously your not a games console programmer..
>
Right, which is what I was indicating. It's no more a good idea to make
judgement calls about what's not appropriate for any (action) game based
on the limitations found on consoles any more than it is to judge
everything by PC standards.
--
······@flippac.org
>
> Right, which is what I was indicating. It's no more a good idea to make
> judgement calls about what's not appropriate for any (action) game based
> on the limitations found on consoles any more than it is to judge
> everything by PC standards.
>
I guarantee you if you program for a console, and port to PC, your PC
version will run more efficiently... You won't be hitting
as-fast-as-the-monitor-runs if your doing runtime garbage collection unless
your game logic is so trivial that it doesn't tax the CPU anyway..
If your trying to push a 600mhz PC with complex gameplay, you won't be
wasting cycles on that crap. If you have a 4ghz PC and don't care, why argue
about performance anyway coz GC or Smart Pointers aren't going to tax your
program if your using them intelligently.
On Fri, 29 Oct 2004, Maahes wrote:
> I guarantee you if you program for a console, and port to PC, your PC
> version will run more efficiently... You won't be hitting
> as-fast-as-the-monitor-runs if your doing runtime garbage collection unless
> your game logic is so trivial that it doesn't tax the CPU anyway..
> If your trying to push a 600mhz PC with complex gameplay, you won't be
> wasting cycles on that crap. If you have a 4ghz PC and don't care, why argue
> about performance anyway coz GC or Smart Pointers aren't going to tax your
> program if your using them intelligently.
>
This applies if and only if you don't have a need to reuse resources
during processing. Otherwise, you may wish to consider your memory
footprint as an issue - at which point, it may or may not be
significantly more efficient to use GC or otherwise. If everything fits in
memory then fair enough.
--
······@flippac.org
This whole discussion started off way too passionate, and lacks a
frame of references.
Please discuss what is meant by game programming? Throwing a complex
interdisciplinary activity around without a clear definition will
invariably get you into trouble.
For what it is worth, I think that anyone contemplating making a game
should first worry about making a usable design, then pick a
programming language or facility(GC) that would 'best' implement that
design.
Regarding C++, no one can seriously claim it to be an easy language,
but if you apply the right idioms to the right problems, it can be
cleaner, safer, and faster than most other languages. resource
aquisition is initialization (RAII) should remove the need for most
garbage collection, but again this depends on the design of your game
engine!
As for higher order messaging and object base classes, please don't
confuse C++ for a deficient dynamic language, it is very deliberately
static. Google to Bjarne Stroustup's (the inventor) webpage to read
motivations behind the design of C++.
Jeremy J
On 2 Nov 2004 12:36:00 -0800, Jeremy J <········@myrealbox.com> wrote:
> For what it is worth, I think that anyone contemplating making a game
> should first worry about making a usable design, then pick a
> programming language or facility(GC) that would 'best' implement that
> design.
>
> Regarding C++, no one can seriously claim it to be an easy language,
> but if you apply the right idioms to the right problems, it can be
> cleaner, safer, and faster than most other languages. resource
> aquisition is initialization (RAII) should remove the need for most
> garbage collection, but again this depends on the design of your game
> engine!
>
> As for higher order messaging and object base classes, please don't
> confuse C++ for a deficient dynamic language, it is very deliberately
> static. Google to Bjarne Stroustup's (the inventor) webpage to read
> motivations behind the design of C++.
I programmed C++ for 10 years (1990-2000).
5 of those years professionally.
Of course you can develop professional applications in C++.
As you state, with experience, it is indeed possible to develop reliable
applications in C++.
My main reason to search out other languages was the amount of effort and
time it
took to get a application off the ground. It is quite unusual to see
anyone developing
a sizable C++ on their own. It typically takes a group of 8 programmers or
more to get a
application off the ground. (I worked for Opera the Internet browser.)
In 1990 the limited memory and speed of my computer pretty much ruled out
Lisp as a language. Today I think more in terms of 'Time to market'.
Developing C++ applications is a time intensive endeavor.
Media for distributing programmes and the computers themselves mean that
speed and size are side issues for most applications.
The exception is, of course, games. Particularly graphic's intensive games.
You are right that the C++ class system is static.
This means classes are used differently than you do in CLOS.
In particular you are more likely to manipulate hierarchies of
objects and not hierarchies of classes. (On the heap)
My main grievances in C++ are the following
1. The standard library came to late.
Most windows libraries and the like use their own collection
hierarchies.
It is not unusual for a application to use two or even three different
collection libraries.
They are mutually incompatible and conversion and the like wastes size,
speed and time.
Also they handle allocation differently.
2. It is difficult to write secure code in C++.
Many C library functions use unsafe practises and this is
not always documented. The classic example is gets but there
are plenty of others.
Again finding and plugging these holes is time consuming.
3. There are big difference between the level of support for C++ among
compilers.
In particular templates, exceptions and name-spaces can cause troubles.
Porting is a slow and time consuming process.
I can't see that developing in C++ is faster, cleaner and more reliable
than most other languages.
Again much of the software quality depends on the programmer more than the
language.
The methodology helps, but again, this is not a feature of the language.
That being said I have met C++ hackers who have a real gift for
programming.
I don't follow Paul Grahams argument that you need a esoteric language to
find a real hacker.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Marco Baringer
Subject: Re: Language flame wars are moot
Date:
Message-ID: <m24qk4crwq.fsf@bese.it>
"John Thingstad" <··············@chello.no> writes:
> I don't follow Paul Grahams argument that you need a esoteric language to
> find a real hacker.
i don't think that was his argument (and if it was i'll need to change
my opinion). i _think_ what he meant was very simply that some
languages are more expressive than others and, in giving you more
"power" (aka rope) you can write better programs.
my paraphrase of graham's sentement: 1) you can write a better book in
a language which has active, passive and phrasal verbs than in one
which has just active (or just passive or just phrasal). 2) someone
whose native tongue only has active verbs won't miss passive or
phrasal verbs.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
All good points.
> 1. The standard library came to late.
> Most windows libraries and the like use their own collection
> hierarchies.
> It is not unusual for a application to use two or even three different
> collection libraries.
> They are mutually incompatible and conversion and the like wastes size,
> speed and time.
> Also they handle allocation differently.
I feel your pain. Standardization was a real train wreck for C++. I
wish to emphasize that C++ should be applied to particular problems
only after determining if the language AND libraries provide
sufficient support. I refuse to write GUI code in C++ because I have
found Objective-C to provide superior support for GUI's on my platform
of choice. Likewise I refuse to write math heavy code in Objective-C
because the STL provides superior support for vectors, matrices,
complex number and a host of other types.
> 2. It is difficult to write secure code in C++.
> Many C library functions use unsafe practises and this is
> not always documented. The classic example is gets but there
> are plenty of others.
> Again finding and plugging these holes is time consuming.
This was once very true, but now less so. Buffer overflows and the
such are beasts of the past for C++ as the standard libs remove NEARLY
ALL need to manipulate raw memory.
> 3. There are big difference between the level of support for C++ among
> compilers.
> In particular templates, exceptions and name-spaces can cause troubles.
> Porting is a slow and time consuming process.
Guilty as charged. I guess I am lucky that I don't have to support old
compilers :)
> I can't see that developing in C++ is faster, cleaner and more reliable
> than most other languages.
> Again much of the software quality depends on the programmer more than the
> language.
I did not say that DEVELOPING is cleaner or faster, but the resulting
programs can be.
Let me be explicit. C++ is HARD. It is not for most desktop
applications. Don't use it unless you know what you are doing. But if
you do know what you are doing then you can write very well defined
programs that run FAST.
> The methodology helps, but again, this is not a feature of the language.
Exactly. C++ does not prescribe a particular methedology, which is
it's biggest strength and the source of so much misunderstanding. C++
is multi paradigm. It SUPPORTS object oriented programming, as well as
functional programming. It IS neither an object oriented language, nor
a functional one. Good methedology is better than all the language
features in the world, as a human can apply methedologies with
discrimination and flexibility, while a compiler lacks the judgement
to apply language features with any flexibility.
Please don't think that I am saying that C++ is the greatest language
ever. I doubt it is. For most desktop apps, it is rather silly. But so
many of the posts on the 'C++ sucks for games' thread come from a
position of ignorance, and I am trying to enlighten.
My real beef with the thread is that it does not define what people
mean by game programming. I for one am writing my graphics engine in
C++, Scenario Editor in Objective-C and network support in Java. These
are all very different activities.
Happy programming, in any language.
Jeremy J
> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.
AKA Retarded mode.
> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.
There's a 90% failure rate for lions when hunting. They still eat.
I would presume that that "very high failure rate" becomes a bit lower when
you're dealing with proficient C++ programmers.
> You can not even change function definitions while the program is
> running and see the effects live (the ultimate debugging tool).
Nothing to do with the language. Such a debugging tool could be developed,
why not develop it?
I myself wouldn't use it.
> 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.
That's because there's no such thing as "half a program". If you really want
this, copy-paste it to another file and just append:
int main(){}
to the end of it.
> 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.
Bullshit. Vague bullshit.
> 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.
Provide an example. I myself forsee no reason or motive to do or have to do
this.
> 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.
"function objects". Get over it! It's just syntatic sugar!
> C++ programs can not "think" of new code at run-time, and plug that
> new code into themselves in compiled form. Not easily, anyway.
"think of new code at run-time". That's because it takes intelligence to
write code, something which computers lack. As for the code coming from
somewhere else, well it's done extremely easily actually - we call it
dynamic linkage.
> 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.
Incorrect.
If both function bodies are identical, then there's no need to write a non-
const version.
If there exists both a const version and a non-const version, then this
indicates that one version alters the object, while the other doesn't.
Conclusion: different code.
You could also make the non-const version call the const version, and then
just do something extra.
> 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.
"procedures"? Never heard of them. I've heard of "functions" alright. I must
say I don't... see... your argument, no pun intended.
If you have a function which takes in an object of a certain class, or as
you call it "data structure", then... (actually, it's so simple I'm not even
going to finish this paragraph).
> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.
Bullshit. Vague bullshit.
> C++ lacks automatic memory management and so it encourages copying
> objects around to make manual memory management manageable.
int auto k = 4;
int* auto p_w = new int(4);
> Reference-counting schemes are usually slower than modern garbage
> collectors and also less general.
Which "garbage collector"? "less general" = vague bullshit.
> 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.
I don't see your argument. I've never encountered such.
> 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.
There's books on a lot of things.
> 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.
Define "programmers". I myself don't fit into the inuendo of a definition in
the above.
> 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.
MS-DOS was written in C++. Window XP was written in C++. Linux was written
in C++.
Come to think of it, what *wasn't* written in C++?
> It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.
My opinion differs.
-JKop
"JKop" <····@NULL.NULL> ··························@news.indigo.ie...
>
> > C++ game developers spend a lot of their time debugging corrupted
> > memory. Few, if any, compilers offer completely safe modes.
>
> AKA Retarded mode.
With C++ you can't vary safe/fast mode on per function or per line
basis.
> > You can not even change function definitions while the program is
> > running and see the effects live (the ultimate debugging tool).
>
> Nothing to do with the language. Such a debugging tool could be developed,
> why not develop it?
> I myself wouldn't use it.
Actually, you can change program during execution (at least in VC++
7.1) however in half of cases you have to stop and recompile it.
> > 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.
>
> That's because there's no such thing as "half a program". If you really want this, copy-paste it to another file and just append:
>
> int main(){}
> to the end of it.
Than cut and add "main()" to another file and stop/start program each
time ??? In Lisp you can share intermediate data between small
portions of the program.
> > 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.
>
> Bullshit. Vague bullshit.
You forced to think of types all time. It's kind of unnecessary
foresight in many cases.
> > 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.
>
> Provide an example. I myself forsee no reason or motive to do or have to do > this.
You have to use interpreter for scripting. Hardly It would be
interpreter of C++.
> > 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.
>
> "function objects". Get over it! It's just syntatic sugar!
Really? IMHO they are very limited imitation of closures.
> > C++ programs can not "think" of new code at run-time, and plug that
> > new code into themselves in compiled form. Not easily, anyway.
>
> "think of new code at run-time". That's because it takes intelligence to
> write code, something which computers lack. As for the code coming from
> somewhere else, well it's done extremely easily actually - we call it
> dynamic linkage.
I.e. C++ self-reflection sucks.
> > 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.
>
> Incorrect.
>
> If both function bodies are identical, then there's no need to write a non-
> const version.
>
> If there exists both a const version and a non-const version, then this
> indicates that one version alters the object, while the other doesn't.
> Conclusion: different code.
So "cut and paste" technology is used all time ;-))
> You could also make the non-const version call the const version, and then
> just do something extra.
>
> > 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.
>
> "procedures"? Never heard of them. I've heard of "functions" alright. I must
> say I don't... see... your argument, no pun intended.
> If you have a function which takes in an object of a certain class, or as
> you call it "data structure", then... (actually, it's so simple I'm not even > going to finish this paragraph).
It means that on Lisp you can easily try current piece code to see it
does well and write another small piece. In C++ you forced to write as
much as possible before you start visualize results (maybe because
"edit and continue" doesn't work properly?).
> > C++ lacks automatic memory management and so it encourages copying
> > objects around to make manual memory management manageable.
>
> int auto k = 4;
>
> int* auto p_w = new int(4);
From MSDN:
"The auto storage-class specifier declares an automatic variable, a
variable with a local lifetime. It is the default storage-class
specifier for block-scoped variable declarations
An auto variable is visible only in the block in which it is declared.
Few programmers use the auto keyword in declarations because all
block-scoped objects not explicitly declared with another storage
class are implicitly automatic. Therefore, the following two
declarations are equivalent:
// auto_keyword.cpp
int main()
{
auto int i = 0; // Explicitly declared as auto.
int j = 0; // Implicitly auto.
}
"
Is that automatic memory managment ???
> > Reference-counting schemes are usually slower than modern garbage
> > collectors and also less general.
>
> Which "garbage collector"? "less general" = vague bullshit.
What's the difference ??? Anyway reference-counting is slower than
modern generational GCs.
> > 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.
>
> I don't see your argument. I've never encountered such.
It means no macro. C preprocessor and templates is hardly comparable
with Lisp macro.
> > C++ programs are slow: even though the compilers are good at
> MS-DOS was written in C++. Window XP was written in C++. Linux was written
> in C++.
>
> Come to think of it, what *wasn't* written in C++?
You are mistaken: MS-DOS and Linux were not written in C++ (maybe
because C++ compilers at that time were very buggy). And also very
doubtful that Windows XP core was written in C++.
Many many things were not written in C++.
Lisptracker
In comp.lang.c++ JKop <····@null.null> wrote:
>> C++ game developers spend a lot of their time debugging corrupted
>> memory. Few, if any, compilers offer completely safe modes.
> AKA Retarded mode.
> (inspired response to obvious troll)
What part of "Do not feed the trolls" was hard to understand?
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Christopher Benson-Manica <·····@nospam.cyberspace.org> writes:
>> (inspired response to obvious troll)
> What part of "Do not feed the trolls" was hard to understand?
> Christopher Benson-Manica | I *should* know what I'm talking about - if I
> ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
[I wouldn't normally participate in a flame-infested thread like
this, but since you're so literally asking for for things you need
to know..]
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.
--
Frode Vatvedt Fjeld
> 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
JKop wrote:
> 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.
Depending on the amount of memory and the size of each allocated block
garbage collection can be faster, or manual handling can be faster. If
you have many small to medium sized objects then garbage collection is
faster, otherwise not so. Copious amount of research exist. Start
some where around here:http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
Retarded? It has nothing to do with being retarded. Sometimes the
requirements of a program is such that you cannot predict when a
resource can be freed without designing this into your program
(I can't really think of many examples where this is not the case)
and that can be hard. When GC can sometimes even make your program
faster... No brainer. (And for the reading impaired, I am not
saying... Nah, figure it out yourself)
--
Thomas.
[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?
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
JKop <····@NULL.NULL> writes:
> > C++ game developers spend a lot of their time debugging corrupted
> > memory. Few, if any, compilers offer completely safe modes.
>
> AKA Retarded mode.
>
> > Unsurprisingly, there is a very high failure rate among projects using
> > C++ for modern game development.
>
> There's a 90% failure rate for lions when hunting. They still eat.
>
> I would presume that that "very high failure rate" becomes a bit lower when
> you're dealing with proficient C++ programmers.
>
> > You can not even change function definitions while the program is
> > running and see the effects live (the ultimate debugging tool).
>
> Nothing to do with the language. Such a debugging tool could be developed,
> why not develop it?
>
> I myself wouldn't use it.
>
> > 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.
>
> That's because there's no such thing as "half a program". If you really want
> this, copy-paste it to another file and just append:
>
> int main(){}
>
> to the end of it.
>
> > 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.
>
> Bullshit. Vague bullshit.
>
> > 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.
>
> Provide an example. I myself forsee no reason or motive to do or have to do
> this.
>
> > 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.
>
> "function objects". Get over it! It's just syntatic sugar!
>
> > C++ programs can not "think" of new code at run-time, and plug that
> > new code into themselves in compiled form. Not easily, anyway.
>
> "think of new code at run-time". That's because it takes intelligence to
> write code, something which computers lack. As for the code coming from
> somewhere else, well it's done extremely easily actually - we call it
> dynamic linkage.
>
> > 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.
>
> Incorrect.
>
> If both function bodies are identical, then there's no need to write a non-
> const version.
>
> If there exists both a const version and a non-const version, then this
> indicates that one version alters the object, while the other doesn't.
> Conclusion: different code.
>
> You could also make the non-const version call the const version, and then
> just do something extra.
>
> > 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.
>
> "procedures"? Never heard of them. I've heard of "functions" alright. I must
> say I don't... see... your argument, no pun intended.
>
> If you have a function which takes in an object of a certain class, or as
> you call it "data structure", then... (actually, it's so simple I'm not even
> going to finish this paragraph).
>
> > Constructors and smart pointers make it hard to tell cheap operations
> > from expensive ones.
>
> Bullshit. Vague bullshit.
>
> > C++ lacks automatic memory management and so it encourages copying
> > objects around to make manual memory management manageable.
>
> int auto k = 4;
>
> int* auto p_w = new int(4);
>
> > Reference-counting schemes are usually slower than modern garbage
> > collectors and also less general.
>
> Which "garbage collector"? "less general" = vague bullshit.
>
> > 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.
>
> I don't see your argument. I've never encountered such.
>
> > 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.
>
> There's books on a lot of things.
>
> > 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.
>
> Define "programmers". I myself don't fit into the inuendo of a definition in
> the above.
>
> > 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.
>
> MS-DOS was written in C++. Window XP was written in C++. Linux was written
> in C++.
>
> Come to think of it, what *wasn't* written in C++?
Linux comes to mind.
"JKop" <····@NULL.NULL> wrote in message
··························@news.indigo.ie...
>
>>> Come to think of it, what *wasn't* written in C++?
>>
>> Linux comes to mind.
>
>
> Really? What was it written in?
>
C
Also MSDOS and MS WIndows were developed in C, as far as I know.
Catalin
Catalin Pitis posted:
>
> "JKop" <····@NULL.NULL> wrote in message
> ··························@news.indigo.ie...
>>
>>>> Come to think of it, what *wasn't* written in C++?
>>>
>>> Linux comes to mind.
>>
>>
>> Really? What was it written in?
>>
> C
>
> Also MSDOS and MS WIndows were developed in C, as far as I know.
>
> Catalin
HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa
HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa
ha ha ha
OOOHhhhhhhhhh, it's too much.
Didn't we switch from coal to oil yyeeaarrss ago?
-JKop
"JKop" <····@NULL.NULL> wrote in message
··························@news.indigo.ie...
> Catalin Pitis posted:
>
>>
>> "JKop" <····@NULL.NULL> wrote in message
>> ··························@news.indigo.ie...
>>>
>>>>> Come to think of it, what *wasn't* written in C++?
>>>>
>>>> Linux comes to mind.
>>>
>>>
>>> Really? What was it written in?
>>>
>> C
>>
>> Also MSDOS and MS WIndows were developed in C, as far as I know.
>>
>> Catalin
>
>
>
> HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa
>
> HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa
>
> ha ha ha
>
>
> OOOHhhhhhhhhh, it's too much.
>
>
> Didn't we switch from coal to oil yyeeaarrss ago?
>
>
> -JKop
It seems not :D
Catalin
> Didn't we switch from coal to oil yyeeaarrss ago?
>
Most powerplants run on Coal still (and some crazy countries use Nuclear).
I think oil is just used for cars and trucks and gays.
>
> -JKop
Maahes wrote:
>>Didn't we switch from coal to oil yyeeaarrss ago?
>>
>
> Most powerplants run on Coal still (and some crazy countries use Nuclear).
> I think oil is just used for cars and trucks and gays.
Many run on natural gas.
Note followup.
Paul
"Catalin Pitis" <·············@iquestint.com.renameme> wrote in message
····················@uni-berlin.de...
>
> "JKop" <····@NULL.NULL> wrote in message
> ··························@news.indigo.ie...
>>
>>>> Come to think of it, what *wasn't* written in C++?
>>>
>>> Linux comes to mind.
>>
>>
>> Really? What was it written in?
>>
> C
>
> Also MSDOS and MS WIndows were developed in C, as far as I know.
>
afaik dos was assembler...
Catalin Pitis wrote:
>
> "JKop" <····@NULL.NULL> wrote in message
> ··························@news.indigo.ie...
>>
>>>> Come to think of it, what *wasn't* written in C++?
>>>
>>> Linux comes to mind.
>>
>>
>> Really? What was it written in?
>>
> C
>
> Also MSDOS and MS WIndows were developed in C, as far as I know.
>
> Catalin
You're totally correct in this. But most higher-order toolkits are written
in C++.
BTW: I don't know a single piece of "real" software that was written in LISP
(AFAIK even Emacs only uses LISP as an extension and scripting language:
Something that is really bad bevhaviour according to the original troll ..
eerrh ... poster).
I am also awaiting good examples for LISP 3D-Engines, LISP- OS kernels, LISP
device drivers, LISP text processors or LISP numerical toolkits. Feel free
to copy your whole project source code for these topics to your
news-transfer-daemon /dev/null...
--
To get my real email adress, remove the two onkas
--
Hendrik Belitz
- Abort, Retry, Fthagn? -
> BTW: I don't know a single piece of "real" software that was written in
> LISP (AFAIK even Emacs only uses LISP as an extension and scripting
> language: Something that is really bad bevhaviour according to the
> original troll .. eerrh ... poster).
>
> I am also awaiting good examples for LISP 3D-Engines, LISP- OS kernels,
> LISP device drivers, LISP text processors or LISP numerical toolkits. Feel
> free to copy your whole project source code for these topics to your
> news-transfer-daemon /dev/null...
I don't want to feed the troll, but you're showing some pretty incredible
ignorance. Just go to the "success stories" section of any lisp vendor's
website if you want to find some examples of real applications written in
lisp.
LISP 3D-Engines: None that I know of.
LISP kernels: Plenty. Google for "lisp machine".
LISP device drivers: Same as for kernels.
LISP numerical toolkits: Probably they exist; don't know of any. This is
just a library issue.
Alex
Hendrik Belitz wrote:
> Catalin Pitis wrote:
>
>>
>> "JKop" <····@NULL.NULL> wrote in message
>> ··························@news.indigo.ie...
>>>
>>>>> Come to think of it, what *wasn't* written in C++?
>>>>
>>>> Linux comes to mind.
>>>
>>>
>>> Really? What was it written in?
>>>
>> C
>>
>> Also MSDOS and MS WIndows were developed in C, as far as I know.
>>
>> Catalin
>
> You're totally correct in this. But most higher-order toolkits are written
> in C++.
>
> BTW: I don't know a single piece of "real" software that was written in
> LISP (AFAIK even Emacs only uses LISP as an extension and scripting
> language: Something that is really bad bevhaviour according to the
> original troll .. eerrh ... poster).
>
> I am also awaiting good examples for LISP 3D-Engines, LISP- OS kernels,
> LISP device drivers, LISP text processors or LISP numerical toolkits. Feel
> free to copy your whole project source code for these topics to your
> news-transfer-daemon /dev/null...
>
On 2004-10-25 15:50:36, Hendrik Belitz wrote:
> BTW: I don't know a single piece of "real" software that was written in LISP
What's the color of the sky in your world?
On Mon, 25 Oct 2004 15:50:36 +0200, Hendrik Belitz wrote:
> Catalin Pitis wrote:
>>
>> "JKop" <····@NULL.NULL> wrote in message
>> ··························@news.indigo.ie...
>>>
>>>>> Come to think of it, what *wasn't* written in C++?
Pretty much everything worthwhile.
>>>> Linux comes to mind.
>>>
>>>
>>> Really? What was it written in?
>>>
>> C
>>
>> Also MSDOS and MS WIndows were developed in C, as far as I know.
I doubt it. I'd bet MSDOS was written in assembler.
> You're totally correct in this. But most higher-order toolkits are written
> in C++.
> BTW: I don't know a single piece of "real" software that was written in LISP
I.e., you're ignorant. [By the way, it's spelled "Lisp", not "LISP"]
> (AFAIK even Emacs only uses LISP as an extension and scripting language:
> Something that is really bad bevhaviour according to the original troll ..
> eerrh ... poster).
Which Emacs? Emacs was original TECO macros (hence the name), then
Lisp. (Some) Unix versions are now written in C with (a crufty
ancient) Lisp as "extension language", yes (but there's hardly any
call for your "only": a fair amount of the core functionality is in
Lisp, and there's rather more Lisp than C there)
> I am also awaiting good examples for LISP 3D-Engines, LISP- OS kernels, LISP
> device drivers, LISP text processors or LISP numerical toolkits. Feel free
Google for "Mirai" and "Genera", for starters.
[You C++ types still have a way to go to catch up to 1980's Lisp :-)]
--
Malum est consilium quod mutari non potest -- Publilius Syrus
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Hendrik Belitz wrote:
> BTW: I don't know a single piece of "real" software that was written in LISP
Yahoo Store, originally Viamall, was written in LISP.
But that was before Java.
John Nagle
Animats
JKop wrote:
>>> Come to think of it, what *wasn't* written in C++?
>>
>> Linux comes to mind.
>
>
> Really? What was it written in?
>
>
>
> -JKop
C and assembly. Look at the source for it.
And I don't think MS-DOS could've been written in C++, wasn't that before
C++ was around?
"Joe Laughlin" <·················@boeing.com> writes:
> And I don't think MS-DOS could've been written in C++, wasn't that before
> C++ was around?
The first native C++ compiler I used under DOS was Zortech C++. This
must have been around 1988/1989.
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?
Petter Gustad wrote:
> "Joe Laughlin" <·················@boeing.com> writes:
>
>> And I don't think MS-DOS could've been written in C++,
>> wasn't that before C++ was around?
>
> The first native C++ compiler I used under DOS was
> Zortech C++. This must have been around 1988/1989.
>
> Petter
And MS-DOS was first written in the early 80's.
"Joe Laughlin" <·················@boeing.com> writes:
> Petter Gustad wrote:
> > "Joe Laughlin" <·················@boeing.com> writes:
> >
> >> And I don't think MS-DOS could've been written in C++,
> >> wasn't that before C++ was around?
> >
> > The first native C++ compiler I used under DOS was
> > Zortech C++. This must have been around 1988/1989.
> And MS-DOS was first written in the early 80's.
That was my point...
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?
Petter Gustad <·············@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 strange cult of unixists
at that point.
--
(espen)
Petter Gustad <·············@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.
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote in message news:<··············@merced.netfonds.no>...
> Petter Gustad <·············@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.
·······@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? -
Espen Vestre wrote:
> Petter Gustad <·············@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
JKop wrote:
<snip>
>> 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.
>
> Incorrect.
>
> If both function bodies are identical, then there's no need to write
> a non- const version.
>
> If there exists both a const version and a non-const version, then
> this indicates that one version alters the object, while the other
> doesn't. Conclusion: different code.
<snip>
Actually, it tends to indicate that one version returns a non-const
pointer/reference and the other returns a const pointer/reference.
[Followups trimmed]
Stewart.
JKop <····@NULL.NULL> writes:
> > 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.
>
> Bullshit. Vague bullshit.
By any reasonable standards, C++'s type system is a brain-damaged
throwback to the 1960s. Much better static type systems can be found
in languages like Haskell and ML. Hell, there's even an assembler with
a better type system:
http://www.cs.cornell.edu/talc/
> > 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.
>
> "function objects". Get over it! It's just syntatic sugar!
Yeah, and with just a bit more typing, you've got yourself a Turing
machine. You can do anything you want in C++, so why would you ever
want to switch to a better language?
> > 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.
>
> "procedures"? Never heard of them. I've heard of "functions" alright. I must
> say I don't... see... your argument, no pun intended.
Where do you think the word "function" comes from? It comes from
mathematics, where it has a very well-defined meaning and certain very
well defined properties. One of these properties is that for any
input, it always returns the same output. This particular meaning has
been universally adopted by the computer science community. In almost
all languages (Miranda and Haskell are the only two exceptions I
know), what you call "functions" are actually procedures or
subroutines, in that they can return different outputs for the same
input. This includes pseudo "functional" languages like ML too, since
it has assignment, references and mutable arrays.
Vladimir
"Neo-LISPer" <··········@yahoo.com> wrote in message
···················@yahoo.com...
> Hey
>
> 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.
> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.
The alternative, garbage collection, tends to corrupt memory too. Have you
heard of a high-availability Visual Basic program?
Game programmers need efficient and deterministic garbage collection. If
they don't code it themselves, following healthy styles, they will corrupt
memory.
> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.
That's because there's a high failure rate period, and most games use C++.
> You can not even change function definitions while the program is
> running and see the effects live (the ultimate debugging tool).
There are those who don't need to debug. The game programming industry has
only begun to adopt unit testing in a very few shops.
> 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.
Test isolation would help that. If objects are decoupled, you can write a
test that plays with only one of them.
Playing with unit test cases, and adding them very easily, is a great way to
preserve all those little experiments, and convert them into constraints.
> 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.
> 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.
You make that sound like a bad thing. Most programs have two languages
(consider the glorious union of VB and SQL). Games need a scripting layer to
decouple designing the game play from its engine. Most other applications
with an engine use this model, too.
> 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.
So what? It also makes the Prototype Pattern a pain in the nuts. These
issues are not in the domain, they are just implementation alternatives.
> 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?
> 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.
It sounds like you need to tell us you are less than perfectly adept at C++.
Have you used it for games?
> 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.
That's because you are familiar with Lisp.
> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.
All cheap and expensive operations are impossible to predict and hard to
tell apart. Profile.
> 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.
Prefer pass-by-reference above all other kinds, because its cognitively
efficient and usually execution efficient.
> 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++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
disturbs me most.
> 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.
How could that complaint be specific to C++?
> 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.
Games must have high performance, so C++ is the leading language for now.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Phlip wrote:
> C++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
> disturbs me most.
stroustrup probably meant to put that in, but there would have been way
to many issues with null mind pointers.
indi
Disclaimer: I don't dislike C++, but the responses to the OP's (mostly
valid) criticisms are pretty uninformed.
> The alternative, garbage collection, tends to corrupt memory too. Have you
> heard of a high-availability Visual Basic program?
>
> Game programmers need efficient and deterministic garbage collection. If
> they don't code it themselves, following healthy styles, they will corrupt
> memory.
Erm no, garbage collection does not corrupt memory unless the garbage
collector is buggy. Have you ever seen a VB program segfault? If you have
special requirements for garbage collection, you just need a garbage
collector tuned to your requirements (e.g. the real-time garbage collectors
available in some implementations of various languages).
>> 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.
>
> Test isolation would help that. If objects are decoupled, you can write a
> test that plays with only one of them.
>
> Playing with unit test cases, and adding them very easily, is a great way
> to preserve all those little experiments, and convert them into
> constraints.
Unit tests help you to /test/ code, but not to debug it. When you've found a
bug, you still need to do the work of actually fixing the code. This is
much easier if you have an environment which supports dynamic redefinition
and interative compilation.
>> 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.
Not using the static type system would entail not using C++ (unless you
intend to represent all your data as void * and fill your program with
casts).
>> 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.
>
> You make that sound like a bad thing. Most programs have two languages
> (consider the glorious union of VB and SQL). Games need a scripting layer
> to decouple designing the game play from its engine. Most other
> applications with an engine use this model, too.
Clearly a separate scripting language is not desirable if you can avoid it
(performance and code overhead from interfacing the two languages, being
constrained by an enforced separation between interelated parts of the
program, etc.) It is difficult to avoid having a separate scripting
language in C++ because it doesn't support incremental compilation. It's
certainly not impossible to avoid it (Half-Life doesn't have one, for
example), but you pay the price: make a trivial mistake in your Half-Life
mod code and the fix-reload-test cycle can be a couple of minutes long.
>> 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.
>
> That's because you are familiar with Lisp.
Indeed, it's much easier to express complex data structures in Lisp.
>> 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.
>
> So what? It also makes the Prototype Pattern a pain in the nuts. These
> issues are not in the domain, they are just implementation alternatives.
This makes no sense. Higher order functions are a win, period. Function
objects are just less powerful than higher order functions (assuming that
these functions are closures). If you've been paying attention to R&D in
programming languages for the past 20-30 years, you'll notice that higher
order functions are one abstraction mechanism that just about every new
language has adopted (often prior to the development of C++). They're so
useful that some people have invested a lot of time into hacking some kind
of HOF facility into C++ (c.f. the Boost Lambda Library).
>> 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.
>
> Prefer pass-by-reference above all other kinds, because its cognitively
> efficient and usually execution efficient.
"Usually" being the operative word. You're also missing the OP's point
completely. If you pass by reference, you enormously increase the
complexity of your memory management code. Sure, C++ has lots of ways to
encapsulate this complexity, but you still have to deal with it, and the
common methods of doing this amount to using a buggy and rather inefficient
GC.
Alex
Phlip wrote:
>
> "Neo-LISPer" <··········@yahoo.com> wrote in message
> ···················@yahoo.com...
>> Hey
>>
>> 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.
>
>> C++ game developers spend a lot of their time debugging corrupted
>> memory. Few, if any, compilers offer completely safe modes.
>
> The alternative, garbage collection, tends to corrupt memory too. Have you
> heard of a high-availability Visual Basic program?
>
> Game programmers need efficient and deterministic garbage collection. If
> they don't code it themselves, following healthy styles, they will corrupt
> memory.
>
>> Unsurprisingly, there is a very high failure rate among projects using
>> C++ for modern game development.
>
> That's because there's a high failure rate period, and most games use C++.
>
>> You can not even change function definitions while the program is
>> running and see the effects live (the ultimate debugging tool).
>
> There are those who don't need to debug. The game programming industry has
> only begun to adopt unit testing in a very few shops.
>
>> 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.
>
> Test isolation would help that. If objects are decoupled, you can write a
> test that plays with only one of them.
>
> Playing with unit test cases, and adding them very easily, is a great way
> to preserve all those little experiments, and convert them into
> constraints.
>
>> 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.
>
>> 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.
>
> You make that sound like a bad thing. Most programs have two languages
> (consider the glorious union of VB and SQL). Games need a scripting layer
> to decouple designing the game play from its engine. Most other
> applications with an engine use this model, too.
>
>> 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.
>
> So what? It also makes the Prototype Pattern a pain in the nuts. These
> issues are not in the domain, they are just implementation alternatives.
>
>> 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?
>
>> 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.
>
> It sounds like you need to tell us you are less than perfectly adept at
> C++. Have you used it for games?
>
>> 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.
>
> That's because you are familiar with Lisp.
>
>> Constructors and smart pointers make it hard to tell cheap operations
>> from expensive ones.
>
> All cheap and expensive operations are impossible to predict and hard to
> tell apart. Profile.
>
>> 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.
>
> Prefer pass-by-reference above all other kinds, because its cognitively
> efficient and usually execution efficient.
>
>> 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++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
> disturbs me most.
>
>> 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.
>
> How could that complaint be specific to C++?
>
>> 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.
>
> Games must have high performance, so C++ is the leading language for now.
>
Alex Drummond wrote:
>>Prefer pass-by-reference above all other kinds, because its cognitively
>>efficient and usually execution efficient.
>
>
> "Usually" being the operative word. You're also missing the OP's point
> completely. If you pass by reference, you enormously increase the
> complexity of your memory management code. Sure, C++ has lots of ways to
> encapsulate this complexity, but you still have to deal with it, and the
> common methods of doing this amount to using a buggy and rather inefficient
> GC.
i'm sorry, you don't know what a c++ reference is.
you do not increase the difficulty of memory management with c++
references, unless you're straddling two different threads. you don't
have to manage the memory of references at all - they are, after all,
references. references have no overhead either.
there is no complexity, and there is no encapsulation of c++ references
that I have ever heard of. nor can i see any valid reasons for it.
you may be thinking of some other kind of reference, as in
reference-counted references, aka smart pointers.
indi
I do know what a C++ reference is. I was using the term rather ambiguously
between a reference in general (i.e. a C++ pointer or a C++ reference) and
an actual C++ reference, because it doesn't make much difference.
References increase memory management complexity just as much as pointers
do; the only difference is that you can't really do any memory management
with a reference, so it's only /correctly/ useable in bits of code which
can take a reference/pointer to a data structure without worrying how it
has been allocated. This does not in any way simplify the management of
references (general concept) in C++ -- you still have to think about who
"owns" the memory that is referenced (general concept), and either keep all
the details in your head, or use C++ smart pointers along with an
inefficient reference-counting method or some such. If it was possible to
write real-world C++ programs using only references and not pointers, I
would take your point, but the fact remains that passing by
reference/pointer invloves more thinking about memory management than
passing by value, which cannot possibly cause a memory leak (unless you
have something funky in a copy constructor).
To move away from the technicalities, you have basically three memory
management options in C++:
1) Pass by value. Sometimes inefficient, easy to understand.
2) Pass by pointer/reference. Usually efficient, memory management becomes
complex and scattered throughout the code.
3) Pass by smart pointer. Easy to understand, but usually more overhead than
a GC.
(This is not to say that one of these methods must be used exclusively
throughout a program).
Alex
Mark A. Gibbs wrote:
>
> Alex Drummond wrote:
>
>>>Prefer pass-by-reference above all other kinds, because its cognitively
>>>efficient and usually execution efficient.
>>
>>
>> "Usually" being the operative word. You're also missing the OP's point
>> completely. If you pass by reference, you enormously increase the
>> complexity of your memory management code. Sure, C++ has lots of ways to
>> encapsulate this complexity, but you still have to deal with it, and the
>> common methods of doing this amount to using a buggy and rather
>> inefficient GC.
>
> i'm sorry, you don't know what a c++ reference is.
>
> you do not increase the difficulty of memory management with c++
> references, unless you're straddling two different threads. you don't
> have to manage the memory of references at all - they are, after all,
> references. references have no overhead either.
>
> there is no complexity, and there is no encapsulation of c++ references
> that I have ever heard of. nor can i see any valid reasons for it.
>
> you may be thinking of some other kind of reference, as in
> reference-counted references, aka smart pointers.
>
> indi
Alex Drummond wrote:
> I do know what a C++ reference is. I was using the term rather ambiguously
> between a reference in general (i.e. a C++ pointer or a C++ reference) and
> an actual C++ reference, because it doesn't make much difference.
ah, but it does, because there is a difference between general
references and c++ references, and that difference invalidates your
entire argument.
> References increase memory management complexity just as much as pointers
> do; the only difference is that you can't really do any memory management
> with a reference, so it's only /correctly/ useable in bits of code which
> can take a reference/pointer to a data structure without worrying how it
> has been allocated. This does not in any way simplify the management of
> references (general concept) in C++ -- you still have to think about who
> "owns" the memory that is referenced (general concept), and either keep all
> the details in your head, or use C++ smart pointers along with an
> inefficient reference-counting method or some such.
c++ references are non-owning references ("weak" references if you
will). therefore, no management required, or even really logical.
you are correct when you say that you do have to be concerned that the
underlying data does not go out of scope before the reference. however,
in practical code, all references are always valid. unless you perform
some acrobatics (ie, bad code design) or are dealing with threading
issues, references will naturally go out of scope before the "real"
object. there is no "management". the only things you do to references
is make them and use them. you can't copy them around really.
you really never need to know how data was allocated or where it is in
memory (and even which memory it is in) to work with it in c++, unless
you are allocating or freeing it, and that responsibility should be in
the same place. but by convention, when data is passed or returned by
reference, it is not the responsibility of any client code.
> If it was possible to
> write real-world C++ programs using only references and not pointers, I
> would take your point,
of course it's possible. but it's also possible to build an airplane
from scratch using only a screwdriver. it's just not really smart, or easy.
using references only is actually easy to do, it just unnecessarily
limits your design options.
> but the fact remains that passing by
> reference/pointer invloves more thinking about memory management than
> passing by value, which cannot possibly cause a memory leak (unless you
> have something funky in a copy constructor).
references cannot cause memory leaks.
when passing bare pointers around (which i personally frown on), you
have to make clear in documentation who owns the pointer. otherwise,
yes, you can end up with memory leaks. or, you can do it the right way
and pass smart pointers around.
> To move away from the technicalities, you have basically three memory
> management options in C++:
>
> 1) Pass by value. Sometimes inefficient, easy to understand.
> 2) Pass by pointer/reference. Usually efficient, memory management becomes
> complex and scattered throughout the code.
false. memory management becomes complex and scattered if you make it
complex and scatter it. the use or non-use of pointers or references
does not cause or solve that.
in good design, memory is freed by the same entity that allocated it.
the use of pointers or references does not invalidate good design. it
allows you to if you so choose, and sometimes that's a valid design
decision. but if your memory management is scattered and out of control,
that's your fault, not any language's.
> 3) Pass by smart pointer. Easy to understand, but usually more overhead than
> a GC.
i honestly have never heard that before in my life. please show me
numbers. here are mine, off a paper advocating garbage collection
(http://www.lisp-p.org/wgc/) no less:
manual gc type
0.0 0.0 static allocation
0.0 0.9 individual blocks
0.9 16.3 individual lists
0.3 15.3 blocks in random order (general case)
50 times slower. hm.
now, this page (http://www.boost.org/libs/smart_ptr/smarttests.htm)
shows that the worst case performance for smart pointers is about 3
times slower than naked pointers. therefore, smart pointers are still
about 17 times faster than garbage collection. again, please show me
your numbers.
the smart pointer included with my compiler std::auto_ptr<T> takes up
exactly the same amout of memory as a bare pointer. copying it costs one
4 byte stack push, one function call, one 4-byte memory access and one
4-byte memory write. interleaved on a modern processor, those operations
(according to my estimate) would cost the same a simple bare-pointer
copy in practical usage (taking things like return-value optimization
into account). in other words, there should be no measurable difference.
now, smart pointer is a category, not a specific type, so it's quite
possible that there are smart pointers out there that are more expensive
than a given garbage collector. but show me some numbers. i don't see
either std::auto_ptr<T> or std::tr1::shared_ptr<T> (aka
boost::shared_ptr<T>) being one of them.
one thing that most gc advocates i've talked to don't seem to get is
that when using garbage collection, *all* pointers are smart pointers.
the only difference between gc smart pointers and traditional c++ smart
pointers is that when they go out of scope, c++ smart pointers free the
memory, whereas gc smart pointers just indicate (doesn't matter how they
do it) to the garbage collector that the memory can be freed at its
convenience. of course, smart pointers in c++ could do the same thing,
and i have one that does. garbage collection is just a special case of
the smart pointer design pattern.
besides, with a garbage collected-only language, you can't practically
implement raii, and i think that's a serious flaw.
there are no perfect solutions, but by cobbling together a collection of
imperfect solutions, you can still do pretty well. i don't consider
garbage collection "new, untested, & questionable", as this page
(http://www.lisp-p.org/wgc/) bizarrely claims "C & C++ programmers" do.
if it is the best solution, i will use it. if it's not, i'll use
something else. but not having options sucks.
indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> one thing that most gc advocates i've talked to don't seem to get is
> that when using garbage collection, *all* pointers are smart
> pointers. the only difference between gc smart pointers and
> traditional c++ smart pointers is that when they go out of scope, c++
> smart pointers free the memory, whereas gc smart pointers just
> indicate (doesn't matter how they do it) to the garbage collector that
> the memory can be freed at its convenience. of course, smart pointers
> in c++ could do the same thing, and i have one that does. garbage
> collection is just a special case of the smart pointer design pattern.
This paragraph demonstrates a serious misunderstanding of the
difference between scope, extent, and the way GC works. I suppose
that it is understandable that a C++ programmer might get scope and
extent confused (I certainly did when all I knew was C and C++). I
will try to make my explanation simple:
The scope of a variable, as you probably already know, is the portions
of source code from which it is accessible. The extent of a variable
is the period of time during execution of the program when the
variable is accessible. A Garbage Collector is concerned with the
extent of variables (and other places where objects can be referenced
from).
Simple distinction: scope is a source-code concept; extent is a
run-time concept.
In a C or C++ program, when you declare a local variable, what you get
is called a "lexically scoped, dynamic extent" variable. This means
that the scope of the variable is determined by lexical markers ("{"
and "}" here) and the variable only lasts as long as program control
is within this same scope. This happens to correspond to the
implementation of variables by storing them on the stack.
In a Common Lisp, Scheme, Smalltalk, Ruby, ML, or Haskell (among
others) program, when you declare a local variable, what you get is a
"lexically scoped, indefinite extent" variable. Once again, the scope
of the variable is determined by some lexical marker, but now the
extent is not known. It is no longer a simple matter to determine
when the variable is not needed any more. Sometimes it can be proven
that a variable is dynamic extent, or it may be declared that way, but
otherwise it must be assumed to be indefinite extent.
In C there is a concept of a "static" variable to a function. This
variable also has "indefinite extent."
In addition, Common Lisp also has the notion of an "indefinite scope,
dynamic extent" variable. This is often referred to as a "dynamically
scoped" variable, but this is a misnomer. Common Lisp calls these
"special variables" to distinguish them from normal lexically-scoped
variables, and they must be declared special before use.
High-level languages use lexically scoped, indefinite extent variables
because of a useful concept known as higher-order functions.
Higher-order functions are functions that can treat functions as
normal objects. When combined with lexical scope, this allows
variables to be "closed over" by inner functions which may be passed
to other functions or returned. If a variable is "closed over" by a
function that is returned from a function, then that variable cannot
go away, because that function may still need it later on. Hence,
"indefinite extent."
The simplest way to manage these indefinite extent variables is to use
Garbage Collection. When the GC is invoked, it locates all live,
accessible objects and treats the rest of the heap as free space.
There are a number of ways of doing this, such as marking live objects
somehow as you trace them, or copying them over into a new space. The
primary difference between GC and reference-counting is that
reference-counting must do book-keeping everytime a variable or a
reference is mutated, and GC does not.
There is no such thing as a "GC smart pointer," as evidenced by the
Boehm conservative collector which works on C programs. The closest
concept to a smart pointer would be the use of a bit which categorizes
a machine word as either a pointer or an integer, when you use a
precise collector (as opposed to a conservative collector). But this
occurs at a level below the actual language semantics; it is not
visible to the programmer.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish <··········@cmu.edu> writes:
> In a C or C++ program, when you declare a local variable, what you get
> is called a "lexically scoped, dynamic extent" variable.
> In a Common Lisp, Scheme, Smalltalk, Ruby, ML, or Haskell (among
> others) program, when you declare a local variable, what you get is a
> "lexically scoped, indefinite extent" variable.
Careful, remember that variables have scope, but not extent. Objects
have extent. Just nitpicking on the terminology because the concepts are
already conflated in the average C/C++ programmer's mind.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> Careful, remember that variables have scope, but not extent. Objects
> have extent. Just nitpicking on the terminology because the concepts are
> already conflated in the average C/C++ programmer's mind.
Bindings have extent. But I didn't want to introduce yet another
piece of terminology.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish <··········@cmu.edu> writes:
> Rahul Jain <·····@nyct.net> writes:
>> Careful, remember that variables have scope, but not extent. Objects
>> have extent. Just nitpicking on the terminology because the concepts are
>> already conflated in the average C/C++ programmer's mind.
>
> Bindings have extent. But I didn't want to introduce yet another
> piece of terminology.
Sorry, very true, but it sounded like you were talking about the object
that happened to be bound when you were talking about indefinite extent,
not about the binding itself.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> ah, but it does, because there is a difference between general
> references and c++ references, and that difference invalidates your
> entire argument.
No it doesn't.
> c++ references are non-owning references ("weak" references if you
> will). therefore, no management required, or even really logical.
No management is /possible/. If you use a reference incorrectly, management
might be /required/, but not actually performed. Say you have a function
which returns a reference to a newly allocated array (this is obviously a
dreadful thing to do, but you could do it) -- you would get a memory leak.
C++ itself does not stop you writing code like this. Hence, you still have
to think about memory management when you write code using references, if
only to say: "right, it's ok to use a reference instead of a pointer here".
> however, in practical code, all references are always valid. unless you
perform
> some acrobatics (ie, bad code design) or are dealing with threading
> issues, references will naturally go out of scope before the "real"
> object. there is no "management". the only things you do to references
> is make them and use them. you can't copy them around really.
I agree. But it's not trivial to use references correctly. You have to be
able to prove to yourself that what you actually want is a weak reference
to some data before you can be sure that you are not introducing memory
allocation bugs. It's not hard to do this, but you're still thinking about
memory management.
All this discussion is really missing the point anyway. Let's say for the
sake of argument that everything you've said re references is correct. You
still have exactly the difficulties I described when you're using pointers
in C++ -- you can either have complex memory management code, or you can
use inefficient reference counting (boradly speaking, there is obviously a
middle ground, and in simple programs memory management isn't too hard).
>> If it was possible to
>> write real-world C++ programs using only references and not pointers, I
>> would take your point,
>
> of course it's possible. but it's also possible to build an airplane
> from scratch using only a screwdriver. it's just not really smart, or
> easy.
That's exactly my point. Pointers (if not references) make memory management
hard. Writing C++ programs without using pointers is painful.
> when passing bare pointers around (which i personally frown on), you
> have to make clear in documentation who owns the pointer. otherwise,
> yes, you can end up with memory leaks. or, you can do it the right way
> and pass smart pointers around.
Yes, and to get back to what I was saying, smart pointers are not as
efficient as a good GC. This is, I emphasise, different from saying that a
program which uses smart pointers in places is less efficient than the same
program using a GC.
> in good design, memory is freed by the same entity that allocated it.
> the use of pointers or references does not invalidate good design.
In a simple program this is possible. You can't seriously be suggesting that
this little nugget of design wisdom (wise as it is) is going to make
programming in C++ almost as easy as programming in a language with a GC.
In my personal experience this just isn't the case (and I'm perfectly
capable of using smart pointers, etc., when it makes sense).
>> 3) Pass by smart pointer. Easy to understand, but usually more overhead
>> than a GC.
>
> i honestly have never heard that before in my life. please show me
> numbers. here are mine, off a paper advocating garbage collection
Reference counting is a really poor garbage collection method (both in terms
of performance and because of the problem of circular references). If a
large portion of your program uses reference counting, it will be less
efficient than the same program in a comparable GC'd language (unless the
comparable GC'd language is slower than C++ for other reasons, of course --
often the case).
> now, this page (http://www.boost.org/libs/smart_ptr/smarttests.htm)
> shows that the worst case performance for smart pointers is about 3
> times slower than naked pointers. therefore, smart pointers are still
> about 17 times faster than garbage collection. again, please show me
> your numbers.
If this statement were remotely true, GC'd languages would use smart
pointers (which usually means reference counting) and not generational GC.
Most don't -- certainly not serious compilers like javac or cmucl. I didn't
read the paper very carefully, but it appeared to be comparing GC to manual
memory management in a limited variety of test cases. Smart pointers are
not really manual memory management; they're a poorly implemented GC
extension to the language. If you don't use them very often, you may get
better overall performance since you'd have 90% manual memory management
and 10% inefficient automatic GC (or something like that). Also, consider
space efficiency, in which reference counting quite obviously loses (like
everything here, this can be a minor or major issue depending on the
program you're writing). The way you compute the 17x figure is not
completely unreasonable, but given that it's a pretty crude combination of
results from two different tests both chosen to support a particular
argument, we shouldn't be too surprised if it's completely wrong. Once
again: if smart pointers are so fast, GC'd languages would use reference
counting and get roughly the same performance; in reality most don't.
IMO there's really no point in throwing around figures in a discussion about
GC performance. There are too many factors. I accept that manual memory
management is faster than GC in most programs, but when memory management
gets hairy, reference counting smart pointers are a pretty inefficient way
of getting automatic memory management. In these cases, a real,
non-reference-counting GC is likely to perform better, if only because it
will be more thoroughly tested and integrated with the language.
Alex
Mark A. Gibbs wrote:
>
> Alex Drummond wrote:
>
>> I do know what a C++ reference is. I was using the term rather
>> ambiguously between a reference in general (i.e. a C++ pointer or a C++
>> reference) and an actual C++ reference, because it doesn't make much
>> difference.
>
> ah, but it does, because there is a difference between general
> references and c++ references, and that difference invalidates your
> entire argument.
>
>> References increase memory management complexity just as much as pointers
>> do; the only difference is that you can't really do any memory management
>> with a reference, so it's only /correctly/ useable in bits of code which
>> can take a reference/pointer to a data structure without worrying how it
>> has been allocated. This does not in any way simplify the management of
>> references (general concept) in C++ -- you still have to think about who
>> "owns" the memory that is referenced (general concept), and either keep
>> all the details in your head, or use C++ smart pointers along with an
>> inefficient reference-counting method or some such.
>
> c++ references are non-owning references ("weak" references if you
> will). therefore, no management required, or even really logical.
>
> you are correct when you say that you do have to be concerned that the
> underlying data does not go out of scope before the reference. however,
> in practical code, all references are always valid. unless you perform
> some acrobatics (ie, bad code design) or are dealing with threading
> issues, references will naturally go out of scope before the "real"
> object. there is no "management". the only things you do to references
> is make them and use them. you can't copy them around really.
>
> you really never need to know how data was allocated or where it is in
> memory (and even which memory it is in) to work with it in c++, unless
> you are allocating or freeing it, and that responsibility should be in
> the same place. but by convention, when data is passed or returned by
> reference, it is not the responsibility of any client code.
>
>> If it was possible to
>> write real-world C++ programs using only references and not pointers, I
>> would take your point,
>
> of course it's possible. but it's also possible to build an airplane
> from scratch using only a screwdriver. it's just not really smart, or
> easy.
>
> using references only is actually easy to do, it just unnecessarily
> limits your design options.
>
>> but the fact remains that passing by
>> reference/pointer invloves more thinking about memory management than
>> passing by value, which cannot possibly cause a memory leak (unless you
>> have something funky in a copy constructor).
>
> references cannot cause memory leaks.
>
> when passing bare pointers around (which i personally frown on), you
> have to make clear in documentation who owns the pointer. otherwise,
> yes, you can end up with memory leaks. or, you can do it the right way
> and pass smart pointers around.
>
>> To move away from the technicalities, you have basically three memory
>> management options in C++:
>>
>> 1) Pass by value. Sometimes inefficient, easy to understand.
>> 2) Pass by pointer/reference. Usually efficient, memory management
>> becomes complex and scattered throughout the code.
>
> false. memory management becomes complex and scattered if you make it
> complex and scatter it. the use or non-use of pointers or references
> does not cause or solve that.
>
> in good design, memory is freed by the same entity that allocated it.
> the use of pointers or references does not invalidate good design. it
> allows you to if you so choose, and sometimes that's a valid design
> decision. but if your memory management is scattered and out of control,
> that's your fault, not any language's.
>
>> 3) Pass by smart pointer. Easy to understand, but usually more overhead
>> than a GC.
>
> i honestly have never heard that before in my life. please show me
> numbers. here are mine, off a paper advocating garbage collection
> (http://www.lisp-p.org/wgc/) no less:
>
> manual gc type
> 0.0 0.0 static allocation
> 0.0 0.9 individual blocks
> 0.9 16.3 individual lists
> 0.3 15.3 blocks in random order (general case)
>
> 50 times slower. hm.
>
> now, this page (http://www.boost.org/libs/smart_ptr/smarttests.htm)
> shows that the worst case performance for smart pointers is about 3
> times slower than naked pointers. therefore, smart pointers are still
> about 17 times faster than garbage collection. again, please show me
> your numbers.
>
> the smart pointer included with my compiler std::auto_ptr<T> takes up
> exactly the same amout of memory as a bare pointer. copying it costs one
> 4 byte stack push, one function call, one 4-byte memory access and one
> 4-byte memory write. interleaved on a modern processor, those operations
> (according to my estimate) would cost the same a simple bare-pointer
> copy in practical usage (taking things like return-value optimization
> into account). in other words, there should be no measurable difference.
>
> now, smart pointer is a category, not a specific type, so it's quite
> possible that there are smart pointers out there that are more expensive
> than a given garbage collector. but show me some numbers. i don't see
> either std::auto_ptr<T> or std::tr1::shared_ptr<T> (aka
> boost::shared_ptr<T>) being one of them.
>
> one thing that most gc advocates i've talked to don't seem to get is
> that when using garbage collection, *all* pointers are smart pointers.
> the only difference between gc smart pointers and traditional c++ smart
> pointers is that when they go out of scope, c++ smart pointers free the
> memory, whereas gc smart pointers just indicate (doesn't matter how they
> do it) to the garbage collector that the memory can be freed at its
> convenience. of course, smart pointers in c++ could do the same thing,
> and i have one that does. garbage collection is just a special case of
> the smart pointer design pattern.
>
> besides, with a garbage collected-only language, you can't practically
> implement raii, and i think that's a serious flaw.
>
> there are no perfect solutions, but by cobbling together a collection of
> imperfect solutions, you can still do pretty well. i don't consider
> garbage collection "new, untested, & questionable", as this page
> (http://www.lisp-p.org/wgc/) bizarrely claims "C & C++ programmers" do.
> if it is the best solution, i will use it. if it's not, i'll use
> something else. but not having options sucks.
>
> indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> one thing that most gc advocates i've talked to don't seem to get is
> that when using garbage collection, *all* pointers are smart
> pointers. the only difference between gc smart pointers and
> traditional c++ smart pointers is that when they go out of scope, c++
> smart pointers free the memory, whereas gc smart pointers just
> indicate (doesn't matter how they do it) to the garbage collector that
> the memory can be freed at its convenience. of course, smart pointers
> in c++ could do the same thing, and i have one that does. garbage
> collection is just a special case of the smart pointer design pattern.
This is pretty much totally incorrect and shows a stunning lack of
understanding of how gc works (even obsolete designs, let alone state
of the art generational collectors). It also is a good indication of
why much of what else you say is confused and otherwise misguided.
If you want to spend cycles in a discussion of this topic, I strongly
suggest you get a book[1] on gc and read it first. At the very least
you will have a much better chance of not being dismissed as a kook.
/Jon
1. Suggestion: http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html
--
'j' - a n t h o n y at romeo/charley/november com
Hello!
Mark A. Gibbs <···········@rogers.com_x> wrote:
>c++ references are non-owning references ("weak" references if you
>will). therefore, no management required, or even really logical.
>you are correct when you say that you do have to be concerned that the
>underlying data does not go out of scope before the reference. however,
>in practical code, all references are always valid. unless you perform
>some acrobatics (ie, bad code design) or are dealing with threading
>issues, references will naturally go out of scope before the "real"
>object. there is no "management". the only things you do to references
>is make them and use them. you can't copy them around really.
Or you're just doing a typo-like mistake, as in
class A {
public:
explicit A(const std::string& x) : x(x) {}
protected:
const std::string& x;
// ^ oops, intention was the same w/o the &
};
A* make_a()
{
return (new A("foo"));
// oops, temporary std::string gets destroyed before we return,
// the A object contains a dangling reference
}
int main()
{
std::auto_ptr<A> x(make_a());
// do something with x
}
Of course it was just a typo. Just a typo that can be horrendous to
debug.
>[...]
>> but the fact remains that passing by
>> reference/pointer invloves more thinking about memory management than
>> passing by value, which cannot possibly cause a memory leak (unless you
>> have something funky in a copy constructor).
>references cannot cause memory leaks.
^ add "alone"
No, but dangling references are easily built.
>[...]
>in good design, memory is freed by the same entity that allocated it.
>the use of pointers or references does not invalidate good design. it
>allows you to if you so choose, and sometimes that's a valid design
>decision. but if your memory management is scattered and out of control,
>that's your fault, not any language's.
So if you need to pass around things, like
A B
is created (doesn't exist yet)
creates x
is created
---- pass on x ->
now needs the x
is destroyed
lives on
you have to agree on a discipline of managing x, or you copy it over,
so A destroys its copy and B manages its own copy. The latter may not
always be viable, because things might rely on the identity of x.
If the pattern how x is transferred or not transferred, you can't just
say "ok, A creates x, B destroys it always".
>[...]
>the smart pointer included with my compiler std::auto_ptr<T> takes up
>exactly the same amout of memory as a bare pointer. copying it costs one
>4 byte stack push, one function call, one 4-byte memory access and one
>4-byte memory write. interleaved on a modern processor, those operations
>(according to my estimate) would cost the same a simple bare-pointer
>copy in practical usage (taking things like return-value optimization
>into account). in other words, there should be no measurable difference.
auto_ptr isn't a smart pointer. It's quite dumbass, not even viable
for containers at all.
>[...]
>besides, with a garbage collected-only language, you can't practically
>implement raii, and i think that's a serious flaw.
You don't need raii then, as most raii is about memory, and the rest
can be handled with good macro facilities (see Common Lisp's
with-open-file for an example) or higher order functions.
>[...]
Kind regards,
Hannah.
Hannah Schroeter wrote:
> Or you're just doing a typo-like mistake, as in
>
> class A {
> public:
> explicit A(const std::string& x) : x(x) {}
>
> protected:
> const std::string& x;
> // ^ oops, intention was the same w/o the &
> };
>
> A* make_a()
> {
> return (new A("foo"));
> // oops, temporary std::string gets destroyed before we return,
> // the A object contains a dangling reference
> }
>
> int main()
> {
> std::auto_ptr<A> x(make_a());
> // do something with x
> }
>
> Of course it was just a typo. Just a typo that can be horrendous to
> debug.
you could just as easily create nightmare typo scenarios in any
language, including plain english. that example is plainly a careless
mistake. no one and no language can promise that some idiot won't come
along and do something stupid to muck everything up.
incidently, make_a() should probably return an auto_ptr<A>.
>>references cannot cause memory leaks.
>
> ^ add "alone"
>
> No, but dangling references are easily built.
oh yes, but by following some simple guidelines they can be just as
easily avoided. i honestly cannot remember the last time i had a
dangling reference crop up in my code.
>>in good design, memory is freed by the same entity that allocated it.
>>the use of pointers or references does not invalidate good design. it
>>allows you to if you so choose, and sometimes that's a valid design
>>decision. but if your memory management is scattered and out of control,
>>that's your fault, not any language's.
>
>
> So if you need to pass around things, like
>
> A B
> is created (doesn't exist yet)
> creates x
>
> is created
> ---- pass on x ->
> now needs the x
> is destroyed
> lives on
>
> you have to agree on a discipline of managing x, or you copy it over,
> so A destroys its copy and B manages its own copy. The latter may not
> always be viable, because things might rely on the identity of x.
i said good design. this is horrendous design.
to put it in concrete terms:
Oven Furnace
is built (doesn't exist yet)
contains it's own thermostat
is created
----- give thermostat to furnace --->
now needs the thermostat
is destroyed
lives on
(with the oven's thermostat)
does that make logical sense?
furnace would be free to put the thermostat into any kind of state that
may be invalid within the context of oven, or vice-versa (you set the
oven to 275� and your house ignites).
but let's say for argument's sake that you did have to have a shared
object and that you could not be sure of it's lifetime.
std::tr1::shared_ptr (aka boost::shared_ptr).
> If the pattern how x is transferred or not transferred, you can't just
> say "ok, A creates x, B destroys it always".
again, shared_ptr. but c++ is more suited to a more deterministic
problem domain. vaguely allocating and tossing memory around with no
concept of ownership or responsibility isn't a good idea in tighter
architectures, or even in more expansive architectures where you want
close control of resources. if memory is cheap and plentiful, then sure,
but then c++ may not be the best tool for the job.
> auto_ptr isn't a smart pointer. It's quite dumbass, not even viable
> for containers at all.
of course auto_ptr is a smart pointer, it's just a smart pointer with a
very specific problem domain. it's specifically for the purpose of
transfer of ownership (as i mention above, c++ tends towards more
deterministic programs).
"smart pointer" is a family of solutions, not a specific solution.
boost::scoped_ptr has an even narrower problem domain, but i still find
it occasionally useful - although auto_ptr does the same job and more at
about the same cost.
>>besides, with a garbage collected-only language, you can't practically
>>implement raii, and i think that's a serious flaw.
>
>
> You don't need raii then, as most raii is about memory, and the rest
> can be handled with good macro facilities (see Common Lisp's
> with-open-file for an example) or higher order functions.
memory is only a very, very small part of raii. the first "r" is
resource - and resource can be anything at all. in fact, in my code, i
probably use it most often for synchronization.
no matter what happens, i can be assured that all resources will be
properly released. that is, for any possible code path, including those
that i cannot predict, and including all exceptional code paths (short
of an absolute emergency (ie. crash)), the resource will be properly
cleaned up. and i can know *exactly* when that will happen.
that is not trivial to do, no matter what macros or other tricks you
use. i don't know lisp that well, but i have a hard time seeing this
pattern being easily implemented in any garbage collected environment.
the only way you can do it in java is if you use try-finally blocks
everywhere, and that's just grotesque.
indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> no matter what happens, i can be assured that all resources will be
> properly released. that is, for any possible code path, including
> those that i cannot predict, and including all exceptional code paths
> (short of an absolute emergency (ie. crash)), the resource will be
> properly cleaned up. and i can know *exactly* when that will happen.
>
> that is not trivial to do, no matter what macros or other tricks you
> use. i don't know lisp that well, but i have a hard time seeing this
> pattern being easily implemented in any garbage collected
> environment. the only way you can do it in java is if you use
> try-finally blocks everywhere, and that's just grotesque.
The reason why you have a hard time seeing why this pattern can be
done trivially in Lisp is because you do not know anything about Lisp.
RAII is a hack. Let me say that again: RAII is a hack, it is based
mostly on the semantics of local variables in C++, which are
dynamic-extent. If you want dynamic-extent resources, then use an
operator which grants you the ability to do so. And if you store the
resource object in a more permanent location, then what guarantee do
you have of when or where in the code it will be deallocated?
In Common Lisp, the operator that can be used to de-allocate
dynamic-extent resources is called UNWIND-PROTECT. It guarantees that
a certain block of code will be executed (for side-effect only) when
the stack unwinds past that point for any reason.
It might be used as such:
(let ((stream (open "file")))
(unwind-protect (do-something stream)
(close stream)))
but this is not quite correct, due to the possibility of interrupt.
Better yet is:
(let ((stream nil))
(unwind-protect
(progn (setf stream (open "file"))
(do-something stream))
(when stream (close stream))))
And perhaps even more improvements can be applied. But all this DOES
NOT MATTER TO THE TYPICAL PROGRAMMER. Why? Because of the Lisp macro!
The typical programmer writes this, and does not worry about the details:
(with-open-file (stream "file")
(do-something stream))
Done. Resource acquired, resource deallocated. No extra clutter, no
fancy finalizers, no scattering of unwind-protects through the code.
You know EXACTLY when the resource is acquired and when it is
returned. Common Lisp libraries always provide this kind of interface
to the user for resources.
In addition, if you don't like macros, you can still do it with just a
higher-order function:
(call-with-open-file "file" (lambda (stream) (do-something stream)))
(Though this isn't standard, it is easy to write.)
RAII is a hack based on the semantics of variables in C++ and the
memory management scheme. You should not need these things in order
to have dynamic-extent resources.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> no matter what happens, i can be assured that all resources will be
> properly released. that is, for any possible code path, including those
> that i cannot predict, and including all exceptional code paths (short
> of an absolute emergency (ie. crash)),
In that case, it's the OS's job to clean up the resources your process
had allocated, IMHO.
> the resource will be properly
> cleaned up. and i can know *exactly* when that will happen.
>
> that is not trivial to do, no matter what macros or other tricks you
> use. i don't know lisp that well, but i have a hard time seeing this
> pattern being easily implemented in any garbage collected environment.
> the only way you can do it in java is if you use try-finally blocks
> everywhere, and that's just grotesque.
You use unwind-protect, which is similar to Java's try-finally, but you
wrap it in a macro that allocates the external resource and deallocates
it when the stack is unwound, placing the body of your macro's
invocation inside the body of the unwind-protect. For example,
with-open-file takes effectively 3 arguments: the variable to be bound
with the stream of the newly opened file, the parameters that will be
passed to the open function, and the body of code that uses that file's
stream. A very common pattern (which is what macros are all about,
automating and abbreviating mechanistic patterns).
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> that is not trivial to do, no matter what macros or other tricks you
> use. i don't know lisp that well, but i have a hard time seeing this
> pattern being easily implemented in any garbage collected
> environment.
As others have pointed out, unwind-protect provides an RAII analogue,
though more akin to Java's finally clause than C++'s paired
constructor-destructor guarantees. Common Lisp macros allow one to
craft similar scoped acquire-release semantics as syntax.
Here are a few macros I find useful toward that end. The first,
with-transaction, runs cleanup forms only if the primary protected
form does not run to completion, or, rather, performs some "non-local
transfer of control." The second, with-restart-transaction, adds a
simple restart around the transaction. The third,
with-cleanup-on-error, only runs the cleanup forms if the primary
protected form exits by way of signaling an error condition.
(defmacro with-transaction (protected-form &rest cleanup-forms)
(let ((gsuccessfulp (gensym "successfulp-")))
`(let ((,gsuccessfulp nil))
(unwind-protect
(multiple-value-prog1
,protected-form
(setq ,gsuccessfulp t))
(unless ,gsuccessfulp
,@cleanup-forms)))))
(defmacro with-restart-transaction ((name format-control &rest args)
protected-form &rest cleanup-forms)
`(with-simple-restart (,name ,format-control ,@args)
(with-transaction
,protected-form
,@cleanup-forms)))
(defmacro with-cleanup-on-error (protected-form &rest cleanup-forms)
(let ((gcond (gensym "cond-")))
`(handler-case
,protected-form
(error (,gcond)
,@cleanup-forms
(error ,gcond)))))
--
Steven E. Harris
> you could just as easily create nightmare typo scenarios in any
> language, including plain english. that example is plainly a careless
> mistake. no one and no language can promise that some idiot won't come
> along and do something stupid to muck everything up.
Of course, but GC still improves the situation by reducing the number of
mistakes it is possible for a programmer to make (although of course memory
management bugs are still possible in a GC'd language). Just because GC is
not a pancea doesn't mean it isn't useful.
> oh yes, but by following some simple guidelines they can be just as
> easily avoided. i honestly cannot remember the last time i had a
> dangling reference crop up in my code.
OK, but what if you're using pointers instead of references (which you have
to some of the time in any real world C++ program). The whole issue of
references and memory management is a bit of a red herring here. IIRC it
started from a misunderstanding when I (rather stupidly) used "reference"
as a general term covering C++ pointers /and/ references. Whatever the
merrits of C++ references (and IMHO it is quite easy to create dangling
references as a novice C++ programmer, it took me a while to stop making
that mistake), you can't do all your memory management using copying and
(C++) reference passing.
> but let's say for argument's sake that you did have to have a shared
> object and that you could not be sure of it's lifetime.
> std::tr1::shared_ptr (aka boost::shared_ptr).
Yes, but reference counting smart pointers are less efficient than good GC
(assuming you are using them in a significant/performance critical portion
of your program) and you have to use the clumsy template syntax in C++ (if
only it had type inference...) I remember once trying to implement a parser
combinator library in C++ (without realising that Boost's Spirit library
had got there first). I gave up when the types for a smart pointer to a
instantiated template of a parser functor got to be about 1.5 lines long.
It became increasingly difficult to work out where the actual code was,
since it was burried in irrelavent memory management details. Memory
management is a solved problem, rather like repeatedly executing an
expression a given number of times is a solved problem, leading to the
development of languages with various looping abstractions. I don't want to
have to resolve the problem of memory management in every program I write.
> but c++ is more suited to a more deterministic
> problem domain. vaguely allocating and tossing memory around with no
> concept of ownership or responsibility isn't a good idea in tighter
> architectures, or even in more expansive architectures where you want
> close control of resources. if memory is cheap and plentiful, then sure,
> but then c++ may not be the best tool for the job.
I realise I'm making a little more or your comment here than is strictly
speaking fair, but given that memory /is/ cheap and plentiful on modern
computers, would that not mean that C++ is not usually the best tool for
the job for modern application design?
As for "vaguely allocating and tossing memory around with no concept of
ownership and responsibility", this is sometimes necessary. The concept of
a particular module/class/bit of a program "owning" a region of memory is
not always a particularly natural one. C++ forces you to use this concept
to make memory management manageable, but sometimes it doesn't make much
sense to treat memory as a "resource" managed by a particular part of the
program. This is when you need to start using smart pointers (/smart/
pointers: auto_ptr is helpful, but the memory management problem it solves
is not exactly thorny -- just add a few delete statements at the end of
your function). To reiterate, smart (reference counting) pointers as a
general approach to memory management are quite inefficient (i.e. they are
less efficient than a good GC) and a pain to use (i.e. they are less easy
to use than automatic memory management). Thus any C++ program which has a
lot of complicated memory management to do is quite likely to run no faster
than it would had it been written in a GC'd language, and be significantly
harder to understand.
This isn't just Lisp propaganda. For example take a look at the rationale
for Boehm GC at http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html.
One quote:
"In general, it is considerably easier to implement and use sophisticated
data structures in the presence of a garbage collector. As a result, it is
easier to avoid imposing arbitrary limits on program parameters (e.g.
string lengths), and to ensure that performance scales reasonably for large
inputs. ****** The cord string package included with our garbage collector
is an example of a useful abstraction that could not be provided without
some form of garbage collection, and would be more expensive with
user-provided reference counting, or the like ******. A program based on
something like the cord package has some chance of continuing to run
reasonably if it receives a 10 megabyte input string where the programmer
expected a line of text. This is much less likely with a string package
that uses a conventional representation."
(****** emphasis is mine, of course)
Alex
Mark A. Gibbs wrote:
>
> Hannah Schroeter wrote:
>
>> Or you're just doing a typo-like mistake, as in
>>
>> class A {
>> public:
>> explicit A(const std::string& x) : x(x) {}
>>
>> protected:
>> const std::string& x;
>> // ^ oops, intention was the same w/o the &
>> };
>>
>> A* make_a()
>> {
>> return (new A("foo"));
>> // oops, temporary std::string gets destroyed before we return,
>> // the A object contains a dangling reference
>> }
>>
>> int main()
>> {
>> std::auto_ptr<A> x(make_a());
>> // do something with x
>> }
>>
>> Of course it was just a typo. Just a typo that can be horrendous to
>> debug.
>
> you could just as easily create nightmare typo scenarios in any
> language, including plain english. that example is plainly a careless
> mistake. no one and no language can promise that some idiot won't come
> along and do something stupid to muck everything up.
>
> incidently, make_a() should probably return an auto_ptr<A>.
>
>>>references cannot cause memory leaks.
>>
>> ^ add "alone"
>>
>> No, but dangling references are easily built.
>
> oh yes, but by following some simple guidelines they can be just as
> easily avoided. i honestly cannot remember the last time i had a
> dangling reference crop up in my code.
>
>>>in good design, memory is freed by the same entity that allocated it.
>>>the use of pointers or references does not invalidate good design. it
>>>allows you to if you so choose, and sometimes that's a valid design
>>>decision. but if your memory management is scattered and out of control,
>>>that's your fault, not any language's.
>>
>>
>> So if you need to pass around things, like
>>
>> A B
>> is created (doesn't exist yet)
>> creates x
>>
>> is created
>> ---- pass on x ->
>> now needs the x
>> is destroyed
>> lives on
>>
>> you have to agree on a discipline of managing x, or you copy it over,
>> so A destroys its copy and B manages its own copy. The latter may not
>> always be viable, because things might rely on the identity of x.
>
> i said good design. this is horrendous design.
>
> to put it in concrete terms:
>
> Oven Furnace
> is built (doesn't exist yet)
> contains it's own thermostat
> is created
> ----- give thermostat to furnace --->
> now needs the thermostat
> is destroyed
> lives on
> (with the oven's thermostat)
>
> does that make logical sense?
>
> furnace would be free to put the thermostat into any kind of state that
> may be invalid within the context of oven, or vice-versa (you set the
> oven to 275� and your house ignites).
>
> but let's say for argument's sake that you did have to have a shared
> object and that you could not be sure of it's lifetime.
> std::tr1::shared_ptr (aka boost::shared_ptr).
>
>> If the pattern how x is transferred or not transferred, you can't just
>> say "ok, A creates x, B destroys it always".
>
> again, shared_ptr. but c++ is more suited to a more deterministic
> problem domain. vaguely allocating and tossing memory around with no
> concept of ownership or responsibility isn't a good idea in tighter
> architectures, or even in more expansive architectures where you want
> close control of resources. if memory is cheap and plentiful, then sure,
> but then c++ may not be the best tool for the job.
>
>> auto_ptr isn't a smart pointer. It's quite dumbass, not even viable
>> for containers at all.
>
> of course auto_ptr is a smart pointer, it's just a smart pointer with a
> very specific problem domain. it's specifically for the purpose of
> transfer of ownership (as i mention above, c++ tends towards more
> deterministic programs).
>
> "smart pointer" is a family of solutions, not a specific solution.
>
> boost::scoped_ptr has an even narrower problem domain, but i still find
> it occasionally useful - although auto_ptr does the same job and more at
> about the same cost.
>
>>>besides, with a garbage collected-only language, you can't practically
>>>implement raii, and i think that's a serious flaw.
>>
>>
>> You don't need raii then, as most raii is about memory, and the rest
>> can be handled with good macro facilities (see Common Lisp's
>> with-open-file for an example) or higher order functions.
>
> memory is only a very, very small part of raii. the first "r" is
> resource - and resource can be anything at all. in fact, in my code, i
> probably use it most often for synchronization.
>
> no matter what happens, i can be assured that all resources will be
> properly released. that is, for any possible code path, including those
> that i cannot predict, and including all exceptional code paths (short
> of an absolute emergency (ie. crash)), the resource will be properly
> cleaned up. and i can know *exactly* when that will happen.
>
> that is not trivial to do, no matter what macros or other tricks you
> use. i don't know lisp that well, but i have a hard time seeing this
> pattern being easily implemented in any garbage collected environment.
> the only way you can do it in java is if you use try-finally blocks
> everywhere, and that's just grotesque.
>
> indi
Alex Drummond wrote:
> Of course, but GC still improves the situation by reducing the number of
> mistakes it is possible for a programmer to make (although of course memory
> management bugs are still possible in a GC'd language). Just because GC is
> not a pancea doesn't mean it isn't useful.
we could dance in circles on this topic until time ended with no
resolution. my reply to the above would naturally be: just because
manual memory management/smart pointers are not a panacea, that does not
mean they aren't still useful.
i make games, and in the context of games, a gc is kind of a silly idea.
generally speaking, my allocation pattern in games tends along the line
of allocating a large pool at the start of each board/level/or more
recently area, then using smart pointers to lock and unlock sections of
that pool as memory is used, then just freeing the entire pool at the
end. garbage collection adds nothing to this design as it is impossible
for memory to leak (unless the pool doesn't get deallocated, which is
hard to miss).
in fact, the gc would take something away, because non-deterministic
deallocations can fugger things up in exactly the wrong place. i already
evaluated java for game design, and this was one of the major blows
against it - you can't control the gc (portably).
so to avoid another go around, let me repeat what i said at the
beginning. every language has it's strengths and weaknesses. use what
works best for the problem at hand. it is my opinion that c++ is the
best solution for game programming - you can try to convince me
otherwise if you want, but you cannot argue either of the previous
sentences.
>>oh yes, but by following some simple guidelines they can be just as
>>easily avoided. i honestly cannot remember the last time i had a
>>dangling reference crop up in my code.
>
>
> OK, but what if you're using pointers instead of references (which you have
> to some of the time in any real world C++ program). The whole issue of
> references and memory management is a bit of a red herring here. IIRC it
> started from a misunderstanding when I (rather stupidly) used "reference"
> as a general term covering C++ pointers /and/ references. Whatever the
> merrits of C++ references (and IMHO it is quite easy to create dangling
> references as a novice C++ programmer, it took me a while to stop making
> that mistake), you can't do all your memory management using copying and
> (C++) reference passing.
no, you would use smart pointers too. i would give holy hell to anyone
on my design teams that used bare pointers without a very valid reason.
look, advocates of languages that feature garbage collection make a big
deal of "memory management" in c++. the truth is, i rarely think about
it. the topic is fresh on my mind at this precise moment because i just
finished refactoring my game engine's memory management module. after
that's done, i probably won't think about it again for a long time.
i don't spend my programming days sitting there tracking every pointer
and fretting about whether it gets properly deallocated and/or is never
dereferenced when it is not valid. i just write good code, run rigourous
tests then double check with modern tools, which - surprise, surprise -
is the same thing you have to do in any language, gc or no. i haven't
had to track down a memory leak or bad dereference any time in recent
memory.
>>but let's say for argument's sake that you did have to have a shared
>>object and that you could not be sure of it's lifetime.
>>std::tr1::shared_ptr (aka boost::shared_ptr).
>
>
> Yes, but reference counting smart pointers are less efficient than good GC
stop. i have heard that several times in this discussion. i provided
numbers indicating that garbage collection was over 15 times slower than
smart pointers. i have seen absolutely no evidence to the contrary.
this song and dance is not new to me. i heard the same routine in the
early 90's with visual basic, then again later with java. "garbage
collection will free the programmer from the worries of memory
management". "_____ will replace c++ as the linga franca of the
programming world". "c++ is a broken and poorly designed dinosaur, _____
is much better." etc. etc. etc.
call me anal if you want, but i base my judgement on facts. or, in the
absence of reasonably measurable facts, i use current practice as my
metric. if garbage collection is so efficient, then why don't the
industry sectors that make their livelihood trying to make the most
efficient programs possible use gc capable languages? go ahead and say
"because they're all old fogies set in their way and buying into old
lies and afraid to change for the future", it will only prompt me to ask
why someone hasn't come along to upset the status quo and force them to
catch up.
ordinarily i'd say bring numbers and i'll consider your point. however,
i *have* numbers, numbers indicating that garbage collection is slower
than smart pointers. so your job now is not only to bring your own
numbers, but to give me an acceptible reason for why my numbers are
wrong. show your work.
as i said before, as far as i'm concerned, all pointers in a garbage
collected environment are smart pointers. you can all take turns calling
me ignorant about lisp or generational garbage collection again if you
like, but i just don't see how gc can be implemented otherwise. they may
not be reference counted, they may not even be implemented by linked
list, but *somehow* *something* has to be aware of when the allocated
memory is no longer being referenced. so *somehow* the references in the
program are being tracked. do i care how? no, not really. it doesn't
change the fact that they are conceptually smart pointers.
> of your program) and you have to use the clumsy template syntax in C++ (if
> only it had type inference...)
template <typename T>
inline std::tr1::shared_ptr<T> make_shared_ptr(T*) {
return std::tr1::shared_ptr<T>(p);
}
// in use:
std::tr1::shared_ptr<foo> p_foo = make_shared_ptr(new foo);
std::tr1::shared_ptr<bar> p_bar = make_shared_ptr(new bar);
>>but c++ is more suited to a more deterministic
>>problem domain. vaguely allocating and tossing memory around with no
>>concept of ownership or responsibility isn't a good idea in tighter
>>architectures, or even in more expansive architectures where you want
>>close control of resources. if memory is cheap and plentiful, then sure,
>>but then c++ may not be the best tool for the job.
>
>
> I realise I'm making a little more or your comment here than is strictly
> speaking fair, but given that memory /is/ cheap and plentiful on modern
> computers, would that not mean that C++ is not usually the best tool for
> the job for modern application design?
that would depend on several things, not the least of which is speed,
just how much of that plentiful memory you have to use and whether or
not you want to flip the proverbial bird to a chunk of your potential
audience because you couldn't be bothered to use their limited memory
more efficiently.
making word perfect? then you have a strong case for why c++ may not be
the best tool.
making doom 3? i dare you to compete against me in the open market with
a game engine that is slower and requires more memory than mine.
> As for "vaguely allocating and tossing memory around with no concept of
> ownership and responsibility", this is sometimes necessary.
it is never necessary. however, you may make a design decision to do
this in order to simplify the design.
on the other hand, it *is* sometimes necessary to keep a tight rein on
how much, how, and when memory is allocated and freed.
> The concept of
> a particular module/class/bit of a program "owning" a region of memory is
> not always a particularly natural one. C++ forces you to use this concept
> to make memory management manageable, but sometimes it doesn't make much
> sense to treat memory as a "resource" managed by a particular part of the
> program. This is when you need to start using smart pointers
it is fair to say that c++ *recommends* that you treat memory as a
finite system resource that must be acquired before use and released
when no longer needed. (forced? no. you are free to do what you want -
including using garbage collection - in c++.) but, and forgive me for
pointing out the obvious, isn't that what memory *is*?
as for whether or not the model of a single module handling memory
management is natural or not, that's a matter of opinion. however, in
the most common case, doesn't memory get allocated and freed from a
single place (the operating system's allocation and deallocation
functions)? regardless, you're free to do all your memory management in
one place or not. it's your choice.
> (/smart/
> pointers: auto_ptr is helpful, but the memory management problem it solves
> is not exactly thorny -- just add a few delete statements at the end of
> your function).
whoa whoa whoa. i may be ignorant of the design of modern garbage
collected environments, but it's clear that you are similarily ignorant
of how to manually manage memory in modern c++.
you don't just go sticking delete's everywhere then pat yourself on the
back for a job well done. do that and i can damn well guarantee that you
will end up with dangling pointers and/or double delete's.
if i ran a search on my entire game engine code, i would expect to find
only a dozen delete's in several thousand lines (including comments i
guess) - and all of them in the memory management module. i intend to
track any others down myself and fix them.
i paid several hundred dollars for a nice professional c++ development
environment, and i'll be damned if i'm going to manually delete every
pointer when the compiler is perfectly well capable of doing it for me.
besides - just where exactly is the "end" of any given function. i can
tell you now that *that* is most assuredly a thorny issue, in just about
any langauge, but most especially modern ones.
> This isn't just Lisp propaganda. For example take a look at the rationale
> for Boehm GC at http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html.
> One quote:
>
> "In general, it is considerably easier to implement and use sophisticated
> data structures in the presence of a garbage collector. As a result, it is
> easier to avoid imposing arbitrary limits on program parameters (e.g.
> string lengths), and to ensure that performance scales reasonably for large
> inputs. ****** The cord string package included with our garbage collector
> is an example of a useful abstraction that could not be provided without
> some form of garbage collection, and would be more expensive with
> user-provided reference counting, or the like ******. A program based on
> something like the cord package has some chance of continuing to run
> reasonably if it receives a 10 megabyte input string where the programmer
> expected a line of text. This is much less likely with a string package
> that uses a conventional representation."
>
> (****** emphasis is mine, of course)
again, forgive me for pointing out the obvious, but if the programmer
was expecting to get a single line of text as input, wouldn't a 10MB
chunk of data be an error? or, alternately, if the program is supposed
to be able to handle a 10MB input string, wouldn't the programmer be in
error for not expecting it?
besides:
#include <cstdlib>
#include <fstream>
#include <iostream>
#include <string>
void make_file();
std::string read_file();
int main() {
std::cout << "Making file...." << std::endl;
make_file();
std::cout << "Reading string...." << std::endl;
std::string input = read_file();
std::cout << "Input size = " << input.length() << std::endl;
std::system("pause");
return 0;
}
void make_file() {
std::ofstream out("file.txt");
for (int i = 0; i < 10485760; ++i)
out << 'a';
}
std::string read_file() {
std::ifstream in("file.txt");
std::string file_contents;
in >> file_contents;
return file_contents;
}
output:
Making file....
Reading string....
Input size = 10485760
Press any key to continue . . .
plus a text file with over 10 million letter "a"'s. i don't exactly know
what the boehm people consider a "conventional representation", but this
string wraps a plain old c-style array.
where's the "memory management"? i admit this is a trivial program, but
it does create a 10MB file using buffered writes, then input a 10MB file
- again, using buffered reads - into a 10MB long string (and it may or
may not copy that string, we can't be sure without more knowledge of the
specific string implementation and compiler), and there's not a single
iota of any conscious memory management to be seen.
indi
On Sat, 30 Oct 2004, Mark A. Gibbs wrote:
> stop. i have heard that several times in this discussion. i provided
> numbers indicating that garbage collection was over 15 times slower than
> smart pointers. i have seen absolutely no evidence to the contrary.
>
I'm afraid I'm not going to provide any here either. Personally my money's
on things like region inference with annotations doing most of the work,
with some GC on top - which is pretty much an inferred version of
competant C++ usage anyway. I do believe that in the cases where reference
counting is appropriate in C++ there're better ways to do the GC in
at least some circumstances though. Depends partly on how many references
there're likely to be to a given object in its lifetime, stuff like that.
> but *somehow* *something* has to be aware of when the allocated
> memory is no longer being referenced. so *somehow* the references in the
> program are being tracked. do i care how? no, not really. it doesn't
> change the fact that they are conceptually smart pointers.
>
Even when the GC works on completely ordinary pointers and uses
introspection to figure out how to navigate everything?
> > of your program) and you have to use the clumsy template syntax in C++ (if
> > only it had type inference...)
>
> template <typename T>
> inline std::tr1::shared_ptr<T> make_shared_ptr(T*) {
> return std::tr1::shared_ptr<T>(p);
> }
>
> // in use:
> std::tr1::shared_ptr<foo> p_foo = make_shared_ptr(new foo);
> std::tr1::shared_ptr<bar> p_bar = make_shared_ptr(new bar);
>
Right. Some of us are used to strongly statically typed languages where
the in-use code might read p_foo = make_shared_ptr(new foo); because all
the types'd be inferred for us.
> > As for "vaguely allocating and tossing memory around with no concept of
> > ownership and responsibility", this is sometimes necessary.
>
> it is never necessary. however, you may make a design decision to do
> this in order to simplify the design.
>
Mind if I ask your preferred non-GC solution for an oft-modified cyclic
graph that can't live on the stack?
> plus a text file with over 10 million letter "a"'s. i don't exactly know
> what the boehm people consider a "conventional representation", but this
> string wraps a plain old c-style array.
>
> where's the "memory management"? i admit this is a trivial program, but
> it does create a 10MB file using buffered writes, then input a 10MB file
> - again, using buffered reads - into a 10MB long string (and it may or
> may not copy that string, we can't be sure without more knowledge of the
> specific string implementation and compiler), and there's not a single
> iota of any conscious memory management to be seen.
>
Sure. Now insert some random extra data throughout - no "serious" text
editor can afford to keep its text in a single array per buffer.
--
······@flippac.org
Philippa Cowderoy wrote:
> On Sat, 30 Oct 2004, Mark A. Gibbs wrote:
>
>>stop. i have heard that several times in this discussion. i provided
>>numbers indicating that garbage collection was over 15 times slower than
>>smart pointers. i have seen absolutely no evidence to the contrary.
>
>
> I'm afraid I'm not going to provide any here either. Personally my money's
> on things like region inference with annotations doing most of the work,
> with some GC on top - which is pretty much an inferred version of
> competant C++ usage anyway. I do believe that in the cases where reference
> counting is appropriate in C++ there're better ways to do the GC in
> at least some circumstances though. Depends partly on how many references
> there're likely to be to a given object in its lifetime, stuff like that.
oh for sure - garbage collection can be very convenient, and in some
cases, very powerful. in my dream programming language, i'd be able to
mark certain objects for later collection, and take control of others
manually. for the time being, i do that via referencing by shared_ptr
when i don't want to be personally responsible for the object.
>>but *somehow* *something* has to be aware of when the allocated
>>memory is no longer being referenced. so *somehow* the references in the
>>program are being tracked. do i care how? no, not really. it doesn't
>>change the fact that they are conceptually smart pointers.
>
>
> Even when the GC works on completely ordinary pointers and uses
> introspection to figure out how to navigate everything?
surely.
i personally think that the term "smart pointers" not a very good one.
there are all kinds of ways for a pointer to be relatively "smart",
depending on how you choose to define "smart". you hvane have pointers
that perform automatic syncronization on dereferencing, for example. so,
let's instead use the term "automatic deallocating pointers" or adp to
save me from cts.
to quote from this page: http://ootips.org/yonat/4dev/smart-pointers.html
"[adp's] have the same interface that pointers do: they... support
pointer operations like dereferencing (operator *) and indirection
(operator ->)... To be smarter than regular pointers, [adp's] need to do
things that regular pointers don't. What could these things be? Probably
the most common bugs in C++ (and C) are related to pointers and memory
management: dangling pointers, memory leaks, allocation failures and
other joys. Having a [adp's] take care of these things can save a lot of
aspirin..."
and to pick out the gist of it: adp's look like pointers, but they don't
have to be explicitly deallocated. doesn't that sound like
garbage-collected references?
i think what you're getting hung up on is that in the traditional idea
of smart pointers, the pointer itself is the actor with the "smarts" to
handle automatic deallocation. i think that's irrelevant. the point of
an adp is that you don't need to know how it deallocates, that's done
automatically when you no longer need the memory. if it deallocates
itself, fine. if it's marked by a gc, fine. therefore, in a garbage
collected environment, all pointers are adp's.
>>template <typename T>
>>inline std::tr1::shared_ptr<T> make_shared_ptr(T*) {
>> return std::tr1::shared_ptr<T>(p);
>>}
>>
>>// in use:
>>std::tr1::shared_ptr<foo> p_foo = make_shared_ptr(new foo);
>>std::tr1::shared_ptr<bar> p_bar = make_shared_ptr(new bar);
>
>
> Right. Some of us are used to strongly statically typed languages where
> the in-use code might read p_foo = make_shared_ptr(new foo); because all
> the types'd be inferred for us.
you lost me - you mean you'd like to be able to just have new variables
appear on first use? à la the worst of the older programming languages
like basic and fortran? i can't imagine in the 21st century that
implicity creating new variables is a desired feature in a programming
language.
just in case that's not what you meant, you do realize that you can do
stuff like:
std::tr1::shared_ptr<foo> p_foo(new bar);
as long as bar and foo can be converted to each other (ex. foo is a base
class of bar).
> Mind if I ask your preferred non-GC solution for an oft-modified cyclic
> graph that can't live on the stack?
never needed one. but i can't imagine that it's never been done.
>>plus a text file with over 10 million letter "a"'s. i don't exactly know
>>what the boehm people consider a "conventional representation", but this
>>string wraps a plain old c-style array.
>>
>>where's the "memory management"? i admit this is a trivial program, but
>>it does create a 10MB file using buffered writes, then input a 10MB file
>>- again, using buffered reads - into a 10MB long string (and it may or
>>may not copy that string, we can't be sure without more knowledge of the
>>specific string implementation and compiler), and there's not a single
>>iota of any conscious memory management to be seen.
>
>
> Sure. Now insert some random extra data throughout - no "serious" text
> editor can afford to keep its text in a single array per buffer.
*sigh* the original problem was: "A program based on something like the
cord package has some chance of continuing to run reasonably if it
receives a 10 megabyte input string where the programmer expected a line
of text." i proved that that was hogwash by showing how a program could
function properly even after a 10MB "string" was input, using the most
basic structures available (ones that one would use if one *were*
expecting a single line of text).
but i also went out of my way to say that if a 10MB input was
*expected*, the programmer should program with that expectation in mind.
if the programmer was designing a "serious" text editor, he would write
a solution appropriate for that problem. obviously, a string is not
appropriate.
what is appropriate? i don't know, i've never made a text editor - a
linked list of a string per line? per paragraph? doesn't really matter
either way, you could use std::list<std::string> for either, and the
story doesn't change. in fact, no matter what the preferred design is,
it can probably be similarly built. and the memory will manage itself.
indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> Philippa Cowderoy wrote:
>
>> Mind if I ask your preferred non-GC solution for an oft-modified cyclic
>> graph that can't live on the stack?
>
> never needed one. but i can't imagine that it's never been done.
I have no idea why you think you're qualified to discuss the benefits of
automatic memory management techniques, then. Now I feel ashamed.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>> Right. Some of us are used to strongly statically typed languages where
>> the in-use code might read p_foo = make_shared_ptr(new foo); because all
>> the types'd be inferred for us.
>
> you lost me - you mean you'd like to be able to just have new variables
> appear on first use? � la the worst of the older programming languages
> like basic and fortran? i can't imagine in the 21st century that
> implicity creating new variables is a desired feature in a programming
> language.
Eh? The code Phillipa posted was exactly the same as the C++ code exceppt
without explicit types. The syntax was maybe misleading -- the equality
operator in most functional languages is not assignment, but a definition
of a term. I.e. foo = 5 means that foo is, by definition, 5.
Alex
Mark A. Gibbs wrote:
>
> Philippa Cowderoy wrote:
>
>> On Sat, 30 Oct 2004, Mark A. Gibbs wrote:
>>
>>>stop. i have heard that several times in this discussion. i provided
>>>numbers indicating that garbage collection was over 15 times slower than
>>>smart pointers. i have seen absolutely no evidence to the contrary.
>>
>>
>> I'm afraid I'm not going to provide any here either. Personally my
>> money's on things like region inference with annotations doing most of
>> the work, with some GC on top - which is pretty much an inferred version
>> of competant C++ usage anyway. I do believe that in the cases where
>> reference counting is appropriate in C++ there're better ways to do the
>> GC in at least some circumstances though. Depends partly on how many
>> references there're likely to be to a given object in its lifetime, stuff
>> like that.
>
> oh for sure - garbage collection can be very convenient, and in some
> cases, very powerful. in my dream programming language, i'd be able to
> mark certain objects for later collection, and take control of others
> manually. for the time being, i do that via referencing by shared_ptr
> when i don't want to be personally responsible for the object.
>
>>>but *somehow* *something* has to be aware of when the allocated
>>>memory is no longer being referenced. so *somehow* the references in the
>>>program are being tracked. do i care how? no, not really. it doesn't
>>>change the fact that they are conceptually smart pointers.
>>
>>
>> Even when the GC works on completely ordinary pointers and uses
>> introspection to figure out how to navigate everything?
>
> surely.
>
> i personally think that the term "smart pointers" not a very good one.
> there are all kinds of ways for a pointer to be relatively "smart",
> depending on how you choose to define "smart". you hvane have pointers
> that perform automatic syncronization on dereferencing, for example. so,
> let's instead use the term "automatic deallocating pointers" or adp to
> save me from cts.
>
> to quote from this page: http://ootips.org/yonat/4dev/smart-pointers.html
>
> "[adp's] have the same interface that pointers do: they... support
> pointer operations like dereferencing (operator *) and indirection
> (operator ->)... To be smarter than regular pointers, [adp's] need to do
> things that regular pointers don't. What could these things be? Probably
> the most common bugs in C++ (and C) are related to pointers and memory
> management: dangling pointers, memory leaks, allocation failures and
> other joys. Having a [adp's] take care of these things can save a lot of
> aspirin..."
>
> and to pick out the gist of it: adp's look like pointers, but they don't
> have to be explicitly deallocated. doesn't that sound like
> garbage-collected references?
>
> i think what you're getting hung up on is that in the traditional idea
> of smart pointers, the pointer itself is the actor with the "smarts" to
> handle automatic deallocation. i think that's irrelevant. the point of
> an adp is that you don't need to know how it deallocates, that's done
> automatically when you no longer need the memory. if it deallocates
> itself, fine. if it's marked by a gc, fine. therefore, in a garbage
> collected environment, all pointers are adp's.
>
>>>template <typename T>
>>>inline std::tr1::shared_ptr<T> make_shared_ptr(T*) {
>>> return std::tr1::shared_ptr<T>(p);
>>>}
>>>
>>>// in use:
>>>std::tr1::shared_ptr<foo> p_foo = make_shared_ptr(new foo);
>>>std::tr1::shared_ptr<bar> p_bar = make_shared_ptr(new bar);
>>
>>
>> Right. Some of us are used to strongly statically typed languages where
>> the in-use code might read p_foo = make_shared_ptr(new foo); because all
>> the types'd be inferred for us.
>
> you lost me - you mean you'd like to be able to just have new variables
> appear on first use? � la the worst of the older programming languages
> like basic and fortran? i can't imagine in the 21st century that
> implicity creating new variables is a desired feature in a programming
> language.
>
> just in case that's not what you meant, you do realize that you can do
> stuff like:
> std::tr1::shared_ptr<foo> p_foo(new bar);
> as long as bar and foo can be converted to each other (ex. foo is a base
> class of bar).
>
>> Mind if I ask your preferred non-GC solution for an oft-modified cyclic
>> graph that can't live on the stack?
>
> never needed one. but i can't imagine that it's never been done.
>
>>>plus a text file with over 10 million letter "a"'s. i don't exactly know
>>>what the boehm people consider a "conventional representation", but this
>>>string wraps a plain old c-style array.
>>>
>>>where's the "memory management"? i admit this is a trivial program, but
>>>it does create a 10MB file using buffered writes, then input a 10MB file
>>>- again, using buffered reads - into a 10MB long string (and it may or
>>>may not copy that string, we can't be sure without more knowledge of the
>>>specific string implementation and compiler), and there's not a single
>>>iota of any conscious memory management to be seen.
>>
>>
>> Sure. Now insert some random extra data throughout - no "serious" text
>> editor can afford to keep its text in a single array per buffer.
>
> *sigh* the original problem was: "A program based on something like the
> cord package has some chance of continuing to run reasonably if it
> receives a 10 megabyte input string where the programmer expected a line
> of text." i proved that that was hogwash by showing how a program could
> function properly even after a 10MB "string" was input, using the most
> basic structures available (ones that one would use if one *were*
> expecting a single line of text).
>
> but i also went out of my way to say that if a 10MB input was
> *expected*, the programmer should program with that expectation in mind.
> if the programmer was designing a "serious" text editor, he would write
> a solution appropriate for that problem. obviously, a string is not
> appropriate.
>
> what is appropriate? i don't know, i've never made a text editor - a
> linked list of a string per line? per paragraph? doesn't really matter
> either way, you could use std::list<std::string> for either, and the
> story doesn't change. in fact, no matter what the preferred design is,
> it can probably be similarly built. and the memory will manage itself.
>
> indi
Alex Drummond wrote:
>>>Right. Some of us are used to strongly statically typed languages where
>>>the in-use code might read p_foo = make_shared_ptr(new foo); because all
>>>the types'd be inferred for us.
>>
>>you lost me - you mean you'd like to be able to just have new variables
>>appear on first use? � la the worst of the older programming languages
>>like basic and fortran? i can't imagine in the 21st century that
>>implicity creating new variables is a desired feature in a programming
>>language.
>
>
> Eh? The code Phillipa posted was exactly the same as the C++ code exceppt
> without explicit types. The syntax was maybe misleading -- the equality
> operator in most functional languages is not assignment, but a definition
> of a term. I.e. foo = 5 means that foo is, by definition, 5.
and what is 5? an integer? a byte value? a floating point number? a
bignum? all of the above (a variant type)?
things get even more muddled if you do "foo = b" where b is an object of
some type. what type? who knows, you'll have to look elsewhere.
i realize the code she posted was the same, but it seems to be implying
to me that foo is a new variable that's created without a type
declaration. that is old school programming. modern languages require
you to specify the type of a new variable.
indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
>> Eh? The code Phillipa posted was exactly the same as the C++ code
>> exceppt
>> without explicit types. The syntax was maybe misleading -- the equality
>> operator in most functional languages is not assignment, but a definition
>> of a term. I.e. foo = 5 means that foo is, by definition, 5.
>
> and what is 5? an integer? a byte value? a floating point number? a
> bignum? all of the above (a variant type)?
5 is whatever it is. "A byte value" is nonsense: that's just a modular
integer, I suppose. In most languages, explicit notation is required to
make something FP (thank god). I don't know why the hell anyone would
use an implementation where 5 needed to be a bignum. An object can't be
of all kinds of types. It is of some specific type (in Lisp, actually,
this only applies to classes, which are a specific kind of type) which
has some set of supertypes. The mother of all types in Lisp is called T
(the name for cannonical true value, as well). All bindings in Lisp are
implicitly declared as being of type T. If the compiler can prove a more
stringent type declaration for the binding, it can, of course, use that
declaration intersected with any declaration explicitly given by the
programmer.
> things get even more muddled if you do "foo = b" where b is an object of
> some type. what type? who knows, you'll have to look elsewhere.
Yes, you look at where b's value comes from... What is so hard about
this?
> i realize the code she posted was the same, but it seems to be implying
> to me that foo is a new variable that's created without a type
> declaration. that is old school programming. modern languages require
> you to specify the type of a new variable.
Bahaha. You mean modern languages are designed for more primitive
compilation techniques and more fragmented type systems? I think not.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> and what is 5? an integer? a byte value? a floating point number? a
> bignum? all of the above (a variant type)?
In Standard ML it would be an integer. The compiler would then correctly
infer that foo was an integer.
> things get even more muddled if you do "foo = b" where b is an object of
> some type. what type? who knows, you'll have to look elsewhere.
Yeah you'll have to look at the definition of b (big deal). Alternatively,
you could give foo an optional type signature, if you thought it would make
the code clearer.
You obviously don't have much experience of statically typed languages with
type inference.
Alex
Mark A. Gibbs wrote:
>
> Alex Drummond wrote:
>
>>>>Right. Some of us are used to strongly statically typed languages where
>>>>the in-use code might read p_foo = make_shared_ptr(new foo); because all
>>>>the types'd be inferred for us.
>>>
>>>you lost me - you mean you'd like to be able to just have new variables
>>>appear on first use? � la the worst of the older programming languages
>>>like basic and fortran? i can't imagine in the 21st century that
>>>implicity creating new variables is a desired feature in a programming
>>>language.
>>
>>
>> Eh? The code Phillipa posted was exactly the same as the C++ code exceppt
>> without explicit types. The syntax was maybe misleading -- the equality
>> operator in most functional languages is not assignment, but a definition
>> of a term. I.e. foo = 5 means that foo is, by definition, 5.
>
> and what is 5? an integer? a byte value? a floating point number? a
> bignum? all of the above (a variant type)?
>
> things get even more muddled if you do "foo = b" where b is an object of
> some type. what type? who knows, you'll have to look elsewhere.
>
> i realize the code she posted was the same, but it seems to be implying
> to me that foo is a new variable that's created without a type
> declaration. that is old school programming. modern languages require
> you to specify the type of a new variable.
>
> indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> and what is 5? an integer? a byte value? a floating point number? a
> bignum? all of the above (a variant type)?
There is a defined syntax for the form of each type. In most (sane)
languages, the string "5" would be interpreted as a small integer of
some sort. Common Lisp, for example, would implement it as a FIXNUM
type since it is small enough; but CL compilers could look at it
abstractly as (INTEGER 5 5) meaning the set of integers between 5 and
5 inclusive. In Standard ML, it would be 5 : int (5 is of type int).
> things get even more muddled if you do "foo = b" where b is an object
> of some type. what type? who knows, you'll have to look elsewhere.
Hardly. If you do (in SML):
let val foo = b in ... end
Then it will figure out that foo has the same static type as b. And
since the ML type-checker has been keeping track of these things, that
is no problem.
> i realize the code she posted was the same, but it seems to be
> implying to me that foo is a new variable that's created without a
> type declaration. that is old school programming. modern languages
> require you to specify the type of a new variable.
If you really think this, you need to fast-forward about 30 years to
the present day. Declaring types explicitly may have been "state of
the art" in 1970, but it has not been the case since ML came onto the
scene. Real statically-typed languages have a well-thought-out type
system with proofs that all well-formed expressions have a type and a
result. Furthermore, designers of _modern_ statically typed languages
actually give a great deal of thought to the decidability of the
inference of types WITHOUT DECLARATIONS NEEDED. C and C++ are
examples of dinosaur type systems, which were created not with
decidability in mind, but implementational convenience. Even Common
Lisp is designed to permit type inference by the compiler; though it
does not require it.
Time for you to start catching up:
http://www.standardml.org/
http://caml.inria.fr/
http://www.haskell.org/
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
On Sat, 30 Oct 2004, Mark A. Gibbs wrote:
>
> Philippa Cowderoy wrote:
>
> > On Sat, 30 Oct 2004, Mark A. Gibbs wrote:
> >
> >>stop. i have heard that several times in this discussion. i provided
> >>numbers indicating that garbage collection was over 15 times slower than
> >>smart pointers. i have seen absolutely no evidence to the contrary.
> >
> >
> > I'm afraid I'm not going to provide any here either. Personally my money's
> > on things like region inference with annotations doing most of the work,
> > with some GC on top - which is pretty much an inferred version of
> > competant C++ usage anyway. I do believe that in the cases where reference
> > counting is appropriate in C++ there're better ways to do the GC in
> > at least some circumstances though. Depends partly on how many references
> > there're likely to be to a given object in its lifetime, stuff like that.
>
> oh for sure - garbage collection can be very convenient, and in some
> cases, very powerful. in my dream programming language, i'd be able to
> mark certain objects for later collection, and take control of others
> manually. for the time being, i do that via referencing by shared_ptr
> when i don't want to be personally responsible for the object.
>
We're probably getting on for the same ideal then, though I tend to come
at it from the opposite angle.
> i think what you're getting hung up on is that in the traditional idea
> of smart pointers, the pointer itself is the actor with the "smarts" to
> handle automatic deallocation. i think that's irrelevant. the point of
> an adp is that you don't need to know how it deallocates, that's done
> automatically when you no longer need the memory. if it deallocates
> itself, fine. if it's marked by a gc, fine. therefore, in a garbage
> collected environment, all pointers are adp's.
>
OK, given that version I'll buy it - though it's a separate concept to
that of a smart pointer IMO.
> >>template <typename T>
> >>inline std::tr1::shared_ptr<T> make_shared_ptr(T*) {
> >> return std::tr1::shared_ptr<T>(p);
> >>}
> >>
> >>// in use:
> >>std::tr1::shared_ptr<foo> p_foo = make_shared_ptr(new foo);
> >>std::tr1::shared_ptr<bar> p_bar = make_shared_ptr(new bar);
> >
> >
> > Right. Some of us are used to strongly statically typed languages where
> > the in-use code might read p_foo = make_shared_ptr(new foo); because all
> > the types'd be inferred for us.
>
> you lost me - you mean you'd like to be able to just have new variables
> appear on first use? Ã la the worst of the older programming languages
> like basic and fortran? i can't imagine in the 21st century that
> implicity creating new variables is a desired feature in a programming
> language.
>
It is for a number of people - the Haskell code I write often has
sufficiently complicated types that having to write them all down
explicitly would both slow me down drastically and obscure the intent of
the code. That said, my variables probably aren't the same as your
variables - in Haskell a variable is just a name for a value (not the same
as a pointer to it!). You can't change the value, only which value the
variable's bound to. New variables in this sense aren't implicit at all -
and the new values in that example are the result of make_shared_ptr and
the result of (new foo).
It's worth noting that unlike in most basics, there's still strong static
typing going on here - p_foo is known to be a shared_ptr<a> where a is
whatever the type of foo was. If the type of foo isn't known at that time,
you even get a function with a (parametrically) polymorphic type - roughly
equivalent to a template function. You were right to ask what the inferred
type of a numeric literal will be in another post, that one'll vary from
language to language depending on the mechanisms available - where it
matters you'll almost always be able to supply a type annotation though.
The important thing here is that you can do all this and never see a
run-time type error - there're some quite impressively powerful type
systems where you can infer everything statically, and some where with
just a handful of annotations you can do things that'd make most C++
programmers stop and blink.
> > Mind if I ask your preferred non-GC solution for an oft-modified cyclic
> > graph that can't live on the stack?
>
> never needed one. but i can't imagine that it's never been done.
>
I can't see a solution that doesn't involve implementing a garbage
collector somewhere along the line. And due to the graph being cyclic,
refcounting won't do either.
--
······@flippac.org
> we could dance in circles on this topic until time ended with no
> resolution. my reply to the above would naturally be: just because
> manual memory management/smart pointers are not a panacea, that does not
> mean they aren't still useful.
They're very useful in a language without GC, yes.
> i make games, and in the context of games, a gc is kind of a silly idea.
> generally speaking, my allocation pattern in games tends along the line
> of allocating a large pool at the start of each board/level/or more
> recently area, then using smart pointers to lock and unlock sections of
> that pool as memory is used, then just freeing the entire pool at the
> end.
I.e. implemeting your own garbage collector. GCs generally allocate big
blocks of memory at the start of program execution and then manage the use
of those blocks. Using smart pointers is going to be less efficient than
using a GC, because reference counting is quite inefficient.
> in fact, the gc would take something away, because non-deterministic
> deallocations can fugger things up in exactly the wrong place. i already
> evaluated java for game design, and this was one of the major blows
> against it - you can't control the gc (portably).
The amount of time spent freeing dereferenced pointers is also fairly
unpredictable. It's perfectly possible to have a GC with some sort of
soft-real time constraint, where it's guaranteed that the GC will not spend
lots of time freeing memory before allowing other threads of the program
CPU time. This sort of guarantee is pretty much impossible to get with
reference counting (unless you really want to look at which references get
lost when for every code path), so GC seems to have the advantage here.
> stop. i have heard that several times in this discussion. i provided
> numbers indicating that garbage collection was over 15 times slower than
> smart pointers. i have seen absolutely no evidence to the contrary.
1) Your numbers are pretty suspect for reasons I gave earlier.
2) If reference counting is so damn efficient, /why don't any cutting edge
modern GCs use it?/ If reference counting is a fast as you say it is, a
modern GC could use it and get equivalent memory management performance to
C++ code using smart pointers; you'd get all the speed of C++ without any
of the difficulty. You're simply wrong here I'm afraid. Reference counting
gives very poor space performance (all those reference count fields to
store) and unpredictable, slowish time performance. See for example this
short discussion of the merits of reference counting smart pointers
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_1.html)
including this performance comparison putting a C++ GC ahead of reference
counting smart pointers
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_11.html).
It also includes an analysis of "maximum pause time", which shows that GC
has no great disadvantage here either, especially not in multithreaded
code, where thread-safe reference counting is extremely expensive.
So the numbers don't all come down on your side of the argument, far from
it.
> call me anal if you want, but i base my judgement on facts. or, in the
> absence of reasonably measurable facts, i use current practice as my
> metric. if garbage collection is so efficient, then why don't the
> industry sectors that make their livelihood trying to make the most
> efficient programs possible use gc capable languages? go ahead and say
> "because they're all old fogies set in their way and buying into old
> lies and afraid to change for the future", it will only prompt me to ask
> why someone hasn't come along to upset the status quo and force them to
> catch up.
I'd rather look at actual performance than try to work out the best
programming tools through sociology. Can all those people be wrong? Yes,
very easily if a good portion of them think the same way as you (everyone
else is doing it so it must be a good idea).
> as i said before, as far as i'm concerned, all pointers in a garbage
> collected environment are smart pointers. you can all take turns calling
> me ignorant about lisp or generational garbage collection again if you
> like, but i just don't see how gc can be implemented otherwise. they may
> not be reference counted, they may not even be implemented by linked
> list, but *somehow* *something* has to be aware of when the allocated
> memory is no longer being referenced. so *somehow* the references in the
> program are being tracked. do i care how? no, not really. it doesn't
> change the fact that they are conceptually smart pointers.
Nonsense. A smart pointer is an entity associated with a particular object
which keeps track of references to that object. There is no such mechanism
at work in a generational GC. So yes, you are ignorant about lisp and
generational GC, so far as I can see, or at least underestimating the
significance of the differences between them.
And of course, you should care about how references are being tracked if you
care about memory management performace. If you don't care how the
references are being tracked, why do you not use a GC?
> you don't just go sticking delete's everywhere then pat yourself on the
> back for a job well done. do that and i can damn well guarantee that you
> will end up with dangling pointers and/or double delete's.
I agree, I was just pointing out that std::auto_ptr (thought it's very fast)
is only fast because it's automating brainless memory management legwork.
Smart pointers which solve more general memory management problems are
quite slow.
> i paid several hundred dollars for a nice professional c++ development
> environment, and i'll be damned if i'm going to manually delete every
> pointer when the compiler is perfectly well capable of doing it for me.
You know, that sounds like an excellent argument for GC...
> again, forgive me for pointing out the obvious, but if the programmer
> was expecting to get a single line of text as input, wouldn't a 10MB
> chunk of data be an error? or, alternately, if the program is supposed
> to be able to handle a 10MB input string, wouldn't the programmer be in
> error for not expecting it?
I don't know, depends on the program. Is giving 10MB of data to a complex
awk program an error? You wouldn't be entitled to expect awk to process the
data quickly, but I think you would be entitled to expect it to process the
data /eventually/. (OK, perhaps we need to scale the number of MBs up to
make the figures realistic for awk, but you get the point...) If a program
just spat out an error saying "sorry, despite the fact that you're running
on a 4 CPU server with 5GB of memory, I'm not going to attempt to do what
you asked me to do because you gave me a bit more data than I was
expecting", IMO that is bordering on being a bug.
You sort of misssed that main point of the quote, which stated that
implemeting such a structure through manual reference counting would
probably be slower.
> plus a text file with over 10 million letter "a"'s. i don't exactly know
> what the boehm people consider a "conventional representation", but this
> string wraps a plain old c-style array.
Yeah, but you couldn't do any manipulation of that string in a reasonable
amount of time. Obviously, if you just want to read loads of data in and do
nothing with it, your best bet is a big C-style array (or at most, a linked
list of such arrays). If you want to write a program manipulating the data,
you need something much more sophisticated.
> where's the "memory management"? i admit this is a trivial program, but
> it does create a 10MB file using buffered writes, then input a 10MB file
> - again, using buffered reads - into a 10MB long string (and it may or
> may not copy that string, we can't be sure without more knowledge of the
> specific string implementation and compiler), and there's not a single
> iota of any conscious memory management to be seen.
Well yeah, because the memory management in this program is trivial -- free
each data structure and the end of the block it was declared in, basically.
Alex
Mark A. Gibbs wrote:
>
> Alex Drummond wrote:
>> Of course, but GC still improves the situation by reducing the number of
>> mistakes it is possible for a programmer to make (although of course
>> memory management bugs are still possible in a GC'd language). Just
>> because GC is not a pancea doesn't mean it isn't useful.
>
> we could dance in circles on this topic until time ended with no
> resolution. my reply to the above would naturally be: just because
> manual memory management/smart pointers are not a panacea, that does not
> mean they aren't still useful.
>
> i make games, and in the context of games, a gc is kind of a silly idea.
> generally speaking, my allocation pattern in games tends along the line
> of allocating a large pool at the start of each board/level/or more
> recently area, then using smart pointers to lock and unlock sections of
> that pool as memory is used, then just freeing the entire pool at the
> end. garbage collection adds nothing to this design as it is impossible
> for memory to leak (unless the pool doesn't get deallocated, which is
> hard to miss).
>
> in fact, the gc would take something away, because non-deterministic
> deallocations can fugger things up in exactly the wrong place. i already
> evaluated java for game design, and this was one of the major blows
> against it - you can't control the gc (portably).
>
> so to avoid another go around, let me repeat what i said at the
> beginning. every language has it's strengths and weaknesses. use what
> works best for the problem at hand. it is my opinion that c++ is the
> best solution for game programming - you can try to convince me
> otherwise if you want, but you cannot argue either of the previous
> sentences.
>
>>>oh yes, but by following some simple guidelines they can be just as
>>>easily avoided. i honestly cannot remember the last time i had a
>>>dangling reference crop up in my code.
>>
>>
>> OK, but what if you're using pointers instead of references (which you
>> have to some of the time in any real world C++ program). The whole issue
>> of references and memory management is a bit of a red herring here. IIRC
>> it started from a misunderstanding when I (rather stupidly) used
>> "reference" as a general term covering C++ pointers /and/ references.
>> Whatever the merrits of C++ references (and IMHO it is quite easy to
>> create dangling references as a novice C++ programmer, it took me a while
>> to stop making that mistake), you can't do all your memory management
>> using copying and (C++) reference passing.
>
> no, you would use smart pointers too. i would give holy hell to anyone
> on my design teams that used bare pointers without a very valid reason.
>
> look, advocates of languages that feature garbage collection make a big
> deal of "memory management" in c++. the truth is, i rarely think about
> it. the topic is fresh on my mind at this precise moment because i just
> finished refactoring my game engine's memory management module. after
> that's done, i probably won't think about it again for a long time.
>
> i don't spend my programming days sitting there tracking every pointer
> and fretting about whether it gets properly deallocated and/or is never
> dereferenced when it is not valid. i just write good code, run rigourous
> tests then double check with modern tools, which - surprise, surprise -
> is the same thing you have to do in any language, gc or no. i haven't
> had to track down a memory leak or bad dereference any time in recent
> memory.
>
>>>but let's say for argument's sake that you did have to have a shared
>>>object and that you could not be sure of it's lifetime.
>>>std::tr1::shared_ptr (aka boost::shared_ptr).
>>
>>
>> Yes, but reference counting smart pointers are less efficient than good
>> GC
>
> stop. i have heard that several times in this discussion. i provided
> numbers indicating that garbage collection was over 15 times slower than
> smart pointers. i have seen absolutely no evidence to the contrary.
>
> this song and dance is not new to me. i heard the same routine in the
> early 90's with visual basic, then again later with java. "garbage
> collection will free the programmer from the worries of memory
> management". "_____ will replace c++ as the linga franca of the
> programming world". "c++ is a broken and poorly designed dinosaur, _____
> is much better." etc. etc. etc.
>
> call me anal if you want, but i base my judgement on facts. or, in the
> absence of reasonably measurable facts, i use current practice as my
> metric. if garbage collection is so efficient, then why don't the
> industry sectors that make their livelihood trying to make the most
> efficient programs possible use gc capable languages? go ahead and say
> "because they're all old fogies set in their way and buying into old
> lies and afraid to change for the future", it will only prompt me to ask
> why someone hasn't come along to upset the status quo and force them to
> catch up.
>
> ordinarily i'd say bring numbers and i'll consider your point. however,
> i *have* numbers, numbers indicating that garbage collection is slower
> than smart pointers. so your job now is not only to bring your own
> numbers, but to give me an acceptible reason for why my numbers are
> wrong. show your work.
>
> as i said before, as far as i'm concerned, all pointers in a garbage
> collected environment are smart pointers. you can all take turns calling
> me ignorant about lisp or generational garbage collection again if you
> like, but i just don't see how gc can be implemented otherwise. they may
> not be reference counted, they may not even be implemented by linked
> list, but *somehow* *something* has to be aware of when the allocated
> memory is no longer being referenced. so *somehow* the references in the
> program are being tracked. do i care how? no, not really. it doesn't
> change the fact that they are conceptually smart pointers.
>
>> of your program) and you have to use the clumsy template syntax in C++
>> (if only it had type inference...)
>
> template <typename T>
> inline std::tr1::shared_ptr<T> make_shared_ptr(T*) {
> return std::tr1::shared_ptr<T>(p);
> }
>
> // in use:
> std::tr1::shared_ptr<foo> p_foo = make_shared_ptr(new foo);
> std::tr1::shared_ptr<bar> p_bar = make_shared_ptr(new bar);
>
>>>but c++ is more suited to a more deterministic
>>>problem domain. vaguely allocating and tossing memory around with no
>>>concept of ownership or responsibility isn't a good idea in tighter
>>>architectures, or even in more expansive architectures where you want
>>>close control of resources. if memory is cheap and plentiful, then sure,
>>>but then c++ may not be the best tool for the job.
>>
>>
>> I realise I'm making a little more or your comment here than is strictly
>> speaking fair, but given that memory /is/ cheap and plentiful on modern
>> computers, would that not mean that C++ is not usually the best tool for
>> the job for modern application design?
>
> that would depend on several things, not the least of which is speed,
> just how much of that plentiful memory you have to use and whether or
> not you want to flip the proverbial bird to a chunk of your potential
> audience because you couldn't be bothered to use their limited memory
> more efficiently.
>
> making word perfect? then you have a strong case for why c++ may not be
> the best tool.
>
> making doom 3? i dare you to compete against me in the open market with
> a game engine that is slower and requires more memory than mine.
>
>> As for "vaguely allocating and tossing memory around with no concept of
>> ownership and responsibility", this is sometimes necessary.
>
> it is never necessary. however, you may make a design decision to do
> this in order to simplify the design.
>
> on the other hand, it *is* sometimes necessary to keep a tight rein on
> how much, how, and when memory is allocated and freed.
>
>> The concept of
>> a particular module/class/bit of a program "owning" a region of memory is
>> not always a particularly natural one. C++ forces you to use this concept
>> to make memory management manageable, but sometimes it doesn't make much
>> sense to treat memory as a "resource" managed by a particular part of the
>> program. This is when you need to start using smart pointers
>
> it is fair to say that c++ *recommends* that you treat memory as a
> finite system resource that must be acquired before use and released
> when no longer needed. (forced? no. you are free to do what you want -
> including using garbage collection - in c++.) but, and forgive me for
> pointing out the obvious, isn't that what memory *is*?
>
> as for whether or not the model of a single module handling memory
> management is natural or not, that's a matter of opinion. however, in
> the most common case, doesn't memory get allocated and freed from a
> single place (the operating system's allocation and deallocation
> functions)? regardless, you're free to do all your memory management in
> one place or not. it's your choice.
>
>> (/smart/
>> pointers: auto_ptr is helpful, but the memory management problem it
>> solves is not exactly thorny -- just add a few delete statements at the
>> end of your function).
>
> whoa whoa whoa. i may be ignorant of the design of modern garbage
> collected environments, but it's clear that you are similarily ignorant
> of how to manually manage memory in modern c++.
>
> you don't just go sticking delete's everywhere then pat yourself on the
> back for a job well done. do that and i can damn well guarantee that you
> will end up with dangling pointers and/or double delete's.
>
> if i ran a search on my entire game engine code, i would expect to find
> only a dozen delete's in several thousand lines (including comments i
> guess) - and all of them in the memory management module. i intend to
> track any others down myself and fix them.
>
> i paid several hundred dollars for a nice professional c++ development
> environment, and i'll be damned if i'm going to manually delete every
> pointer when the compiler is perfectly well capable of doing it for me.
>
> besides - just where exactly is the "end" of any given function. i can
> tell you now that *that* is most assuredly a thorny issue, in just about
> any langauge, but most especially modern ones.
>
>> This isn't just Lisp propaganda. For example take a look at the rationale
>> for Boehm GC at http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html.
>> One quote:
>>
>> "In general, it is considerably easier to implement and use sophisticated
>> data structures in the presence of a garbage collector. As a result, it
>> is easier to avoid imposing arbitrary limits on program parameters (e.g.
>> string lengths), and to ensure that performance scales reasonably for
>> large inputs. ****** The cord string package included with our garbage
>> collector is an example of a useful abstraction that could not be
>> provided without some form of garbage collection, and would be more
>> expensive with user-provided reference counting, or the like ******. A
>> program based on something like the cord package has some chance of
>> continuing to run reasonably if it receives a 10 megabyte input string
>> where the programmer expected a line of text. This is much less likely
>> with a string package that uses a conventional representation."
>>
>> (****** emphasis is mine, of course)
>
> again, forgive me for pointing out the obvious, but if the programmer
> was expecting to get a single line of text as input, wouldn't a 10MB
> chunk of data be an error? or, alternately, if the program is supposed
> to be able to handle a 10MB input string, wouldn't the programmer be in
> error for not expecting it?
>
> besides:
>
> #include <cstdlib>
> #include <fstream>
> #include <iostream>
> #include <string>
>
> void make_file();
> std::string read_file();
>
> int main() {
> std::cout << "Making file...." << std::endl;
> make_file();
>
> std::cout << "Reading string...." << std::endl;
> std::string input = read_file();
>
> std::cout << "Input size = " << input.length() << std::endl;
>
> std::system("pause");
> return 0;
> }
>
> void make_file() {
> std::ofstream out("file.txt");
>
> for (int i = 0; i < 10485760; ++i)
> out << 'a';
> }
>
> std::string read_file() {
> std::ifstream in("file.txt");
>
> std::string file_contents;
> in >> file_contents;
>
> return file_contents;
> }
>
>
> output:
> Making file....
> Reading string....
> Input size = 10485760
> Press any key to continue . . .
>
> plus a text file with over 10 million letter "a"'s. i don't exactly know
> what the boehm people consider a "conventional representation", but this
> string wraps a plain old c-style array.
>
> where's the "memory management"? i admit this is a trivial program, but
> it does create a 10MB file using buffered writes, then input a 10MB file
> - again, using buffered reads - into a 10MB long string (and it may or
> may not copy that string, we can't be sure without more knowledge of the
> specific string implementation and compiler), and there's not a single
> iota of any conscious memory management to be seen.
>
> indi
Alex Drummond <··········@ucl.ac.uk> writes:
> Well yeah, because the memory management in this program is trivial -- free
> each data structure and the end of the block it was declared in, basically.
And that doesn't even require a heap.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Alex Drummond wrote:
>>i make games, and in the context of games, a gc is kind of a silly idea.
>>generally speaking, my allocation pattern in games tends along the line
>>of allocating a large pool at the start of each board/level/or more
>>recently area, then using smart pointers to lock and unlock sections of
>>that pool as memory is used, then just freeing the entire pool at the
>>end.
>
>
> I.e. implemeting your own garbage collector. GCs generally allocate big
> blocks of memory at the start of program execution and then manage the use
> of those blocks. Using smart pointers is going to be less efficient than
> using a GC, because reference counting is quite inefficient.
read the fine print: "allocating a large pool at the start of each
board/level/or more recently area". that implies also that i would
deallocate all level data at the end of a level, so all expensive
operations are between levels. in other words, i may have implemented my
own garbage collector, but i've done it better than lisp could have.
furthermore, i don't *need* to have smart pointers - the memory is
automatically cleaned up, remember? for those objects which will be hit
the hardest by being counted - those that hang around the longest or are
used the most - i would probably choose not to, if i found it too wasteful.
garbage collectors are neat toys, and they do have their uses sometimes,
but though the average programmer may be dumb as toast, they're still
smarter than any garbage collector.
>>in fact, the gc would take something away, because non-deterministic
>>deallocations can fugger things up in exactly the wrong place. i already
>>evaluated java for game design, and this was one of the major blows
>>against it - you can't control the gc (portably).
>
>
> The amount of time spent freeing dereferenced pointers is also fairly
> unpredictable. It's perfectly possible to have a GC with some sort of
> soft-real time constraint, where it's guaranteed that the GC will not spend
> lots of time freeing memory before allowing other threads of the program
> CPU time. This sort of guarantee is pretty much impossible to get with
> reference counting (unless you really want to look at which references get
> lost when for every code path), so GC seems to have the advantage here.
fair enough, except that you can know exactly when those deallocations
will occur in the non-gc environment, and you can postpone them if you
really can't afford the time in the current block. in my opinion, that
negates the advantage.
>>stop. i have heard that several times in this discussion. i provided
>>numbers indicating that garbage collection was over 15 times slower than
>>smart pointers. i have seen absolutely no evidence to the contrary.
>
>
> 1) Your numbers are pretty suspect for reasons I gave earlier.
i agree, but they're still the only ones.
> 2) If reference counting is so damn efficient, /why don't any cutting edge
> modern GCs use it?/ If reference counting is a fast as you say it is, a
> modern GC could use it and get equivalent memory management performance to
> C++ code using smart pointers; you'd get all the speed of C++ without any
> of the difficulty. You're simply wrong here I'm afraid. Reference counting
beats the hell out of me - i don't program garbage collectors, and i'm
not really inclined to argue the benefits of one implementation vs. another.
> gives very poor space performance (all those reference count fields to
> store) and unpredictable, slowish time performance. See for example this
> short discussion of the merits of reference counting smart pointers
> (http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_1.html)
> including this performance comparison putting a C++ GC ahead of reference
> counting smart pointers
> (http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_11.html).
> It also includes an analysis of "maximum pause time", which shows that GC
> has no great disadvantage here either, especially not in multithreaded
> code, where thread-safe reference counting is extremely expensive.
you and i apparently looked at the same slides and can away with very
different perceptions. the graph you put up was apparently allocating
and deallocating lots and lots of small nodes (i estimate 16 bytes)
repeatedly. because the gc can perform all deallocations en masse and it
doesn't have to count references i'm not particularly surprised at the
result.
i can't imagine trying to do that in modern game code. more likely i'd
use pools, which means these results probably closer approximate
performance:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_23.html
(or
http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_24.html)
and of course, the critical measurement in game performance is the pause
time. what makes the gc behaviour really bad (besides the obviously
glaring difference) is that that pause time can theoretically happen
anywhere, which is hardly ideal.
maybe you can tune the garbage collector by setting some flags that
either disable the gc unless you explicitly enable it, or somehow
amortize that pausing time... but wasn't the gc supposed to eliminate
being concerned about memory management?
> So the numbers don't all come down on your side of the argument, far from
> it.
my argument from the beginning has been: no language or language feature
solves everything, so use what's best to solve the problem you're trying
to solve. i fail to see how these numbers don't support that.
my biggest beef with gc languages is that generally they offer no other
options besides garbage collection. the reason i choose to use c++ is
that for any given allocation, i can choose to do it on the stack, via
manual memory management or smart pointers. whichever works best to suit
the problem at hand.
so perhaps my resistance to garbage collection is a bit irrational. but
i believe that a wholesale switch to garbage collection is a case of
throwing the baby out with the bathwater. it's not hard to demonstrate
that garbage collection isn't perfect, and *not* using it gives you more
options, that usually - at least in my field - are better options.
however - to repeat myself yet again - if garbage collection turns out
to be the best solution for a given problem, i'll use it. whatever works
best.
indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> read the fine print: "allocating a large pool at the start of each
> board/level/or more recently area". that implies also that i would
> deallocate all level data at the end of a level, so all expensive
> operations are between levels. in other words, i may have implemented my
> own garbage collector, but i've done it better than lisp could have.
No you haven't. This is exactly how a garbage collector already works.
Just set the infant generation size to the size of the pool you allocate
there.
> furthermore, i don't *need* to have smart pointers - the memory is
> automatically cleaned up, remember? for those objects which will be hit
> the hardest by being counted - those that hang around the longest or are
> used the most - i would probably choose not to, if i found it too
> wasteful.
So you'd implement a generational GC.
> garbage collectors are neat toys, and they do have their uses sometimes,
> but though the average programmer may be dumb as toast, they're still
> smarter than any garbage collector.
Is that why you advocate that they write a really crappy GC every time
they write a library or application?
> fair enough, except that you can know exactly when those deallocations
> will occur in the non-gc environment, and you can postpone them if you
> really can't afford the time in the current block. in my opinion, that
> negates the advantage.
The whole point of stop-and-copy GC is that you postpone all
"deallocations" (actually, deallocation is a no-op. it's copying that
takes time.) until some point where you'll do the memory management in
one batch.
> beats the hell out of me - i don't program garbage collectors, and i'm
> not really inclined to argue the benefits of one implementation vs.
> another.
And yet you're claiming that refcounting is faster than generational
collectors, rather explicitly.
> and of course, the critical measurement in game performance is the pause
> time. what makes the gc behaviour really bad (besides the obviously
> glaring difference) is that that pause time can theoretically happen
> anywhere, which is hardly ideal.
No, it can theoretically happen anywhere the programmer wants to allow
it.
> maybe you can tune the garbage collector by setting some flags that
> either disable the gc unless you explicitly enable it, or somehow
> amortize that pausing time... but wasn't the gc supposed to eliminate
> being concerned about memory management?
No. GC is supposed to eliminate explicitly managing memory. You let the
GC take care of the mechanics of dealing with the memory and you simply
make sure that you are not leaving any dangling pointers after you're no
longer using some object.
> my argument from the beginning has been: no language or language feature
> solves everything, so use what's best to solve the problem you're trying
> to solve. i fail to see how these numbers don't support that.
>
> my biggest beef with gc languages is that generally they offer no other
> options besides garbage collection. the reason i choose to use c++ is
> that for any given allocation, i can choose to do it on the stack, via
> manual memory management or smart pointers. whichever works best to suit
> the problem at hand.
So instead of having the option of a fast, correct memory management
technique, you prefer a fast, limited-application one, a slow,
limited-purpose one, or a slower, limited-purpose one. You consider that
allowing for the best way to solve different problems?
Lisp, BTW, has a dynamic-extent declaration that the implementation can
use as a signal to allocate an object on the stack. The other cases you
mentioned are useless in a decent Lisp, because they already have a GC.
For more complex memory management situations, the Lisp Machine actually
had a way to switch from using one memory management strategy to another
within a specific code block. For example, some of the low-level code
used manual allocation and deallocation of memory because the GC might
not have been initialized when that code is run, IIRC.
> so perhaps my resistance to garbage collection is a bit irrational. but
> i believe that a wholesale switch to garbage collection is a case of
> throwing the baby out with the bathwater. it's not hard to demonstrate
> that garbage collection isn't perfect, and *not* using it gives you more
> options, that usually - at least in my field - are better options.
That's blatantly wrong. You can always use what Lispers call
"resourcing" where you have a pool of objects and you return objects to
the pool explicitly. Although maintaining free-lists is very difficult
to do in an efficient way.
> however - to repeat myself yet again - if garbage collection turns out
> to be the best solution for a given problem, i'll use it. whatever works
> best.
Any GC is a correct solution to any memory management problem. If it's
not fast enough, you can use a faster one for your allocation and
deallocation patterns, as provided by the language already or by various
libraries.
Often, simply tuning the parameters that are used to decide when to
trigger GC and adjusting allocation of necessarily long-lived objects to
go directly to an older generation will be enough. What would be nice is
a similar allocation option that indicated that the objects allocated in
this block will all be short-lived and should be allocated in a separate
infant generation.
And don't look at Sun's JVM for a fast GC. It's highly suboptimal,
especially when using JTables. It only has 3 generations, with a
mark-and-sweep on the last generation. A good GC should have at least 4
generations, preferably 5 or 6, so that the oldest generation is really
reserved for effectively permanent data.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> read the fine print: "allocating a large pool at the start of each
> board/level/or more recently area". that implies also that i would
> deallocate all level data at the end of a level, so all expensive
> operations are between levels. in other words, i may have implemented my
> own garbage collector, but i've done it better than lisp could have.
Whether or not it's better than what Lisp could have done is an empirical
question, and I don't see any empirical evidence here. Presumably if you
have a reference to some level data, and you make that reference go out of
scope at the end of a level, you'd achieve pretty much the same effect. And
if you are keeping data in memory which is no longer referenced, I really
doubt that this waste of memory will improve performance.
> furthermore, i don't *need* to have smart pointers - the memory is
> automatically cleaned up, remember? for those objects which will be hit
> the hardest by being counted - those that hang around the longest or are
> used the most - i would probably choose not to, if i found it too
> wasteful.
Well OK, you don't need smart pointers because your using an example of a
trivial memory management problem. I.e. load a level, play a level, unload
a level. A GC doesn't need smart pointers to do this either.
> garbage collectors are neat toys, and they do have their uses sometimes,
> but though the average programmer may be dumb as toast, they're still
> smarter than any garbage collector.
I guess the average programmer is also smarter than the part of a C++
compiler which handles lexical variable scoping. Does this mean that
programmers should handle their own variable scoping discipline? This would
allow many useful techniques, such as sharing local variables between
functions which did not call themselves recursively.
> fair enough, except that you can know exactly when those deallocations
> will occur in the non-gc environment, and you can postpone them if you
> really can't afford the time in the current block. in my opinion, that
> negates the advantage.
You can easily postpone a GC by turning it off while some block of code
executes.
> beats the hell out of me - i don't program garbage collectors, and i'm
> not really inclined to argue the benefits of one implementation vs.
> another.
Presumably because you don't know what you're talking about when it comes to
the implementation of GCs. I take it that you accept my point that
reference counting is usually slow compared to more sophisticated methods.
> you and i apparently looked at the same slides and can away with very
> different perceptions. the graph you put up was apparently allocating
> and deallocating lots and lots of small nodes (i estimate 16 bytes)
> repeatedly. because the gc can perform all deallocations en masse and it
> doesn't have to count references i'm not particularly surprised at the
> result.
>
> i can't imagine trying to do that in modern game code. more likely i'd
> use pools, which means these results probably closer approximate
> performance:
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_23.html
> (or
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_24.html)
>
> and of course, the critical measurement in game performance is the pause
> time. what makes the gc behaviour really bad (besides the obviously
> glaring difference) is that that pause time can theoretically happen
> anywhere, which is hardly ideal.
You're completely mistaken to compare your use of pools with a GC allocating
large objects. A GC is going to allocate large pools of memory at a time,
just as you are doing manaully. You may be allocating large pools, but many
of the objects held in these pools are going to be small (objects
representing entities in the game world, data used by game AI code, etc.)
This is exactly what a GC will do for you, it will optimise memory
management by storing small objects in large pools, and as you say,
"deallocating them en masse". If you actually have some large objects, you
presumably won't be losing references to them every few fractions of a
second (certainly not if they represent some kind of persistent game state)
so the overhead from deallocating them will be negligible. Generally, big
objects tend to stick around longer than small objects, so it's not so bad
if they take up a bit more GC time.
If there are critical bits of code where you just cannot have the overhead
of any GC at all, just turn off the GC for that bit of code.
> maybe you can tune the garbage collector by setting some flags that
> either disable the gc unless you explicitly enable it, or somehow
> amortize that pausing time... but wasn't the gc supposed to eliminate
> being concerned about memory management?
I don't think GC was really supposed to do that. Although it does for the
vast majority of the code in the vast majority of programs.
> my argument from the beginning has been: no language or language feature
> solves everything, so use what's best to solve the problem you're trying
> to solve. i fail to see how these numbers don't support that.
Empirical evidence has no bearing on the truth of a platitude.
> my biggest beef with gc languages is that generally they offer no other
> options besides garbage collection. the reason i choose to use c++ is
> that for any given allocation, i can choose to do it on the stack, via
> manual memory management or smart pointers. whichever works best to suit
> the problem at hand.
>
> so perhaps my resistance to garbage collection is a bit irrational. but
> i believe that a wholesale switch to garbage collection is a case of
> throwing the baby out with the bathwater. it's not hard to demonstrate
> that garbage collection isn't perfect, and *not* using it gives you more
> options, that usually - at least in my field - are better options.
Well, the whole argument has been about whether those other options are
actually better.
Alex
Mark A. Gibbs wrote:
>
> Alex Drummond wrote:
>
>>>i make games, and in the context of games, a gc is kind of a silly idea.
>>>generally speaking, my allocation pattern in games tends along the line
>>>of allocating a large pool at the start of each board/level/or more
>>>recently area, then using smart pointers to lock and unlock sections of
>>>that pool as memory is used, then just freeing the entire pool at the
>>>end.
>>
>>
>> I.e. implemeting your own garbage collector. GCs generally allocate big
>> blocks of memory at the start of program execution and then manage the
>> use of those blocks. Using smart pointers is going to be less efficient
>> than using a GC, because reference counting is quite inefficient.
>
> read the fine print: "allocating a large pool at the start of each
> board/level/or more recently area". that implies also that i would
> deallocate all level data at the end of a level, so all expensive
> operations are between levels. in other words, i may have implemented my
> own garbage collector, but i've done it better than lisp could have.
>
> furthermore, i don't *need* to have smart pointers - the memory is
> automatically cleaned up, remember? for those objects which will be hit
> the hardest by being counted - those that hang around the longest or are
> used the most - i would probably choose not to, if i found it too
> wasteful.
>
> garbage collectors are neat toys, and they do have their uses sometimes,
> but though the average programmer may be dumb as toast, they're still
> smarter than any garbage collector.
>
>>>in fact, the gc would take something away, because non-deterministic
>>>deallocations can fugger things up in exactly the wrong place. i already
>>>evaluated java for game design, and this was one of the major blows
>>>against it - you can't control the gc (portably).
>>
>>
>> The amount of time spent freeing dereferenced pointers is also fairly
>> unpredictable. It's perfectly possible to have a GC with some sort of
>> soft-real time constraint, where it's guaranteed that the GC will not
>> spend lots of time freeing memory before allowing other threads of the
>> program CPU time. This sort of guarantee is pretty much impossible to get
>> with reference counting (unless you really want to look at which
>> references get lost when for every code path), so GC seems to have the
>> advantage here.
>
> fair enough, except that you can know exactly when those deallocations
> will occur in the non-gc environment, and you can postpone them if you
> really can't afford the time in the current block. in my opinion, that
> negates the advantage.
>
>>>stop. i have heard that several times in this discussion. i provided
>>>numbers indicating that garbage collection was over 15 times slower than
>>>smart pointers. i have seen absolutely no evidence to the contrary.
>>
>>
>> 1) Your numbers are pretty suspect for reasons I gave earlier.
>
> i agree, but they're still the only ones.
>
>> 2) If reference counting is so damn efficient, /why don't any cutting
>> edge modern GCs use it?/ If reference counting is a fast as you say it
>> is, a modern GC could use it and get equivalent memory management
>> performance to C++ code using smart pointers; you'd get all the speed of
>> C++ without any
>> of the difficulty. You're simply wrong here I'm afraid. Reference
>> counting
>
> beats the hell out of me - i don't program garbage collectors, and i'm
> not really inclined to argue the benefits of one implementation vs.
> another.
>
>> gives very poor space performance (all those reference count fields to
>> store) and unpredictable, slowish time performance. See for example this
>> short discussion of the merits of reference counting smart pointers
>>
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_1.html)
>> including this performance comparison putting a C++ GC ahead of reference
>> counting smart pointers
>>
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_11.html).
>> It also includes an analysis of "maximum pause time", which shows that GC
>> has no great disadvantage here either, especially not in multithreaded
>> code, where thread-safe reference counting is extremely expensive.
>
> you and i apparently looked at the same slides and can away with very
> different perceptions. the graph you put up was apparently allocating
> and deallocating lots and lots of small nodes (i estimate 16 bytes)
> repeatedly. because the gc can perform all deallocations en masse and it
> doesn't have to count references i'm not particularly surprised at the
> result.
>
> i can't imagine trying to do that in modern game code. more likely i'd
> use pools, which means these results probably closer approximate
> performance:
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_23.html
> (or
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_24.html)
>
> and of course, the critical measurement in game performance is the pause
> time. what makes the gc behaviour really bad (besides the obviously
> glaring difference) is that that pause time can theoretically happen
> anywhere, which is hardly ideal.
>
> maybe you can tune the garbage collector by setting some flags that
> either disable the gc unless you explicitly enable it, or somehow
> amortize that pausing time... but wasn't the gc supposed to eliminate
> being concerned about memory management?
>
>> So the numbers don't all come down on your side of the argument, far from
>> it.
>
> my argument from the beginning has been: no language or language feature
> solves everything, so use what's best to solve the problem you're trying
> to solve. i fail to see how these numbers don't support that.
>
> my biggest beef with gc languages is that generally they offer no other
> options besides garbage collection. the reason i choose to use c++ is
> that for any given allocation, i can choose to do it on the stack, via
> manual memory management or smart pointers. whichever works best to suit
> the problem at hand.
>
> so perhaps my resistance to garbage collection is a bit irrational. but
> i believe that a wholesale switch to garbage collection is a case of
> throwing the baby out with the bathwater. it's not hard to demonstrate
> that garbage collection isn't perfect, and *not* using it gives you more
> options, that usually - at least in my field - are better options.
>
> however - to repeat myself yet again - if garbage collection turns out
> to be the best solution for a given problem, i'll use it. whatever works
> best.
>
> indi
> read the fine print: "allocating a large pool at the start of each
> board/level/or more recently area". that implies also that i would
> deallocate all level data at the end of a level, so all expensive
> operations are between levels. in other words, i may have implemented my
> own garbage collector, but i've done it better than lisp could have.
Whether or not it's better than what Lisp could have done is an empirical
question, and I don't see any empirical evidence here. Presumably if you
have a reference to some level data, and you make that reference go out of
scope at the end of a level, you'd achieve pretty much the same effect. And
if you are keeping data in memory which is no longer referenced, I really
doubt that this waste of memory will improve performance.
> furthermore, i don't *need* to have smart pointers - the memory is
> automatically cleaned up, remember? for those objects which will be hit
> the hardest by being counted - those that hang around the longest or are
> used the most - i would probably choose not to, if i found it too
> wasteful.
Well OK, you don't need smart pointers because your using an example of a
trivial memory management problem. I.e. load a level, play a level, unload
a level. A GC doesn't need smart pointers to do this either.
> garbage collectors are neat toys, and they do have their uses sometimes,
> but though the average programmer may be dumb as toast, they're still
> smarter than any garbage collector.
I guess the average programmer is also smarter than the part of a C++
compiler which handles lexical variable scoping. Does this mean that
programmers should handle their own variable scoping discipline? This would
allow many useful techniques, such as sharing local variables between
functions which did not call themselves recursively.
> fair enough, except that you can know exactly when those deallocations
> will occur in the non-gc environment, and you can postpone them if you
> really can't afford the time in the current block. in my opinion, that
> negates the advantage.
You can easily postpone a GC by turning it off while some block of code
executes.
> beats the hell out of me - i don't program garbage collectors, and i'm
> not really inclined to argue the benefits of one implementation vs.
> another.
Presumably because you don't know what you're talking about when it comes to
the implementation of GCs. I take it that you accept my point that
reference counting is usually slow compared to more sophisticated methods.
> you and i apparently looked at the same slides and can away with very
> different perceptions. the graph you put up was apparently allocating
> and deallocating lots and lots of small nodes (i estimate 16 bytes)
> repeatedly. because the gc can perform all deallocations en masse and it
> doesn't have to count references i'm not particularly surprised at the
> result.
>
> i can't imagine trying to do that in modern game code. more likely i'd
> use pools, which means these results probably closer approximate
> performance:
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_23.html
> (or
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_24.html)
>
> and of course, the critical measurement in game performance is the pause
> time. what makes the gc behaviour really bad (besides the obviously
> glaring difference) is that that pause time can theoretically happen
> anywhere, which is hardly ideal.
You're completely mistaken to compare your use of pools with a GC allocating
large objects. A GC is going to allocate large pools of memory at a time,
just as you are doing manaully. You may be allocating large pools, but many
of the objects held in these pools are going to be small (objects
representing entities in the game world, data used by game AI code, etc.)
This is exactly what a GC will do for you, it will optimise memory
management by storing small objects in large pools, and as you say,
"deallocating them en masse". If you actually have some large objects, you
presumably won't be losing references to them every few fractions of a
second (certainly not if they represent some kind of persistent game state)
so the overhead from deallocating them will be negligible. Generally, big
objects tend to stick around longer than small objects, so it's not so bad
if they take up a bit more GC time.
If there are critical bits of code where you just cannot have the overhead
of any GC at all, just turn off the GC for that bit of code.
> maybe you can tune the garbage collector by setting some flags that
> either disable the gc unless you explicitly enable it, or somehow
> amortize that pausing time... but wasn't the gc supposed to eliminate
> being concerned about memory management?
I don't think GC was really supposed to do that. Although it does for the
vast majority of the code in the vast majority of programs.
> my argument from the beginning has been: no language or language feature
> solves everything, so use what's best to solve the problem you're trying
> to solve. i fail to see how these numbers don't support that.
Empirical evidence has no bearing on the truth of a platitude.
> my biggest beef with gc languages is that generally they offer no other
> options besides garbage collection. the reason i choose to use c++ is
> that for any given allocation, i can choose to do it on the stack, via
> manual memory management or smart pointers. whichever works best to suit
> the problem at hand.
>
> so perhaps my resistance to garbage collection is a bit irrational. but
> i believe that a wholesale switch to garbage collection is a case of
> throwing the baby out with the bathwater. it's not hard to demonstrate
> that garbage collection isn't perfect, and *not* using it gives you more
> options, that usually - at least in my field - are better options.
Well, the whole argument has been about whether those other options are
actually better.
Alex
Mark A. Gibbs wrote:
>
> Alex Drummond wrote:
>
>>>i make games, and in the context of games, a gc is kind of a silly idea.
>>>generally speaking, my allocation pattern in games tends along the line
>>>of allocating a large pool at the start of each board/level/or more
>>>recently area, then using smart pointers to lock and unlock sections of
>>>that pool as memory is used, then just freeing the entire pool at the
>>>end.
>>
>>
>> I.e. implemeting your own garbage collector. GCs generally allocate big
>> blocks of memory at the start of program execution and then manage the
>> use of those blocks. Using smart pointers is going to be less efficient
>> than using a GC, because reference counting is quite inefficient.
>
> read the fine print: "allocating a large pool at the start of each
> board/level/or more recently area". that implies also that i would
> deallocate all level data at the end of a level, so all expensive
> operations are between levels. in other words, i may have implemented my
> own garbage collector, but i've done it better than lisp could have.
>
> furthermore, i don't *need* to have smart pointers - the memory is
> automatically cleaned up, remember? for those objects which will be hit
> the hardest by being counted - those that hang around the longest or are
> used the most - i would probably choose not to, if i found it too
> wasteful.
>
> garbage collectors are neat toys, and they do have their uses sometimes,
> but though the average programmer may be dumb as toast, they're still
> smarter than any garbage collector.
>
>>>in fact, the gc would take something away, because non-deterministic
>>>deallocations can fugger things up in exactly the wrong place. i already
>>>evaluated java for game design, and this was one of the major blows
>>>against it - you can't control the gc (portably).
>>
>>
>> The amount of time spent freeing dereferenced pointers is also fairly
>> unpredictable. It's perfectly possible to have a GC with some sort of
>> soft-real time constraint, where it's guaranteed that the GC will not
>> spend lots of time freeing memory before allowing other threads of the
>> program CPU time. This sort of guarantee is pretty much impossible to get
>> with reference counting (unless you really want to look at which
>> references get lost when for every code path), so GC seems to have the
>> advantage here.
>
> fair enough, except that you can know exactly when those deallocations
> will occur in the non-gc environment, and you can postpone them if you
> really can't afford the time in the current block. in my opinion, that
> negates the advantage.
>
>>>stop. i have heard that several times in this discussion. i provided
>>>numbers indicating that garbage collection was over 15 times slower than
>>>smart pointers. i have seen absolutely no evidence to the contrary.
>>
>>
>> 1) Your numbers are pretty suspect for reasons I gave earlier.
>
> i agree, but they're still the only ones.
>
>> 2) If reference counting is so damn efficient, /why don't any cutting
>> edge modern GCs use it?/ If reference counting is a fast as you say it
>> is, a modern GC could use it and get equivalent memory management
>> performance to C++ code using smart pointers; you'd get all the speed of
>> C++ without any
>> of the difficulty. You're simply wrong here I'm afraid. Reference
>> counting
>
> beats the hell out of me - i don't program garbage collectors, and i'm
> not really inclined to argue the benefits of one implementation vs.
> another.
>
>> gives very poor space performance (all those reference count fields to
>> store) and unpredictable, slowish time performance. See for example this
>> short discussion of the merits of reference counting smart pointers
>>
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_1.html)
>> including this performance comparison putting a C++ GC ahead of reference
>> counting smart pointers
>>
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_11.html).
>> It also includes an analysis of "maximum pause time", which shows that GC
>> has no great disadvantage here either, especially not in multithreaded
>> code, where thread-safe reference counting is extremely expensive.
>
> you and i apparently looked at the same slides and can away with very
> different perceptions. the graph you put up was apparently allocating
> and deallocating lots and lots of small nodes (i estimate 16 bytes)
> repeatedly. because the gc can perform all deallocations en masse and it
> doesn't have to count references i'm not particularly surprised at the
> result.
>
> i can't imagine trying to do that in modern game code. more likely i'd
> use pools, which means these results probably closer approximate
> performance:
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_23.html
> (or
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_24.html)
>
> and of course, the critical measurement in game performance is the pause
> time. what makes the gc behaviour really bad (besides the obviously
> glaring difference) is that that pause time can theoretically happen
> anywhere, which is hardly ideal.
>
> maybe you can tune the garbage collector by setting some flags that
> either disable the gc unless you explicitly enable it, or somehow
> amortize that pausing time... but wasn't the gc supposed to eliminate
> being concerned about memory management?
>
>> So the numbers don't all come down on your side of the argument, far from
>> it.
>
> my argument from the beginning has been: no language or language feature
> solves everything, so use what's best to solve the problem you're trying
> to solve. i fail to see how these numbers don't support that.
>
> my biggest beef with gc languages is that generally they offer no other
> options besides garbage collection. the reason i choose to use c++ is
> that for any given allocation, i can choose to do it on the stack, via
> manual memory management or smart pointers. whichever works best to suit
> the problem at hand.
>
> so perhaps my resistance to garbage collection is a bit irrational. but
> i believe that a wholesale switch to garbage collection is a case of
> throwing the baby out with the bathwater. it's not hard to demonstrate
> that garbage collection isn't perfect, and *not* using it gives you more
> options, that usually - at least in my field - are better options.
>
> however - to repeat myself yet again - if garbage collection turns out
> to be the best solution for a given problem, i'll use it. whatever works
> best.
>
> indi
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> as i said before, as far as i'm concerned, all pointers in a garbage
> collected environment are smart pointers. you can all take turns calling
> me ignorant about lisp or generational garbage collection again if you
> like, but i just don't see how gc can be implemented otherwise.
That's because you don't know what you are talking about, and saying
it's so doesn't make it so. Why don't you at least _read_ up on this
topic before posting anymore garbage (so to speak)?
I think that's the real problem here - you clearly don't know the
first thing about this stuff but insist on telling us all how _you_
think it _must_ work because that is how _you_ believe it _must_ be.
Not only a kook, but a megalomaniacal one.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
"Mark A. Gibbs" <···········@rogers.com_x> writes:
> Hannah Schroeter wrote:
> > const std::string& x;
[...]
> you could just as easily create nightmare typo scenarios in any language,
> including plain english. that example is plainly a careless mistake. no one
> and no language can promise that some idiot won't come along and do something
> stupid to muck everything up.
One can do stupid mistakes in any language, but C++ is absolutely at the top
of the list for having single character typos cause so much havoc.
There are just so many pitfalls to be disciplined about it's beyond belief.
C++ is wonderful at providing so much control and abilities to the programmer,
but the cost is death at the slightest relaxing of your guard.
If I had to do a game in a compiled, non-GC language, I would pick Delphi or
even Ada. Delphi has a very well designed OS interface, though, and its easy
to extend its foreign function calls.
If I had to pick an easy-to-use language it would be Java or C#: simple
programming model, garbage collection, easy to train other developers.
If I had to pick the most technically superior language it would be a Lisp
variant. Now if only people would not be so scared of it.
I am not a games developer (just a lurker), and certainly games have real time
considerations, but I am suspecting that the majority of a game's logic can be
expressed in "easy code", code where garbarge collection is not a big deal,
and the speed optimizations that clutter a design are not necessary.
Those performance-centric portions of a game engine can be done in whatever
hacky way that gets the job done: C/C++/ASM. But the callers of the game
engine's services do not themselves need to be high performance -- they need
only invoke the high-performance services.
C++ just doesn't scale well for doing large projects. That is, unless you are
willing to *not* use most of its low level features.
C++ is just too much work. Languages have evolved and there is no reason not
to use a better one.
At the very very least: garbage collection is a step up, a sign of being
civilized. It's like flying a jet versus riding a horse and buggy. The cases
where one does *not* use GC should be in the minority, in very controlled and
planned situations with good reasons.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
All this GC collection talk is not relevant to Console games programming.
On consoles, (PS2, XBox, Gamecube), we use non-fragmenting memory
architectures.
I say WE use it. Its not mandatory, but if you don't use it beware, coz
fragmentation will crash your program (out of memory) way before you are
really out of memory.
In this system, you have a set of chunks (blocks of contiguous memory). Game
objects reside in a particular chunk and allocates come out of that chunks.
Frees do nothing are not used.
When a game is finished with a chunk (ie. you exit the current level) you
through out the chunk completely and all memory is lost.
Thus there is NO fragmentation.
This system also allows us to stream chunks of memory in and out, so we
might have 3 chunks:
A,B
A is used for the game level.
B is used for the game character.
We may switch character by throwing out B and loading up a new character
into B. The level stays in A and is unaffected by the operation.
As I don't know modern LISP, and I've never heard of a LISP game on a
CONSOLE, I can't argue why you can't do this in LISP.
On Tue, 26 Oct 2004, Maahes wrote:
> All this GC collection talk is not relevant to Console games programming.
> On consoles, (PS2, XBox, Gamecube), we use non-fragmenting memory
> architectures.
>
> I say WE use it. Its not mandatory, but if you don't use it beware, coz
> fragmentation will crash your program (out of memory) way before you are
> really out of memory.
>
> In this system, you have a set of chunks (blocks of contiguous memory). Game
> objects reside in a particular chunk and allocates come out of that chunks.
> Frees do nothing are not used.
> When a game is finished with a chunk (ie. you exit the current level) you
> through out the chunk completely and all memory is lost.
>
Sure, variants on pooling seem pretty common in console coding from what
I've heard. If you know all the blocks of memory in a chunk are the same
size, would you consider running a GC anyway? This'd give you a
combination of no fragmentation (owing to how the memory's allocated) and
not having to wait 'til the end of the chunk's lifetime to reclaim memory.
--
······@flippac.org
Hello!
Maahes <······@internode.on.net> wrote:
>[...]
>In this system, you have a set of chunks (blocks of contiguous memory). Game
>objects reside in a particular chunk and allocates come out of that chunks.
>Frees do nothing are not used.
>When a game is finished with a chunk (ie. you exit the current level) you
>through out the chunk completely and all memory is lost.
Sounds like what MLkit with Regions does *automatically* (i.e. it
analyzes the code for code regions in which a specific set of objects
is created and after which all of that set is definitely dead).
It does so for SML, which is defined as a language with automatic
memory management (and usually implemented with a GC, but that's not
mandated, and there was a version of the ML kit which relied *only*
on region analysis, i.e. no GC at run time, but no "free" instructions
in the source code either; since there are cases where that's
disadvantageous, they now use a combination of regions and GC IIRC).
>[...]
Kind regards,
Hannah.
On Mon, 25 Oct 2004 14:22:32 +0000, Alex Drummond
<··········@ucl.ac.uk> wrote:
>Have you ever seen a VB program segfault?
Plenty of times.
>>> 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.
>>
>> So what? It also makes the Prototype Pattern a pain in the nuts. These
>> issues are not in the domain, they are just implementation alternatives.
>
>This makes no sense. Higher order functions are a win, period. Function
>objects are just less powerful than higher order functions (assuming that
>these functions are closures). If you've been paying attention to R&D in
>programming languages for the past 20-30 years, you'll notice that higher
>order functions are one abstraction mechanism that just about every new
>language has adopted (often prior to the development of C++). They're so
>useful that some people have invested a lot of time into hacking some kind
>of HOF facility into C++ (c.f. the Boost Lambda Library).
Definitions of "higher order" for functions vary but what C++ actually
lacks natively is lexical closures - which can be emulated by function
objects and nested classes.
>>> 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.
>>
>> Prefer pass-by-reference above all other kinds, because its cognitively
>> efficient and usually execution efficient.
>
>"Usually" being the operative word. You're also missing the OP's point
>completely. If you pass by reference, you enormously increase the
>complexity of your memory management code. Sure, C++ has lots of ways to
>encapsulate this complexity, but you still have to deal with it, and the
>common methods of doing this amount to using a buggy and rather inefficient
>GC.
This line of arguement is so ridiculous it almost doesn't merit
response. I've coded professionally in C/C++ for almost 2 decades.
I've written real time embedded software, network applications, an
operating system and several compilers. I can count on my fingers the
number of times I've been bitten by non trivial memory management
problems. The same goes for most other experienced C/C++ programmers
I've met - it just isn't an issue.
What I have experienced, however, is the following:
Decent C/C++ programmers who come to Lisp (or other GC'd languages)
very quickly become spoiled by having Mom around to clean up after
them. Because they now find themselves rarely thinking about memory
management in contrast to the near constant awareness they had
previously, the times they really had a problem stand out and tend to
be exaggerated in their memories (though not intentionally I think).
OTOH, decent Lisp programmers who find themselves having to work in
C/C++ have problems because they normally don't have to think about
cleaning up after themselves and Mom isn't around to do it for them.
So they tend to have problems whenever they confront C/C++ and thus
have a distorted view of the reality of programming with it.
I like Lisp (well actually I like Scheme better) far more than C++,
but automatic memory management has little to do with my reasons.
Learning to program involves learning effective resource management.
I could easily argue that programmers who learn high level, GC'd
languages first are done a disservice and are not as competent because
they don't learn effective memory management.
Programmer competency and experience are the real issues and they are
independent of language.
George
--
for email reply remove "/" from address
>>Have you ever seen a VB program segfault?
>
> Plenty of times.
I was wondering how long it would be before someone said that. Now, if
Visual Basic actually provides a direct means of attempting to access out
of bounds memory, you have a point, and I'd have to use some other high
level language as an example (I don't know for sure that it doesn't because
I don't know the language). If a VB program segfaulted via an external C
library (e.g. by passing incorrect arguments to some external function,
etc.) you're just being pedantic.
> Definitions of "higher order" for functions vary but what C++ actually
> lacks natively is lexical closures - which can be emulated by function
> objects and nested classes.
Not really. Function objects have to capture bindings manually, so the
emulation is rather clumsy. OK, you can use nested classes, but it's still
a PITA to define a class just to capture a few lexical bindings -- in Lisp
I can capture whichever bindings I like whenever I like, without any
hassle. The syntax for function objects is generally rather verbose. Using
higher order functions in C++ just isn't cheap enough to make it a widely
useful technique, especially when the types start getting complicated. If
you look at the kind of higher order functions which are trivial to write
in a strongly typed language like ML or Haskell, the type system of C++ is
just not up to the job regarding higher order functions. Of course, C++ is
not meant to be a functional language, and I'm not saying that it should
be. But some people like to pretend that it's trivial to simulate
functional programming features in C++, when it isn't.
> This line of arguement is so ridiculous it almost doesn't merit
> response. I've coded professionally in C/C++ for almost 2 decades.
> I've written real time embedded software, network applications, an
> operating system and several compilers. I can count on my fingers the
> number of times I've been bitten by non trivial memory management
> problems. The same goes for most other experienced C/C++ programmers
> I've met - it just isn't an issue.
That's funny, because I've only written small to medium sized programs in
C++, and I'm always getting bitten by nontrivial memory management issues
(e.g. you get nontrivial memory management issues if ever you want to have
complex expressions composed of objects without copying them, as you might
for example in a parser combinator library). There are plenty of very
experienced C++ programmers who say exactly the opposite of what you say
(many of them, of course, have subsequently moved to Lisp/Java/whatever). I
know I keep pointing to this, but if memory management is so trivial for
everyone, why would Boehm GC have been developed? See
http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html, where he says for
example:
"...commonly proposed estimates are that 30% or 40% of development time is
devoted to storage management for programs that manipulate complex linked
data structures. (See, for example, Rovner, ``On Adding Garbage Collection
and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent
Language'', PARC CSL-84-7.)"
Now I'm willing to bet that Hans Boehm has written a few big C++ programs in
his time.
> Decent C/C++ programmers who come to Lisp (or other GC'd languages)
> very quickly become spoiled by having Mom around to clean up after
> them. Because they now find themselves rarely thinking about memory
> management in contrast to the near constant awareness they had
> previously, the times they really had a problem stand out and tend to
> be exaggerated in their memories (though not intentionally I think).
In other words, they realise what an enormous PITA memory management
actually is. You don't realise this until you do some serious programming
in a GC'd language. As you say, in C++ you have to maintain a "near
constant awareness".
> OTOH, decent Lisp programmers who find themselves having to work in
> C/C++ have problems because they normally don't have to think about
> cleaning up after themselves and Mom isn't around to do it for them.
> So they tend to have problems whenever they confront C/C++ and thus
> have a distorted view of the reality of programming with it.
Well, my view of programming in C++ is that it's rarely worth the effort. I
don't have any more problems with C++ than your average C++ programmer, I
don't think, I just /resent/ it more. Maybe this is what you meant.
> I like Lisp (well actually I like Scheme better) far more than C++,
> but automatic memory management has little to do with my reasons.
> Learning to program involves learning effective resource management.
> I could easily argue that programmers who learn high level, GC'd
> languages first are done a disservice and are not as competent because
> they don't learn effective memory management.
Yawn. If you learn C you don't learn effective processor register
management. If you suddenly find that you need to know about memory
management in detail, you can always buy a book on it, or indeed learn C,
if you think that would help. I'd also note that the ignorance goes the
other way. Many C++ programmers have a poor knowledge of GC.
> Programmer competency and experience are the real issues and they are
> independent of language.
If they are the real issues, why are you making such a big deal out of Lisp
vs C++? Everyone knows that they're not the only issues. Anyone who's (say)
tried writing a text-munging program in C instead of Perl will know this.
Differences between languages are significant.
Alex
George Neuner wrote:
> On Mon, 25 Oct 2004 14:22:32 +0000, Alex Drummond
> <··········@ucl.ac.uk> wrote:
>
>>Have you ever seen a VB program segfault?
>
> Plenty of times.
>
>
>>>> 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.
>>>
>>> So what? It also makes the Prototype Pattern a pain in the nuts. These
>>> issues are not in the domain, they are just implementation alternatives.
>>
>>This makes no sense. Higher order functions are a win, period. Function
>>objects are just less powerful than higher order functions (assuming that
>>these functions are closures). If you've been paying attention to R&D in
>>programming languages for the past 20-30 years, you'll notice that higher
>>order functions are one abstraction mechanism that just about every new
>>language has adopted (often prior to the development of C++). They're so
>>useful that some people have invested a lot of time into hacking some kind
>>of HOF facility into C++ (c.f. the Boost Lambda Library).
>
> Definitions of "higher order" for functions vary but what C++ actually
> lacks natively is lexical closures - which can be emulated by function
> objects and nested classes.
>
>
>>>> 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.
>>>
>>> Prefer pass-by-reference above all other kinds, because its cognitively
>>> efficient and usually execution efficient.
>>
>>"Usually" being the operative word. You're also missing the OP's point
>>completely. If you pass by reference, you enormously increase the
>>complexity of your memory management code. Sure, C++ has lots of ways to
>>encapsulate this complexity, but you still have to deal with it, and the
>>common methods of doing this amount to using a buggy and rather
>>inefficient GC.
>
> This line of arguement is so ridiculous it almost doesn't merit
> response. I've coded professionally in C/C++ for almost 2 decades.
> I've written real time embedded software, network applications, an
> operating system and several compilers. I can count on my fingers the
> number of times I've been bitten by non trivial memory management
> problems. The same goes for most other experienced C/C++ programmers
> I've met - it just isn't an issue.
>
> What I have experienced, however, is the following:
>
> Decent C/C++ programmers who come to Lisp (or other GC'd languages)
> very quickly become spoiled by having Mom around to clean up after
> them. Because they now find themselves rarely thinking about memory
> management in contrast to the near constant awareness they had
> previously, the times they really had a problem stand out and tend to
> be exaggerated in their memories (though not intentionally I think).
>
> OTOH, decent Lisp programmers who find themselves having to work in
> C/C++ have problems because they normally don't have to think about
> cleaning up after themselves and Mom isn't around to do it for them.
> So they tend to have problems whenever they confront C/C++ and thus
> have a distorted view of the reality of programming with it.
>
> I like Lisp (well actually I like Scheme better) far more than C++,
> but automatic memory management has little to do with my reasons.
> Learning to program involves learning effective resource management.
> I could easily argue that programmers who learn high level, GC'd
> languages first are done a disservice and are not as competent because
> they don't learn effective memory management.
>
> Programmer competency and experience are the real issues and they are
> independent of language.
>
> George
On Thu, 28 Oct 2004 13:20:04 +0000, Alex Drummond
<··········@ucl.ac.uk> wrote:
>>>Have you ever seen a VB program segfault?
>>
>> Plenty of times.
>
>I was wondering how long it would be before someone said that. Now, if
>Visual Basic actually provides a direct means of attempting to access out
>of bounds memory, you have a point, and I'd have to use some other high
>level language as an example (I don't know for sure that it doesn't because
>I don't know the language). If a VB program segfaulted via an external C
>library (e.g. by passing incorrect arguments to some external function,
>etc.) you're just being pedantic.
Its pretty near impossible in the latest incarnation (based on .NET)
but earlier versions could easily be broken passing data to and from a
COM control. Since COM integration was supposed to be one of VB's
strengths, the relative ease of screwing it up was troublesome.
>> Definitions of "higher order" for functions vary but what C++ actually
>> lacks natively is lexical closures - which can be emulated by function
>> objects and nested classes.
>
>Not really. Function objects have to capture bindings manually, so the
>emulation is rather clumsy. OK, you can use nested classes, but it's still
>a PITA to define a class just to capture a few lexical bindings -- in Lisp
>I can capture whichever bindings I like whenever I like, without any
>hassle. The syntax for function objects is generally rather verbose. Using
>higher order functions in C++ just isn't cheap enough to make it a widely
>useful technique, especially when the types start getting complicated. If
>you look at the kind of higher order functions which are trivial to write
>in a strongly typed language like ML or Haskell, the type system of C++ is
>just not up to the job regarding higher order functions. Of course, C++ is
>not meant to be a functional language, and I'm not saying that it should
>be. But some people like to pretend that it's trivial to simulate
>functional programming features in C++, when it isn't.
I don't pretend it is trivial to emulate lexical closures in C++ and I
completely agree that trying it is far from convenient. I'm not sure
what constitutes "verbose" as regards function operators - you only
define them once so it doesn't matter how ugly that is and calls look
like any other function call.
Regarding higher order, I said definitions vary. It is certainly easy
enough to pass functions as parameters and return them as results.
The stumbling block to general effectiveness is the lack of easy
closures.
>> This line of arguement is so ridiculous it almost doesn't merit
>> response. I've coded professionally in C/C++ for almost 2 decades.
>> I've written real time embedded software, network applications, an
>> operating system and several compilers. I can count on my fingers the
>> number of times I've been bitten by non trivial memory management
>> problems. The same goes for most other experienced C/C++ programmers
>> I've met - it just isn't an issue.
>
>That's funny, because I've only written small to medium sized programs in
>C++, and I'm always getting bitten by nontrivial memory management issues
>(e.g. you get nontrivial memory management issues if ever you want to have
>complex expressions composed of objects without copying them, as you might
>for example in a parser combinator library). There are plenty of very
>experienced C++ programmers who say exactly the opposite of what you say
>(many of them, of course, have subsequently moved to Lisp/Java/whatever). I
>know I keep pointing to this, but if memory management is so trivial for
>everyone, why would Boehm GC have been developed? See
>http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html, where he says for
>example:
>
>"...commonly proposed estimates are that 30% or 40% of development time is
>devoted to storage management for programs that manipulate complex linked
>data structures. (See, for example, Rovner, ``On Adding Garbage Collection
>and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent
>Language'', PARC CSL-84-7.)"
>
>Now I'm willing to bet that Hans Boehm has written a few big C++ programs in
>his time.
I'm also willing to bet Boehm has written plenty of big programs. I
also have written very big and complicated programs. I do question
the statistic that 30% (or whatever) of development time is spent on
memory management - I have never found that to be anywhere close to
being true. I don't have rigorous numbers but a guesstimate based on
my own experience would be closer to 5% for an experienced C++ coder.
It becomes automatic like breathing. Specifying how to cleanup is
part of defining an object and complex data structures are modeled as
objects. It is the second thing you do right after specifying how to
construct the object. And notice I said "construct" rather than
"initialize" ... those being separate concepts in C++.
It's largely a matter of coding dicipline and good design.
>> Decent C/C++ programmers who come to Lisp (or other GC'd languages)
>> very quickly become spoiled by having Mom around to clean up after
>> them. Because they now find themselves rarely thinking about memory
>> management in contrast to the near constant awareness they had
>> previously, the times they really had a problem stand out and tend to
>> be exaggerated in their memories (though not intentionally I think).
>
>In other words, they realise what an enormous PITA memory management
>actually is. You don't realise this until you do some serious programming
>in a GC'd language. As you say, in C++ you have to maintain a "near
>constant awareness".
Yes but as I said above, the "near constant awareness" is largely on
auto pilot. You don't think about it as a problem because it's an
integral part of your life.
>> OTOH, decent Lisp programmers who find themselves having to work in
>> C/C++ have problems because they normally don't have to think about
>> cleaning up after themselves and Mom isn't around to do it for them.
>> So they tend to have problems whenever they confront C/C++ and thus
>> have a distorted view of the reality of programming with it.
>
>Well, my view of programming in C++ is that it's rarely worth the effort. I
>don't have any more problems with C++ than your average C++ programmer, I
>don't think, I just /resent/ it more. Maybe this is what you meant.
That's exactly what I meant but I was coming at it from a different
angle. Most complicated Lisp programs eventually end up in the FFI
and I believe this is the source of most Lisp users' frustration with
C/C++.
In my experience, people who learned lower level languages
(C,C++,Pascal, etc.) first and then discovered the higher level
languages have fewer problems changing gears than do people who
learned the high level language first and learned the lower in order
to work with the FFI.
>> I like Lisp (well actually I like Scheme better) far more than C++,
>> but automatic memory management has little to do with my reasons.
>> Learning to program involves learning effective resource management.
>> I could easily argue that programmers who learn high level, GC'd
>> languages first are done a disservice and are not as competent because
>> they don't learn effective memory management.
>
>Yawn. If you learn C you don't learn effective processor register
>management. If you suddenly find that you need to know about memory
>management in detail, you can always buy a book on it, or indeed learn C,
>if you think that would help. I'd also note that the ignorance goes the
>other way.
Register management is not germane to this discussion - the subject of
which is languages above the assembler level.
Memory is an important resource which must be managed even in Lisp.
Witness the many newbies who get into trouble because they forgot to
let go of bindings. Teaching using very high level languages results
in important concepts being glossed over or ignored completely.
> Many C++ programmers have a poor knowledge of GC.
Many Lisp programmers do also. Out of sight means out of mind.
>> Programmer competency and experience are the real issues and they are
>> independent of language.
>
>If they are the real issues, why are you making such a big deal out of Lisp
>vs C++? Everyone knows that they're not the only issues. Anyone who's (say)
>tried writing a text-munging program in C instead of Perl will know this.
>Differences between languages are significant.
I don't give a rat about Lisp vs. C++ or whether you or anyone else
here likes Lisp or C++. Somebody else started this "big deal" and
others are still continuing it as I write this. I'm responding to
what I considered to be an unfair characterization of one of the main
topics of the discussion.
George
--
for email reply remove "/" from address
George Neuner wrote:
> Its pretty near impossible in the latest incarnation (based on .NET)
> but earlier versions could easily be broken passing data to and from a
> COM control. Since COM integration was supposed to be one of VB's
> strengths, the relative ease of screwing it up was troublesome.
OK, but I think the gist of my original point still stands.
George Neuner wrote:
> I'm not sure
> what constitutes "verbose" as regards function operators - you only
> define them once so it doesn't matter how ugly that is and calls look
> like any other function call.
Verbose compared to an anonymous lambda function. Especially when C++
doesn't allow class definitions within functions/methods (last time I
checked). Perhaps "inconvenient" would be more on the mark than "verbose".
George Neuner wrote:
> Regarding higher order, I said definitions vary. It is certainly easy
> enough to pass functions as parameters and return them as results.
> The stumbling block to general effectiveness is the lack of easy
> closures.
OK, so we (gasp!) pretty much agree here.
George Neuner wrote:
> I'm also willing to bet Boehm has written plenty of big programs. I
> also have written very big and complicated programs. I do question
> the statistic that 30% (or whatever) of development time is spent on
> memory management - I have never found that to be anywhere close to
> being true. I don't have rigorous numbers but a guesstimate based on
> my own experience would be closer to 5% for an experienced C++ coder.
I think we'll just have to agree to differ here. If you have a complex data
structure in your C++ program, you have to spend some significant time and
effort deciding how you're going to manage it, especially if it needs to be
accessed from several bits of code. (Yes, of course you don't want lots of
different modules munging the same data, but sometimes you have to have
this, and the best you can do is write a high-level interface to the shared
data structure to prevent it being corrupted completely if something goes
wrong). Garbage collection can make handling this sort of situation
significantly easier, since you can mostly forget about keeping track of
which module needs which bit of data kept alive. More than 5% easier in my
personal experience at least.
Probably we can't have a sensible argument over this now. I'm not saying
your 5% figure is wrong for you, but I just don't have that experience
myself.
George Neuner wrote:
> It becomes automatic like breathing. Specifying how to cleanup is
> part of defining an object and complex data structures are modeled as
> objects. It is the second thing you do right after specifying how to
> construct the object. And notice I said "construct" rather than
> "initialize" ... those being separate concepts in C++.
Right, but:
1) I find thinking about how I'm going to manage the memory of some trivial
little object quite opressive. (And C was my first programming language if
you don't count Basic, so this isn't because I was brought up with GC).
2) It's just not that simple if you're dealing with complex data.
George Neuner wrote:
> In my experience, people who learned lower level languages
> (C,C++,Pascal, etc.) first and then discovered the higher level
> languages have fewer problems changing gears than do people who
> learned the high level language first and learned the lower in order
> to work with the FFI.
Probably in general with regard to high-level and low-level languages this
is true. But really, I think most Lisp programmers these days learned C
first.
George Neuner wrote:
> Memory is an important resource which must be managed even in Lisp.
> Witness the many newbies who get into trouble because they forgot to
> let go of bindings. Teaching using very high level languages results
> in important concepts being glossed over or ignored completely.
Any Lisp education which omits scope and extent is incomplete, and newbies
almost by definition frequently get into trouble. I expect they forget to
call delete in C++ more than (or at least as much as) they forget to let go
of bindings in GC'd language. You can teach memory management concepts in a
GC'd language, though you may well be correct that such concepts often get
glossed over. If this is the case, it ought to be fixed ;)
Alex
George Neuner wrote:
> On Thu, 28 Oct 2004 13:20:04 +0000, Alex Drummond
> <··········@ucl.ac.uk> wrote:
>
>>>>Have you ever seen a VB program segfault?
>>>
>>> Plenty of times.
>>
>>I was wondering how long it would be before someone said that. Now, if
>>Visual Basic actually provides a direct means of attempting to access out
>>of bounds memory, you have a point, and I'd have to use some other high
>>level language as an example (I don't know for sure that it doesn't
>>because I don't know the language). If a VB program segfaulted via an
>>external C library (e.g. by passing incorrect arguments to some external
>>function, etc.) you're just being pedantic.
>
> Its pretty near impossible in the latest incarnation (based on .NET)
> but earlier versions could easily be broken passing data to and from a
> COM control. Since COM integration was supposed to be one of VB's
> strengths, the relative ease of screwing it up was troublesome.
>
>
>>> Definitions of "higher order" for functions vary but what C++ actually
>>> lacks natively is lexical closures - which can be emulated by function
>>> objects and nested classes.
>>
>>Not really. Function objects have to capture bindings manually, so the
>>emulation is rather clumsy. OK, you can use nested classes, but it's still
>>a PITA to define a class just to capture a few lexical bindings -- in Lisp
>>I can capture whichever bindings I like whenever I like, without any
>>hassle. The syntax for function objects is generally rather verbose. Using
>>higher order functions in C++ just isn't cheap enough to make it a widely
>>useful technique, especially when the types start getting complicated. If
>>you look at the kind of higher order functions which are trivial to write
>>in a strongly typed language like ML or Haskell, the type system of C++ is
>>just not up to the job regarding higher order functions. Of course, C++ is
>>not meant to be a functional language, and I'm not saying that it should
>>be. But some people like to pretend that it's trivial to simulate
>>functional programming features in C++, when it isn't.
>
> I don't pretend it is trivial to emulate lexical closures in C++ and I
> completely agree that trying it is far from convenient. I'm not sure
> what constitutes "verbose" as regards function operators - you only
> define them once so it doesn't matter how ugly that is and calls look
> like any other function call.
>
> Regarding higher order, I said definitions vary. It is certainly easy
> enough to pass functions as parameters and return them as results.
> The stumbling block to general effectiveness is the lack of easy
> closures.
>
>
>>> This line of arguement is so ridiculous it almost doesn't merit
>>> response. I've coded professionally in C/C++ for almost 2 decades.
>>> I've written real time embedded software, network applications, an
>>> operating system and several compilers. I can count on my fingers the
>>> number of times I've been bitten by non trivial memory management
>>> problems. The same goes for most other experienced C/C++ programmers
>>> I've met - it just isn't an issue.
>>
>>That's funny, because I've only written small to medium sized programs in
>>C++, and I'm always getting bitten by nontrivial memory management issues
>>(e.g. you get nontrivial memory management issues if ever you want to have
>>complex expressions composed of objects without copying them, as you might
>>for example in a parser combinator library). There are plenty of very
>>experienced C++ programmers who say exactly the opposite of what you say
>>(many of them, of course, have subsequently moved to Lisp/Java/whatever).
>>I know I keep pointing to this, but if memory management is so trivial for
>>everyone, why would Boehm GC have been developed? See
>>http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html, where he says
>>for example:
>>
>>"...commonly proposed estimates are that 30% or 40% of development time is
>>devoted to storage management for programs that manipulate complex linked
>>data structures. (See, for example, Rovner, ``On Adding Garbage Collection
>>and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent
>>Language'', PARC CSL-84-7.)"
>>
>>Now I'm willing to bet that Hans Boehm has written a few big C++ programs
>>in his time.
>
> I'm also willing to bet Boehm has written plenty of big programs. I
> also have written very big and complicated programs. I do question
> the statistic that 30% (or whatever) of development time is spent on
> memory management - I have never found that to be anywhere close to
> being true. I don't have rigorous numbers but a guesstimate based on
> my own experience would be closer to 5% for an experienced C++ coder.
>
> It becomes automatic like breathing. Specifying how to cleanup is
> part of defining an object and complex data structures are modeled as
> objects. It is the second thing you do right after specifying how to
> construct the object. And notice I said "construct" rather than
> "initialize" ... those being separate concepts in C++.
>
> It's largely a matter of coding dicipline and good design.
>
>
>
>>> Decent C/C++ programmers who come to Lisp (or other GC'd languages)
>>> very quickly become spoiled by having Mom around to clean up after
>>> them. Because they now find themselves rarely thinking about memory
>>> management in contrast to the near constant awareness they had
>>> previously, the times they really had a problem stand out and tend to
>>> be exaggerated in their memories (though not intentionally I think).
>>
>>In other words, they realise what an enormous PITA memory management
>>actually is. You don't realise this until you do some serious programming
>>in a GC'd language. As you say, in C++ you have to maintain a "near
>>constant awareness".
>
> Yes but as I said above, the "near constant awareness" is largely on
> auto pilot. You don't think about it as a problem because it's an
> integral part of your life.
>
>
>
>>> OTOH, decent Lisp programmers who find themselves having to work in
>>> C/C++ have problems because they normally don't have to think about
>>> cleaning up after themselves and Mom isn't around to do it for them.
>>> So they tend to have problems whenever they confront C/C++ and thus
>>> have a distorted view of the reality of programming with it.
>>
>>Well, my view of programming in C++ is that it's rarely worth the effort.
>>I don't have any more problems with C++ than your average C++ programmer,
>>I don't think, I just /resent/ it more. Maybe this is what you meant.
>
> That's exactly what I meant but I was coming at it from a different
> angle. Most complicated Lisp programs eventually end up in the FFI
> and I believe this is the source of most Lisp users' frustration with
> C/C++.
>
> In my experience, people who learned lower level languages
> (C,C++,Pascal, etc.) first and then discovered the higher level
> languages have fewer problems changing gears than do people who
> learned the high level language first and learned the lower in order
> to work with the FFI.
>
>
>>> I like Lisp (well actually I like Scheme better) far more than C++,
>>> but automatic memory management has little to do with my reasons.
>>> Learning to program involves learning effective resource management.
>>> I could easily argue that programmers who learn high level, GC'd
>>> languages first are done a disservice and are not as competent because
>>> they don't learn effective memory management.
>>
>>Yawn. If you learn C you don't learn effective processor register
>>management. If you suddenly find that you need to know about memory
>>management in detail, you can always buy a book on it, or indeed learn C,
>>if you think that would help. I'd also note that the ignorance goes the
>>other way.
>
> Register management is not germane to this discussion - the subject of
> which is languages above the assembler level.
>
> Memory is an important resource which must be managed even in Lisp.
> Witness the many newbies who get into trouble because they forgot to
> let go of bindings. Teaching using very high level languages results
> in important concepts being glossed over or ignored completely.
>
>> Many C++ programmers have a poor knowledge of GC.
>
> Many Lisp programmers do also. Out of sight means out of mind.
>
>
>>> Programmer competency and experience are the real issues and they are
>>> independent of language.
>>
>>If they are the real issues, why are you making such a big deal out of
>>Lisp vs C++? Everyone knows that they're not the only issues. Anyone who's
>>(say) tried writing a text-munging program in C instead of Perl will know
>>this. Differences between languages are significant.
>
> I don't give a rat about Lisp vs. C++ or whether you or anyone else
> here likes Lisp or C++. Somebody else started this "big deal" and
> others are still continuing it as I write this. I'm responding to
> what I considered to be an unfair characterization of one of the main
> topics of the discussion.
>
>
> George
On Thu, 28 Oct 2004 21:56:45 +0000, Alex Drummond
<··········@ucl.ac.uk> wrote:
>George Neuner wrote:
>> I'm not sure
>> what constitutes "verbose" as regards function operators - you only
>> define them once so it doesn't matter how ugly that is and calls look
>> like any other function call.
>
>Verbose compared to an anonymous lambda function. Especially when C++
>doesn't allow class definitions within functions/methods (last time I
>checked). Perhaps "inconvenient" would be more on the mark than "verbose".
Ok, I'll buy that. I also appreciate the anonymous lambda.
>George Neuner wrote:
>> I'm also willing to bet Boehm has written plenty of big programs. I
>> also have written very big and complicated programs. I do question
>> the statistic that 30% (or whatever) of development time is spent on
>> memory management - I have never found that to be anywhere close to
>> being true. I don't have rigorous numbers but a guesstimate based on
>> my own experience would be closer to 5% for an experienced C++ coder.
>
>I think we'll just have to agree to differ here. If you have a complex data
>structure in your C++ program, you have to spend some significant time and
>effort deciding how you're going to manage it, especially if it needs to be
>accessed from several bits of code. (Yes, of course you don't want lots of
>different modules munging the same data, but sometimes you have to have
>this, and the best you can do is write a high-level interface to the shared
>data structure to prevent it being corrupted completely if something goes
>wrong). Garbage collection can make handling this sort of situation
>significantly easier, since you can mostly forget about keeping track of
>which module needs which bit of data kept alive. More than 5% easier in my
>personal experience at least.
>
>Probably we can't have a sensible argument over this now. I'm not saying
>your 5% figure is wrong for you, but I just don't have that experience
>myself.
I've seen the same 30..40% figures bandied about in the literature. I
just don't know where those figures come from and I dispute whether
they really apply to professional coders. I can readily believe they
apply to a survey of college students with little programming
experience beyond class projects.
I'm sure I spent that much time thinking about data structuring when I
first learned to program and had little experience, but after doing it
for a few years, working on different types of applications and seeing
what kinds of data structuring patterns different problems fall into,
I found the need to think real hard to find a good solution for most
problems went away and I could spend time instead applying thought to
those problems that really required an optimal solution.
Relatively few problems require an optimal data structure. A good one
recognized quickly is very often all you need. Spending a whole lot
of time thinking out the best data structure is one form of premature
optimization. It may be necessary in the end, but you rarely know it
when you start.
>
>George Neuner wrote:
>> It becomes automatic like breathing. Specifying how to cleanup is
>> part of defining an object and complex data structures are modeled as
>> objects. It is the second thing you do right after specifying how to
>> construct the object. And notice I said "construct" rather than
>> "initialize" ... those being separate concepts in C++.
>
>Right, but:
>
>1) I find thinking about how I'm going to manage the memory of some trivial
>little object quite opressive. (And C was my first programming language if
>you don't count Basic, so this isn't because I was brought up with GC).
That's a valid point of view, but my answer to it is just don't use
languages that require it (which you don't).
I think an honest debate on the merits and shortcomings of different
languages is useful. The problem is debate too often degenerates into
flame wars and exaggerations. I don't think it is fair to castigate
any particular language publicly. That only serves to incite others
who don't share [the generic] your opinion and frighten newbies who
don't have one yet.
>
>2) It's just not that simple if you're dealing with complex data.
>
A lot of reading helps as a starting point. I probably spend 10% of
my [ total work and off ] time reviewing and cross indexing literature
on a wide variety of software subjects. I also believe in anal
retentive note keeping on interesting problem solutions I come across.
>George Neuner wrote:
>> Memory is an important resource which must be managed even in Lisp.
>> Witness the many newbies who get into trouble because they forgot to
>> let go of bindings. Teaching using very high level languages results
>> in important concepts being glossed over or ignored completely.
>
>Any Lisp education which omits scope and extent is incomplete, and newbies
>almost by definition frequently get into trouble. I expect they forget to
>call delete in C++ more than (or at least as much as) they forget to let go
>of bindings in GC'd language. You can teach memory management concepts in a
>GC'd language, though you may well be correct that such concepts often get
>glossed over. If this is the case, it ought to be fixed ;)
>
No argument. I just pointing out that newbies get into trouble with
memory regardless of language. The rather prevalent cites of GC'd
languages as a boon to teaching are IMO red herrings. The sooner the
student is confronted with the harsh realities of resource management,
the better they will learn ( or give up on programming altogether
which serves to raise the average compentency in the field ).
George
--
for email reply remove "/" from address
George Neuner wrote:
> I think an honest debate on the merits and shortcomings of different
> languages is useful. The problem is debate too often degenerates into
> flame wars and exaggerations. I don't think it is fair to castigate
> any particular language publicly. That only serves to incite others
> who don't share [the generic] your opinion and frighten newbies who
> don't have one yet.
All practical* computer languages are implicitly theories - that
language x is an efficient notation for programmers to express
algorithms with. Your suggestion, that languages (or their users) should
be above attack, would more or less freeze the evolution of practical
computer science, wouldn't it? When you say you don't think it is
"fair", are you implying that languages have rights, or that users of
consciousness-expanding languages shouldn't pick on users of languages
suited more to bookkeepers and bean-counters?
* - Languages like Brainf*ck, Unlambda and Befunge, deliberately
designed to be turing complete yet painful to use, are proof that
languages vary in expressivity and ease of use.
--
Cameron MacKinnon
Toronto, Canada
On Fri, 29 Oct 2004 19:22:50 -0400, Cameron MacKinnon
<··········@clearspot.net> wrote:
>George Neuner wrote:
>> I think an honest debate on the merits and shortcomings of different
>> languages is useful. The problem is debate too often degenerates into
>> flame wars and exaggerations. I don't think it is fair to castigate
>> any particular language publicly. That only serves to incite others
>> who don't share [the generic] your opinion and frighten newbies who
>> don't have one yet.
>
>All practical* computer languages are implicitly theories - that
>language x is an efficient notation for programmers to express
>algorithms with. Your suggestion, that languages (or their users) should
>be above attack, would more or less freeze the evolution of practical
>computer science, wouldn't it? When you say you don't think it is
>"fair", are you implying that languages have rights, or that users of
>consciousness-expanding languages shouldn't pick on users of languages
>suited more to bookkeepers and bean-counters?
>
I said the level of debate should be above condemnation of choices and
instead should focus on the reasons for those choices and whether or
not the choices are valid for their intended purpose. The designers
of each language had reasons for making the choices they did. [the
generic] You may not agree with the choices made but they should be
respected as being valid for their intended purpose unless you can
offer incontravertable proof that the choices were wrong.
When I speak of "fairness" I am referring to the rights of *people*
who are reading this debate. They have the right not to be misled by
offerings of incorrect or incomplete information, by questionable
opinions of people who have little or no experience with the language
in question, and further from malicious attack by people who do know
what they are talking about but have an axe to grind.
Language debates are rarely debates ... they too often degenerate into
religious warfare. Let's keep things civil and have a thoughtful
discussion.
>* - Languages like Brainf*ck, Unlambda and Befunge, deliberately
>designed to be turing complete yet painful to use, are proof that
>languages vary in expressivity and ease of use.
So what? I'm not attacking those languages or calling anyone stupid
for using them.
George
--
for email reply remove "/" from address
George Neuner wrote:
> I said the level of debate should be above condemnation of choices and
> instead should focus on the reasons for those choices and whether or
> not the choices are valid for their intended purpose. The designers
> of each language had reasons for making the choices they did. [the
> generic] You may not agree with the choices made but they should be
> respected as being valid for their intended purpose unless you can
> offer incontravertable proof that the choices were wrong.
C was designed as a portable assembler to ease the writing and
maintenance of an operating system of a few thousand lines, fitting into
RAM of a few thousand words. This happened about 35 years ago.
C++ was designed as a preprocessor to be upward compatible with C.
Possibly because the designer couldn't write, or didn't want to be
bothered writing his own compiler. Valid? Sure - for him, fifteen years
ago. He saw C as broken, but knew that a new language wouldn't gain
acceptance, so he gave the world C with a bag on the side.
Committees have since added a few things to the spec. Each member of a
committee typically has constituents' pet interests to represent; things
he wants to get into the language. To do so, he'll typically support
other members' pet interests in exchange for support of his own. Should
I respect these choices as being valid? Taken in aggregate, they tend to
lead to bloated languages which are a nightmare for compiler
implementors and often language users as well. You spoke of choices as
being valid "for their intended purpose". Am I to respect language
misfeatures if their original intended purpose was to placate vendor X's
biggest customer, or so vendor Y wouldn't have to rewrite so much code?
So sorry, if a committee serves up a steaming pile of crap, I'm not
going to salute it no matter how well intentioned they were. If a
language makes me work harder than I need to in 2004, I don't care
whether it made work easier for the person who invented it back when men
were men and we didn't comment code because we couldn't afford the extra
Hollerith cards.
> When I speak of "fairness" I am referring to the rights of *people*
> who are reading this debate. They have the right not to be misled by
> offerings of incorrect or incomplete information, by questionable
> opinions of people who have little or no experience with the language
> in question, and further from malicious attack by people who do know
> what they are talking about but have an axe to grind.
Are you reading this thread via a gateway on Encyclopaedia Britannica's
website? Because if so, you should know that it's originating on USENET,
where our motto is "you get what you pay for, and then some."
> Language debates are rarely debates ... they too often degenerate into
> religious warfare. Let's keep things civil and have a thoughtful
> discussion.
Dude, you read from and posted into a thread entitled "C++ sucks for
games." If anything, I'd say the thread has been improving.
--
Cameron MacKinnon
Toronto, Canada
George Neuner <·········@comcast.net> writes:
> Relatively few problems require an optimal data structure. A good one
> recognized quickly is very often all you need. Spending a whole lot
> of time thinking out the best data structure is one form of premature
> optimization. It may be necessary in the end, but you rarely know it
> when you start.
So why should you spend excessive amounts of time building
infrastructure to manage copying and refcounting and coming up with
policies for doing that when you could just use a GC, even if it's a bit
less optimal?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Hello!
Phlip <·········@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.
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/bin/view/Main/TestFirstUserInterfaces
Hello!
Phlip <·········@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.
"Phlip" <·········@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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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/bin/view/Main/TestFirstUserInterfaces
On Mon, 25 Oct 2004 14:26:16 GMT, "Phlip" <·········@yahoo.com> wrote:
>
>"Neo-LISPer" <··········@yahoo.com> wrote in message
>···················@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
> 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 ······@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
Neo-LISPer wrote:
> Some senseless stuff
Besides your poor trolling attempts (most of your arguments just show that
you have no knowledge of C++) you don't even tell us what the alternative
to C++ in game programming could be.
--
To get my real email adress, remove the two onkas
--
Hendrik Belitz
- Abort, Retry, Fthagn? -
I think he's suggesting its Lisp...
"Hendrik Belitz" <················@fz-juelich.de> wrote in message
····················@uni-berlin.de...
> Neo-LISPer wrote:
>
>> Some senseless stuff
>
> Besides your poor trolling attempts (most of your arguments just show that
> you have no knowledge of C++) you don't even tell us what the alternative
> to C++ in game programming could be.
>
> --
> To get my real email adress, remove the two onkas
> --
> Hendrik Belitz
> - Abort, Retry, Fthagn? -
Hendrik Belitz schrieb:
> Neo-LISPer wrote:
>
>
>>Some senseless stuff
>
>
> Besides your poor trolling attempts
> (most of your arguments just show that
> you have no knowledge of C++) you don't
> even tell us what the alternative
> to C++ in game programming could be.
>
I think his posting was in regard to a nonsense article that was shortly
discussed in the Lisp-newsgroup. An X-Box designer who used Lisp over a
decade ago "analysed" Lisp for the development of modern computer games.
After making some false assumptions he came to the conclusion that one
should better not do it in Lisp.
Andr�
--
Not easy to understand for non-germans: http://tinyurl.com/64x7y
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).
c++ is typically much better at accessing c code than most other languages.
any other issues are fairly minor (there is a lack of convinient syntax for
many things, but these things are not that hard to pull off through other
means). some things would be nice (syntactic closures and lexical scoping,
...), but do not justify many other costs.
using languages other than c or c++ tends to end up being more expensive.
this post can be generally be referred to as trolling, however.
"Neo-LISPer" <··········@yahoo.com> wrote in message
···················@yahoo.com...
> 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.
"cr88192" <·······@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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <·····@nyct.net> wrote in message
···················@nyct.net...
> "cr88192" <·······@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.
Neo-LISPer wrote:
> 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.
<snip>
> 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.
<snip>
> 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.
<snip>
I guess the answer is: if you can't find anyone to join your C++ team,
start your project in a language that everyone likes.
Have you checked out D? It addresses a handful of your issues....
http://www.digitalmars.com/d/
Stewart.
Stewart Gordon <·········@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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Stewart Gordon <·········@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.
Neo-LISPer wrote:
> Hey
>
> Recently, I researched using C++ for game programming and here is what
> I found:
[Snip -- This section already commented on by others elsethread.]
>It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.
It is your opinion and you are welcome to it.
My observation from watching shows on video games is that there
are only a handful of different types. My guess is that the
engine is written in some language, Pascal, C++, Lisp, and
each "level" is written in a higher level language. Once the
engine is working, they don't change it. Most of the changes
are made using the higher level language. A video game project
doesn't want its time wasted in coding up each level in C++,
C, Pascal, Ada or whatever. A less time-consuming method is
to write each level using a higher level language. Many
game shops have specialized languages for their engines.
Perhaps you need to learn that the choice of the language
is not the issue. The issue is the quality of the product
that one can produce using the given language. If the
shop dictates that assembly is the language, then the
company must produce the best quality product using
assembly. In many shops, there is no choice on which
language can be used. You use their language and live
with it.
So if you are independently developing games, then by
all means, use the language you are most comfortable
with. However, do the rest of us a favor and keep
your opinions of other languages to yourself. The
issue of the "best" language for a given project is
and will always be a religous issue.
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
"Neo-LISPer" <··········@yahoo.com> wrote in message
···················@yahoo.com...
Personally, I couldn't care less! What're you trying to accomplish, change
someone's mind? No, you're just trolling. So get lost, and let us do some
real work.
-Howard
"Neo-LISPer" has been quoting the "Mike Cox" known-troll in his sig in
some previous postings to comp.lang.lisp [1] I gave him the benefit of
the doubt for a few posts, but that might tell you where he's coming
from if you've encountered "Mike Cox" trolling before. For some reason
"Mike Cox" started attempting to troll comp.lang.lisp a while back,
too, it's even possible Neo-LISPer and Mike Cox are the same person.
Note that it may more innocent (even if it is Mike Cox!), could be just
the overenthusiastic lisp newbie effect (no one more zealous than the
recently converted) - if so, then, Neo-LISPer, please don't do that.
Two wrongs don't make a right [2].
I urge people in both language communities to write games in whatever
languages they bloody well feel like, and to not feed the trolls. Like
I probably just did by posting this. Gaah.
[1]
http://groups.google.com/groups?q=group:comp.lang.lisp+Mike+Cox+neo-lisper&hl=en&lr=&ie=UTF-8&selm=87breve2mx.fsf%40yahoo.com&rnum=1
[2] See recent silly "Why Lisp Sucks for Games" thread on comp.lang.lisp
caused by an article by someone self-identifying as a microsoft c++
programmer and apparently feeling some compulsion to attack (somewhat
poorly) the use of lisp in games. Or, better, don't...
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.
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...
"Neo-LISPer" <··········@yahoo.com> wrote in message
···················@yahoo.com...
> 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.
In article <··········@duster.adelaide.on.net>,
"Maahes" <······@internode.on.net> 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.
>
> 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.
Recursion takes a while to get the hang of, but not long and then it can
be quite elegant.
kenny
Kenneth Tilton <·······@nyc.rr.com> writes:
> Recursion takes a while to get the hang of, but not long and then it can
> be quite elegant.
In my C/C++ programming daze, I used to use recursion when
appropriate. Comming from Basic and Fortran 77, C's ability to do
recursion was actually quite nice.
As for that (trimmed) long division problem... I thought the /
opperator handled that.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
>> 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
> 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
>> :) 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...
"Maahes" <······@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
"Maahes" <······@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/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html
Then you can write the function like this:
(defun distance (a time vi)
#I "0.5*a*time*time + vi*time")
The nice thing is, that it doesn't require any runtime time, because the
macro creates the usual Lisp prefix form at compile-time (more exact: at
read time). You can take a look at the interactive REPL how it would
look like, just type in this:
(macroexpand '#I "0.5*a*time*time + vi*time")
and it prints this:
(+ (* 0.5 A TIME TIME) (* VI TIME))
Would be nice sometimes for C-macros to have such an interactive test of
macros, for example for the Microsoft MFC ones :-)
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
JKop <····@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.
"Mario S. Mommer" <········@yahoo.com> wrote in message
···················@germany.igpm.rwth-aachen.de...
>
> JKop <····@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.
Personally I find 1/2 against natural writing (at least in maths).
I put everything above a /2 ...
So the equation would be: (a*sqr(t)+v*t)/2
Although I come from a BASIC background and don't know about the / in C++ .
--
=========
Comp Whizz
=========
(The C++ beginner)
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...
"Maahes" <······@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�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
"Maahes" <······@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
Maahes schrieb:
> 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...
For a beginner it might be mental gymnastics. Like with gymnastics your
brain gets trained. After some time you have no problems to use prefix
notation for things for which you usually use infix notation.
As someone already mentioned, if you want you can get infix notation.
But if you want to get everything with prefix notation in C++... how
would you then do that? ;-)
Andr�
--
http://tinyurl.com/64x7y
>
>
>>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!
>> 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" <······@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
"Maahes" <······@internode.on.net> writes:
> S = 1.0/2.0*a*sqr(t) + vi*t;
Matthew Danish <··········@cmu.edu> writes:
> $S=\frac{1}{2}at^{2} + v_{i}t$
I write:
(= S (+ (* 1/2 a (^ t 2)) (* (v i) t)))
I don't see much difference between these forms.
> THAT is what mathematical notation looks like. The garbage you
> propose above, although widely adopted, is still a perversion.
Anything from:
ftp://publications.ai.mit.edu/ai-publications/0-499/AIM-145.ps
to:
http://www-sop.inria.fr/lemme/Loic.Pottier/ei98.ps
So you'd want to program like this:
(deformula "
1 2
S = --- a t + v t
2 i
")
Note that in ASCII-art, it's still quite parseable.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon wrote:
> So you'd want to program like this:
>
> (deformula "
> 1 2
> S = --- a t + v t
> 2 i
> ")
>
> Note that in ASCII-art, it's still quite parseable.
>
Actually, I'd like to use a math-aware editor that would take special
keystrokes and interpret them to build a mathematical expression visually.
Like Mathematica does, if you've used it. (Or Lyx, although not as well.)
That's neither here nor there, though; no language known to me does that,
although I'm sure I could make Lisp do it with the appropriate editor
extensions. The same goes for C, though, even if I *would* have to use
comments for things they were never meant to do.
Matthew Danish <··········@cmu.edu> writes:
> 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.
But Wall Street isn't in Jersey. :P
In an app I'm working on, bond coupon payment rates are stored as
fractional values (6.25% coupon is stored as 0.0625). They are then
multiplied back by 100 for displaying on screen. Of course, the lost
precision causes the number to sometimes be displayed on screen with
lots of trailing 9s or 0s and a 1 if they use the "convenient"
overloading of the + operator in Java to do string formatting using some
arbitrary format and concatenation. I used Lisp to analyze the
FP-representation (using decode-float) and made a little writeup about
how it's impossible to store such numbers accurately in FP. Ironically,
if they hadn't divided the rate by 100, FP would be fine because all
fixed coupon rates are multiples of 1/8, so the denominator will always
be a power of 2. Fun, fun.
:)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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
"Andr� Thieme" <······························@justmail.de> wrote in message
·················@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)
In article <············@newsg3.svr.pol.co.uk>,
"Computer Whizz" <···········@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.
Sashank Varma <····@vanderbilt.edu> writes:
> In article <············@newsg3.svr.pol.co.uk>,
> "Computer Whizz" <···········@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?
"Petter Gustad" <·············@gustad.com> wrote in message
···················@scimul.dolphinics.no...
> Sashank Varma <····@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)
"Computer Whizz" <···········@hotmail.com> writes:
> "Petter Gustad" <·············@gustad.com> wrote in message
> ···················@scimul.dolphinics.no...
> > Sashank Varma <····@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?
"Petter Gustad" <·············@gustad.com> wrote in message
···················@scimul.dolphinics.no...
> "Computer Whizz" <···········@hotmail.com> writes:
>
>> "Petter Gustad" <·············@gustad.com> wrote in message
>> ···················@scimul.dolphinics.no...
>> > Sashank Varma <····@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)
> 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" <·············@gustad.com> wrote in message
> ···················@scimul.dolphinics.no...
>> "Computer Whizz" <···········@hotmail.com> writes:
>>
>>> "Petter Gustad" <·············@gustad.com> wrote in message
>>> ···················@scimul.dolphinics.no...
>>> > Sashank Varma <····@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.
>
Alex Drummond <··········@ucl.ac.uk> writes:
>> 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.
One other thing that can be a bit confusing for folks who are
coming from a C background is that you can't easily compose
functions in C, so nested function calls look strange.
--jon
Alex Drummond wrote:
>> 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.
>
Actually, I've found that building up complex arithmetic expressions is
easier in Lisp than with normal arithmetic notation, because I can
immediately see the tree-structure involved.
This isn't always true, of course.
"Computer Whizz" <···········@hotmail.com> writes:
> No, it was the implementation of all those darned ()'s and spaces.
> I like the more natural way than that used in Lisp - that's all.
> It had nothing to do with Complex.
I notice that in the above paragraph, you mostly use spaces to
separate symbols. A comma only appears once. More generally, white
space seems to be the standard seperator for symbols in lists:
Shopping list:
lettuce
bacon
tomatoes
bread
mayonnaise
chips
dip
You also seem to be used to prefix notation for function calls:
foo(x);
Well, (foo x) is hardly any different. It has the same number of
parens and does not require a statement terminator. The advantage of
Lisp's notation becomes most evident when you need to write a macro.
Lisp code is expressed as Lisp lists. The full power of Lisp is
available to manipulate lists so that you can write arbitrarily
complex macros. This is not the case with macro systems that only
manipulate text.
The simple syntax also means that editors can provide more assistance
to the programmer. If you type something out of whack, it often shows
up clearly in the editor.
Best of all, Lisp can express programs with less code than most other
languages. This is less code to write, read, and debug. Programming
is more productive. Python programmers make the same argument when
comparing Python to, say, Java. The difference is, Lisp does not
suffer the performance penalty that Python does even though the code
is just about as concise.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Computer Whizz schrieb:
> "Petter Gustad" <·············@gustad.com> wrote in message
> ···················@scimul.dolphinics.no...
>
>>"Computer Whizz" <···········@hotmail.com> writes:
>>
>>
>>>"Petter Gustad" <·············@gustad.com> wrote in message
>>>···················@scimul.dolphinics.no...
>>>
>>>>Sashank Varma <····@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.
You already showed in one example that you used the correct syntax. So
if it was difficult for you this time that you probably did not look at
it like you did before.
(+ 2/3 2/3 1/3) is in C++:
2./3. + 2./3. + 1./3. or also:
(float)2/(float)3 + (float)2/(float)3 + (float)1/(float)3;
Now *that* is not so natural, is it? ;-)
In Lisp you not only have integers or floats, you also have rationals
which are always accurate (but slower because they don't use the
floating point unit) and even complex numbers.
Complex numbers need some special way to write them down. This is
similar to C where you need to say that 2 is a float by writing it
either 2. or 2.0 or (float)2 or maybe float(2)
C++ does not have complex numbers, Lisp does, and you write them down
this way:
#C(real i)
for example #C(3 3)
Of course + does work on complex numbers too. And you don't have to do
explicit operator overloading and you are lucky, you don't need to write
a class "Complex", *cheers*
Andr�
--
http://tinyurl.com/64x7y
Andr� Thieme <······························@justmail.de> wrote:
> C++ does not have complex numbers, Lisp does, and you write them down
> this way:
> #C(real i)
> for example #C(3 3)
C++ has complex numbers, defined as a template:
http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss schrieb:
> Andr� Thieme <······························@justmail.de> wrote:
>
>
>>C++ does not have complex numbers, Lisp does, and you write them down
>>this way:
>>#C(real i)
>>for example #C(3 3)
>
>
> C++ has complex numbers, defined as a template:
>
> http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html
>
Yes, that's right. However, they are still not so easy accessible like
the infix operators in our earlier discussions. Therefore complex
numbers would need to be included in the base language. If you need them
for just one part in your program, then do this in C++:
(+ #C(3 4) 25)
Just look at the example program on the site you posted.
Have fun
Andr�
--
http://tinyurl.com/64x7y
"Andr� Thieme" <······························@justmail.de> wrote in message
·················@ulric.tng.de...
> Frank Buss schrieb:
>
>> Andr� Thieme <······························@justmail.de> wrote:
>>
>>
>>>C++ does not have complex numbers, Lisp does, and you write them down
>>>this way:
>>>#C(real i)
>>>for example #C(3 3)
>>
>>
>> C++ has complex numbers, defined as a template:
>>
>> http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html
>>
>
> Yes, that's right. However, they are still not so easy accessible like the
> infix operators in our earlier discussions. Therefore complex numbers
> would need to be included in the base language. If you need them for just
> one part in your program, then do this in C++:
> (+ #C(3 4) 25)
>
> Just look at the example program on the site you posted.
>
> Have fun
>
>
> Andr�
> --
> http://tinyurl.com/64x7y
True, C++ does have some missing things from it's "base" language (Oh how I
sorely missed strings at first glance when I first tried C++)...
But I did get to realise about using chr[] and chr* quite soon, and then
including the <string> library.
I read a bit on that D programming language mentioned somewhere, about
complex numbers being much easier to use - and indeed it seemed so.
And no - the trouble with Lisp to begin with is trying to find the "core" ()
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.
So before I pass out - I shall post this message and retire.
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <···········@hotmail.com> writes:
> "Andr� Thieme" <······························@justmail.de> wrote in message
> ·················@ulric.tng.de...
> > Frank Buss schrieb:
>
> And no - the trouble with Lisp to begin with is trying to find the "core" ()
> and work outwards from there - kind of backward to my natural way of
> thinking... Like reading right-to-left.
> The one's I've quoted are short.
>
I think you are fundamentally misunderstanding Lisp program structure.
Unless you've happened to land in the middle of some huge FP example,
Lisp reads like any other procedural language.
Gregm
"Computer Whizz" <···········@hotmail.com> wrote in message news:<············@news7.svr.pol.co.uk>...
> "Andr� Thieme" <······························@justmail.de> wrote in message
> ·················@ulric.tng.de...
> > Frank Buss schrieb:
> >
> >> Andr� Thieme <······························@justmail.de> wrote:
> >>
> >>
> >>>C++ does not have complex numbers, Lisp does, and you write them down
> >>>this way:
> >>>#C(real i)
> >>>for example #C(3 3)
> >>
> >>
> >> C++ has complex numbers, defined as a template:
> >>
> >> http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html
> >>
> >
> > Yes, that's right. However, they are still not so easy accessible like the
> > infix operators in our earlier discussions. Therefore complex numbers
> > would need to be included in the base language. If you need them for just
> > one part in your program, then do this in C++:
> > (+ #C(3 4) 25)
> >
> > Just look at the example program on the site you posted.
> >
> > Have fun
> >
> >
> > Andr�
> > --
> > http://tinyurl.com/64x7y
>
> True, C++ does have some missing things from it's "base" language (Oh how I
> sorely missed strings at first glance when I first tried C++)...
> But I did get to realise about using chr[] and chr* quite soon, and then
> including the <string> library.
>
> I read a bit on that D programming language mentioned somewhere, about
> complex numbers being much easier to use - and indeed it seemed so.
>
> And no - the trouble with Lisp to begin with is trying to find the "core" ()
What trouble with Lisp? What is your Lisp experience?
> and work outwards from there - kind of backward to my natural way of
> thinking... Like reading right-to-left.
> The one's I've quoted are short.
That is actually wrong; to properly understand a Lisp expression, you
must work from outside in. You first consider it to be a list, where
the first element denotes the identity of the operator. Otherwise you
can get tripped up. For instance, suppose you had:
(defclass a (foo b c) ..)
If you were looking from the inside out, you might think that there is
a function call (FOO B C). But in fact, this is a DEFCLASS form, where
class A is being defined, and its base classes (multiple inheritance)
are FOO, B and C. The DEFCLASS operator has complete control over the
interpretation of the rest of the form; you have to know its semantics
in order to understand that form.
You read the form left to right. The main connective is always
leftmost. Its constituents can be read from left to right, and their
connectives are also on the left and so forth. Speaking of Forth, that
is the language you must be thinking of which requires some right to
left thinking.
The C and C++ languages have plenty of prefix forms. Function calls:
f(g(x, y), z); // analogous to (f (g x y) z)
sizeof (char *); // sizeof operator is prefixed
return 3; // return operator
if ...
for ...
while ...
switch ...
class ...
All prefix operators, like in Lisp. Oh yes and there are lists all
over the place in C++ source. Lists of function and template
arguments, lists of declarations and statements, lists of base
classes, lists of base class initializers, lists of this lists of
that. They all have inconsistent syntax with each other! Semicolon
terminators here, comma separators there. Initial colon elsewhere. In
Lisp source code, anything that is a list has the same syntax as any
other list, whether it be a list of arguments, list of base classes,
list of variable forms in a LET or whatever.
As to your other point, it is actually infix syntax which forces you
to get to the ``inner core'' just to discover what operation is being
done and get the gist of the expression. Consider the case where you
have:
< ... some long expression ...> + < .. some long expression ...>
You have to parse the thing just to find out that the + buried in the
middle is the main connective. To parse it you have to take into
account operator precedence, associativity and all that. Until you do
the parse, you don't even know that it's an additive expression.
Lisp was deliberately designed so that the main connective is easy to
find without parsing. This isn't a coincidence; it makes it easier to
write code which analyzes and processes code. Such code is found in
Lisp macros, which are parts of a Lisp program that extend the
language with new syntax and semantics that other parts of a program
use.
> So before I pass out - I shall post this message and retire.
Please tell us it's for good.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
[ ... ]
> > And no - the trouble with Lisp to begin with is trying to find the "core"
> > ()
>
> What trouble with Lisp? What is your Lisp experience?
Lisp has a number of problems, particularly fragmentation. The
fragmentation _has_ reduced considerably since CL was invented, but
unfortunately CL is, in some ways, the worst possible dialect.
I can't speak for the person to whom you were posting, but my Lisp
experience includes having used it off and on for 20+ years, and
having written three (or four, depending on your viewpoint)
implementations during that time.
[ ... ]
> Speaking of Forth, that
> is the language you must be thinking of which requires some right to
> left thinking.
While Forth (using RPN) obviously does, Lisp does as well, for at
least some situations, particularly mathematical ones, and for almost
exactly the same reason: in both cases, what starts as a mathematical
expression has to be transcribed into the language so the syntax
directly expresses the precedence of operations that are implied in
the original expression.
OTOH, none of the above really compares with APL for right-to-left
reading.
[ ... ]
> if ...
> for ...
> while ...
> switch ...
> class ...
>
> All prefix operators, like in Lisp.
Pardon my pointing out the obvious, but in C or C++, none of the above
is an operator at all.
> Oh yes and there are lists all
> over the place in C++ source. Lists of function and template
> arguments, lists of declarations and statements, lists of base
> classes, lists of base class initializers, lists of this lists of
> that. They all have inconsistent syntax with each other! Semicolon
> terminators here, comma separators there. Initial colon elsewhere. In
> Lisp source code, anything that is a list has the same syntax as any
> other list, whether it be a list of arguments, list of base classes,
> list of variable forms in a LET or whatever.
Partly true, but not entirely so -- in particular, see below about
M-expressions.
[ ... ]
> Lisp was deliberately designed so that the main connective is easy to
> find without parsing. This isn't a coincidence; it makes it easier to
> write code which analyzes and processes code. Such code is found in
> Lisp macros, which are parts of a Lisp program that extend the
> language with new syntax and semantics that other parts of a program
> use.
When John McCarthy designed Lisp, the intent was that S-expressions
would be used for data. Programmers were intended to write code using
M-expressions, which have a syntax more like other languages,
including some inconsistencies, such as using a mixture of parentheses
and square brackets, as well as sometimes putting the first item in a
list outside the brackets and sometimes inside.
The original intent was that M-expressions would be translated to
S-expressions, and then those would be interpreted. As a first step,
an interpreter that accepted S-expressions was written. Before a
front-end, or even a syntax for the language it would accept, was
finished, the S-expression syntax had been accepted to the extent that
M-expressions never materialized.
You might (even well be right to) believe that Lisp is better off for
this, but claiming it was a deliberate design, at the very best,
distorts the facts beyond recognition.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
> ...
> When John McCarthy designed Lisp, the intent was that S-expressions
> would be used for data. Programmers were intended to write code using
> M-expressions, which have a syntax more like other languages,
> including some inconsistencies, such as using a mixture of parentheses
> and square brackets, as well as sometimes putting the first item in a
> list outside the brackets and sometimes inside.
>
> The original intent was that M-expressions would be translated to
> S-expressions, and then those would be interpreted. As a first step,
> an interpreter that accepted S-expressions was written. Before a
> front-end, or even a syntax for the language it would accept, was
> finished, the S-expression syntax had been accepted to the extent that
> M-expressions never materialized.
iirc, one of the many texts on the history of lisp went into detail abut
that: the people working on and with this interpreter discovered
macros, used then heavily, and saw no way how to preserve their power
when switching to M-expressions
> ...
hs
Hartmann Schaffer <··@hartmann.schaffernet> writes:
> Jerry Coffin wrote:
>> ...
>> When John McCarthy designed Lisp, the intent was that S-expressions
>> would be used for data. Programmers were intended to write code using
>> M-expressions, which have a syntax more like other languages,
>> including some inconsistencies, such as using a mixture of parentheses
>> and square brackets, as well as sometimes putting the first item in a
>> list outside the brackets and sometimes inside.
>> The original intent was that M-expressions would be translated to
>> S-expressions, and then those would be interpreted. As a first step,
>> an interpreter that accepted S-expressions was written. Before a
>> front-end, or even a syntax for the language it would accept, was
>> finished, the S-expression syntax had been accepted to the extent that
>> M-expressions never materialized.
>
> iirc, one of the many texts on the history of lisp went into detail
> abut that: the people working on and with this interpreter discovered
> macros, used then heavily, and saw no way how to preserve their power
> when switching to M-expressions
I have the Lisp 1.5 manual and I, for one, find M-exps to be more
difficult to read than S-exps. And, although I use emacs quite
regularly, I also about 20% of my time in a REPL w/out a
"lisp-aware" editor. I don't generally have problems with
mismatched () either.
On a related note, I'm also quite capable of taking a conversation
on multiple, nested tangents w/out losing track of how to complete
each tangent and get back to the conslusion of the main thread of
conversation.
Lisp just works more closely to how my brain works.
--jon
·······@taeus.com (Jerry Coffin) wrote in message news:<···························@posting.google.com>...
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> [ ... ]
>
> > if ...
> > for ...
> > while ...
> > switch ...
> > class ...
> >
> > All prefix operators, like in Lisp.
>
> Pardon my pointing out the obvious, but in C or C++, none of the above
> is an operator at all.
It's true that the operator terminology is not used in this way in the
defining documents for these languages. However, it's not inaccurate
to call these operators, and there is a vacancy for calling them
something.
This is a statement: while (<expr>) <statement>
This is a reserved keyword: while
But what do you call the *role* that the keyword plays within the
statement? I would argue that it's an operator. It distinguishes the
semantics from something else like if (<expr>) <statement>.
Some other symbols in C have two names. For example = is sometimes an
operator (in assignment expressions) and sometimes a punctuator
(separating the initializing expression in a declarator).
And then there is the sizeof keyword, whose job description in a unary
expression is that of operator. (Also, typeid in C++).
My second remark is that it would be an obvious extension to the
semantics of C to allow statements to have return values. In fact such
extensions exist; for example in GNU C, the last expression evaluated
in a brace-enclosed block is yielded as a value.
C borrows from Lisp the idea that evaluation is performed by
expressions, including side effects such as assignment, and even these
yield result values. But then the idea is screwed up by the
introduction of statements which don't propagate result value. In
principle, compound statements, selection statements and others could
actually be expressions. If that were the case, it would be even more
obvious to call the keywords operators, in analogy with sizeof.
> > Oh yes and there are lists all
> > over the place in C++ source. Lists of function and template
> > arguments, lists of declarations and statements, lists of base
> > classes, lists of base class initializers, lists of this lists of
> > that. They all have inconsistent syntax with each other! Semicolon
> > terminators here, comma separators there. Initial colon elsewhere. In
> > Lisp source code, anything that is a list has the same syntax as any
> > other list, whether it be a list of arguments, list of base classes,
> > list of variable forms in a LET or whatever.
>
> Partly true, but not entirely so -- in particular, see below about
> M-expressions.
M-expressions survive in disguised form in various functional
languages, which are about as readable as line noise.
> > Lisp was deliberately designed so that the main connective is easy to
> > find without parsing. This isn't a coincidence; it makes it easier to
> > write code which analyzes and processes code. Such code is found in
> > Lisp macros, which are parts of a Lisp program that extend the
> > language with new syntax and semantics that other parts of a program
> > use.
>
> When John McCarthy designed Lisp, the intent was that S-expressions
> would be used for data. Programmers were intended to write code using
> M-expressions, which have a syntax more like other languages,
> including some inconsistencies, such as using a mixture of parentheses
> and square brackets, as well as sometimes putting the first item in a
> list outside the brackets and sometimes inside.
I should have said *is* designed. I'm referring to the current design,
not to the various bad ideas that were discarded or shunted along the
way toward that design.
> The original intent was that M-expressions would be translated to
> S-expressions, and then those would be interpreted. As a first step,
> an interpreter that accepted S-expressions was written. Before a
> front-end, or even a syntax for the language it would accept, was
> finished, the S-expression syntax had been accepted to the extent that
> M-expressions never materialized.
>
> You might (even well be right to) believe that Lisp is better off for
> this, but claiming it was a deliberate design, at the very best,
> distorts the facts beyond recognition.
Sure it was a deliberate design. It just hadn't been suspected that
the syntax would gain that level of acceptance as a primary way to
input code. McCarthy's intuition suggested to him that it would be
regarded as a disadvantage.
Common Lisp actually captures that original intent by supporting a
programmable lexical analyzer, in which you can set up custom
notations. There exists a highly portable infix package in which you
can write something like:
f(x, y, a[i + j] += 3)
the custom reader converts it to the list object:
(f x y (incf (aref (+ i j)) 3))
I don't know of any project which uses that. There don't seem to be
takers for this, like there weren't any takers for M-expressions way
back when. The syntactic masochists are using things like CAML or
Haskell.
By the way, I should mention that C++ pays my bills. I'm a long-time C
and C++ programmer, in addition to many other things. I didn't become
interested in Lisp until I was around 31 years old. I never
encountered it at university. There were some Scheme courses, but I
got equivalent credit for them from another school. I heard that
Scheme was some dumbed-down Lisp for teaching, and so I smelled
trouble (and now I know how right I had been!) There was a programming
languages course that served as a prerequisite for the upper level
compiler construction course, but I got around that one as well! I
talked to the prof and his concern was simply whether I can handle the
flow of assignments that lead up to the working compiler, and I
replied that I was a solid C hacker, and so he said okay. ;)
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
·································@posting.google.com...
> "Computer Whizz" <···········@hotmail.com> wrote in message
> news:<············@news7.svr.pol.co.uk>...
>>
>> And no - the trouble with Lisp to begin with is trying to find the "core"
>> ()
>
> What trouble with Lisp? What is your Lisp experience?
Very little experience, I have only seen what is in this newsgroup thread.
I do however correct myself and claim "my" trouble.
>
>> and work outwards from there - kind of backward to my natural way of
>> thinking... Like reading right-to-left.
>> The one's I've quoted are short.
>
> That is actually wrong; to properly understand a Lisp expression, you
> must work from outside in. You first consider it to be a list, where
> the first element denotes the identity of the operator. Otherwise you
> can get tripped up. For instance, suppose you had:
>
> (defclass a (foo b c) ..)
As Jerry has replied - it is indeed important to find the core in maths
problems (all/99%) of which I have see in here, while also some function
calls. You need to scan to see a rough idea, then re-scan to perhaps see the
parameters and then rescan again to see the function calls.
The above looks at a quick scan (without paying attention to defclass) as a
function foo being called, as you say below... But after moving leftward the
mind is corrected.
>
> If you were looking from the inside out, you might think that there is
> a function call (FOO B C). But in fact, this is a DEFCLASS form, where
> class A is being defined, and its base classes (multiple inheritance)
> are FOO, B and C. The DEFCLASS operator has complete control over the
> interpretation of the rest of the form; you have to know its semantics
> in order to understand that form.
>
> You read the form left to right. The main connective is always
> leftmost. Its constituents can be read from left to right, and their
> connectives are also on the left and so forth. Speaking of Forth, that
> is the language you must be thinking of which requires some right to
> left thinking.
>
> The C and C++ languages have plenty of prefix forms. Function calls:
>
> f(g(x, y), z); // analogous to (f (g x y) z)
Now here it is much better for C/C++ IMO.
parameters are passed using the ()'s to group them together, and the
function outside. While in Lisp, the function and parameters are in exactly
the same place.
For me it's exactly like writing this post but removing all the comma's,
full stops etc and just leaving the words and spaces - the flow seems to
dissapear.
>
>> So before I pass out - I shall post this message and retire.
>
> Please tell us it's for good.
Thanks!
And no, I do not back down on my own personal views until I am satisfied
with what I am given.
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <···········@hotmail.com> wrote in message news:<············@newsg1.svr.pol.co.uk>...
> > The C and C++ languages have plenty of prefix forms. Function calls:
> >
> > f(g(x, y), z); // analogous to (f (g x y) z)
>
> Now here it is much better for C/C++ IMO.
> parameters are passed using the ()'s to group them together, and the
> function outside. While in Lisp, the function and parameters are in exactly
> the same place.
How are they in the same place? The function is in the leftmost
position, and the arguments are not!
The function belongs with the arguments; enclosing it together with
them expresses this grouping.
Consider what happens when the prefix syntax where functions are
outside of the group is combined with infix operators:
x * f(x, y)
Now what is the grouping? Is it (x * f)(x y)? Or do you just assume
that the prefix operator always has a higher precedence than the
binary *, whatever it is? That doesn't quite work:
x + f(x, y); // additive expression, function call is tighter
foo::bar(x, y); // C++ scope resolution, foo goes with bar
obj.func(x, y); // member selection, obj goes with func.
But:
(obj.*pmemb)(x, y); // .* low precedence, parens needed!
Ooops.
If you move the function to the right of the parenthesis, these
ambiguities disappear.
> For me it's exactly like writing this post but removing all the comma's,
> full stops etc and just leaving the words and spaces - the flow seems to
> dissapear.
The text is in fact mostly words and spaces. The, punctuation, is,
quite, minimal, compared, to, C++, Pascal, Etc. What a waste of
keystrokes; what do the commas accomplish? They disambiguate things
like x, ++y versus x++, y. One syntactic sdidiocy is patched over
with another. What a false economy; just so that you could have these
prefix operators and whatnot, you have to type extra punctuation even
when you are not using them!
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
[ ... ]
> The function belongs with the arguments; enclosing it together with
> them expresses this grouping.
Quite the contrary -- the function is something radically different
from its arguments. Even if a function accepts other functions as
arguments, the function being invoked is treated and used entirely
differently from the argument(s).
[ ... ]
> But:
>
> (obj.*pmemb)(x, y); // .* low precedence, parens needed!
>
> Ooops.
>
> If you move the function to the right of the parenthesis, these
> ambiguities disappear.
First of all, you should be sufficiently aware of programming language
terminology to be well aware that this is NOT an example of an
ambiguity. It's true that the default precedence in C isn't always
right -- but it's NOT true that this leads to an ambiguity. The
meaning without parentheses may not be what you wanted, but that
doesn't mean it's ambiguous at all.
C defines operator precedence that works correctly (at least by doing
some looking through my code) well over 95% of the time. Lisp never
requires parentheses to override default operator precedence, but only
because it throws out the baby with the bathwater -- rather than
requiring parentheses to fix the precedence in a tiny minority of
cases, it requires parentheses in _every_ case, no matter _how_
obvious the right thing to do is.
[ ... ]
> The text is in fact mostly words and spaces. The, punctuation, is,
> quite, minimal, compared, to, C++, Pascal, Etc. What a waste of
> keystrokes; what do the commas accomplish? They disambiguate things
> like x, ++y versus x++, y.
The do considerably more than that -- they (along with C's plethora of
other syntactical clues) provide enough differentiation that the eye
tracks it much more easily.
Hopefully we can start by agreeing that to somebody who doesn't know
the language at all, that nearly every programming language is
_completely_ unreadable -- Cobol is the only thing that really even
tries, and one of its unique dangers stems directly from the fact that
people _think_ they understand it long before they really do. Neither
C, nor C++, nor Lisp, however, presents much danger in this regard.
As such, at least _some_ degree of familiarity with the language at
hand is required before "readability" really has much meaning.
With that given, tests have repeatedly shown that C is far more
readable than Lisp. Just for an obvious example, consider finding
problems in code, such as:
int fact(int x) {
if (x == 0);
return 1;
return x * fact(x-1);
}
and:
(define (fact x) (if (= x 0)
(1
(* x (fact (- x 1))))))
In my testing, C programmers find the problem in the C code an average
of more than five times as fast as Lisp programmers find the problem
in the Lisp code. In addition, C compilers almost universally give
SOME sort of complaint pointing (at least indirectly) to the problem
in the C code (typically pointing out the dead code) while Lisp
compilers (and interpreters, the last time I looked) generally accept
the latter code without so much as a peep.
> One syntactic sdidiocy is patched over
> with another. What a false economy; just so that you could have these
> prefix operators and whatnot, you have to type extra punctuation even
> when you are not using them!
Lisp hardly provides a suitable platform from which to launch such a
diatribe. Rather the contrary -- Lisp has more extra punctuation than
nearly any other language extant.
In any case, while counting keystrokes has some meaning when
evaluating calculators (yes, I still use HPs), typing in punctuation
on a normal keyboard rarely seems to be a real source of major
problems. If terseness is your measure of choice anyway, then any
choice other than APL seems nearly indefensible for you.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
>> (obj.*pmemb)(x, y); // .* low precedence, parens needed!
>>
>>Ooops.
>>
>>If you move the function to the right of the parenthesis, these
>>ambiguities disappear.
>
>
> First of all, you should be sufficiently aware of programming language
> terminology to be well aware that this is NOT an example of an
> ambiguity. It's true that the default precedence in C isn't always
> right -- but it's NOT true that this leads to an ambiguity. The
> meaning without parentheses may not be what you wanted, but that
> doesn't mean it's ambiguous at all.
It creates opportunity for programmer error. Multiple levels of operator
precedence and direction leads to code which, for many everyday math
expressions, many people find more compact and (initially) readable. But
other expressions are tricky to correctly construct in the first place,
and difficult to read subsequently. Good C style suggests sometimes
inserting extra parentheses to make the code more easily understandable
to future maintainers. Lisp neither requires nor allows such practice.
>
> C defines operator precedence that works correctly (at least by doing
> some looking through my code) well over 95% of the time. Lisp never
> requires parentheses to override default operator precedence, but only
> because it throws out the baby with the bathwater -- rather than
> requiring parentheses to fix the precedence in a tiny minority of
> cases, it requires parentheses in _every_ case, no matter _how_
> obvious the right thing to do is.
You make Lisp sound long winded, verbose, redundant and redundant. But
those parens replace all the punctuation in C, not just its parens. I
find Lisp code is typically much more concise than code in those other
languages. Further, that consistent use of parens is the key to the
powerful macro systems which make it easy to programmatically transform
large, complex blocks of code.
> As such, at least _some_ degree of familiarity with the language at
> hand is required before "readability" really has much meaning.
>
> With that given, tests have repeatedly shown that C is far more
> readable than Lisp. Just for an obvious example, consider finding
> problems in code, such as:
>
> int fact(int x) {
> if (x == 0);
> return 1;
> return x * fact(x-1);
> }
>
> and:
>
> (define (fact x) (if (= x 0)
> (1
> (* x (fact (- x 1))))))
Would you care to cite those tests?
As regards your code above, I can't help but notice that the Lisp code
is shorter than the C. Please don't feel compelled to create a
counterexample.
But they're both indented incorrectly. Lisp editors have been
automatically indenting code for decades now, a handy labour saving
device. So your Lisp typo above hasn't been a danger since the era of
"blue ribbon" coding practice, when computer time was so expensive that
programs were keypunched offline, then visually inspected for bugs
before handing the deck off to the guy in the white smock, who would run
it and give you the printout of the results.
I understand editors that automatically indent code have become popular
among users of other languages recently.
> Lisp hardly provides a suitable platform from which to launch such a
> diatribe. Rather the contrary -- Lisp has more extra punctuation than
> nearly any other language extant.
Ooh, that gets me wondering. I compared a 460kloc CMUCL source tree
(.lisp files only) with a 377kloc VNC tree (.c files only). For the Lisp:
[·······@ode]$ find ~/lisp/cmucl-20031202/ -name '*.lisp'|xargs cat|perl
-ne 'foreach(split
//){if(/[a-zA-Z0-9]/){$_="ALPHANUMERIC"}elsif(/\s/){$_="WHITESPACE"}else{$_="OTHER"}$x{$_}++;$total++}END{foreach(sort
keys %x){print "$x{$_}\t". int($x{$_}/$total*100) . "%\t$_\n";}}'
10269697 63% ALPHANUMERIC
2503321 15% OTHER
3288547 20% WHITESPACE
And similarly, for the C:
6122166 61% ALPHANUMERIC
1410264 14% OTHER
2414824 24% WHITESPACE
As others have said, once one is used to looking at Lisp code (say a
week for the really slow learners), a lot of the parens tend to
disappear, especially the long strings of )))))) that terminate blocks.
--
Cameron MacKinnon
Toronto, Canada
·······@taeus.com (Jerry Coffin) writes:
> As such, at least _some_ degree of familiarity with the language at
> hand is required before "readability" really has much meaning.
I agree with this.
> With that given, tests have repeatedly shown that C is far more
> readable than Lisp. Just for an obvious example, consider finding
> problems in code, such as:
>
> int fact(int x) {
> if (x == 0);
> return 1;
> return x * fact(x-1);
> }
>
> and:
>
> (define (fact x) (if (= x 0)
> (1
> (* x (fact (- x 1))))))
>
> In my testing, C programmers find the problem in the C code an average
> of more than five times as fast as Lisp programmers find the problem
> in the Lisp code.
I expect a C programmer who is not familiar at all with Lisp will see
how the C function can be blown up. It certainly doesn't help that
the Scheme version doesn't even seem to be defined correctly. In
Common Lisp, the above fact function might look something like this:
(defun fact (x)
(if (< x 1)
1
(* x (fact (1- x)))))
I cheated a bit by not letting the thing blow the stack with a
negative x. I don't think a Lisp programmer would add unnecessary
parens. The compiler certainly wouldn't take them. The Lisp version
will also return the correct result for values of x where x! is larger
than MAXINT.
After typing in this reply and going back to proof read it, I only
just noticed the extra semi-colon in your if that breaks the C fact
function completely. I noticed the extra parens in your Scheme
version right off. Granted, a C compiler will warn you about not
returning an int (or is it an error?) with your fact function.
In Lisp, it is also fairly trivial to use a technique called
tail-optimization. Scheme guarantees this by definition. Most Common
Lisp compilers also support it. The tail-call version of fact looks
something like this:
CL-USER> (defun fact (x &optional (a 1))
(if (< x 1)
a
(fact (1- x) (* x a))))
FACT
CL-USER> (fact 0)
1
CL-USER> (fact 1)
1
CL-USER> (fact 2)
2
CL-USER> (fact 3)
6
CL-USER> (fact 4)
24
CL-USER> (fact -1)
1
CL-USER> (fact 5)
120
CL-USER> (fact 50)
30414093201713378043612608166064768844377641568960512000000000000
Tail optimization is simply a way for the compiler to turn a recursive
function into iterative code. Of course Common Lisp supports a large
number of iterative constructs. So you don't have to bend your brain
looking for a tail-recursive function.
I also typed this into a live REPL to make sure I didn't flub the
tail-call version. Even though the factorial function is a very
common example, the tail version is less so and I had to make it up
from scratch because it wasn't in my memory.
It also let me show off bignums ;-)
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Following up on myself :-/
David Steuber <·····@david-steuber.com> writes:
> ·······@taeus.com (Jerry Coffin) writes:
>
> > With that given, tests have repeatedly shown that C is far more
> > readable than Lisp. Just for an obvious example, consider finding
> > problems in code, such as:
> >
> > int fact(int x) {
> > if (x == 0);
> > return 1;
> > return x * fact(x-1);
> > }
I should be more careful about responding in the middle of the night
(or the edge or whatever). It actually took me a while to realize
that this function will always return 1.
> In Lisp, it is also fairly trivial to use a technique called
> tail-optimization. Scheme guarantees this by definition. Most Common
> Lisp compilers also support it. The tail-call version of fact looks
> something like this:
>
> CL-USER> (defun fact (x &optional (a 1))
> (if (< x 1)
> a
> (fact (1- x) (* x a))))
Because Emacs + SLIME shows you the arguments for a function, and the
accumulator variable that makes tail-calls possible is not really
supposed to be part of the interface, I've decided I prefer this
version (even though it is a bit longer):
CL-USER> (defun n! (n)
(labels ((fact (x a)
(if (< x 1)
a
(fact (1- x) (* x a)))))
(fact n 1)))
N!
I also like the name better.
CL-USER> (mapcar #'n! '(0 1 2 3 4 5 6 7 8 9 10))
(1 1 2 6 24 120 720 5040 40320 362880 3628800)
This also introduces the Common Lisp feature LABELS which allows you
to define local functions that can call themselves recursively.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
·······@taeus.com (Jerry Coffin) writes:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
>
> [ ... ]
>
>> The function belongs with the arguments; enclosing it together with
>> them expresses this grouping.
>
> Quite the contrary -- the function is something radically different
> from its arguments. Even if a function accepts other functions as
> arguments, the function being invoked is treated and used entirely
> differently from the argument(s).
How so? In Lisp, we have *expressions* which are evaluated for
their value and/or their side effects. Ommitting special forms and
macros for a second, we get:
1. Each argument expressions is evaluated to produce one or more
values.
2. The function expression is evaluted using the values of the
arguments obtained by the step above.
What's different about these two cases? In both cases, an
expression is evaluated after it's arguments have been evaluated for
their values, etc. With the recursive evaluation process involved
in lisp, there is no distinction between functions and arguments
because they are all just expressions.
In the case of *some* special forms, not all (or perhaps any) of
their arguments are evaluated prior to the logic of the form being
evaluated, which is useful for things like (quote ...) which
precludes evaluation of it's argument expression.
In the case of macros, which are source-to-source transforms, the
argument expressions are not evaluated prior to the macro
transformation taking place - and you can specifically control how
much of the argument expressions are evaluated *during* the
transformation.
I think that the distinction you're referring to is a by-product of
procedural languages, most of which have problems with functional
composition.
It is even possible to represent data as nothing more than closures
with accessors into the closure. Take, for example, this
implementation of the "cons" data type which uses the constructor
my-cons and accessors my-car/my-cdr (adapted from SICP):
(defun my-cons (x y)
(lambda (car-or-cdr)
(cond ((= car-or-cdr 0) x)
((= car-or-cdr 1) y))))
(defun my-car (a-cons)
(if (null a-cons)
nil
(funcall a-cons 0)))
(defun my-cdr (a-cons)
(if (null a-cons)
nil
(funcall a-cons 1)))
CL-USER> (setf the-cons (my-cons 'a 'b))
#<Interpreted Function "LAMBDA (X Y)" {4095B7C9}>
CL-USER> (my-car the-cons)
A
CL-USER> (my-cdr the-cons)
B
CL-USER> (setf the-list (my-cons 'a (my-cons 'b '())))
#<Interpreted Function "LAMBDA (X Y)" {4096BA79}>
CL-USER> (my-car the-list)
A
CL-USER> (my-cdr the-list)
#<Interpreted Function "LAMBDA (X Y)" {4096B9E1}>
CL-USER> (my-car (my-cdr the-list))
B
CL-USER> (my-car (my-cdr (my-cdr the-list)))
NIL
Contrast this with the default representation of a "cons":
CL-USER> (setf the-cons (cons 'a 'b))
(A . B)
CL-USER> (car the-cons)
A
CL-USER> (cdr the-cons)
B
CL-USER> (setf the-list (cons 'a (cons 'b '())))
(A B)
CL-USER> (car the-list)
A
CL-USER> (cdr the-list)
(B)
CL-USER> (car (cdr the-list))
B
CL-USER> (car (cdr (cdr the-list)))
NIL
--jon
In article <···························@posting.google.com>,
Jerry Coffin <·······@taeus.com> wrote:
> With that given, tests have repeatedly shown that C is far more
> readable than Lisp.
I'm curious - do you have references for these tests?
> Just for an obvious example, consider finding
> problems in code, such as:
>
> int fact(int x) {
> if (x == 0);
> return 1;
> return x * fact(x-1);
> }
>
> and:
>
> (define (fact x) (if (= x 0)
> (1
> (* x (fact (- x 1))))))
>
> In my testing, C programmers find the problem in the C code an average
> of more than five times as fast as Lisp programmers find the problem
> in the Lisp code. In addition, C compilers almost universally give
> SOME sort of complaint pointing (at least indirectly) to the problem
> in the C code (typically pointing out the dead code) while Lisp
> compilers (and interpreters, the last time I looked) generally accept
> the latter code without so much as a peep.
I saw the problem right away, even with the screwy indentation, and I've
only been hacking Lisp for a year or two. But assuming I didn't see it:
First of all, let's indent the Scheme code properly. Note I didn't do this
by hand, I just threw it at emacs:
(define (fact x)
(if (= x 0)
(1
(* x (fact (- x 1))))))
Notice how the indentation below the if statement doesn't line up. This
is the first big clue that something is wrong. Any mildly experienced
Lisp programmer will see the "shape" of this code as wrong.
That aside, I seem to have very good implementations installed by your
standards:
Scheme48:
| Warning: non-procedure in operator position
| (1 (* x (fact (- x 1))))
| (procedure: #{Type :exact-integer #f #f})
I also translated your example into CL for tests with CL compilers.
(defun fact (x)
(if (= x 0)
(1
(* x (fact (- x 1))))))
OpenMCL:
| > Error in process listener(1): While compiling FACT :
| > 1 is not a symbol or lambda expression in the form (1 (* X (FACT (- X 1)))) .
SBCL:
| ; in: LAMBDA NIL
| ; (1 (* X (FACT (- X 1))))
| ;
| ; caught ERROR:
| ; illegal function call
| ; compilation unit finished
| ; caught 1 ERROR condition
CMUCL produces the same error as SBCL when compiling the function, or on
calling (fact 0).
Furthermore, gcc (the only C compiler I have available) doesn't produce
any warnings for your C example with "-ansi -pedantic -Wall". However,
a quality editor will indent the code unexpectedly just like emacs does
for the Lisp example, so the problem can be caught in that way.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
> Quite the contrary -- the function is something radically different
> from its arguments. Even if a function accepts other functions as
> arguments, the function being invoked is treated and used entirely
> differently from the argument(s).
"Belongs with" doesn't mean "is the same thing as". Functions and their
arguments still need to be grouped. If you have trouble distinguishing the
first element of a list from the other elements, you shouldn't be
programming.
> First of all, you should be sufficiently aware of programming language
> terminology to be well aware that this is NOT an example of an
> ambiguity. It's true that the default precedence in C isn't always
> right -- but it's NOT true that this leads to an ambiguity. The
> meaning without parentheses may not be what you wanted, but that
> doesn't mean it's ambiguous at all.
It's not ambiguous if you're a C compiler, but it is if you're a human who
hasn't memorised all the operator precedence rules.
> C defines operator precedence that works correctly (at least by doing
> some looking through my code) well over 95% of the time. Lisp never
> requires parentheses to override default operator precedence, but only
> because it throws out the baby with the bathwater -- rather than
> requiring parentheses to fix the precedence in a tiny minority of
> cases, it requires parentheses in _every_ case, no matter _how_
> obvious the right thing to do is.
So what? C requires semicolons at the end of every line, no matter how
obvious it is where the break between two lines of code is. The difference
here is really only in arithmetic expressions. If you really want infix
arithmetic in Lisp, you can have it.
> The do considerably more than that -- they (along with C's plethora of
> other syntactical clues) provide enough differentiation that the eye
> tracks it much more easily.
Not true in my personal experience. Lisp code is very easy to track because
its structure is explicit. C code is potentially very confusing (e.g. a
multiline else clause which is indenteded correctly, but which isn't
deliniated by { }).
> With that given, tests have repeatedly shown that C is far more
> readable than Lisp. Just for an obvious example, consider finding
> problems in code, such as:
>
> int fact(int x) {
> if (x == 0);
> return 1;
> return x * fact(x-1);
> }
>
> and:
>
> (define (fact x) (if (= x 0)
> (1
> (* x (fact (- x 1))))))
>
> In my testing, C programmers find the problem in the C code an average
> of more than five times as fast as Lisp programmers find the problem
> in the Lisp code. In addition, C compilers almost universally give
> SOME sort of complaint pointing (at least indirectly) to the problem
> in the C code (typically pointing out the dead code) while Lisp
> compilers (and interpreters, the last time I looked) generally accept
> the latter code without so much as a peep.
This test didn't work for me, I spotted both errors in a few seconds. The
extra parenthesis in the Lisp code is /really obvious/ if you know the
language because 1 can't possibly be a function. As for compiler warnings,
if you translate this into Common Lisp and compile it with a good compiler
(e.g. SBCL) you certainly will get a warning. The quality of many Scheme
systems isn't as high in this regard.
> Lisp hardly provides a suitable platform from which to launch such a
> diatribe. Rather the contrary -- Lisp has more extra punctuation than
> nearly any other language extant.
Depends what you mean by punctuation. It has fewer rules of punctuation, but
probably more punctuation characters (if you count the parens).
Alex
Jerry Coffin wrote:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message
> news:<····························@posting.google.com>...
>
> [ ... ]
>
>> The function belongs with the arguments; enclosing it together with
>> them expresses this grouping.
>
> Quite the contrary -- the function is something radically different
> from its arguments. Even if a function accepts other functions as
> arguments, the function being invoked is treated and used entirely
> differently from the argument(s).
>
> [ ... ]
>
>> But:
>>
>> (obj.*pmemb)(x, y); // .* low precedence, parens needed!
>>
>> Ooops.
>>
>> If you move the function to the right of the parenthesis, these
>> ambiguities disappear.
>
> First of all, you should be sufficiently aware of programming language
> terminology to be well aware that this is NOT an example of an
> ambiguity. It's true that the default precedence in C isn't always
> right -- but it's NOT true that this leads to an ambiguity. The
> meaning without parentheses may not be what you wanted, but that
> doesn't mean it's ambiguous at all.
>
> C defines operator precedence that works correctly (at least by doing
> some looking through my code) well over 95% of the time. Lisp never
> requires parentheses to override default operator precedence, but only
> because it throws out the baby with the bathwater -- rather than
> requiring parentheses to fix the precedence in a tiny minority of
> cases, it requires parentheses in _every_ case, no matter _how_
> obvious the right thing to do is.
>
> [ ... ]
>
>> The text is in fact mostly words and spaces. The, punctuation, is,
>> quite, minimal, compared, to, C++, Pascal, Etc. What a waste of
>> keystrokes; what do the commas accomplish? They disambiguate things
>> like x, ++y versus x++, y.
>
> The do considerably more than that -- they (along with C's plethora of
> other syntactical clues) provide enough differentiation that the eye
> tracks it much more easily.
>
> Hopefully we can start by agreeing that to somebody who doesn't know
> the language at all, that nearly every programming language is
> _completely_ unreadable -- Cobol is the only thing that really even
> tries, and one of its unique dangers stems directly from the fact that
> people _think_ they understand it long before they really do. Neither
> C, nor C++, nor Lisp, however, presents much danger in this regard.
>
> As such, at least _some_ degree of familiarity with the language at
> hand is required before "readability" really has much meaning.
>
> With that given, tests have repeatedly shown that C is far more
> readable than Lisp. Just for an obvious example, consider finding
> problems in code, such as:
>
> int fact(int x) {
> if (x == 0);
> return 1;
> return x * fact(x-1);
> }
>
> and:
>
> (define (fact x) (if (= x 0)
> (1
> (* x (fact (- x 1))))))
>
> In my testing, C programmers find the problem in the C code an average
> of more than five times as fast as Lisp programmers find the problem
> in the Lisp code. In addition, C compilers almost universally give
> SOME sort of complaint pointing (at least indirectly) to the problem
> in the C code (typically pointing out the dead code) while Lisp
> compilers (and interpreters, the last time I looked) generally accept
> the latter code without so much as a peep.
>
>> One syntactic sdidiocy is patched over
>> with another. What a false economy; just so that you could have these
>> prefix operators and whatnot, you have to type extra punctuation even
>> when you are not using them!
>
> Lisp hardly provides a suitable platform from which to launch such a
> diatribe. Rather the contrary -- Lisp has more extra punctuation than
> nearly any other language extant.
>
> In any case, while counting keystrokes has some meaning when
> evaluating calculators (yes, I still use HPs), typing in punctuation
> on a normal keyboard rarely seems to be a real source of major
> problems. If terseness is your measure of choice anyway, then any
> choice other than APL seems nearly indefensible for you.
>
Alex Drummond <··········@ucl.ac.uk> wrote in message news:<············@uns-a.ucl.ac.uk>...
[ ... ]
> > First of all, you should be sufficiently aware of programming language
> > terminology to be well aware that this is NOT an example of an
> > ambiguity. It's true that the default precedence in C isn't always
> > right -- but it's NOT true that this leads to an ambiguity. The
> > meaning without parentheses may not be what you wanted, but that
> > doesn't mean it's ambiguous at all.
>
> It's not ambiguous if you're a C compiler, but it is if you're a human who
> hasn't memorised all the operator precedence rules.
Based on this reply, about all I can guess is that you don't know what
"ambiguous" really means. Being ignorant of the meaning of a statement
doesn't imply that the statement is ambiguous; to be ambiguous, it
must be impossible to determine the meaning of the statement,
regardless of one's knowledge of the language, etc.
My utter ignorance of Japanese is FAR from justification for claiming
that all Japanese is ambigous.
I find it particularly interesting that C and C++ both contain some
things that (based on pure syntax) really ARE ambiguous, but those
attacking them seem to be sufficiently ignorant that they don't even
realize what they should be citing (that's a hint guys: your side
deserves a MUCH better argument than you're putting up for it).
[ ... ]
> C requires semicolons at the end of every line, no matter how
> obvious it is where the break between two lines of code is.
This is simply incorrect. If I choose to do so, I can write an
arbitrary number of lines of C without semicolons. C _does_ require a
semicolon at the end of a _statement_ (and in a few other situations),
but equating a statement with a line simply shows (though it's already
pretty obvious) that you really don't know what you're talking about.
> The difference here is really only in arithmetic expressions.
That's simply not true -- infix expressions can be useful in all sorts
of non-mathematical situations. In any case, the thing we program IS
called a "computer", but you sound as if nobody should actually expect
it to be able to do any computation!
[ ... ]
> Not true in my personal experience. Lisp code is very easy to track because
> its structure is explicit. C code is potentially very confusing (e.g. a
> multiline else clause which is indenteded correctly, but which isn't
> deliniated by { }).
How can that possibly be confusing?
[ ... ]
> > In my testing, C programmers find the problem in the C code an average
> > of more than five times as fast as Lisp programmers find the problem
> > in the Lisp code. In addition, C compilers almost universally give
> > SOME sort of complaint pointing (at least indirectly) to the problem
> > in the C code (typically pointing out the dead code) while Lisp
> > compilers (and interpreters, the last time I looked) generally accept
> > the latter code without so much as a peep.
>
> This test didn't work for me, I spotted both errors in a few seconds.
The question is "how few?" Based on the content of your post, it would
appear that you know Lisp a LOT better than you know C in any case. As
such, if the two were about equally readable, you would have been able
to spot the problem in the LISP much MORE quickly.
[ ... ]
> Depends what you mean by punctuation. It has fewer rules of punctuation, but
> probably more punctuation characters (if you count the parens).
Given Kaz's mention of "waste of keystrokes", the actual number of
characters seemed to be the only possible interpretation.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
> I find it particularly interesting that C and C++ both contain some
> things that (based on pure syntax) really ARE ambiguous, but those
> attacking them seem to be sufficiently ignorant that they don't even
> realize what they should be citing (that's a hint guys: your side
> deserves a MUCH better argument than you're putting up for it).
Why bother arguing about shift/reduce and reduce/reduce conflicts and
the de facto and de jure meanings of e.g. a[x+++y] = x+++y; - every
language has a wart or two in the corner cases, and C defenders are just
going to reply that such things are bad style and not done anyway. If
mere syntax was the biggest hindrance to productivity, then
preprocessors, smart editors and code formatters could solve it.
Say, speaking of citing, don't you still owe us one from your claim that
"[t]ests have repeatedly shown that C is far more readable than Lisp."
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
[ ... ]
> Why bother arguing about shift/reduce and reduce/reduce conflicts and
> the de facto and de jure meanings of e.g. a[x+++y] = x+++y; - every
> language has a wart or two in the corner cases, and C defenders are just
> going to reply that such things are bad style and not done anyway.
Those weren't the cases I was talking about -- in fact, none of what
you've cited above is really an ambiguity either.
There are, however, ambiguities to be found, such as:
a b(c);
In C++, this could be either a definition of b as an object of type a,
with c as an initializer, OR it could be a declaration of b as a
function that returns an a and takes a c as a parameter. There are a
number of other examples along this line, but (at least from a
viewpoint of pure syntax) these are real ambiguities. C++ has a fairly
simple rule about how to deal with all of them, but even though the
rule itself is simple, implementing it is anything but, and is
semantic, not syntactical -- the syntax itself really IS ambiguous.
[ ... ]
> Say, speaking of citing, don't you still owe us one from your claim that
> "[t]ests have repeatedly shown that C is far more readable than Lisp."
Where do you find a mention (by anybody) of citing anything?
In any case, I never said or implied that I'd provide citations. I
said those were results from tests that I conducted. I conducted the
tests for a (temporary) employer, so I'm pretty sure I couldn't
(legally) publish the results without their permission. Since that
company went under in the .com bust I'm not even sure whose permission
I'd need at this point.
In the end, I'm reasonably certain other tests have been done, but if
you want them, you'll have to find them yourself -- until or unless
there's some change in Lisp syntax that invalidates what I've already
done, I'm not much more interested in searching for such results than
I am in searching for new proofs that the world is round.
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) writes:
> There are, however, ambiguities to be found, such as:
>
> a b(c);
>
> In C++, this could be either a definition of b as an object of type a,
> with c as an initializer, OR it could be a declaration of b as a
> function that returns an a and takes a c as a parameter. There are a
> number of other examples along this line, but (at least from a
> viewpoint of pure syntax) these are real ambiguities. C++ has a fairly
> simple rule about how to deal with all of them, but even though the
> rule itself is simple, implementing it is anything but, and is
> semantic, not syntactical -- the syntax itself really IS ambiguous.
Didn't I already say that? Maybe I wasn't being clear, but this is why a
real description of the structure of a C/C++ program can not be very
similar to the source. It needs all kinds of annotations indicating what
each token really is in this semantic context.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> > a b(c);
> > In C++, this could be either a definition of b as an object of type a,
> > with c as an initializer, OR it could be a declaration of b as a
> > function that returns an a and takes a c as a parameter. There are a
> > number of other examples along this line, but (at least from a
> > viewpoint of pure syntax) these are real ambiguities. C++ has a fairly
> > simple rule about how to deal with all of them, but even though the
> > rule itself is simple, implementing it is anything but, and is
> > semantic, not syntactical -- the syntax itself really IS ambiguous.
>
> Didn't I already say that? Maybe I wasn't being clear, but this is why a
> real description of the structure of a C/C++ program can not be very
> similar to the source. It needs all kinds of annotations indicating what
> each token really is in this semantic context.
"Doc, it hurts when I go like that."
"I'm writing you a prescription. 'Don't go like that.'"
A description of a program at the source level should be its source. If you
have a problem with that, spend more time cleaning up your code, so a
statement like a_t b(c_t) is more clearly a declaration, with _t on its
types, and not a function call.
A higher level description of a design shouldn't waste its time on low-level
details like those.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
>> It's not ambiguous if you're a C compiler, but it is if you're a human
>> who hasn't memorised all the operator precedence rules.
>
> Based on this reply, about all I can guess is that you don't know what
> "ambiguous" really means. Being ignorant of the meaning of a statement
> doesn't imply that the statement is ambiguous; to be ambiguous, it
> must be impossible to determine the meaning of the statement,
> regardless of one's knowledge of the language, etc.
Depends on what you mean by ambiguous. It's pretty clear that what I meant
was something which could plausibly be thought to have several distinct
meanings. If you don't like me using the word ambiguous outside its narrow,
techincal sense to express that meaning, fine, but what I wrote made sense.
>> C requires semicolons at the end of every line, no matter how
>> obvious it is where the break between two lines of code is.
>
> This is simply incorrect. If I choose to do so, I can write an
> arbitrary number of lines of C without semicolons. C _does_ require a
> semicolon at the end of a _statement_ (and in a few other situations),
> but equating a statement with a line simply shows (though it's already
> pretty obvious) that you really don't know what you're talking about.
FFS, I meant a line as in a unit of code which needs to be terminated by a
semicolon in C (should have said "statement", I guess). I did not literally
mean a sequence of characters terminated by a newline, since (as you so
kindly point out) this would have made what I said completely incorrect.
Doesn't take much charity of interpretation to work out what I meant here.
>> The difference here is really only in arithmetic expressions.
>
> That's simply not true -- infix expressions can be useful in all sorts
> of non-mathematical situations. In any case, the thing we program IS
> called a "computer", but you sound as if nobody should actually expect
> it to be able to do any computation!
Virtually all of C's infix operators are arithmetic (if you include
bitshifting, etc.). Your last sentence doesn't make any sense to me.
>> Not true in my personal experience. Lisp code is very easy to track
>> because its structure is explicit. C code is potentially very confusing
>> (e.g. a multiline else clause which is indenteded correctly, but which
>> isn't deliniated by { }).
>
> How can that possibly be confusing?
Erm, this is a classic C error. It looks like several statements belong to
the else clause (from the indentation), but actually only one does. Not so
difficult to spot, but at least as hard as the extra paren in your example
Scheme code.
>> This test didn't work for me, I spotted both errors in a few seconds.
>
> The question is "how few?" Based on the content of your post, it would
> appear that you know Lisp a LOT better than you know C in any case. As
> such, if the two were about equally readable, you would have been able
> to spot the problem in the LISP much MORE quickly.
No, I know C++ better than I do Lisp, actually. It's only your pedantic
interpretation of "ambiguous" and "line" that have convinced you otherwise.
Regardless of how well I know C++, I'm certainly not a CL guru, and even I
was able to spot that extra paren almost immediately. It's not like we're
talking a difference between hours and days here.
>> Depends what you mean by punctuation. It has fewer rules of punctuation,
>> but probably more punctuation characters (if you count the parens).
>
> Given Kaz's mention of "waste of keystrokes", the actual number of
> characters seemed to be the only possible interpretation.
Fair enough, but I wasn't referring back to that comment. I think someone
else on this thread posted a comparison showing that the typical number of
non-alphanumeric characters in C and Lisp source is virtually identical.
Alex
Jerry Coffin wrote:
> Alex Drummond <··········@ucl.ac.uk> wrote in message
> news:<············@uns-a.ucl.ac.uk>...
>
> [ ... ]
>
>> > First of all, you should be sufficiently aware of programming language
>> > terminology to be well aware that this is NOT an example of an
>> > ambiguity. It's true that the default precedence in C isn't always
>> > right -- but it's NOT true that this leads to an ambiguity. The
>> > meaning without parentheses may not be what you wanted, but that
>> > doesn't mean it's ambiguous at all.
>>
>> It's not ambiguous if you're a C compiler, but it is if you're a human
>> who hasn't memorised all the operator precedence rules.
>
> Based on this reply, about all I can guess is that you don't know what
> "ambiguous" really means. Being ignorant of the meaning of a statement
> doesn't imply that the statement is ambiguous; to be ambiguous, it
> must be impossible to determine the meaning of the statement,
> regardless of one's knowledge of the language, etc.
>
> My utter ignorance of Japanese is FAR from justification for claiming
> that all Japanese is ambigous.
>
> I find it particularly interesting that C and C++ both contain some
> things that (based on pure syntax) really ARE ambiguous, but those
> attacking them seem to be sufficiently ignorant that they don't even
> realize what they should be citing (that's a hint guys: your side
> deserves a MUCH better argument than you're putting up for it).
>
> [ ... ]
>
>> C requires semicolons at the end of every line, no matter how
>> obvious it is where the break between two lines of code is.
>
> This is simply incorrect. If I choose to do so, I can write an
> arbitrary number of lines of C without semicolons. C _does_ require a
> semicolon at the end of a _statement_ (and in a few other situations),
> but equating a statement with a line simply shows (though it's already
> pretty obvious) that you really don't know what you're talking about.
>
>> The difference here is really only in arithmetic expressions.
>
> That's simply not true -- infix expressions can be useful in all sorts
> of non-mathematical situations. In any case, the thing we program IS
> called a "computer", but you sound as if nobody should actually expect
> it to be able to do any computation!
>
> [ ... ]
>
>> Not true in my personal experience. Lisp code is very easy to track
>> because its structure is explicit. C code is potentially very confusing
>> (e.g. a multiline else clause which is indenteded correctly, but which
>> isn't deliniated by { }).
>
> How can that possibly be confusing?
>
> [ ... ]
>
>> > In my testing, C programmers find the problem in the C code an average
>> > of more than five times as fast as Lisp programmers find the problem
>> > in the Lisp code. In addition, C compilers almost universally give
>> > SOME sort of complaint pointing (at least indirectly) to the problem
>> > in the C code (typically pointing out the dead code) while Lisp
>> > compilers (and interpreters, the last time I looked) generally accept
>> > the latter code without so much as a peep.
>>
>> This test didn't work for me, I spotted both errors in a few seconds.
>
> The question is "how few?" Based on the content of your post, it would
> appear that you know Lisp a LOT better than you know C in any case. As
> such, if the two were about equally readable, you would have been able
> to spot the problem in the LISP much MORE quickly.
>
> [ ... ]
>
>> Depends what you mean by punctuation. It has fewer rules of punctuation,
>> but probably more punctuation characters (if you count the parens).
>
> Given Kaz's mention of "waste of keystrokes", the actual number of
> characters seemed to be the only possible interpretation.
>
·······@taeus.com (Jerry Coffin) wrote in message news:<···························@posting.google.com>...
> Alex Drummond <··········@ucl.ac.uk> wrote in message news:<············@uns-a.ucl.ac.uk>...
>
> [ ... ]
>
> > > First of all, you should be sufficiently aware of programming language
> > > terminology to be well aware that this is NOT an example of an
> > > ambiguity. It's true that the default precedence in C isn't always
> > > right -- but it's NOT true that this leads to an ambiguity. The
> > > meaning without parentheses may not be what you wanted, but that
> > > doesn't mean it's ambiguous at all.
> >
> > It's not ambiguous if you're a C compiler, but it is if you're a human who
> > hasn't memorised all the operator precedence rules.
>
> Based on this reply, about all I can guess is that you don't know what
> "ambiguous" really means.
Ambiguous means I have to look up a bunch of hidden rules that were
added to an ambiguous language and arbitrarily resolve the parsing
conflicts. The existence of the hidden rules doesn't solve all of the
problems.
By the way, look at the ridiculous grammar factoring that's needed in
order to avoid the use of explicit precedence and associativity rules.
The expression 42 ends up being a multiplicative-expression *and*
an additive-expression at the same time. Yet it neither adds nor
multiplies.
Being ignorant of the meaning of a statement
> doesn't imply that the statement is ambiguous; to be ambiguous, it
> must be impossible to determine the meaning of the statement,
> regardless of one's knowledge of the language, etc.
>
> My utter ignorance of Japanese is FAR from justification for claiming
> that all Japanese is ambigous.
I'm almost certain that Japanese is full of ambiguities, being a
natural language.
The difference is that there aren't any hidden rules about it. An
ambiguity in natural language doesn't pretend to be something else.
If you utter something ambiguous that leads to a misunderstanding, you
can't claim superiority by referring the poor victim of your
misunderstanding to an associative precedence chart.
Now every message must have some hidden rules which indicate how it
should be parsed. But those rules can be made minimal. Moreover, the
message can even be structured such that the rules can be just about
deduced from its structure.
An ambiguous message is one whose parsing cannot be cracked without
access to the hidden rules, even if it is encountered by an
intelligence which is able to correctly figure out every other aspect
of the message, like which symbols are operators and operands, and
that the operators are binary, and so on.
Suppose that an alien encounters a message from Earth which looks like
A + B * C / D - E * F
The alien might be able to deduce what the operators are, and then it
is stuck.
Now the same alien receives:
(- (+ A (/ (* B C) D)) (* E F))
Aha, it's obvious that the two symbols ( ) are special and that they
serve to enclose, as suggested by their shape. Moreover, they balance,
which reinforces that suspicion.
Given a larger repertoire of such messages, it becomes obvious that
the operators like * and + always appear in the left position of a
sublist, and the other symbols like A B C are in the remaining
positions. So the message itself can convey the idea that + - * / are
somehow different from these other A B C ... In the first message,
even this is huge leap. One could suspect that A and + are unary
operators, and find nothing in the message to contradict the idea.
> I find it particularly interesting that C and C++ both contain some
> things that (based on pure syntax) really ARE ambiguous, but those
What, like evaluation orders? That's not pure syntax, but semantics.
That's a whole different pile of unbelieveable idiocy that should have
been fixed long ago.
Or, I'm guessing that perhaps by ``pure syntax'' you mean ``just the
raw grammar, with no symbol table information''. As in, what is this:
(a)(b)(c)+(d);
Our choices are:
typedef int a, b, c;
int d;
// ...
(a)(b)(c)+(d); // unary + expression put through casts!
Another choice:
extern int (*a(int))(int);
int b, c, d;
// ...
// call a with argument b, which returns pointer to a function that
// takes int and returns a pointer to an int -> int function.
// This function is called with argument c. The result is added
// with the value of d.
(a)(b)(c)+(d);
And so on. I once wrote a parser which could deal with these
ambiguities. The goal of the parser was to classify an expression into
three categories: 1) has side effects for sure. 2) might have side
effects depending on which way it is parsed and 3) has no side
effects, for sure. When there was an ambiguity like the above, it
would parse it both ways, record its findings and backtrack. The
backtracking was done using an exception handling package hacked over
setjmp and longjmp in C.
With this package, one can put assertions into function #define
macros, so that at run time, suspicious uses of these macros would
blow up!
For example, suppose you were implementing a macro for int getc(FILE
*) macro, and you needed to evaluate the stream variable twice in the
macro expansion.
With my package, I could write the getc() macro call such that when
the first time it is evaluated, the enclosed expression is parsed and
classified. If it is found to have side effects, like getc(stream++)
then the program stops with an assertion. If it's suspected to have
side effects, a warning is produced and the program continues, and of
course if there are no side effects, it is silent. In both these
cases, the expression is stored into a hash table so it doesn't have
to be parsed again; the next time that same call is evaluated, the
hash will tell that all is good.
So as you can see, I have done some incredibly devilish things in
order to make a dumb language safer.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
[ ... ]
> Ambiguous means I have to look up a bunch of hidden rules that were
> added to an ambiguous language and arbitrarily resolve the parsing
> conflicts.
Okay, so we no longer have to wonder: you clearly don't know what
ambiguous means!
> By the way, look at the ridiculous grammar factoring that's needed in
> order to avoid the use of explicit precedence and associativity rules.
> The expression 42 ends up being a multiplicative-expression *and*
> an additive-expression at the same time. Yet it neither adds nor
> multiplies.
I find this a bit interesting, but I'm afraid I'll have to wait until
after work to look it up, since my copy of the standard is at home.
[ ... ]
> I'm almost certain that Japanese is full of ambiguities, being a
> natural language.
Probably true -- but the ambiguities are due to the definition (or
lack thereof) of the language, not my ignorance.
> The difference is that there aren't any hidden rules about it.
Hmm...your definition of "hidden" seems to be a strange one. The rules
(grammatical and otherwise) for C++ are all contained in a single
standard. For English there's no single standard specifying all the
grammatical rules, and probably not even one book directory to point
to all the other books that contain all the rules. To me, this seems
far more a matter of "hidden rules". I suppose Japanese may be better
than English in this regard (most languages are, after all) but I
still doubt that they're all in one place or anything like it.
> An
> ambiguity in natural language doesn't pretend to be something else.
That simply makes it sound remarkably as if you have little or no
experience with real life or natural languages at all. Just for
example, I'd guess that at least 60% of all the law suits filed on
earth are based on contrat language that pretended to be something
else, but was (in retrospect) clearly ambiguous.
> If you utter something ambiguous that leads to a misunderstanding, you
> can't claim superiority by referring the poor victim of your
> misunderstanding to an associative precedence chart.
I see. I guess there are no contract attorneys (or probably any kind
of attorneys) in your world?
[ ... ]
> Suppose that an alien encounters a message from Earth which looks like
>
> A + B * C / D - E * F
>
> The alien might be able to deduce what the operators are, and then it
> is stuck.
I probably shouldn't try to argue this one, since (based on your
comments above) you seem to be from a planet substantially different
from the one where I live, so you probably have considerably more
knowledge of being that are comletely alien, at least to me.
I guess in the end, if your position is that Lisp might be more useful
for aliens, so be, I won't try to argue the point. The fact remains
that by the time most people start to program, something like "a+b*c"
already has meaning for them, and completely ignoring that background
(and in fact basically requiring that they UNlearn the useful
knowledge they already posess) does NOT improve understanding.
> Now the same alien receives:
>
> (- (+ A (/ (* B C) D)) (* E F))
>
> Aha, it's obvious that the two symbols ( ) are special and that they
> serve to enclose, as suggested by their shape. Moreover, they balance,
> which reinforces that suspicion.
You start by postulating a being of which we know absolutely nothing,
but then postulate that you can provide an accurate prediction about
what it'll find obvious.
I'm not sure whether to believe that you're unbelievably coneited, or
merely insane.
> > I find it particularly interesting that C and C++ both contain some
> > things that (based on pure syntax) really ARE ambiguous, but those
>
> What, like evaluation orders?
No, of course not. Which part of "syntax" didn't you understand?
> That's not pure syntax, but semantics.
Oh, so it wasn't lack of understanding, just a lousy attempt at a
straw man.
> That's a whole different pile of unbelieveable idiocy that should have
> been fixed long ago.
You do nobody (especially yourself) any favors by claiming any
decision with you happen to disagree as "unbelievable idiocy".
> Or, I'm guessing that perhaps by ``pure syntax'' you mean ``just the
> raw grammar, with no symbol table information''. As in, what is this:
>
> (a)(b)(c)+(d);
I'm not sure this is the simplest or best-chosen example, but at least
it IS an example of what I mentioned, yes.
[ ... ]
> With my package, I could write the getc() macro call such that when
> the first time it is evaluated, the enclosed expression is parsed and
> classified. If it is found to have side effects, like getc(stream++)
> then the program stops with an assertion. If it's suspected to have
> side effects, a warning is produced and the program continues, and of
> course if there are no side effects, it is silent. In both these
> cases, the expression is stored into a hash table so it doesn't have
> to be parsed again; the next time that same call is evaluated, the
> hash will tell that all is good.
I guess I can see where this would be a stimulating intellectual
project, but I'm hard put to conceive of a lot of useful purposes for
it.
> So as you can see, I have done some incredibly devilish things in
> order to make a dumb language safer.
...or at least think you have. It sounds to me like an awful lot of
work with little real benefit, but if you're happy with what you did,
more power to you.
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) writes:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
>
>> The difference is that there aren't any hidden rules about it.
>
> Hmm...your definition of "hidden" seems to be a strange one.
Are you familiar with the principle of least surprise? That's what we're
trying to convey here.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> Suppose that an alien encounters a message from Earth which looks like
>
> A + B * C / D - E * F
>
> The alien might be able to deduce what the operators are, and then it
> is stuck.
>
> Now the same alien receives:
>
> (- (+ A (/ (* B C) D)) (* E F))
>
Clipped all the other funny stuff.
BTW, another fine example of why C is easier to read than Lisp.
Of course, if you wanted to write clean code in a team environment, you
would be expected to use:
A + (B * C / D) - (E * F)
so that there is no misunderstanding of your code. Certainly not needed, but
makes it easier to read at a glance, which is what I would say is the
highest priority when designing a language to be used in a team
environment..
Gee, I just love this thread... Will it ever end. I can see this stuff going
round in circles for weeks :)
"Maahes" <······@internode.on.net> writes:
> A + (B * C / D) - (E * F)
>
> so that there is no misunderstanding of your code. Certainly not needed, but
> makes it easier to read at a glance, which is what I would say is the
> highest priority when designing a language to be used in a team
> environment..
Not sufficient:
1 + (2 * 2 / 4) - (1 * 1)
Do you expect: 1 or 0 ?
<source language=c>
1 + (2 * (2 / 4)) - (1 * 1), /* ==> 0 */
1 + ((2 * 2) / 4) - (1 * 1) /* ==> 1 */
</source>
> Gee, I just love this thread... Will it ever end. I can see this stuff going
> round in circles for weeks :)
--
__Pascal Bourguignon__
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@naiad.informatimago.com...
> "Maahes" <······@internode.on.net> writes:
>> A + (B * C / D) - (E * F)
>>
>> so that there is no misunderstanding of your code. Certainly not needed,
>> but
>> makes it easier to read at a glance, which is what I would say is the
>> highest priority when designing a language to be used in a team
>> environment..
>
> Not sufficient:
>
> 1 + (2 * 2 / 4) - (1 * 1)
>
> Do you expect: 1 or 0 ?
> <source language=c>
> 1 + (2 * (2 / 4)) - (1 * 1), /* ==> 0 */
> 1 + ((2 * 2) / 4) - (1 * 1) /* ==> 1 */
> </source>
>
>
I am sorry I am thick but how do you get 0?
1 + (2 * (2/4)) - (1 * 1) ==>
1 + (2 * 0.5) - 1 ==>
1 + 1 - 1 ==>
1
Now if the equation was A + (B / C / D) - (E * F) now the problem would
exist as / is not associative.
So
1 + (2 / (2 /4)) - (1 * 1) ==> 4
while
1 + ((2 / 2) / 4) - (1 * 1) ==> 0.25
By the way I am a Lisp user not a C++ user
rmagere wrote:
> "Pascal Bourguignon" <····@mouse-potato.com> wrote in message
> ···················@naiad.informatimago.com...
>
>>"Maahes" <······@internode.on.net> writes:
>>
>>>A + (B * C / D) - (E * F)
>>>
>>>so that there is no misunderstanding of your code. Certainly not needed,
>>>but
>>>makes it easier to read at a glance, which is what I would say is the
>>>highest priority when designing a language to be used in a team
>>>environment..
>>
>>Not sufficient:
>>
>> 1 + (2 * 2 / 4) - (1 * 1)
>>
>>Do you expect: 1 or 0 ?
>><source language=c>
>> 1 + (2 * (2 / 4)) - (1 * 1), /* ==> 0 */
>> 1 + ((2 * 2) / 4) - (1 * 1) /* ==> 1 */
>></source>
>>
>>
>
> I am sorry I am thick but how do you get 0?
> 1 + (2 * (2/4)) - (1 * 1) ==>
2/4 is integer division (so you would expect 0 as result)
> 1 + (2 * 0.5) - 1 ==>
1+(2*0)-1 ==>
> 1 + 1 - 1 ==>
1 + 0 - 1 ==>
> 1
0
hs
Appologies for digging up this rather old thread, but I'd not read
comp.games.development.programming.misc for a wee while and the title of
this thread just made me laugh out loud.
It's like standing in front of the pyramids and saying "Stones suck for
construction". Jeez, C++ may have some flaws (lots, even), but it's
done kinda okay in the game development stakes ;o)
Peter Ashford <··@here.there.com> wrote
> It's like standing in front of the pyramids and saying "Stones suck for
> construction".
Well, that was an interesting analogy. Judging by the realities of
pyramid building, I'd say the only reasonable conclusion would be
approximately "Stones suck for construction".
Reversing the analogy, you seem to be saying that using C++ for game
development is extremely labor intensive, will almost always be
finished far too late, is lamentably inefficient (compare total size
to usable volume in the pyramids) and incomplete (if you want any kind
of utilities (such as light or fresh air) in a pyramid, you have to
bring them yourself), can really only be attempted by large
corporations - preferably governments, and has frankly been obsolete
since before antiquity.
I think C++ is a lot better than that. Maybe not as good as Lisp, but
it's still very good for most projects.
;-)
Peter Lewerin wrote:
> Peter Ashford <··@here.there.com> wrote
>
>
>>It's like standing in front of the pyramids and saying "Stones suck for
>>construction".
>
>
> Well, that was an interesting analogy. Judging by the realities of
> pyramid building, I'd say the only reasonable conclusion would be
> approximately "Stones suck for construction".
>
> Reversing the analogy, you seem to be saying that using C++ for game
> development is extremely labor intensive, will almost always be
> finished far too late, is lamentably inefficient (compare total size
> to usable volume in the pyramids) and incomplete (if you want any kind
> of utilities (such as light or fresh air) in a pyramid, you have to
> bring them yourself), can really only be attempted by large
> corporations - preferably governments, and has frankly been obsolete
> since before antiquity.
Haha... very good ;o)
> I think C++ is a lot better than that. Maybe not as good as Lisp, but
> it's still very good for most projects.
>
> ;-)
Lisp would IMO be as good for games as C++ *if* the tools existed to
support it (how many PS2 LISP compilers do you know of, for example)
IMO that's the major reason that C++ is the only game in town - everyone
looking for performance used to use ASM, then C, now C++. There's
several generations of tool chains blending one into another meaning
several generations of intertia for any other language to overcome.
With equivallent tools, I believe that either LISP or Java could well be
better options for developing the majority of game titles... but, that
support does not exist and probably never will.
Peter Ashford wrote:
> Peter Lewerin wrote:
>
>> Peter Ashford <··@here.there.com> wrote
>>
>>
>>> It's like standing in front of the pyramids and saying "Stones suck
>>> for construction".
>>
>>
>>
>> Well, that was an interesting analogy. Judging by the realities of
>> pyramid building, I'd say the only reasonable conclusion would be
>> approximately "Stones suck for construction".
>>
>> Reversing the analogy, you seem to be saying that using C++ for game
>> development is extremely labor intensive, will almost always be
>> finished far too late, is lamentably inefficient (compare total size
>> to usable volume in the pyramids) and incomplete (if you want any kind
>> of utilities (such as light or fresh air) in a pyramid, you have to
>> bring them yourself), can really only be attempted by large
>> corporations - preferably governments, and has frankly been obsolete
>> since before antiquity.
>
>
> Haha... very good ;o)
>
>> I think C++ is a lot better than that. Maybe not as good as Lisp, but
>> it's still very good for most projects.
>>
>> ;-)
>
>
> Lisp would IMO be as good for games as C++ *if* the tools existed to
> support it (how many PS2 LISP compilers do you know of, for example)
>
> IMO that's the major reason that C++ is the only game in town - everyone
> looking for performance used to use ASM, then C, now C++. There's
> several generations of tool chains blending one into another meaning
> several generations of intertia for any other language to overcome. With
> equivallent tools, I believe that either LISP or Java could well be
> better options for developing the majority of game titles... but, that
> support does not exist and probably never will.
No, they never will. That is because nothing ever changes in
programming. That is why the Web is invariably programmed using COBOL,
VSAM, CICS and...uh-oh....
...never mind!!!
kenny (going back to work on his Lisp game engine with his new OpenGL
shading reference in hand)
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> No, they never will. That is because nothing ever changes in
> programming. That is why the Web is invariably programmed using COBOL,
> VSAM, CICS and...uh-oh....
>
> ...never mind!!!
Why? Indeed, the web is programmed using COBOL, VSAM, and CICS. Check
for example one of the 272,000 pages referenced by google on: Web CICS.
(16e6 for Web Java, and about 1e6 for Web Lisp).
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Pascal Bourguignon wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>No, they never will. That is because nothing ever changes in
>>programming. That is why the Web is invariably programmed using COBOL,
>>VSAM, CICS and...uh-oh....
>>
>>...never mind!!!
>
>
> Why? Indeed, the web is programmed using COBOL, VSAM, and CICS. Check
> for example one of the 272,000 pages referenced by google on: Web CICS.
>
>
>
> (16e6 for Web Java, and about 1e6 for Web Lisp).
So CICS has one fourth the share of a dead language and less than 2% of
Java?
See? CICS will always be king of the mountain! (Numbers get smaller as
they go up, right?)
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
>>
>> Lisp would IMO be as good for games as C++ *if* the tools existed to
>> support it (how many PS2 LISP compilers do you know of, for example)
>>
>> IMO that's the major reason that C++ is the only game in town -
>> everyone looking for performance used to use ASM, then C, now C++.
>> There's several generations of tool chains blending one into another
>> meaning several generations of intertia for any other language to
>> overcome. With equivallent tools, I believe that either LISP or Java
>> could well be better options for developing the majority of game
>> titles... but, that support does not exist and probably never will.
>
>
> No, they never will. That is because nothing ever changes in
> programming. That is why the Web is invariably programmed using COBOL,
> VSAM, CICS and...uh-oh....
>
> ...never mind!!!
>
> kenny (going back to work on his Lisp game engine with his new OpenGL
> shading reference in hand)
Dude, I'm writing openGL / Java code - I *know* that you can write good
games without using C++. HOWEVER what I or you do has no effect on the
game studios out there who have millions invested in staff knowledge and
tool chains built around C++.
I wouldn't even matter if these alternate solutions were technologically
superior (which you might argue) because the investment in current
technology adds up to a hell of a lot of inertia to change.
I wasn't making a claim that technology never changes, or better
solutions never come along - I'm talking about the studios investment in
tools and knowledge. That was the point of the ASM->C->C++ language
transition comment in the original post.
Peter Ashford wrote:
>>>
>>> Lisp would IMO be as good for games as C++ *if* the tools existed to
>>> support it (how many PS2 LISP compilers do you know of, for example)
>>>
>>> IMO that's the major reason that C++ is the only game in town -
>>> everyone looking for performance used to use ASM, then C, now C++.
>>> There's several generations of tool chains blending one into another
>>> meaning several generations of intertia for any other language to
>>> overcome. With equivallent tools, I believe that either LISP or Java
>>> could well be better options for developing the majority of game
>>> titles... but, that support does not exist and probably never will.
>>
>>
>>
>> No, they never will. That is because nothing ever changes in
>> programming. That is why the Web is invariably programmed using COBOL,
>> VSAM, CICS and...uh-oh....
>>
>> ...never mind!!!
>>
>> kenny (going back to work on his Lisp game engine with his new OpenGL
>> shading reference in hand)
>
>
> Dude, I'm writing openGL / Java code - I *know* that you can write good
> games without using C++. HOWEVER what I or you do has no effect on the
> game studios out there who have millions invested in staff knowledge and
> tool chains built around C++.
Fine, fine, fine! Like any dinosaur, C++ has a lot of inertia, for all
the reasons you stated. Do you think COBOL/VSAM had no inertia? Staff
knowledge? Existing software?
But you said "...and probably never will". Bzzt!
My read on the situation is, inertia schmertia. These dynasties
disappear overnight. And the edge Lisp has over C++ is close to an order
of magnitude, so this will be an exceptionally quick transition.
This whole thread started when some Microsoft drone did his master's
bidding and trashed Lisp on his personal Web site. That just confirms
what any follower of comp.lang.lisp can tell you: the Ice Age is over.
The thaw has begun. A steady stream of newbies has the old-timers
scrambling to keep up with the newby FAQs (and we're so happy to see
them that we do not even mind that the Qs are FA).
And Micro$oft is scared, as they always are by anything they cannot control.
As they say in your business, Game Over. I recommend AllegroCL on the
win32 platform, btw, if you want to start your re-training.
:)
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <·····················@twister.nyc.rr.com>,
·······@nyc.rr.com says...
> This whole thread started when some Microsoft drone did his master's
> bidding and trashed Lisp on his personal Web site. That just confirms
> what any follower of comp.lang.lisp can tell you: the Ice Age is over.
> The thaw has begun. A steady stream of newbies has the old-timers
> scrambling to keep up with the newby FAQs (and we're so happy to see
> them that we do not even mind that the Qs are FA).
No, it started when some idiot posted here that "C++ sucked for games".
The website you refer to has been there a long time, though not a
fraction as long as Lisp has existed.
If Lisp ever should have a major turnaround in its popularity, MS will
quite happily add Visual Lisp to their product range.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <·····················@twister.nyc.rr.com>,
> ·······@nyc.rr.com says...
> If Lisp ever should have a major turnaround in its popularity, MS will
> quite happily add Visual Lisp to their product range.
>
Who would they buy it from, do you think? lol..
Gregm
On Tue, 23 Nov 2004, Gerry Quinn wrote:
> The website you refer to has been there a long time, though not a
> fraction as long as Lisp has existed.
>
> If Lisp ever should have a major turnaround in its popularity, MS will
> quite happily add Visual Lisp to their product range.
>
I'm not so sure it'd be that simple. It'd require major changes to the CLR
as I understand it - for better or worse, .NET assumes a Java-like OO
model. And I suspect MS's commitment to it's pretty hefty, it's their
ticket off x86 should they feel the need.
--
······@flippac.org
Philippa Cowderoy wrote:
> On Tue, 23 Nov 2004, Gerry Quinn wrote:
>
>
>>The website you refer to has been there a long time, though not a
>>fraction as long as Lisp has existed.
>>
>>If Lisp ever should have a major turnaround in its popularity, MS will
>>quite happily add Visual Lisp to their product range.
>>
>
>
> I'm not so sure it'd be that simple. It'd require major changes to the CLR
> as I understand it - for better or worse, .NET assumes a Java-like OO
> model. And I suspect MS's commitment to it's pretty hefty, it's their
> ticket off x86 should they feel the need.
>
I hate .NET because I'm a Java fan and I think M$ are just trying to
crush something that's better than anything they could have thought of
themselves... but... .NET has been pretty successfull at getting
multiple languages to run in their runtime. There's already Lisp,
Haskell, Scheme, ML and many other languages running on the .NET platform.
.NET is evil and you should all shun M$, but I don't beleive that it has
the technical limitations you ascribe to it (I beleive those limitations
would be more likely applicable to the JVM which wasn't really designed
as a language neutral VM).
From: Edi Weitz
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <ubrdnxwyi.fsf@agharta.de>
On Thu, 25 Nov 2004 01:01:46 +1300, Peter Ashford <··@here.there.com> wrote:
> .NET is evil and you should all shun M$, but I don't beleive that it
> has the technical limitations you ascribe to it (I beleive those
> limitations would be more likely applicable to the JVM which wasn't
> really designed as a language neutral VM).
.NET makes a couple of assumptions that really don't fit Common
Lisp. Duane Rettig of Franz Inc. has posted a couple of interesting
articles about this topic some years ago. One of them is here:
<http://groups.google.com/groups?q=g:thl826061951d&dq=&hl=en&selm=47kp4j52c.fsf%40beta.franz.com>
Edi.
PS: Followup-To set.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Thu, 25 Nov 2004 01:01:46 +1300, Peter Ashford <··@here.there.com> wrote:
>
>
>>.NET is evil and you should all shun M$, but I don't beleive that it
>>has the technical limitations you ascribe to it (I beleive those
>>limitations would be more likely applicable to the JVM which wasn't
>>really designed as a language neutral VM).
>
>
> .NET makes a couple of assumptions that really don't fit Common
> Lisp. Duane Rettig of Franz Inc. has posted a couple of interesting
> articles about this topic some years ago. One of them is here:
>
> <http://groups.google.com/groups?q=g:thl826061951d&dq=&hl=en&selm=47kp4j52c.fsf%40beta.franz.com>
>
Interesting. Thank you.
On Thu, 25 Nov 2004, Peter Ashford wrote:
> I hate .NET because I'm a Java fan and I think M$ are just trying to
> crush something that's better than anything they could have thought of
> themselves... but... .NET has been pretty successfull at getting
> multiple languages to run in their runtime. There's already Lisp,
> Haskell, Scheme, ML and many other languages running on the .NET platform.
>
AIUI these tend to have interoperability limitations, though I guess I
should play with GHC's Haskell-on-.NET support once 6.4's out.
--
······@flippac.org
Gerry Quinn wrote:
> In article <·····················@twister.nyc.rr.com>,
> ·······@nyc.rr.com says...
>
>
>>This whole thread started when some Microsoft drone did his master's
>>bidding and trashed Lisp on his personal Web site. That just confirms
>>what any follower of comp.lang.lisp can tell you: the Ice Age is over.
>>The thaw has begun. A steady stream of newbies has the old-timers
>>scrambling to keep up with the newby FAQs (and we're so happy to see
>>them that we do not even mind that the Qs are FA).
>
>
> No, it started when some idiot posted here that "C++ sucked for games".
I meant in the larger sense, not that of the literal thread. And the
"idiot" is not really an idiot; the idiocy was a parody of the web site,
and the provocativeness intended simply to make for a lively, drawn-out
thread which would turn the un-saved on to Lisp.
The thread almost died, but you have kept it going nicely by sticking to
reasonable technical arguments and being more open-minded than is really
appropriate on Usenet. :)
> The website you refer to has been there a long time, though not a
> fraction as long as Lisp has existed.
When the site got noticed again and slammed on cll (again), the dweeb
added a second page pretending to respond to critics but actually
ducking all the solid objections.
>
> If Lisp ever should have a major turnaround in its popularity, MS will
> quite happily add Visual Lisp to their product range.
Yep. And it will break the standard so they can monopolize Lisp as well.
That will probably be the end of them.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> wrote in
··························@twister.nyc.rr.com:
> Gerry Quinn wrote:
>> In article <·····················@twister.nyc.rr.com>,
>> ·······@nyc.rr.com says...
<snip>
>> The website you refer to has been there a long time, though not
>> a fraction as long as Lisp has existed.
>
> When the site got noticed again and slammed on cll (again), the
> dweeb added a second page pretending to respond to critics but
> actually ducking all the solid objections.
What site? This thread started by some person that didn't posted
here second time.
This thread has just 668 posts and is growing...
Funny is he didn't say LISP is solution for all that problems,
however main debate was about LISP.
Two score and six years ago our fathers brought forth on this planet, a
new language, conceived with Lambda, and dedicated to the proposition that
all objects are created equal. Now Raghar wrote thusly:
> Kenny Tilton <·······@nyc.rr.com> wrote in
> ··························@twister.nyc.rr.com:
>
>> Gerry Quinn wrote:
>>> In article <·····················@twister.nyc.rr.com>,
>>> ·······@nyc.rr.com says...
> <snip>
>>> The website you refer to has been there a long time, though not
>>> a fraction as long as Lisp has existed.
>>
>> When the site got noticed again and slammed on cll (again), the
>> dweeb added a second page pretending to respond to critics but
>> actually ducking all the solid objections.
>
> What site? This thread started by some person that didn't posted
> here second time.
Pearls before swines, aka USENET poster remorse syndrome.
> This thread has just 668 posts and is growing...
>
> Funny is he didn't say LISP is solution for all that problems,
> however main debate was about LISP.
What part of "most of the good programmers graduated to languages like Lisp
or avoided C++ altogether" do you need help interpreting as an endorsement?
Raghar wrote:
> What site?
there is a thread in c.l.l that has "Lisp sucks for game" in its title
(check google) whose 1st message points to that site
> This thread started by some person that didn't posted
> here second time.
this post was a parody to the arguments given on the website. perhaps
the choice of newsgroups was ill advised
> This thread has just 668 posts and is growing...
actually, i found some of the subthreads quite interesting
hs
Hartmann Schaffer wrote:
> this post was a parody to the arguments given on the website.
Right. However, that should not be taken to mean that anything I wrote was
inaccurate. I stand by everything I wrote to the letter [1].
The original "Lisp sucks" web site focused on the perceived problems of
Lisp, ignoring the fact that C++, the implied alternative, "sucks" far, far
more.
[1] Except the term "closures" should have been used instead of
"higher-order functions"
In article <··················@yahoo.com>, ··········@yahoo.com says...
> Hartmann Schaffer wrote:
>
> > this post was a parody to the arguments given on the website.
>
> Right. However, that should not be taken to mean that anything I wrote was
> inaccurate. I stand by everything I wrote to the letter
On this newsgroup we have no particular interest in the institutional
squabbles of language advocates, so your 'parody' was somewhat wasted.
[As for the website and its companion, they look somewhat more coherent
and reasonable than most of what has been posted here.]
> The original "Lisp sucks" web site focused on the perceived problems of
> Lisp, ignoring the fact that C++, the implied alternative, "sucks" far, far
> more.
Then why do YOU think hardly anybody uses Lisp for games development?
What games have YOU developed in Lisp?
- Gerry Quinn
On Wed, 24 Nov 2004 11:26:59 -0000, Gerry Quinn
<······@DELETETHISindigo.ie> wrote:
> In article <··················@yahoo.com>, ··········@yahoo.com says...
>> Hartmann Schaffer wrote:
>>
>> > this post was a parody to the arguments given on the website.
>>
>> Right. However, that should not be taken to mean that anything I wrote
>> was
>> inaccurate. I stand by everything I wrote to the letter
>
> On this newsgroup we have no particular interest in the institutional
> squabbles of language advocates, so your 'parody' was somewhat wasted.
> [As for the website and its companion, they look somewhat more coherent
> and reasonable than most of what has been posted here.]
>
>> The original "Lisp sucks" web site focused on the perceived problems of
>> Lisp, ignoring the fact that C++, the implied alternative, "sucks" far,
>> far
>> more.
>
> Then why do YOU think hardly anybody uses Lisp for games development?
> What games have YOU developed in Lisp?
>
> - Gerry Quinn
Ehm.. Look at the number of cross postings.
comp.lang.lisp, which I am reading, does this sort of thing all the time.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>>The original "Lisp sucks" web site focused on the perceived problems of
>>Lisp, ignoring the fact that C++, the implied alternative, "sucks" far, far
>>more.
>
>
> Then why do YOU think hardly anybody uses Lisp for games development?
> What games have YOU developed in Lisp?
>
> - Gerry Quinn
Personally I think my point about the tool chain and knowledge
investment in C++ is a large part of why *any* other language will have
a hard time changing the way things are.
Peter Ashford <··@here.there.com> wrote in
··························@news.xtra.co.nz:
<snip>
>>
>> Then why do YOU think hardly anybody uses Lisp for games
>> development? What games have YOU developed in Lisp?
>>
>> - Gerry Quinn
>
> Personally I think my point about the tool chain and knowledge
> investment in C++ is a large part of why *any* other language
> will have a hard time changing the way things are.
Perhaps the reason is a code readability. It's very high in Java,
somewhat high in LISP, a little higher in un camuflaged C# and
completely unreadable for amateurs in C++ (If there was
communication between two different code bases) As a result your
chief could be uneducated*1 (idiot) and talk too much into your
work.
*1 change uneducated into university educated that forgot brain if
he had one.
My news server is down so it will be interesting if this will
appear
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··················@yahoo.com>, ··········@yahoo.com says...
> > Hartmann Schaffer wrote:
> >
> > > this post was a parody to the arguments given on the website.
> >
...
> [As for the website and its companion, they look somewhat more coherent
> and reasonable than most of what has been posted here.]
This comment is a sad but telling commentary on most of what you've
written here.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <······················@195.250.128.45>, ······@mail.com
says...
> Funny is he didn't say LISP is solution for all that problems,
> however main debate was about LISP.
His name was enough to mark him as a Lisp crank.
- Gerry Quinn
>> Dude, I'm writing openGL / Java code - I *know* that you can write
>> good games without using C++. HOWEVER what I or you do has no effect
>> on the game studios out there who have millions invested in staff
>> knowledge and tool chains built around C++.
>
>
> Fine, fine, fine! Like any dinosaur, C++ has a lot of inertia, for all
> the reasons you stated. Do you think COBOL/VSAM had no inertia? Staff
> knowledge? Existing software?
>
> But you said "...and probably never will". Bzzt!
I also said "game studios" and "tool chains"
Those were never programmed in COBOL, and studios with products that
cost as much as they currently do and employ as large teams as they
currently do have NEVER existed before in the history of computing, so
your analogy is not at all to the point. Your analogy works for
business computing, and in that context I'd agree, That wasn't what I
was talking about however.
> My read on the situation is, inertia schmertia. These dynasties
> disappear overnight.
No chance.
And the edge Lisp has over C++ is close to an order
> of magnitude, so this will be an exceptionally quick transition.
Don't berate me, I like LISP.
> This whole thread started when some Microsoft drone did his master's
> bidding and trashed Lisp on his personal Web site. That just confirms
> what any follower of comp.lang.lisp can tell you: the Ice Age is over.
> The thaw has begun. A steady stream of newbies has the old-timers
> scrambling to keep up with the newby FAQs (and we're so happy to see
> them that we do not even mind that the Qs are FA).
>
> And Micro$oft is scared, as they always are by anything they cannot
> control.
My comments have nothing to do with the beast from Redmond.
> As they say in your business, Game Over. I recommend AllegroCL on the
> win32 platform, btw, if you want to start your re-training.
I don't need to retrain, I already know LISP, have done for years. And
I prefer CLISP thanks :o)
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <uu0rfcqv9.fsf@news.dtpq.com>
Peter Ashford <··@here.there.com> writes:
>
> Those were never programmed in COBOL, and studios with products that
> cost as much as they currently do and employ as large teams as they
> currently do have NEVER existed before in the history of computing,
What is it about game studios that is fundamentally different
from any other software house? Certainly the size of their
teams and the cost of their investments is miniscule compared
to most other software development efforts which have changed
technologies over years.
Christopher C. Stacy wrote:
> Peter Ashford <··@here.there.com> writes:
>
>>Those were never programmed in COBOL, and studios with products that
>>cost as much as they currently do and employ as large teams as they
>>currently do have NEVER existed before in the history of computing,
>
>
> What is it about game studios that is fundamentally different
> from any other software house? Certainly the size of their
> teams and the cost of their investments is miniscule compared
> to most other software development efforts which have changed
> technologies over years.
Tools and middleware providers have small niches that they live in.
There is a very small market of game developers in the world, so the
number of people who will buy a physics engine or a rendering engine is
very very small. Noone in that market can afford to produce a product
for a non-existent market and it's hard to start out with LISP because
the middleware tools don't exist. You can write everything yourself but
that's a serious impediment to writing a AAA game where most, if not
all, games use at least some middleware from someone else.
In article <·····················@news.xtra.co.nz>, ··@here.there.com
says...
> Christopher C. Stacy wrote:
> > What is it about game studios that is fundamentally different
> > from any other software house? Certainly the size of their
> > teams and the cost of their investments is miniscule compared
> > to most other software development efforts which have changed
> > technologies over years.
>
> Tools and middleware providers have small niches that they live in.
> There is a very small market of game developers in the world, so the
> number of people who will buy a physics engine or a rendering engine is
> very very small. Noone in that market can afford to produce a product
> for a non-existent market and it's hard to start out with LISP because
> the middleware tools don't exist. You can write everything yourself but
> that's a serious impediment to writing a AAA game where most, if not
> all, games use at least some middleware from someone else.
What puzzles me is, if Lisp is so good, where are the shareware and
freeware Lisp games?
There are plenty in C++, and C, and VB, and Delphi, and Flash, and Java.
We know it's perfectly do-able - people have implemented games in Lisp
on this thread. So what goes wrong, if the language is really so
powerful and productive?
It's like insisting that a chisel is better than an axe for cutting
trees, all the while shivering because your house has no firewood!
[Okay, we accept that the great hero Badcur once cut down a tree with a
chisel, nearly as fast as an average person might do with an axe.]
- Gerry Quinn
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <usm6xjooz.fsf@news.dtpq.com>
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <·····················@news.xtra.co.nz>, ··@here.there.com
> says...
> > Christopher C. Stacy wrote:
>
> > > What is it about game studios that is fundamentally different
> > > from any other software house? Certainly the size of their
> > > teams and the cost of their investments is miniscule compared
> > > to most other software development efforts which have changed
> > > technologies over years.
> >
> > Tools and middleware providers have small niches that they live in.
> > There is a very small market of game developers in the world, so the
> > number of people who will buy a physics engine or a rendering engine is
> > very very small. Noone in that market can afford to produce a product
> > for a non-existent market and it's hard to start out with LISP because
> > the middleware tools don't exist. You can write everything yourself but
> > that's a serious impediment to writing a AAA game where most, if not
> > all, games use at least some middleware from someone else.
>
> What puzzles me is, if Lisp is so good, where are the shareware and
> freeware Lisp games?
This is your own personal puzzle, of course.
In article <·············@news.dtpq.com>, ······@news.dtpq.com says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> >
> > What puzzles me is, if Lisp is so good, where are the shareware and
> > freeware Lisp games?
>
> This is your own personal puzzle, of course.
If it doesn't puzzle you, how about explaining it to the rest of us?
- Gerry Quinn
Gerry Quinn wrote:
> In article <·············@news.dtpq.com>, ······@news.dtpq.com says...
>> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>> >
>> > What puzzles me is, if Lisp is so good, where are the shareware and
>> > freeware Lisp games?
You mean like your crapola screensaver a dyslexic child would be ashamed of
creating?
You were given examples of commercial Lisp successes, including platform
gaming, now you have to insist on freeware, as if you are making some
point?
>> This is your own personal puzzle, of course.
>
> If it doesn't puzzle you, how about explaining it to the rest of us?
It's just you, troll. No "us".
followup set
In article <··················@yahoo.com>, ··········@yahoo.com says...
> Gerry Quinn wrote:
> >> >
> >> > What puzzles me is, if Lisp is so good, where are the shareware and
> >> > freeware Lisp games?
>
> You mean like your crapola screensaver a dyslexic child would be ashamed of
> creating?
My 'crapola screensaver' went some considerable way towards buying me a
house. I don't have to rely entirely on my own judgement rergarding its
quality. The opinion of an infantile troll hurling abuse when defeated
in argument is duly noted.
> You were given examples of commercial Lisp successes, including platform
> gaming, now you have to insist on freeware, as if you are making some
> point?
Actually, I've been given ONE example of a very talented team that had
some success using Lisp for part of their code. There's not much
evidence that their success was due to the use of Lisp (bit of a
curate's egg as far as I can see), and it may very well have been
despite it.
The point I was making, however, relates more to the posters on this
games newsgroup who are pushing Lisp as the new wonder-drug for games
programming. They don't seem to be working in the commercial games
industry (unlike the author of the website you claim to be the origin of
your clueless 'parody'). Yet neither is there much evidence that they
have done much in the way of games programming outside of the industry.
You can criticise my software - but have you created ANYTHING AT ALL
that you are not ashamed to put on public display, other than a stupid
troll? You are all mouth and no trousers, Mr. "Neo-LISPer". [I'm not
going to bother deconstructing that name, I think we can all easily
parse the way in which the latest evanescency of pop culture has
provided a hook on which to hang fantasies of infantile omnipotence
emerging without effort from knowledge of the Primal Secret.]
I ask again - if Lisp is so great for writing games, where are the games
written by the Lisp enthusiasts? If chisels are so great for cutting
trees, why are the chisel-using woodcutters shivering in the cold?
- Gerry Quinn
Gerry Quinn wrote:
> I ask again - if Lisp is so great for writing games, where are the games
> written by the Lisp enthusiasts? If chisels are so great for cutting
> trees, why are the chisel-using woodcutters shivering in the cold?
>
As a matter of fact, I'm writing one right now. (Along with the.. hmm...
four other projects I'm currently working on. Don't hold your breath.)
It's a clone of the classic (as in old) game called "Gravity Well", but
looks like it's going to be much smaller than the original, code-wise.
Well, such is life...
If you're interested in seeing a real Lisp-based game, tell me so and I'll
slip you a note when it's done.
Oh, and before anyone starts talking about GC pauses, it isn't nearly as
much of a problem as people want to believe. My code only conses on object
creation, not mere state changes; that, combined with my "purify" call at
startup, means even a full GC takes too little time to notice any jitter.
(Yes, I'd like more control of the GC; unpurify, in particular, as it's
leaking memory right now. No, it isn't a big issue, and I could get around
it if it was.)
Svein Ove Aas wrote:
> Oh, and before anyone starts talking about GC pauses, it isn't nearly as
> much of a problem as people want to believe. My code only conses on object
> creation, not mere state changes; that, combined with my "purify" call at
> startup, means even a full GC takes too little time to notice any jitter.
>
> (Yes, I'd like more control of the GC; unpurify, in particular, as it's
> leaking memory right now. No, it isn't a big issue, and I could get around
> it if it was.)
Actually, I'm very interested in this. Do you have to take a lot of care to
make sure your code doesn't cons? Does cons-less code look strange, or is
it more difficult to maintain? I suppose to write it isn't that difficult,
as you start out with normal lisp code that functions properly and then
transform it into something that doesn't cons.
In fact, I seem to remember the folks that wrote the Orbitz airline stuff
going through the same thing. I wonder if there's a paper anywhere
detailing the sorts of things they had to do to keep memory usage constant
and thus remove dependence on the GC. If not, I'd be interested to hear
about the subject from someone else.
Chris Capel
Chris Capel <······@iba.nktech.net> writes:
> Svein Ove Aas wrote:
>
> > Oh, and before anyone starts talking about GC pauses, it isn't nearly as
> > much of a problem as people want to believe. My code only conses on object
> > creation, not mere state changes; that, combined with my "purify" call at
> > startup, means even a full GC takes too little time to notice any jitter.
> >
> > (Yes, I'd like more control of the GC; unpurify, in particular, as it's
> > leaking memory right now. No, it isn't a big issue, and I could get around
> > it if it was.)
>
> Actually, I'm very interested in this. Do you have to take a lot of care to
> make sure your code doesn't cons?
No, it's not difficult at all: just cons all you need at the beginning:
(defvar *conses* (make-list +cons-cell-pool-size+))
(defun alloc-cons (&optional car cdr)
(let ((cell (pop *conses*)))
(setf (car cell) car (cdr cell) cdr)
cell))
(defun free-cons (cell)
(push cell *conses*))
And then uses alloc-cons instead of cons, and free-cons instead of
(setf cell nil). (You should add functions such as mapcar, remove,
append, etc to use these alloc-cons/free-cons too).
> Does cons-less code look strange, or is
> it more difficult to maintain? I suppose to write it isn't that difficult,
> as you start out with normal lisp code that functions properly and then
> transform it into something that doesn't cons.
Not stranger and not more difficult than maintaing C code with
malloc/free. Starting from existing code, you just change (:use
"COMMON-LISP") with (:use "CONSLESS-COMMON-LISP") in your package
definition, and you add some strategically placed free-cons.
> In fact, I seem to remember the folks that wrote the Orbitz airline stuff
> going through the same thing. I wonder if there's a paper anywhere
> detailing the sorts of things they had to do to keep memory usage constant
> and thus remove dependence on the GC. If not, I'd be interested to hear
> about the subject from someone else.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Pascal Bourguignon wrote:
> Chris Capel <······@iba.nktech.net> writes:
>
>> Svein Ove Aas wrote:
>>
>> > Oh, and before anyone starts talking about GC pauses, it isn't nearly
>> > as much of a problem as people want to believe. My code only conses on
>> > object creation, not mere state changes; that, combined with my
>> > "purify" call at startup, means even a full GC takes too little time to
>> > notice any jitter.
>> >
>> > (Yes, I'd like more control of the GC; unpurify, in particular, as it's
>> > leaking memory right now. No, it isn't a big issue, and I could get
>> > around it if it was.)
>>
>> Actually, I'm very interested in this. Do you have to take a lot of care
>> to make sure your code doesn't cons?
>
> No, it's not difficult at all: just cons all you need at the beginning:
>
> (defvar *conses* (make-list +cons-cell-pool-size+))
>
> (defun alloc-cons (&optional car cdr)
> (let ((cell (pop *conses*)))
> (setf (car cell) car (cdr cell) cdr)
> cell))
>
> (defun free-cons (cell)
> (push cell *conses*))
>
> And then uses alloc-cons instead of cons, and free-cons instead of
> (setf cell nil). (You should add functions such as mapcar, remove,
> append, etc to use these alloc-cons/free-cons too).
Ah! I wouldn't have thought of that. I suppose that the only difficulty in
this route is finding all of the different standard functions that cons
(like that memory leak Svein mentioned).
>> Does cons-less code look strange, or is
>> it more difficult to maintain? I suppose to write it isn't that
>> difficult, as you start out with normal lisp code that functions properly
>> and then transform it into something that doesn't cons.
>
> Not stranger and not more difficult than maintaing C code with
> malloc/free. Starting from existing code, you just change (:use
> "COMMON-LISP") with (:use "CONSLESS-COMMON-LISP") in your package
> definition, and you add some strategically placed free-cons.
Hmm. So, you have to make sure to allocate enough conses at the beginning of
the code. And then you have to make sure that you don't alloc-cons too
much, either, or else you'll run out of your own pool. So cons-less code
*will* end up looking different than normal lisp code--code that doesn't
have soft real-time constraints like graphics code--but still a lot better
than C++.
And even then, you don't want to be allocating and freeing more memory than
necessary, since that takes time and can be indeterministic (in that you
might be freeing long lists of things). And I suppose the more arrays you
use, the better. Is there a way to preallocate space for arrays?
It seems to me like you still wouldn't want to use cl-consless:remove as
opposed to cl-c:delete and similar pairs because the functions themselves
don't know how the return and original values are going to be used, so they
have to leave them alone, and thus waste memory in places where the
original won't be used any longer.
Chris Capel
Hello!
Chris Capel <······@iba.nktech.net> wrote:
>[...]
>Hmm. So, you have to make sure to allocate enough conses at the beginning of
>the code. And then you have to make sure that you don't alloc-cons too
>much, either, or else you'll run out of your own pool. So cons-less code
>*will* end up looking different than normal lisp code--code that doesn't
>have soft real-time constraints like graphics code--but still a lot better
>than C++.
However, for soft real-time I'd ask myself whether it's worth to write
special cost, comared to shopping around for an implementation of a
language with automatic memory management with real-time/incremental/...
GC (i.e. a GC technique that guarantees a not too high upper limit on
latencies).
Kind regards,
Hannah.
From: Wade Humeniuk
Subject: Re: Cons-less code (was C++ sucks for games.... oh really?)
Date:
Message-ID: <RMdqd.12767$VL6.2433@clgrps13>
Pascal Bourguignon wrote:
>
>
> No, it's not difficult at all: just cons all you need at the beginning:
>
> (defvar *conses* (make-list +cons-cell-pool-size+))
>
> (defun alloc-cons (&optional car cdr)
> (let ((cell (pop *conses*)))
> (setf (car cell) car (cdr cell) cdr)
> cell))
>
> (defun free-cons (cell)
> (push cell *conses*))
>
> And then uses alloc-cons instead of cons, and free-cons instead of
> (setf cell nil). (You should add functions such as mapcar, remove,
> append, etc to use these alloc-cons/free-cons too).
>
>
That is not really cons-less code. All that has happened here is that
you have taken over manual control of memory management. I would
think most Lisps allocate conses just like that pop, but garbage collect
it within gc. The suggested method would probably be even slower than
letting the Lisp do it itself (it is written to do just that).
Also if I not mistaken many Lisp compilers can reuse conses locally within
a function. The only definition I can think of cons-less code is when
the Lisp indicates that it did not allocate conses with a code profile.
Conses do not happen just with lists, but with boxing and unboxing various
values.
Wade
Wade Humeniuk wrote:
> Pascal Bourguignon wrote:
>>
>> No, it's not difficult at all: just cons all you need at the beginning:
>>
>> (defvar *conses* (make-list +cons-cell-pool-size+))
>>
>> (defun alloc-cons (&optional car cdr)
>> (let ((cell (pop *conses*)))
>> (setf (car cell) car (cdr cell) cdr)
>> cell))
>>
>> (defun free-cons (cell)
>> (push cell *conses*))
>>
>> And then uses alloc-cons instead of cons, and free-cons instead of
>> (setf cell nil). (You should add functions such as mapcar, remove,
>> append, etc to use these alloc-cons/free-cons too).
>
> That is not really cons-less code. All that has happened here is that
> you have taken over manual control of memory management. I would
> think most Lisps allocate conses just like that pop, but garbage collect
> it within gc. The suggested method would probably be even slower than
> letting the Lisp do it itself (it is written to do just that).
Well, the one thing I *can* say about this is that once you're done with any
given cons, you can go ahead and free it on the spot, which will spread out
your "manual gc" over thousands or millions of tiny "gc" calls a second,
which would basically eliminate GC pauses. But probably much slower
overall.
> The only definition I can think of cons-less code is when
> the Lisp indicates that it did not allocate conses with a code profile.
This was what I was imagining, and it seems to me that this sort of
cons-less code, without alloc-cons and free-cons, would look very strange
indeed compared to normal code. I remember someone who had worked on it
making that observation about the Orbitz code.
In fact, just for fun a while back, I made a small function to search for
some strange property of number having something to do with primes, and it
didn't do anything that required consing, and yet was consing up a storm,
so I put in declarations for all the numbers, and that got rid of the
problem. But boy was that code hard to read! I had to declare the type, not
only of every function and parameter, but of every intermediate value in
every calculation. Ugh.
Chris Capel
Chris Capel <······@iba.nktech.net> writes:
> This was what I was imagining, and it seems to me that this sort of
> cons-less code, without alloc-cons and free-cons, would look very strange
> indeed compared to normal code. I remember someone who had worked on it
> making that observation about the Orbitz code.
>
> In fact, just for fun a while back, I made a small function to search for
> some strange property of number having something to do with primes, and it
> didn't do anything that required consing, and yet was consing up a storm,
> so I put in declarations for all the numbers, and that got rid of the
> problem. But boy was that code hard to read! I had to declare the type, not
> only of every function and parameter, but of every intermediate value in
> every calculation. Ugh.
This would be a case where having a compiler that does type
inferencing would have been helpful. I'm guessing you were not using
a Python-based system (cmucl or sbcl), or if you were, most of those
declarations were unnecessary. I'd suggest reading the section of the
CMUCL manual on type inferencing, it should help give you an idea of
the style that Python handles best.
From: Wade Humeniuk
Subject: Re: Cons-less code (was C++ sucks for games.... oh really?)
Date:
Message-ID: <v2eqd.12847$VL6.811@clgrps13>
Pascal Bourguignon wrote:
>
> No, it's not difficult at all: just cons all you need at the beginning:
>
> (defvar *conses* (make-list +cons-cell-pool-size+))
>
> (defun alloc-cons (&optional car cdr)
> (let ((cell (pop *conses*)))
> (setf (car cell) car (cdr cell) cdr)
> cell))
>
> (defun free-cons (cell)
> (push cell *conses*))
>
Oh, one more thing, I think free-cons, should
be
(defun free-cons (cell)
(setf (car cell) nil)
(setf (cdr cell) nil)
(push cell *conses*))
Unless (car cell) is a member of *conses* and then,
one has to track whether (caar cell) has any references,
and so on and so on......
Oh yeah and whether (cdr cell) is a member of *conses*
also....
(defvar *allocated-conses* nil)
(defun alloc-cons (&optional car cdr)
(let ((cell (pop *conses*)))
(setf (car cell) car (cdr cell) cdr)
(push cell *allocated-conses*)
cell))
(defun free-cons (cell)
(when (member (car cell) *allocated-conses*)
(free-cons (car cell))
(when (member (cdr cell) *allocated-conses*)
(free-cons (cdr cell))
(setf (car cell) nil
(cdr cell) nil)
(delete cell *allocated-conses*)
(push cell *conses*))
This code is still not sufficient as some list
may be made up of maunally allocated conses
and system allocated conses. One would have
to traverse the whole tree, delinking the whole
list.
Wade
Wade Humeniuk <····································@telus.net> writes:
> Pascal Bourguignon wrote:
>
> > No, it's not difficult at all: just cons all you need at the
> > beginning:
> > (defvar *conses* (make-list +cons-cell-pool-size+))
> > (defun alloc-cons (&optional car cdr)
> > (let ((cell (pop *conses*)))
> > (setf (car cell) car (cdr cell) cdr)
> > cell))
> > (defun free-cons (cell)
> > (push cell *conses*))
> >
>
> Oh, one more thing, I think free-cons, should
> be
>
> (defun free-cons (cell)
> (setf (car cell) nil)
> (setf (cdr cell) nil)
> (push cell *conses*))
>
> Unless (car cell) is a member of *conses* and then,
> one has to track whether (caar cell) has any references,
> and so on and so on......
Perhaps, but you don't want to give too much work to the garbage
collector. You may even have disabled it!
> This code is still not sufficient as some list
> may be made up of maunally allocated conses
> and system allocated conses. One would have
> to traverse the whole tree, delinking the whole
> list.
System allocated conses are taken care by rewritting all the
COMMON-LISP functions that do cons.
And of course, this applies to strings, arrays, objects, etc.
And avoid all declaration to avoid unboxing/reboxing!
Yes, you will have to rewrite the whole COMMON-LISP package.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
On 28 Nov 2004 03:18:35 +0100, Pascal Bourguignon wrote:
> No, it's not difficult at all: just cons all you need at the beginning:
> (defvar *conses* (make-list +cons-cell-pool-size+))
> (defun alloc-cons (&optional car cdr)
> (let ((cell (pop *conses*)))
> (setf (car cell) car (cdr cell) cdr)
> cell))
> (defun free-cons (cell)
> (push cell *conses*))
(push cell *conses*) == (setq *conses* (cons cell *conses*))
i.e., this conses.
Try this, instead:
(defun alloc-cons (&optional car cdr)
(if *conses*
(let ((cell *conses*))
(setq *conses* (cdr cell)
(car cell) car
(cdr cell) cdr)
cell)
(cons car cdr))) ; or error, if you prefer
(defun free-cons (cell)
(setq *conses* (nconc cell *conses*))
nil)
--
If that makes any sense to you, you have a big problem.
-- C. Durance, Computer Science 234
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
·······@gmail.com (Paul Khuong) writes:
> > (defvar *conses* (make-list +cons-cell-pool-size+))
> [...]
> Wouldn't it be better in the general case to use dynamic-extent and to
> avoid constructs that return cons (escaping cons can't be simply stack
> allocated)? That would leave the pre-allocated pool only for those
> cases where it can't be avoided. Basically, this seems to be the same
> as malloc-less code in non-GCed languages like C.
I would rather still programm in Lisp... Actually, in C/C++ I never
use "dynamic-extent" objects, at most "auto" variables. But this
could be something to put in a macro.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Pascal Bourguignon <····@mouse-potato.com> writes:
> I would rather still programm in Lisp... Actually, in C/C++ I never
> use "dynamic-extent" objects, at most "auto" variables. But this
> could be something to put in a macro.
What is the difference between Common Lisp's DYNAMIC-EXTENT and
automatic variables in C/C++? I think I get the case in Lisp where a
special variable is rebound in a LET. But what about variables that
are created by a LET but never leave the LET? Can't those be stack
allocated like C automatic variables? Isn't that DYNAMIC-EXTENT?
How fancy would the compiler have to be to assume DYNAMIC-EXTENT
without an explicit declaration?
I looked at HyperSpec/Body/d_dynami.htm#dynamic-extent and it says,
"The most common optimization is to stack allocate the initial value
of the objects named by the vars."
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Paul F. Dietz
Subject: Re: DYNAMIC-EXTENT vs C's auto (was Re: Cons-less code)
Date:
Message-ID: <41AB3628.1070406@dls.net>
David Steuber wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>
>>I would rather still programm in Lisp... Actually, in C/C++ I never
>>use "dynamic-extent" objects, at most "auto" variables. But this
>>could be something to put in a macro.
>
>
> What is the difference between Common Lisp's DYNAMIC-EXTENT and
> automatic variables in C/C++? I think I get the case in Lisp where a
> special variable is rebound in a LET. But what about variables that
> are created by a LET but never leave the LET? Can't those be stack
> allocated like C automatic variables? Isn't that DYNAMIC-EXTENT?
>
> How fancy would the compiler have to be to assume DYNAMIC-EXTENT
> without an explicit declaration?
>
> I looked at HyperSpec/Body/d_dynami.htm#dynamic-extent and it says,
> "The most common optimization is to stack allocate the initial value
> of the objects named by the vars."
Understand that *variables* are not the interesting things to stack
allocate, objects are. DYNAMIC-EXTENT says that the objects to which
the variable are bound are not accessible after the scope of the variable.
Without an explicit dynamic-extent declaration, the compiler
would have to perform analysis to determine that the value
doesn't 'escape'. Example:
(defun foo ()
(let ((x (cons 'a 'b)))
(setf *s* x)
nil))
Here, the cons created in the second line cannot be stack allocated,
since it is still accessible (through the special variable *s*) after
the scope of x.
Closures can also be declared dynamic extent, if they are bound to
function names in FLET or LABELS forms. In some cases implementations
can determined that unnamed closures (from lambdas) can also be
stack allocated, most typically when they are passed to builtin
functions that the compiler knows don't allow that parameter to
escape.
Paul
From: Svein Ove Aas
Subject: Re: DYNAMIC-EXTENT vs C's auto (was Re: Cons-less code)
Date:
Message-ID: <cofdlr$97f$1@services.kq.no>
David Steuber wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> I would rather still programm in Lisp... Actually, in C/C++ I never
>> use "dynamic-extent" objects, at most "auto" variables. But this
>> could be something to put in a macro.
>
>
> What is the difference between Common Lisp's DYNAMIC-EXTENT and
> automatic variables in C/C++? I think I get the case in Lisp where a
> special variable is rebound in a LET. But what about variables that
> are created by a LET but never leave the LET? Can't those be stack
> allocated like C automatic variables? Isn't that DYNAMIC-EXTENT?
>
Dynamic-extent variables can be passed on downstream. Consider this
situation:
(defun fun1 ()
(let ((list (list 1 2 3)))
(declare (dynamic-extent list))
(fun2 list)))
(defun fun2 (list)
(print list))
Undr normal circumstances, list is a cons cell pointing to another cons cell
pointing to a third cons cell. Simple, typical list, but allocated on the
heap.
With dynamic-extent, those three cells (may, not on SBCL at the moment) get
allocated on the stack instead; when passed to fun2, it gets a reference to
fun1's stack frame instead of the heap. (Well, actually fun2 gets a copy of
the first cons cell, but that's still on the stack, so...)
After returning from fun1 (dynamic-extent, see), said cons cells will be
gone, but if something along the line had passed on one of the first two
cons cells in the list, said cell would be pointing into demon space.
> How fancy would the compiler have to be to assume DYNAMIC-EXTENT
> without an explicit declaration?
>
Depending on the situation, sufficiently smart.
> I looked at HyperSpec/Body/d_dynami.htm#dynamic-extent and it says,
> "The most common optimization is to stack allocate the initial value
> of the objects named by the vars."
>
The SBCL manual has some words on the issue, too.
From: David Steuber
Subject: Re: DYNAMIC-EXTENT vs C's auto (was Re: Cons-less code)
Date:
Message-ID: <87llcknyi4.fsf@david-steuber.com>
Svein Ove Aas <·········@aas.no> writes:
> David Steuber wrote:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> >
> >> I would rather still programm in Lisp... Actually, in C/C++ I never
> >> use "dynamic-extent" objects, at most "auto" variables. But this
> >> could be something to put in a macro.
> >
> >
> > What is the difference between Common Lisp's DYNAMIC-EXTENT and
> > automatic variables in C/C++? I think I get the case in Lisp where a
> > special variable is rebound in a LET. But what about variables that
> > are created by a LET but never leave the LET? Can't those be stack
> > allocated like C automatic variables? Isn't that DYNAMIC-EXTENT?
> >
> Dynamic-extent variables can be passed on downstream. Consider this
> situation:
>
> (defun fun1 ()
> (let ((list (list 1 2 3)))
> (declare (dynamic-extent list))
> (fun2 list)))
>
> (defun fun2 (list)
> (print list))
>
>
> Undr normal circumstances, list is a cons cell pointing to another cons cell
> pointing to a third cons cell. Simple, typical list, but allocated on the
> heap.
>
> With dynamic-extent, those three cells (may, not on SBCL at the moment) get
> allocated on the stack instead; when passed to fun2, it gets a reference to
> fun1's stack frame instead of the heap. (Well, actually fun2 gets a copy of
> the first cons cell, but that's still on the stack, so...)
>
> After returning from fun1 (dynamic-extent, see), said cons cells will be
> gone, but if something along the line had passed on one of the first two
> cons cells in the list, said cell would be pointing into demon space.
It's the same way in C++ though, isn't it? If you return a reference
or pointer to an object that was stack allocated and now no longer
exists you are begging for disaster. Is this a common error for C or
C++ programmers? I know it is according to the Java sales literature
but I don't remember ever doing it myself. Then again, in C or C++
the only heap objects created after program startup are very
explicitly created with malloc or new. Everything else is on the
stack or statically allocated.
> > How fancy would the compiler have to be to assume DYNAMIC-EXTENT
> > without an explicit declaration?
> >
> Depending on the situation, sufficiently smart.
This brings up another question I've had. No one seems to have
written the elusive sufficiently smart compiler. Is this because it
is impossible to do in the halting problem sense? Or has no one had
the time?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Is this a common error for C or C++ programmers?
I've never done it, and I've never seen a bug in any production code
attributed to such a mistake. It perhaps arises among students in a
first course.
> I know it is according to the Java sales literature but I don't
> remember ever doing it myself.
Much of what distinguishes Java from C and C++ is based on
aggressively precluding these kinds errors that in my experience just
don't arise. I wonder if Gosling had been working with a team of poor
C++ programmers, and decided that bondage would be more efficient than
enlightenment.
--
Steven E. Harris
From: Paul F. Dietz
Subject: Re: DYNAMIC-EXTENT vs C's auto (was Re: Cons-less code)
Date:
Message-ID: <1ZednZLxhKrxVTbcRVn-ow@dls.net>
David Steuber wrote:
>>>How fancy would the compiler have to be to assume DYNAMIC-EXTENT
>>>without an explicit declaration?
>>>
>>
>>Depending on the situation, sufficiently smart.
>
>
> This brings up another question I've had. No one seems to have
> written the elusive sufficiently smart compiler. Is this because it
> is impossible to do in the halting problem sense? Or has no one had
> the time?
I think it's a combination of lack of time, lack of demand, and
the complexity of getting it right (in other words, cost).
I think faster computers (and automated testing) can help deal
with the first and third points. I also hope demand is increasing.
BTW, some lisp compilers do allocate closures with dynamic extent in
some situations where it is safe to do so.
Paul
From: Paul F. Dietz
Subject: Re: DYNAMIC-EXTENT vs C's auto (was Re: Cons-less code)
Date:
Message-ID: <BJadnU9ZJPuHjzDcRVn-3Q@dls.net>
David Steuber wrote:
>>I think it's a combination of lack of time, lack of demand, and
>>the complexity of getting it right (in other words, cost).
>>
>>I think faster computers (and automated testing) can help deal
>>with the first and third points. I also hope demand is increasing.
>
>
> As a general rule, I would like the compiler to produce the fastest
> code it can (in a reasonable time). Just because computers are
> getting faster is no reason to gratuitously produce slow code. I
> don't think hardware really is so cheap.
You misunderstood my point. Computers are getting faster, which
is making the edit-compile-test cycle faster for big programs,
*such as Lisp implementations*. I think one of the reasons for
the increase in activity on the internals of the free lisps
is that it's becoming easier and easier to hack on them, even
on cheap hardware.
Fast hardware also lets you run 19K+ regression test suites
pretty quickly. :) And if you want the compilers to get smarter,
you need to have some assurance that they're correct. Fast hardware
lets you immediately pound on them with millions of automatically
generated tests.
>>BTW, some lisp compilers do allocate closures with dynamic extent in
>>some situations where it is safe to do so.
>
> Off the top of my head, I can't think of such a situation.
For example: when the closure is passed as an argument to a standardized
function that the system knows will not allow the argument to escape.
Any :test, :test-not, or :key argument to such functions, function
arguments to MAP + friends, the -IF(-NOT) functions, SORT, and so
on (some of these may get done with inlining, though).
Paul
From: David Steuber
Subject: Re: DYNAMIC-EXTENT vs C's auto (was Re: Cons-less code)
Date:
Message-ID: <878y8iatpr.fsf@david-steuber.com>
"Paul F. Dietz" <·····@dls.net> writes:
> David Steuber wrote:
>
> >>I think it's a combination of lack of time, lack of demand, and
> >>the complexity of getting it right (in other words, cost).
> >>
> >>I think faster computers (and automated testing) can help deal
> >>with the first and third points. I also hope demand is increasing.
> > As a general rule, I would like the compiler to produce the fastest
> > code it can (in a reasonable time). Just because computers are
> > getting faster is no reason to gratuitously produce slow code. I
> > don't think hardware really is so cheap.
>
> You misunderstood my point. Computers are getting faster, which
> is making the edit-compile-test cycle faster for big programs,
> *such as Lisp implementations*. I think one of the reasons for
> the increase in activity on the internals of the free lisps
> is that it's becoming easier and easier to hack on them, even
> on cheap hardware.
>
> Fast hardware also lets you run 19K+ regression test suites
> pretty quickly. :) And if you want the compilers to get smarter,
> you need to have some assurance that they're correct. Fast hardware
> lets you immediately pound on them with millions of automatically
> generated tests.
Ah. Right. That makes sense.
> >>BTW, some lisp compilers do allocate closures with dynamic extent in
> >>some situations where it is safe to do so.
> > Off the top of my head, I can't think of such a situation.
>
> For example: when the closure is passed as an argument to a standardized
> function that the system knows will not allow the argument to escape.
> Any :test, :test-not, or :key argument to such functions, function
> arguments to MAP + friends, the -IF(-NOT) functions, SORT, and so
> on (some of these may get done with inlining, though).
I've done this and not recognized it for what it was. I wonder if
that is another step towards Lisp-think. The language hasn't become
transparent for me yet, if you get my meaning, but I think I'm getting
there.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Nikodemus Siivola
Subject: Re: DYNAMIC-EXTENT vs C's auto (was Re: Cons-less code)
Date:
Message-ID: <cokao0$i6anj$1@midnight.cs.hut.fi>
David Steuber <·····@david-steuber.com> wrote:
>> BTW, some lisp compilers do allocate closures with dynamic extent in
>> some situations where it is safe to do so.
> Off the top of my head, I can't think of such a situation. But that's
(defun frob (list)
(mapcar (lambda (elt)
(list elt list))
list))
The compiler could here infer that the closure was dynamic-extent and
stack-allocate it even without a declaration to the effect: there is
no way for the closure to escape.
Cheers,
-- Nikodemus
Pascal Bourguignon <····@mouse-potato.com> wrote in message news:<··············@thalassa.informatimago.com>...
> ·······@gmail.com (Paul Khuong) writes:
> > > (defvar *conses* (make-list +cons-cell-pool-size+))
> > [...]
> > Wouldn't it be better in the general case to use dynamic-extent and to
> > avoid constructs that return cons (escaping cons can't be simply stack
> > allocated)? That would leave the pre-allocated pool only for those
> > cases where it can't be avoided. Basically, this seems to be the same
> > as malloc-less code in non-GCed languages like C.
>
> I would rather still programm in Lisp... Actually, in C/C++ I never
> use "dynamic-extent" objects, at most "auto" variables. But this
> could be something to put in a macro.
hm, a macro that produces cons-less code.... interesting thought
--
Certum quod factum.
Philip Haddad
In article <············@services.kq.no>, ·········@aas.no says...
> Gerry Quinn wrote:
>
> > I ask again - if Lisp is so great for writing games, where are the games
> > written by the Lisp enthusiasts? If chisels are so great for cutting
> > trees, why are the chisel-using woodcutters shivering in the cold?
> >
> As a matter of fact, I'm writing one right now. (Along with the.. hmm...
> four other projects I'm currently working on. Don't hold your breath.)
>
> It's a clone of the classic (as in old) game called "Gravity Well", but
> looks like it's going to be much smaller than the original, code-wise.
> Well, such is life...
>
> If you're interested in seeing a real Lisp-based game, tell me so and I'll
> slip you a note when it's done.
Good luck! So long as it can run on Windows, or in the free trial
version of LispWorks. Certainly I would find a bunch of completed
distributed games written in Lisp far more indicative of its actual
powers than all the advocacy posts in the world!
> Oh, and before anyone starts talking about GC pauses, it isn't nearly as
> much of a problem as people want to believe. My code only conses on object
> creation, not mere state changes; that, combined with my "purify" call at
> startup, means even a full GC takes too little time to notice any jitter.
Well, if gc was going to be an issue on this sort of game, we could
forget about it as a technology! I've done a few Java applet games
myself, and I never found it a problem.
- Gerry Quinn
Gerry Quinn wrote:
> In article <············@services.kq.no>, ·········@aas.no says...
>> Gerry Quinn wrote:
>>
>> > I ask again - if Lisp is so great for writing games, where are the
>> > games
>> > written by the Lisp enthusiasts? If chisels are so great for cutting
>> > trees, why are the chisel-using woodcutters shivering in the cold?
>> >
>> As a matter of fact, I'm writing one right now. (Along with the.. hmm...
>> four other projects I'm currently working on. Don't hold your breath.)
>>
>> It's a clone of the classic (as in old) game called "Gravity Well", but
>> looks like it's going to be much smaller than the original, code-wise.
>> Well, such is life...
>>
>> If you're interested in seeing a real Lisp-based game, tell me so and
>> I'll slip you a note when it's done.
>
> Good luck! So long as it can run on Windows, or in the free trial
> version of LispWorks. Certainly I would find a bunch of completed
> distributed games written in Lisp far more indicative of its actual
> powers than all the advocacy posts in the world!
>
I suspect it could run under Corman, actually. Probably CLISP too.
Lispworks has that heap limit, unfortunately; I need to set a pretty large
heap to avoid GC jitter.
The largest problem is that it uses cl-sdl, and I have no idea how to make
that work under Windows, not that I've tried. I have no Windows box.
>> Oh, and before anyone starts talking about GC pauses, it isn't nearly as
>> much of a problem as people want to believe. My code only conses on
>> object creation, not mere state changes; that, combined with my "purify"
>> call at startup, means even a full GC takes too little time to notice any
>> jitter.
>
> Well, if gc was going to be an issue on this sort of game, we could
> forget about it as a technology! I've done a few Java applet games
> myself, and I never found it a problem.
>
The game isn't all that small, although it started out small. Creeping
featuritis is probably a far greater problem in Lisp than in C++, simply
because it's a lot easier to get it /right/.
As for GC, I personally think there are a number of improvements that could
be made, mostly along the lines of declarations. It is, admittedly, harder
to see when Lisp will cons than when Java will cons.
On Sun, 28 Nov 2004 13:14:39 +0100, Svein Ove Aas <·········@aas.no> wrote:
>>
> The game isn't all that small, although it started out small. Creeping
> featuritis is probably a far greater problem in Lisp than in C++, simply
> because it's a lot easier to get it /right/.
>
lol. What world are you on..
Have you seen what has happened to Windows Media Player, Real Player and
Quicktime lately..
These simple apps have grown to have their own browser, play DVD's and
CD's maintain
music and film databases etc. etc..
What used to be a simple plug-in to watch a film now want to take over
your computer and gobble 10's of megabytes of RAM even when not in use.
I's not there, of course. Bloat seems to bee creeping into everything.
You get a successful app so you hire more programmers.
These programmers add more code and more features.
Next you know everyone is put off by the 'bloat' ware.
The only ones that don't notice are the makers of the software that
continue
to add features.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> On Sun, 28 Nov 2004 13:14:39 +0100, Svein Ove Aas <·········@aas.no> wrote:
>
>>>
>> The game isn't all that small, although it started out small. Creeping
>> featuritis is probably a far greater problem in Lisp than in C++, simply
>> because it's a lot easier to get it /right/.
>>
>
> lol. What world are you on..
no, it is true. all i wanted to produce was version two of my
educational software and I accidentally developed Cells and lost all
interest in educational software.
then when I tried to go back to the ed software I tried to develop first
a portable GUI to make cross-platform easier and ended up falling in
love with OpenGL and OpenAl and lord knows what next.
Now the Open source fairy drops off a portable Lisp GUI (cells-gtk) and
though I am spending a little time uffi-izing it, I find it quite drab.
I have been ruined by Lisp3D.
newbies, turn back before it is too late!
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On Mon, 29 Nov 2004 01:19:41 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
> John Thingstad wrote:
>> On Sun, 28 Nov 2004 13:14:39 +0100, Svein Ove Aas <·········@aas.no>
>> wrote:
>>
>>>>
>>> The game isn't all that small, although it started out small. Creeping
>>> featuritis is probably a far greater problem in Lisp than in C++,
>>> simply
>>> because it's a lot easier to get it /right/.
>>>
>> lol. What world are you on..
>
> no, it is true. all i wanted to produce was version two of my
> educational software and I accidentally developed Cells and lost all
> interest in educational software.
>
> then when I tried to go back to the ed software I tried to develop first
> a portable GUI to make cross-platform easier and ended up falling in
> love with OpenGL and OpenAl and lord knows what next.
>
> Now the Open source fairy drops off a portable Lisp GUI (cells-gtk) and
> though I am spending a little time uffi-izing it, I find it quite drab.
> I have been ruined by Lisp3D.
>
> newbies, turn back before it is too late!
>
> kenny
>
It may be easier.. But it's just a big a problem in C++.
lol.
I have been researching fuzzy reasoning lately.
A implementation is in the wind.
Who known what I'll end up with?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Gerry Quinn wrote:
> I ask again - if Lisp is so great for writing games, where are the games
> written by the Lisp enthusiasts? If chisels are so great for cutting
> trees, why are the chisel-using woodcutters shivering in the cold?
Your question reduces to the question of why more people in general
don't use Lisp. The number of people using C variants is much larger
than the number using Lisp variants. Why? I don't think anyone actually
knows that.
I have an intuition that some people just don't take to it. I worked on
a large project once that was at first written in Lisp. The team was a
little less than a hundred programmers, of whom about ten percent were
Lisp programmers.
During development, the Lisp programmers wrote idiomatic Lisp code. The
C programmers wrote highly unidiomatic Lisp code. When the majority of
programmers were working in Lisp, there were many complaints that the
system was too slow. After a fork later on, there were two versions of
the system, one written by C programmers in C++, the other written by
Lisp programmers in Lisp. The Lisp system was faster, had better support
for system updates, was written by a team one tenth the size of the C++
version, and crashed less (but the C++ version, in its favor, was
smaller in memory).
One of the smartest (and stubbornest) Lisp programmers I've ever known
tried for a while at every engineering meeting to explain to the C
programmers why their Lisp code was slow. It never seemed to make any
difference. Indeed, they tended to take the position that they did not
want to alter the style of their code.
I was a C programmer before I was a Lisp programmer, and that's true of
most Lisp programmers I know. I know no C programmers who were Lisp
programmers first. However, I also know a fairly large number of C
programmers who had ample opportunity to become Lisp programmers, and
didn't, and who did not write idiomatic Lisp code even when they had
been writing Lisp code every day for two years.
I also thought it was notable that the C programmers tended to describe
the differences between Lisp and C in terms of syntax; the Lisp
programmers tended to describe the difference in terms of semantics. To
put it another way, the C programmers tended to argue that if you
changed the syntax of Lisp to look like C, it would be C. The Lisp
programmers tended to argue that if you changed the syntax of C to look
like Lisp, it would still not be Lisp.
It seems to me that many people just don't don't take to it. Those who
do, seem to take to it very quickly after a brief exposure. Those who
don't react that way probably never will take to it. If the
abovementioned project is representative, that's probably most C
programmers.
It is as if you either have the Lisp gene, or you don't. It seems like
most people don't. If that's true, then it would explain why many more
people use C variants than Lisp variants, and that would in turn explain
why there are many more games written in C than in Lisp.
This explanation says nothing about whether C or Lisp is technically
superior; the result would be the same no matter which position is true,
and even if neither position is true.
mikel <·····@evins.net> writes:
> Gerry Quinn wrote:
>
> > I ask again - if Lisp is so great for writing games, where are the games
> > written by the Lisp enthusiasts? If chisels are so great for
> > cutting trees, why are the chisel-using woodcutters shivering in the
> > cold?
>
> Your question reduces to the question of why more people in general
> don't use Lisp. The number of people using C variants is much larger
> than the number using Lisp variants. Why? I don't think anyone
> actually knows that.
>
> I have an intuition that some people just don't take to it. I worked
> on a large project once that was at first written in Lisp. The team
> was a little less than a hundred programmers, of whom about ten
> percent were Lisp programmers.
>
> During development, the Lisp programmers wrote idiomatic Lisp
> code. The C programmers wrote highly unidiomatic Lisp code. When the
> majority of programmers were working in Lisp, there were many
> complaints that the system was too slow. After a fork later on, there
> were two versions of the system, one written by C programmers in C++,
> the other written by Lisp programmers in Lisp. The Lisp system was
> faster, had better support for system updates, was written by a team
> one tenth the size of the C++ version, and crashed less (but the C++
> version, in its favor, was smaller in memory).
>
> One of the smartest (and stubbornest) Lisp programmers I've ever known
> tried for a while at every engineering meeting to explain to the C
> programmers why their Lisp code was slow. It never seemed to make any
> difference. Indeed, they tended to take the position that they did not
> want to alter the style of their code.
>
> I was a C programmer before I was a Lisp programmer, and that's true
> of most Lisp programmers I know. I know no C programmers who were Lisp
> programmers first. However, I also know a fairly large number of C
> programmers who had ample opportunity to become Lisp programmers, and
> didn't, and who did not write idiomatic Lisp code even when they had
> been writing Lisp code every day for two years.
>
> I also thought it was notable that the C programmers tended to
> describe the differences between Lisp and C in terms of syntax; the
> Lisp programmers tended to describe the difference in terms of
> semantics. To put it another way, the C programmers tended to argue
> that if you changed the syntax of Lisp to look like C, it would be
> C. The Lisp programmers tended to argue that if you changed the syntax
> of C to look like Lisp, it would still not be Lisp.
>
> It seems to me that many people just don't don't take to it. Those who
> do, seem to take to it very quickly after a brief exposure. Those who
> don't react that way probably never will take to it. If the
> abovementioned project is representative, that's probably most C
> programmers.
>
> It is as if you either have the Lisp gene, or you don't. It seems like
> most people don't. If that's true, then it would explain why many more
> people use C variants than Lisp variants, and that would in turn
> explain why there are many more games written in C than in Lisp.
>
> This explanation says nothing about whether C or Lisp is technically
> superior; the result would be the same no matter which position is
> true, and even if neither position is true.
Read this site:
http://www.reciprocality.org/
http://www.reciprocality.org/Reciprocality/index.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Pascal Bourguignon <····@mouse-potato.com> writes:
>
> Read this site:
> http://www.reciprocality.org/
> http://www.reciprocality.org/Reciprocality/index.html
Wow. I didn't know about this work. Thanks for sharing. Now I know why
thinking back to seventh grade upsets me, and I know where to look to
rediscover my strength. All those wasted years, makes me want to cry.
This thing ties in nicely with the Thomas Hylland Eriksen work that
was mentioned here a couple of weeks ago, "Tyranny of the Moment"
<http://folk.uio.no/geirthe/Tyranny.html>.
In article <·····················@newssvr13.news.prodigy.com>,
·····@evins.net says...
>
> It is as if you either have the Lisp gene, or you don't. It seems like
> most people don't. If that's true, then it would explain why many more
> people use C variants than Lisp variants, and that would in turn explain
> why there are many more games written in C than in Lisp.
C++ is not a C variant, unless you just mean syntax. So I'm not quite
sure what you mean by the "C programmers" who you said were programming
in C++.
> This explanation says nothing about whether C or Lisp is technically
> superior; the result would be the same no matter which position is true,
> and even if neither position is true.
Although it could be argued that a language (here you seem to be talking
about C) that everyone can use is better than a language that only some
can use. However, that aside, a certain possiblility arises...
I'm not trolling - this is a serious if nasty question: could it be that
the reason the majority of C programmers reject 'idiomatic Lisp' is
because they see what you call 'idiomatic Lisp' as simply bad
programming practice?
After all, some people seem to have a 'spaghetti' gene, and can code
stuff that works after a fashion, but which lesser mortals can't
understand or maintain. Maybe Lisp is on the same chromosome.
- Gerry Quinn
> I'm not trolling - this is a serious if nasty question: could it be that
> the reason the majority of C programmers reject 'idiomatic Lisp' is
> because they see what you call 'idiomatic Lisp' as simply bad
> programming practice?
>
> After all, some people seem to have a 'spaghetti' gene, and can code
> stuff that works after a fashion, but which lesser mortals can't
> understand or maintain. Maybe Lisp is on the same chromosome.
The difference between Lisp code and spaghetti code is that anyone who can
understand well-written Lisp can understand any well-written Lisp.
Spaghetti code can't be understood easily by *anyone* except the person
that wrote it.
BTW, I'm not speaking absolutely, but the trends are clear.
Chris Capel
In article <···············@corp.supernews.com>, ······@iba.nktech.net
says...
> > I'm not trolling - this is a serious if nasty question: could it be that
> > the reason the majority of C programmers reject 'idiomatic Lisp' is
> > because they see what you call 'idiomatic Lisp' as simply bad
> > programming practice?
> >
> > After all, some people seem to have a 'spaghetti' gene, and can code
> > stuff that works after a fashion, but which lesser mortals can't
> > understand or maintain. Maybe Lisp is on the same chromosome.
>
> The difference between Lisp code and spaghetti code is that anyone who can
> understand well-written Lisp can understand any well-written Lisp.
> Spaghetti code can't be understood easily by *anyone* except the person
> that wrote it.
Fair enough, if that is the case. Probably all languages look like
spaghetti until you know them.
You might want to reconsider whether Naughty Dog is a suitable exemplar
of Lisp useage, however, given the comments on the engine code in the
Gamasutra post-mortem. And is the pronounced tendency of even
successful Lisp projects to get re-written in another language
*entirely* due to PHBs who are afraid of not being able to hire Lisp
users?
I only ask. You Lisp-ers can best answer it among yourselves.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> And is the pronounced tendency of even successful Lisp projects to
> get re-written in another language *entirely* due to PHBs who are
> afraid of not being able to hire Lisp users?
What other reasons could there be? As the Dilbert strip illustrates,
PHBs are idiots by definition.
Also, while this has happened, how common is it to re-implement a
successful system in another language? Do you think ITA will do it to
Orbitz?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <·····················@newssvr13.news.prodigy.com>,
> ·····@evins.net says...
> >
> > It is as if you either have the Lisp gene, or you don't. It seems like
> > most people don't. If that's true, then it would explain why many more
> > people use C variants than Lisp variants, and that would in turn explain
> > why there are many more games written in C than in Lisp.
>
> C++ is not a C variant, unless you just mean syntax. So I'm not quite
> sure what you mean by the "C programmers" who you said were programming
> in C++.
It is when used by most C programmers. AFAICT, there is a small
vanguard of C++ users that write what I consider to be good,
idiomatic, modern C++. I would expect these same programmers to learn
to write idiomatic Lisp when thrown into a Lisp shop, for the reason
that they've already had to learn a very new style when they learned
to write idiomatic C++. I'd expect they will generally go nuts with
macros (in a good way). That's what happened with me, at least. I'm
not saying which language they'd prefer, but they should be able to
adapt to writing in Lisp.
In article <···············@conquest.OCF.Berkeley.EDU>,
···@conquest.OCF.Berkeley.EDU says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> >
> > C++ is not a C variant, unless you just mean syntax. So I'm not quite
> > sure what you mean by the "C programmers" who you said were programming
> > in C++.
>
> It is when used by most C programmers. AFAICT, there is a small
> vanguard of C++ users that write what I consider to be good,
> idiomatic, modern C++. I would expect these same programmers to learn
> to write idiomatic Lisp when thrown into a Lisp shop, for the reason
> that they've already had to learn a very new style when they learned
> to write idiomatic C++. I'd expect they will generally go nuts with
> macros (in a good way). That's what happened with me, at least. I'm
> not saying which language they'd prefer, but they should be able to
> adapt to writing in Lisp.
If by the above you mean - and I suspect you do - those programmers
whose obsession with 'generic programming' has caused them to lose sight
of the basics of object orientation, the Lisp community is welcome to
them as far as I am concerned.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> If by the above you mean - and I suspect you do - those programmers
> whose obsession with 'generic programming' has caused them to lose sight
> of the basics of object orientation,
Since when was C++ concerned with or even aspiring to reach this
summit, "the basics of object orientation?" Modern, idiomatic C++ is
best characterized by full exploitation of all its language facilities
and use of certain conventions to make library building and reuse
easier. None of that has anything to do with object orientation, and
none of that effort is suffering for lack of such concern.
> the Lisp community is welcome to them as far as I am concerned.
You're not even cheerleading for C++ as it lives today, but building a
moat around your own stunted idea of what it should be.
--
Steven E. Harris
From: Raistlin Magere
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <coceq1$8no$1@news.ox.ac.uk>
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <·····················@newssvr13.news.prodigy.com>,
> ·····@evins.net says...
> >
>
> I'm not trolling - this is a serious if nasty question: could it be that
> the reason the majority of C programmers reject 'idiomatic Lisp' is
> because they see what you call 'idiomatic Lisp' as simply bad
> programming practice?
>
> After all, some people seem to have a 'spaghetti' gene, and can code
> stuff that works after a fashion, but which lesser mortals can't
> understand or maintain. Maybe Lisp is on the same chromosome.
>
Hi,
you might remember that last time I discussed about self-adaptive software
on this thread with you I was what I would like to think as reasonable and
polite (not saying you are either).
However paragraphs like the one above, especially after a very long thread
which has entered into some technical detail (not much but some) cannot be
considered anything else but Trolling - no matter whether you are saying "I
am not trolling".
Let's be honest excellence is the realm of few people not of the masses by
this I am not saying that only few people are "excellent" but that given an
area of expertise only few people are actually excellent at it. So in a way
just that fact that "many" can use something could be thought as a proof of
mediocracy rather than of "merit" and I think this is a serious statement
that you should consider.
After all, many people do not understand the general theory of relativity or
for that matter not even newtonian physics so maybe what many people think
is not relevant.
But I am not trolling, honestly (or am I).
Anyway I will not reply to this e-mail as I have already spent enough time
on this thread, however you might want to consider some of the points made
by Christopher C. Stacy and especially just drop this topic it is not worth
it.
Thanks.
Follow-up set and please excuse me as I wasn't able to follow the
golden-rule of "Do not feed the troll".
In article <············@news.ox.ac.uk>, ·······@*the-mail-that-
burns*.com says...
> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> ·······························@news.indigo.ie...
> >
> > I'm not trolling - this is a serious if nasty question: could it be that
> > the reason the majority of C programmers reject 'idiomatic Lisp' is
> > because they see what you call 'idiomatic Lisp' as simply bad
> > programming practice?
>
> However paragraphs like the one above, especially after a very long thread
> which has entered into some technical detail (not much but some) cannot be
> considered anything else but Trolling - no matter whether you are saying "I
> am not trolling".
I really am not trolling.
> Let's be honest excellence is the realm of few people not of the masses by
> this I am not saying that only few people are "excellent" but that given an
> area of expertise only few people are actually excellent at it. So in a way
> just that fact that "many" can use something could be thought as a proof of
> mediocracy rather than of "merit" and I think this is a serious statement
> that you should consider.
I wasn't talking about "excellence". I was talking about "good practice".
They are different things.
- Gerry Quinn
On Mon, 29 Nov 2004 11:07:58 +0000, Gerry Quinn wrote:
>
> I wasn't talking about "excellence". I was talking about "good practice".
> They are different things.
>
Yup, agreed. In my experience people use the terms "good practice" and
"best practice" to mean "average practice", i.e. what everyone else is
doing (if I remember correctly, Paul Graham makes the same observation in
his book Hackers And Painters).
You are welcome to your "good practices". I prefer something better than
the average.
Cheers,
Bill.
From: Raistlin Magere
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <cocf69$8t7$3@news.ox.ac.uk>
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <·····················@newssvr13.news.prodigy.com>,
> ·····@evins.net says...
> >
> > It is as if you either have the Lisp gene, or you don't. It seems like
> > most people don't. If that's true, then it would explain why many more
> > people use C variants than Lisp variants, and that would in turn explain
> > why there are many more games written in C than in Lisp.
>
> C++ is not a C variant, unless you just mean syntax. So I'm not quite
> sure what you mean by the "C programmers" who you said were programming
> in C++.
>
> > This explanation says nothing about whether C or Lisp is technically
> > superior; the result would be the same no matter which position is true,
> > and even if neither position is true.
>
> Although it could be argued that a language (here you seem to be talking
> about C) that everyone can use is better than a language that only some
> can use. However, that aside, a certain possiblility arises...
>
> I'm not trolling - this is a serious if nasty question: could it be that
> the reason the majority of C programmers reject 'idiomatic Lisp' is
> because they see what you call 'idiomatic Lisp' as simply bad
> programming practice?
>
> After all, some people seem to have a 'spaghetti' gene, and can code
> stuff that works after a fashion, but which lesser mortals can't
> understand or maintain. Maybe Lisp is on the same chromosome.
>
> - Gerry Quinn
>
On Sun, 28 Nov 2004, Gerry Quinn wrote:
> I'm not trolling - this is a serious if nasty question: could it be that
> the reason the majority of C programmers reject 'idiomatic Lisp' is
> because they see what you call 'idiomatic Lisp' as simply bad
> programming practice?
>
I can't speak for lisp, but most of the people I've talked to about my
Haskell code don't have any serious objections on those grounds. A few
insist that the (statically-typed, Java-and-C++) OO way is better even
when it's quite clearly a worse fit, something which I tend to ignore
because I'm fully aware of the problems I'd avoided.
> After all, some people seem to have a 'spaghetti' gene, and can code
> stuff that works after a fashion, but which lesser mortals can't
> understand or maintain. Maybe Lisp is on the same chromosome.
>
I could be snarky about syntax, but otherwise I'm tempted to disagree
strongly.
One thing notable about Haskell code btw, is that every experienced
Haskell coder I've talked to about it finds it significantly easier to
reverse engineer and otherwise understand Haskell code than other
languages they've coded in, even when they have more experience in the
other languages. But Haskell tends to meet a block in people, largely
around the twin points of recursion and abstraction. I suspect lisp hits
the same problems.
--
······@flippac.org
Gerry Quinn wrote:
> In article <·····················@newssvr13.news.prodigy.com>,
> ·····@evins.net says...
>
>>It is as if you either have the Lisp gene, or you don't. It seems like
>>most people don't. If that's true, then it would explain why many more
>>people use C variants than Lisp variants, and that would in turn explain
>>why there are many more games written in C than in Lisp.
>
>
> C++ is not a C variant, unless you just mean syntax. So I'm not quite
> sure what you mean by the "C programmers" who you said were programming
> in C++.
Feel free to describe C and C++ with whatever words you prefer to the
words "C variant".
>>This explanation says nothing about whether C or Lisp is technically
>>superior; the result would be the same no matter which position is true,
>>and even if neither position is true.
>
>
> Although it could be argued that a language (here you seem to be talking
> about C) that everyone can use is better than a language that only some
> can use. However, that aside, a certain possiblility arises...
>
> I'm not trolling - this is a serious if nasty question: could it be that
> the reason the majority of C programmers reject 'idiomatic Lisp' is
> because they see what you call 'idiomatic Lisp' as simply bad
> programming practice?
No.
From: Rene de Visser
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <cof1ob$eds$1@news.sap-ag.de>
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> I'm not trolling - this is a serious if nasty question: could it be that
> the reason the majority of C programmers reject 'idiomatic Lisp' is
> because they see what you call 'idiomatic Lisp' as simply bad
> programming practice?
I have programming experience in a number of programming languages including
C, C++ and Common Lisp among others.
I think that there a number of reasons C programmers reject 'idiomatic
Lisp'.
a) The formatting. It took me a couple of weeks to get past how Lisp code
looks like because of the formatting and parenthese.
b) Learning curve. I found this to be quite steep. There are a lot of in
built functions and macros, etc in common lisp. At the beginning of learning
C++ versus learning common lisp it was a lot easier for me to read a 30 000
line C++ program compared to a 10 000 line lisp program. To read the
Lisp program you need to know the ANSI standard fairly well, and learn to
pick out the standard stuff compared to the program specific constructions.
Often Common Lisp is more compact. At the beginning this is a learning
disadvantage, at least for working your way into the language with existing
code.
c) In combination of a) and b) above and the lack of strong motivating
reasons to learn Lisp (such as good job opportunities), I think are the main
reasons for the rejection.
I would think that 90% C programmers that reject Lisp don't get far enough
that they could recognize good or bad programming practice in Lisp programs.
Rene.
On Mon, 29 Nov 2004 12:38:50 +0100, Rene de Visser
<··············@hotmail.de> wrote:
>
> I would think that 90% C programmers that reject Lisp don't get far
> enough
> that they could recognize good or bad programming practice in Lisp
> programs.
>
> Rene.
>
>
I second that.
You really need to know a great deal about lisp to read Lisp programmes.
In the beginning exceptions, multiple-value-bind and destructuring-bind
really put me off because of the complexity.
Then there is the special forms.
In Python you can be reasonably productive in a week.
In Lisp it takes considerably longer.
The arguments about Lisp being so productive may actually hurt
because if you try it without being experienced you will be
less productive. So they figure the rest is hype from language
advocates with a inferiority complex.
The best best cure I have seen is Peter Seibel's book
'Practical Common Lisp'. (Thanks Peter)
This hands on, yet nontrivial, tour of common Lisp thoroghly
introdudes the uniqueness of the Lisp programming language.
(PAIP by Peter Norvig should perhaps also be mentioned)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"Rene de Visser" <··············@hotmail.de> writes:
> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> ·······························@news.indigo.ie...
> > I'm not trolling - this is a serious if nasty question: could it be that
> > the reason the majority of C programmers reject 'idiomatic Lisp' is
> > because they see what you call 'idiomatic Lisp' as simply bad
> > programming practice?
>
> I have programming experience in a number of programming languages including
> C, C++ and Common Lisp among others.
>
> I think that there a number of reasons C programmers reject 'idiomatic
> Lisp'.
>
> a) The formatting. It took me a couple of weeks to get past how Lisp code
> looks like because of the formatting and parenthese.
> b) Learning curve. I found this to be quite steep. There are a lot of in
> built functions and macros, etc in common lisp. At the beginning of learning
> C++ versus learning common lisp it was a lot easier for me to read a 30 000
> line C++ program compared to a 10 000 line lisp program.
Well, every time I converted a C program to Lisp, I got a 10 to 20
fold reduction. A 10,000 line lisp program is equivalent to at least
a 100,000 line C program.
> To read the
> Lisp program you need to know the ANSI standard fairly well, and learn to
> pick out the standard stuff compared to the program specific constructions.
Yes, but to read a C program, you need to know the ANSI C library
standard fairly well too. And all the other C libraries used in your
C program.
> Often Common Lisp is more compact. At the beginning this is a learning
> disadvantage, at least for working your way into the language with existing
> code.
> c) In combination of a) and b) above and the lack of strong motivating
> reasons to learn Lisp (such as good job opportunities), I think are the main
> reasons for the rejection.
>
> I would think that 90% C programmers that reject Lisp don't get far enough
> that they could recognize good or bad programming practice in Lisp programs.
>
> Rene.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Pascal Bourguignon <····@mouse-potato.com> writes:
> Well, every time I converted a C program to Lisp, I got a 10 to 20
> fold reduction. A 10,000 line lisp program is equivalent to at least
> a 100,000 line C program.
3 or 4 years ago, I wrote a small program in C to demonstrate to
myself that one could write C in an "object-oriented" style. This
notion came to me via a book I was reading at the time, which
introduced C++ as a "convenience" improvement over writing
"object-oriented" code in C. Prior to this, I had been exposed to
C++ as a new language that shared some simlilarities to C but with
extra stuff. I would expect that the code would be smaller if it
were written in C++, but I haven't ever bothered to do so.
The code is designed to read in a small data base of individuals,
then arrange a gift exchange among them. It is 888loc. A slightly
different version written the same day is 936loc, including
debugging output, comments, white-space, etc. The basic data
structure was a linked-list of "objects" representing people. This
version was written in approximately 6 hours (including time spent
of the first version), and hasn't been polished at all. This is, in
essence, the first draft that passed through the compiler and
yielded valid output.
Some stats on the 2nd version of the C code:
936 loc
154 blank lines (visual whitespace) [16%]
137 comments (102 single line comments) [15%]
56 assignments [06%]
32 functions defined
8 while loops [01%]
6 structs defined
Last night, I re-wrote it in CL (it took about 3 hours) because it's
my preferred langauge to use and I needed to add some additional
functionality. My previous versions could not deal with the
situation where there were multiple people who could not be chosen
by a given person. The CL code is 116 lines. Once again, I used a
list of person-objects. This code is also un-polishsed and
un-profiled.
Some stats on the code:
116 loc
17 comments (14 single line comments) [14%]
16 blank lines (visual whitespace) [14%]
12 assignments (via setf) [10%]
10 lets (including the top-level invocation)
8 functions defined
6 do loops (each of which used pop to access list members) [05%]
3 remove/remove-if calls
2 throws (for error detection)
2 special variables
1 catch (for restarting)
1 CLOS object type (person-record)
0 methods (other than accessors)
So, between the two versions of the program, they seem to be
written in roughly the same style with respect to visual whitespace
and commenting. The CL version spends a higher % of code in loops
and assignment, because a lot of the other code (library support for
linked lists, etc) is built-in and not counted. The C version has
8x as many lines.
It seems to me that I am more productive when writing in CL. I
can write fewer lines of code to achieve a given result, which means
that I save time. This is with about 3kloc of CL under my belt.
So, while I'm not as time-efficient at writing lines of CL (0.66
lines per minute) as I am at writing lines of C (2.6 lines per
minute), I expect that to improve as I get more experience.
--jon
Gerry Quinn wrote:
> In article <·····················@newssvr13.news.prodigy.com>,
> ·····@evins.net says...
>
>>It is as if you either have the Lisp gene, or you don't. It seems like
>>most people don't. If that's true, then it would explain why many more
>>people use C variants than Lisp variants, and that would in turn explain
>>why there are many more games written in C than in Lisp.
>
>
> C++ is not a C variant, unless you just mean syntax. So I'm not quite
> sure what you mean by the "C programmers" who you said were programming
> in C++.
>
>
>>This explanation says nothing about whether C or Lisp is technically
>>superior; the result would be the same no matter which position is true,
>>and even if neither position is true.
>
>
> Although it could be argued that a language (here you seem to be talking
> about C) that everyone can use is better than a language that only some
> can use. However, that aside, a certain possiblility arises...
>
> I'm not trolling - this is a serious if nasty question: could it be that
> the reason the majority of C programmers reject 'idiomatic Lisp' is
> because they see what you call 'idiomatic Lisp' as simply bad
> programming practice?
>
> After all, some people seem to have a 'spaghetti' gene, and can code
> stuff that works after a fashion, but which lesser mortals can't
> understand or maintain. Maybe Lisp is on the same chromosome.
>
> - Gerry Quinn
>
I tend to think the OP is probably on to something. I'm no expert LISP
programmer, but I am an expert at C and Java, and I have seen many C
(and C++) programmers write bad Java then blame the language when it
doesn't run well.
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <u8y8nj6va.fsf@news.dtpq.com>
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> The point I was making, however, relates more to the posters on
> this games newsgroup who are pushing Lisp as the new wonder-drug
> for games programming.
> I ask again - if Lisp is so great for writing games, where are the games
> written by the Lisp enthusiasts? If chisels are so great for cutting
> trees, why are the chisel-using woodcutters shivering in the cold?
People have already patiently provided many technical questions
to your questions. Responding to the closing paragraph of your
latest message, above, I make the following observations.
1. Here you pretend to be restating your most recent question,
but it is subtly different than what you asked before.
You asked, "If Lisp is so great, where are the games?"
My first response was I might deign to answer your questions
if you paid me to do so. This was intended to discourage you,
but also to point out the logical fallacies of your line of
inquiry. (It also was intended to convey a hint that maybe
most Lisp programmers are busy doing something that they
think will make money.) At this point, I'm just responding,
gratis, and finally, on the hopes that you'll get at a
satisfactory answer and quit pestering us.
First, there can be no objective meaning of "good" without a lot
of context. In your most recent restatement of your question, you
clarify that you mean "good for games". However, in an attempt to
define "good for games", detailed technical explanations have been
already provided to answer any concerns you might have in that area.
You have ignored or rejected those responses.
Second, you further assert that a programming language is only good
for games if this is evidenced by there being lots of games written
in it already. I don't see the clear logic in that. It is already
well-known that Lisp has not been the most popular language, and that
there is a tradition of writing games in C. But that history does
not speak to the technical merits or "good" possibilities.
It mainly speaks to the fact that most people are uneducated
in the benefits of Lisp. This has been explained to you several times.
You have ignored or rejected those responses.
2. Your analogy to chisels and woodcutters is an unfounded non-sequitor.
3. This conversation was begun on October 25, by someone writing a list
of percevied defficiencies in the C++ language with respect to
game programming. (He didn't mention Lisp, but he cross-posted to
the lisp and c++ newsgroups. Looked like kind of a troll, to me,)
You entered the fray the next day, with:
> 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.
People answered both of those for you honestly, but you didn't really
want to hear the answers. There have been about 700 messages, and I bet
that all the relevent technical information has already been exchanged
between whatever people might have been interested in the various camps.
Almost all of the recent messages in the thread from "your side" have
been from you alone, and they are not really technical.
So there is no point continuing.
Your objection to using Lisp boils down to the fact that you are
already committed to using C++, because you have made an investment
in the existing tools that you like, and it's too expensive to consider
using something else (especially if you have to develop it yourself).
Since that's your criteria, you have a forgone conclusion,
As far as I know, there are not a lot of tools and library support
specifically for writing games in Lisp. What you fail to appreciate
is the contention on the part of most Lisp programmers that because Lisp
is such a superior language, appropriate tool chains are easy to create,
relative to languages like C++. So if people were interested in using
Lisp for games, they would do that. (This "roll your own" outlook,
which has its dual aspects, is based on different set of assumptions
than most software engineers have.) It's what the Naughty Dog story is
about. However, since neither they (nor anyone else) has not given away
to you that proprietary technology, which is the basis of their competitive
advantage, you reject that.
Indeed, it is _not_ useful technology to you, since you don't have it!
> My 'crapola screensaver' went some considerable way
> towards buying me a house.
You like to cite your screensaver (with your tool chain), while the Lisp
people like to cite Naughty Dog (with their tool chain). You give as
your ultimate evaluation criteria the fact that you have helped pay for
your house with your screensaver. Therefore, the proper form of analysis
would be to ask whether you made more money with your screensaver than
Naughty Dog did with their line of games and the approach they took.
But that's for you to ponder, because the folks on comp.lang.lisp
are already convinced of the answer to that comparison,
and they believe they know how it generalizes.
Please rest easy now, and have fun writing your games in the sure
knowledge that for you, C++ does not suck for games, and Lisp sucks.
You began by asserting right up front that "Lisp programmers don't
actually *produce* anything". Given that C++ is much more popular
than Lisp, it requires no advocacy effort from you. And if some
people be misled into thinking that Lisp could be better for games,
why should that bother you? Perhaps you ought to examine your feelings
and see if you can figure out why you are so upset with Lisp programmers.
But please go do it by yourself.
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <u4qjbj6st.fsf@news.dtpq.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> People have already patiently provided many technical questions
> to your questions.
I meant "answers to your questions", of course.
Or did I?
:)
In article <·············@news.dtpq.com>, ······@news.dtpq.com says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > The point I was making, however, relates more to the posters on
> > this games newsgroup who are pushing Lisp as the new wonder-drug
> > for games programming.
>
> > I ask again - if Lisp is so great for writing games, where are the games
> > written by the Lisp enthusiasts? If chisels are so great for cutting
> > trees, why are the chisel-using woodcutters shivering in the cold?
> My first response was I might deign to answer your questions
> if you paid me to do so. This was intended to discourage you,
> but also to point out the logical fallacies of your line of
> inquiry. (It also was intended to convey a hint that maybe
> most Lisp programmers are busy doing something that they
> think will make money.)
They don't seem to be doing it with Lisp.
> First, there can be no objective meaning of "good" without a lot
> of context. In your most recent restatement of your question, you
> clarify that you mean "good for games". However, in an attempt to
> define "good for games", detailed technical explanations have been
> already provided to answer any concerns you might have in that area.
> You have ignored or rejected those responses.
So you are admitting that Lisp is, in fact, not good for games?
> Second, you further assert that a programming language is only good
> for games if this is evidenced by there being lots of games written
> in it already. I don't see the clear logic in that. It is already
> well-known that Lisp has not been the most popular language, and that
> there is a tradition of writing games in C. But that history does
> not speak to the technical merits or "good" possibilities.
> It mainly speaks to the fact that most people are uneducated
> in the benefits of Lisp. This has been explained to you several times.
> You have ignored or rejected those responses.
There seem to be plenty of Lisp enthusiasts. The elephant in the living
room is that they seem to produce very little finished software. Deal
with it.
> 2. Your analogy to chisels and woodcutters is an unfounded non-sequitor.
>
> 3. This conversation was begun on October 25, by someone writing a list
> of percevied defficiencies in the C++ language with respect to
> game programming. (He didn't mention Lisp, but he cross-posted to
> the lisp and c++ newsgroups. Looked like kind of a troll, to me,)
> You entered the fray the next day, with:
He mentioned Lisp in his name.
> > 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.
And it's as true today as it was true then, as the thread can testify.
> People answered both of those for you honestly, but you didn't really
> want to hear the answers. There have been about 700 messages, and I bet
> that all the relevent technical information has already been exchanged
> between whatever people might have been interested in the various camps.
> Almost all of the recent messages in the thread from "your side" have
> been from you alone, and they are not really technical.
> So there is no point continuing.
My questions weren't technical for the most part, so I don't see the
relevance of "answers to technical questions".
> Your objection to using Lisp boils down to the fact that you are
> already committed to using C++, because you have made an investment
> in the existing tools that you like, and it's too expensive to consider
> using something else (especially if you have to develop it yourself).
> Since that's your criteria, you have a forgone conclusion,
I don't have any objection to using Lisp. I don't have any desire to
use it myself, but since advocates have been claiming that it either
gives them super-powers, or allows their innate superiority to come
forth, I am interested in checking out this to ensure I am missing
nothing. Thus, I ask the questions: "You say you have super powers,
have you saved the world recently?" or "Okay then, have you rescued a
cat from a tree in the last month?". And if the answer to the latter is
also no, I can safely pass on the magic juice.
> As far as I know, there are not a lot of tools and library support
> specifically for writing games in Lisp. What you fail to appreciate
> is the contention on the part of most Lisp programmers that because Lisp
> is such a superior language, appropriate tool chains are easy to create,
> relative to languages like C++. So if people were interested in using
> Lisp for games, they would do that. (This "roll your own" outlook,
> which has its dual aspects, is based on different set of assumptions
> than most software engineers have.)
If you re-read that a few times, you'll understand where I am coming
from. "Oh yes, it's so easy I don't bother to do it" seems a fair
translation of the above.
> It's what the Naughty Dog story is
> about. However, since neither they (nor anyone else) has not given away
> to you that proprietary technology, which is the basis of their competitive
> advantage, you reject that.
> Indeed, it is _not_ useful technology to you, since you don't have it!
>
> > My 'crapola screensaver' went some considerable way
> > towards buying me a house.
>
> You like to cite your screensaver (with your tool chain), while the Lisp
> people like to cite Naughty Dog (with their tool chain). You give as
The difference (apart from the fact that I can cite my own work, modest
as it may be) is that I am just one of many. And of course, there is no
comparison between me and Naughty Dog - there are many equivalents of
Naughty Dog using C++. When I asked about small games and screensavers,
I was pointing out the apparent absence of results from the individual
enthusiasts, who don't at least suffer from the problems associated with
hiring a team of Lisp programmers, and who can make do with basic tools.
[And of course, it's so incredibly easy to make your own, right?]
> your ultimate evaluation criteria the fact that you have helped pay for
> your house with your screensaver. Therefore, the proper form of analysis
> would be to ask whether you made more money with your screensaver than
> Naughty Dog did with their line of games and the approach they took.
> But that's for you to ponder, because the folks on comp.lang.lisp
> are already convinced of the answer to that comparison,
> and they believe they know how it generalizes.
That's a silly comparison. The point I am making is that Naughty Dog
seem to be just about the only team making modern games with Lisp (and
reading their post-mortem it's doubtful that it brought them benefits
overall).
> Please rest easy now, and have fun writing your games in the sure
> knowledge that for you, C++ does not suck for games, and Lisp sucks.
>
> You began by asserting right up front that "Lisp programmers don't
> actually *produce* anything". Given that C++ is much more popular
> than Lisp, it requires no advocacy effort from you. And if some
> people be misled into thinking that Lisp could be better for games,
> why should that bother you? Perhaps you ought to examine your feelings
> and see if you can figure out why you are so upset with Lisp programmers.
> But please go do it by yourself.
I'm not upset at all, I just like to throw cold water on silver bullet
merchants. If they have something real they'll be stronger for it. And
if they don't, it will save their victims time.
- Gerry Quinn
Gerry Quinn wrote:
>
>
> I'm not upset at all, I just like to throw cold water on silver bullet
> merchants. If they have something real they'll be stronger for it. And
> if they don't, it will save their victims time.
>
I am certainly all for that statement. However the world is run with help
from the silver bullet merchants. When C++ was just starting out it was the
silver bullet advocates that got it going. About 1993 we started working
with the first beta version of the DEC VMS C++ compiler, because someone
advocated for it to management. They convinced them things would be more productive
and would allow code reuse. (Neither of which came true). I tend to believe that
the majority of the Lisp users are mature enough to not make exaggerated promises
and that may be part of the problem. Many people do not wish to hear the unvarnished
truth, they want to hear things like "Free software will solve the world's woes".
The silver bullet merchants are the myth promoters and as a programmer who would prefer
to use Lisp it is crappy that it has been painted it with too many falsehoods.
I would say that when Lisp did not deliver during the AI boom (no language could
of delivered the (now) outlandish claims) it got targeted for all the
political reasons. Thankfully the people involved are either leaving or forgetting.
Wade
In article <····················@clgrps13>, whumeniu-delete-this-
···············@telus.net says...
> Gerry Quinn wrote:
> >
> > I'm not upset at all, I just like to throw cold water on silver bullet
> > merchants. If they have something real they'll be stronger for it. And
> > if they don't, it will save their victims time.
> >
> I am certainly all for that statement. However the world is run with help
> from the silver bullet merchants. When C++ was just starting out it was the
> silver bullet advocates that got it going. About 1993 we started working
> with the first beta version of the DEC VMS C++ compiler, because someone
> advocated for it to management. They convinced them things would be more productive
> and would allow code reuse. (Neither of which came true).
Yes. I suppose the other extreme is when you have to be dragged kicking
and screaming to new technology!
> I tend to believe that
> the majority of the Lisp users are mature enough to not make exaggerated promises
> and that may be part of the problem. Many people do not wish to hear the unvarnished
> truth, they want to hear things like "Free software will solve the world's woes".
> The silver bullet merchants are the myth promoters and as a programmer who would prefer
> to use Lisp it is crappy that it has been painted it with too many falsehoods.
>
> I would say that when Lisp did not deliver during the AI boom (no language could
> of delivered the (now) outlandish claims) it got targeted for all the
> political reasons. Thankfully the people involved are either leaving or forgetting.
Although Lisp seems uniquely prone to the myth of "If I just make this
program complicated and recursive enough, miracles will emerge!"
Douglas Hofstadter, you have much to answer for...
- Gerry Quinn
Gerry Quinn wrote:
> In article <····················@clgrps13>, whumeniu-delete-this-
> ···············@telus.net says...
>> I would say that when Lisp did not deliver during the AI boom (no
>> language could of delivered the (now) outlandish claims) it got targeted
>> for all the
>> political reasons. Thankfully the people involved are either leaving or
>> forgetting.
>
> Although Lisp seems uniquely prone to the myth of "If I just make this
> program complicated and recursive enough, miracles will emerge!"
> Douglas Hofstadter, you have much to answer for...
>
The problem is, miracles frequently do emerge.
Oh, the embarassment.
Svein Ove Aas <·········@aas.no> writes:
> Gerry Quinn wrote:
> > Although Lisp seems uniquely prone to the myth of "If I just make this
> > program complicated and recursive enough, miracles will emerge!"
> > Douglas Hofstadter, you have much to answer for...
> >
> The problem is, miracles frequently do emerge.
> Oh, the embarassment.
While miracles often happen, it is most certainly *not* because of increased
complexity and undue amounts of recursion.
It is because the code describes the solution in a cleaner way, with a greater
economy of expression.
Increased complexity is almost always a bad sign. We should choose solutions
that reduce it, not increase it. If that means C++, then that is the logical
choice. If that means lisp, then there you go.
Unfortunately, in real life, the situation is not that simple either:
politics, programmer availability, experience, etc., all come into play.
[Followups broken, since the intended audience is in fact more than just c.l.l]
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
<snip>
> As far as I know, there are not a lot of tools and library support
> specifically for writing games in Lisp. What you fail to appreciate
> is the contention on the part of most Lisp programmers that because Lisp
> is such a superior language, appropriate tool chains are easy to create,
> relative to languages like C++. So if people were interested in using
> Lisp for games, they would do that. (This "roll your own" outlook,
> which has its dual aspects, is based on different set of assumptions
> than most software engineers have.)
Hmmm... I think you misunderstand just how much work is being done by
middleware in games these days. It's not just a matter of libraries
which you can link to with a FFI, middleware like physics engines
provide C++ code that can be inserted into your codebase in a number of
ways, intercepted at a number of levels by virtue of exposing a large
part of the C++ API. *NO* foreign code is going to be able to acccess
that very well - not just LISP - *any* non C++ language at all.
"Appropriate tool chains" are NOT easy to create. That's the reason
that there are specialists in physics, character animation, graphics
engines etc...
If all you were talking about was simply linking to a trivial library
and executing a script or two, then fine, but if that's your idea of
what middleware is, you're well off the mark I'm afraid.
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <uk6s4tnvh.fsf@news.dtpq.com>
Peter Ashford <··@here.there.com> writes:
> "Appropriate tool chains" are NOT easy to create. That's the reason
> that there are specialists in physics, character animation, graphics
> engines etc...
How many times have you done this in Lisp?
Christopher C. Stacy wrote:
> Peter Ashford <··@here.there.com> writes:
>
>
>>"Appropriate tool chains" are NOT easy to create. That's the reason
>>that there are specialists in physics, character animation, graphics
>>engines etc...
>
>
> How many times have you done this in Lisp?
Just for fun I downloaded OpenSG, a C++ scene graph manager. A little
over 3500 or so files. I was just wondering what it would be like to
translate something like that to Lisp.
My first thought was, cool, 1500 or so are headers, I am 42% done.
And of course 90% of everything is pretty small, so probably 10% of the
lines go to the copyright/license stuff. Now I am halfway home. Jacek
says my result will be ten to twenty times smaller, so that means I am
97.5% done. Start icing the champagne. Now what about the last 250
points (2.5%)?
I went looking for some beef. Figured the code which loaded models must
be meaty. Turned out to be a lot of greenspun (can we just add that to
the language to make the next five years transitioning to Lisp a little
easier?).
It occurred to me at this point that a straight translation would be
impossible, since ripping out the greenspun puts one on a slippery slope
to a rewrite. During which an extraordinary effort goes into deciding
what is beef and what is gristle. (And to think I am a vegetarian.)
Then I looked over at "Real-Time Rendering" by Moller and Haines sitting
on my desk. They give all the math and theory for a lot of the
functionality provided by OpenSG. Translating /that/ to CL would be a
lot faster and more fun.
Which brings me back to my theory: the game industry has labored
mightily with C++ and produced a mouse. Lisp will run it down with a
year or two of serious effort. Game over, as they say.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Up spake Kenny Tilton:
> I went looking for some beef. Figured the code which loaded models must
> be meaty. Turned out to be a lot of greenspun (can we just add that to
^^^^^^^^^
Excuse my ignorance, but what is this word? Is it a pejorative?
--
-trent
I'm not sure if this is a good or a bad thing. Probably a bad thing;
most things are bad things. -- Nile Evil Bastard
Trent Buck wrote:
> Up spake Kenny Tilton:
>
>>I went looking for some beef. Figured the code which loaded models must
>>be meaty. Turned out to be a lot of greenspun (can we just add that to
>
> ^^^^^^^^^
>
> Excuse my ignorance, but what is this word? Is it a pejorative?
>
Yes and no. From the man himself http://philip.greenspun.com/research/:
"Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C
or Fortran program contains an ad-hoc, informally-specified bug-ridden
slow implementation of half of Common Lisp."
"I've seen this in .signatures on USENET postings but I can no longer
remember where I wrote it originally. On the Squeak discussion group,
Vassili Bykov helpfully explained the meaning: "that complex systems
implemented in low-level languages cannot avoid reinventing and/or
reimplementing (poorly on both counts) the facilities built into
higher-level languages. Like garbage collection in OLE or keyword
arguments in X."
;;------------------------------------------------------
It is not a pejorative because, well, linked lists are useful data
structures and if your language does not have built-ins for that it is a
good idea to implement them. As best you can.
It is a pejorative because it is a slam on non-Lisp languages for not
providing the built-ins. Well, and maybe the programmer for not choosing
Lisp. But hey, not too many people have been clued into Lisp.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Trent Buck <·········@tznvy.pbz> writes:
> Up spake Kenny Tilton:
>> I went looking for some beef. Figured the code which loaded models must
>> be meaty. Turned out to be a lot of greenspun (can we just add that to
> ^^^^^^^^^
>
> Excuse my ignorance, but what is this word? Is it a pejorative?
It's from this:
Greenspun's Tenth Rule of Programming:
Any sufficiently complicated C or Fortran program contains an
ad-hoc, informally-specified bug-ridden slow implementation of
half of Common Lisp.
I recently defined my own corollary to Greenspun's 10th:
Seibel's Corollary to Greenspun's 10th
Any sufficently complicated Java program requires a programmable
IDE to make up for the half of Common Lisp not implemented in the
program itself.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Trent Buck <·········@tznvy.pbz> writes:
>
>
>>Up spake Kenny Tilton:
>>
>>>I went looking for some beef. Figured the code which loaded models must
>>>be meaty. Turned out to be a lot of greenspun (can we just add that to
>>
>> ^^^^^^^^^
>>
>>Excuse my ignorance, but what is this word? Is it a pejorative?
>
>
> It's from this:
>
> Greenspun's Tenth Rule of Programming:
>
> Any sufficiently complicated C or Fortran program contains an
> ad-hoc, informally-specified bug-ridden slow implementation of
> half of Common Lisp.
>
> I recently defined my own corollary to Greenspun's 10th:
>
> Seibel's Corollary to Greenspun's 10th
>
> Any sufficently complicated Java program requires a programmable
> IDE to make up for the half of Common Lisp not implemented in the
> program itself.
As someone who has programed extremely large systems in Java using
solely Emacs, let me just say: bullshit.
Peter Ashford <··@here.there.com> writes:
> Peter Seibel wrote:
>> Trent Buck <·········@tznvy.pbz> writes:
>>
>>>Up spake Kenny Tilton:
>>>
>>>> I went looking for some beef. Figured the code which loaded models
>>>> must be meaty. Turned out to be a lot of greenspun (can we just
>>>> add that to
>>>
>>> ^^^^^^^^^
>>>
>>>Excuse my ignorance, but what is this word? Is it a pejorative?
>> It's from this:
>> Greenspun's Tenth Rule of Programming:
>> Any sufficiently complicated C or Fortran program contains an
>> ad-hoc, informally-specified bug-ridden slow implementation of
>> half of Common Lisp.
>> I recently defined my own corollary to Greenspun's 10th:
>> Seibel's Corollary to Greenspun's 10th
>> Any sufficently complicated Java program requires a programmable
>> IDE to make up for the half of Common Lisp not implemented in the
>> program itself.
>
> As someone who has programed extremely large systems in Java using
> solely Emacs, let me just say: bullshit.
Isn't Emacs a programmable IDE?
--jon
Peter Ashford <··@here.there.com> writes:
> Peter Seibel wrote:
> > Trent Buck <·········@tznvy.pbz> writes:
> >
> >>Up spake Kenny Tilton:
> >>
> >>> I went looking for some beef. Figured the code which loaded models
> >>> must be meaty. Turned out to be a lot of greenspun (can we just
> >>> add that to
> >>
> >> ^^^^^^^^^
> >>
> >>Excuse my ignorance, but what is this word? Is it a pejorative?
> > It's from this:
> > Greenspun's Tenth Rule of Programming:
> > Any sufficiently complicated C or Fortran program contains an
> > ad-hoc, informally-specified bug-ridden slow implementation of
> > half of Common Lisp.
> > I recently defined my own corollary to Greenspun's 10th:
> > Seibel's Corollary to Greenspun's 10th
> > Any sufficently complicated Java program requires a programmable
> > IDE to make up for the half of Common Lisp not implemented in the
> > program itself.
>
> As someone who has programed extremely large systems in Java using
> solely Emacs, let me just say: bullshit.
Three things:
1. Emacs is probably the most capable programmable IDE currently
available.
2. 'large' and 'complex' are neither necessary nor sufficient for each
other.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay <······@foo.com> writes:
> Peter Ashford <··@here.there.com> writes:
>
> > Peter Seibel wrote:
> > > Trent Buck <·········@tznvy.pbz> writes:
> > >
> > >>Up spake Kenny Tilton:
> > >>
> > >>> I went looking for some beef. Figured the code which loaded models
> > >>> must be meaty. Turned out to be a lot of greenspun (can we just
> > >>> add that to
> > >>
> > >> ^^^^^^^^^
> > >>
> > >>Excuse my ignorance, but what is this word? Is it a pejorative?
> > > It's from this:
> > > Greenspun's Tenth Rule of Programming:
> > > Any sufficiently complicated C or Fortran program contains an
> > > ad-hoc, informally-specified bug-ridden slow implementation of
> > > half of Common Lisp.
> > > I recently defined my own corollary to Greenspun's 10th:
> > > Seibel's Corollary to Greenspun's 10th
> > > Any sufficently complicated Java program requires a programmable
> > > IDE to make up for the half of Common Lisp not implemented in the
> > > program itself.
> >
> > As someone who has programed extremely large systems in Java using
> > solely Emacs, let me just say: bullshit.
>
> Three things:
>
> 1. Emacs is probably the most capable programmable IDE currently
> available.
>
> 2. 'large' and 'complex' are neither necessary nor sufficient for each
> other.
Fat fingers/brain fart. Sent before finished.
3. 1 an 2 don't imply your conclusion is false, only that the
reasoning for it is incorrect. I tend to think it is false (that
Seibel's Corollary to Greenspun's 10th is not BS)
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Peter Ashford <··@here.there.com> writes:
> Peter Seibel wrote:
>> Trent Buck <·········@tznvy.pbz> writes:
>>
>>>Up spake Kenny Tilton:
>>>
>>>> I went looking for some beef. Figured the code which loaded models
>>>> must be meaty. Turned out to be a lot of greenspun (can we just
>>>> add that to
>>>
>>> ^^^^^^^^^
>>>
>>>Excuse my ignorance, but what is this word? Is it a pejorative?
>> It's from this:
>> Greenspun's Tenth Rule of Programming:
>> Any sufficiently complicated C or Fortran program contains an
>> ad-hoc, informally-specified bug-ridden slow implementation of
>> half of Common Lisp.
>> I recently defined my own corollary to Greenspun's 10th:
>> Seibel's Corollary to Greenspun's 10th
>> Any sufficently complicated Java program requires a programmable
>> IDE to make up for the half of Common Lisp not implemented in the
>> program itself.
>
> As someone who has programed extremely large systems in Java using
> solely Emacs, let me just say: bullshit.
Hey, *I'm* speaking as someone who has programmed extremely large
systems in Java using solely Emacs. (I was an early engineer at
Weblogic and the server architect at a company where we built a
transactional message queuing system in Java including our own
transactional, persistent store.) Of course, as others have pointed
out, Emacs *is* a programmable IDE of sorts.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
On Wed, 01 Dec 2004 10:53:13 +1300, Peter Ashford wrote:
> Peter Seibel wrote:
>> Seibel's Corollary to Greenspun's 10th
>>
>> Any sufficently complicated Java program requires a programmable
>> IDE to make up for the half of Common Lisp not implemented in the
>> program itself.
>
> As someone who has programed extremely large systems in Java using
> solely Emacs, let me just say: bullshit.
It's only because I use a programmable IDE (Emacs, as others have pointed
out) that I can bear my day job (which basically boils down to endless
greenspuning in Java).
Cheers,
Bill.
Christopher C. Stacy wrote:
> Peter Ashford <··@here.there.com> writes:
>
>
>>"Appropriate tool chains" are NOT easy to create. That's the reason
>>that there are specialists in physics, character animation, graphics
>>engines etc...
>
>
> How many times have you done this in Lisp?
I have never done it in Lisp. However, I DO work making middleware for
games, and I know LISP as well.
I'm not saying that making middleware in Lisp is harder than C++ - I'm
sure it isn't, I'm saying that all the current middleware is written in
C++ and it's hard to make an AAA title without using middleware. As
there is currently no Lisp middleware like Havoc or the Unreal Engine, I
conclude that writing an AAA game in Lisp faces a lot more work than
doing the same in C++ where I can choose commodity items as middleware.
I'm sick of getting misinterpretted on this - I'm not criticing Lisp, I
LIKE Lisp - I'm saying that a whole field of products that are
indespensible to modern AAA game construction do not exist for Lisp, and
that's an issue if you chose to use Lisp to write games.
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <ud5xvx9zq.fsf@news.dtpq.com>
Peter Ashford <··@here.there.com> writes:
> I'm saying that a whole field of products that are indespensible
> to modern AAA game construction do not exist for Lisp,
Realizing that "indespensible" might be somewhat subjective,
I don't think anybody disputes your statement there.
People are suggesting that Lisp might be very good for creating
those missing components, with a cost that is orders of magnitude
below what it would take to do it in C++.
Christopher C. Stacy wrote:
> Peter Ashford <··@here.there.com> writes:
>
>>I'm saying that a whole field of products that are indespensible
>>to modern AAA game construction do not exist for Lisp,
>
>
> Realizing that "indespensible" might be somewhat subjective,
> I don't think anybody disputes your statement there.
>
> People are suggesting that Lisp might be very good for creating
> those missing components, with a cost that is orders of magnitude
> below what it would take to do it in C++.
>
I have no issue with that.
We agree that those products (Lisp middleware) don't currently don't
exist.
The issue I see going forward is this - to be commercially successful at
making middleware, there need to be people buying your product, which
requires a market of Lisp game programmers. There doesn't currently
exist such a market, therefore good Lisp middleware is not going to be
written.
To create this market, there needs to be a bunch of Lisp trailblazers -
the equivallent of companies like Id, who create a game with a great
engine that they can make money off as a game but also license to other
Lisp game developers - then you start boot strapping the whole situation
(and this is how the C++ middleware market was created as well)
The difference is that the C++ middleware market bootstrapped in this
way when there was *no other alternative*. Lisp would have to do it,
when better, more mature, more productive middleware already exists in
C++. NOTE: that is not a comment on C++ versus Lisp, its a comment on
the quality and maturity of products like Havoc, Unreal Engine etc...
When Id made their engine such that it could be licenced by third
parties, there was nothing else there filling the gap. If Lisp
developers want to try and do the same thing, they face stiff
competition from an already existing middleware and toolchain market.
This is the difference I'm talking about - it's a Mac versus Windows
thing (or Amiga vs Windows) The new tech might be better in every way
but if the market is off somewhere else doing its own thing, then
breaking into that market and causing revolutionary change is nigh on
impossible.
You guys keep thinking that Lisp will succeed because it is
technologically superior. I'm happy to conceed that point, I just don't
think it makes any difference to the market.
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <u8y8ixtn0.fsf@news.dtpq.com>
Peter Ashford <··@here.there.com> writes:
> The issue I see going forward is this - to be commercially successful
> at making middleware, there need to be people buying your product,
> which requires a market of Lisp game programmers. There doesn't
> currently exist such a market, therefore good Lisp middleware is not
> going to be written.
>
> To create this market, there needs to be a bunch of Lisp trailblazers
> -
> the equivallent of companies like Id, who create a game with a great
> engine that they can make money off as a game but also license to
> other Lisp game developers - then you start boot strapping the whole
> situation (and this is how the C++ middleware market was created as
> well)
[...]
> You guys keep thinking that Lisp will succeed because it is
> technologically superior. I'm happy to conceed that point, I just
> don't think it makes any difference to the market.
You seem to be talking about a "market" of programmers who want
to obtain third-party "tool chains" or "middleware" with which
to develop their games.
Alternatively, individuals or individual companies could decide to
create (from scratch) their own Lisp software tools in which to
develop their games in Lisp. (Exactly what programs need to be
written depends on how you are going to use Lisp for the product.)
Then, rather than re-sell their tools, they could just use them
to their own strategic competitive advantage.
Maybe they could call the resulting product "Jak and Dexter".
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
By the way, The first commercially successful game I can think of that
was written in Lisp pre-dates video games. That would be Zork.
(It was written in an old dialect of Lisp called "MDL".)
I don't know whether you think that's very relevent to this
discussion or not; just thought it was an interesting historical tidbit.
Lisp has mostly been used for things other than developing games.
But graphics and AI, for example, have always been mainstays.
and those two domains certainly intersect with video games.
It has only been fairly recently that most computers were powerful
enough to run Lisp, so it hasn't been an option for most developers.
Lisp has a history of about 40 years, and for about 24 of those years,
"roll your own" is the approach that its practitioners have favored.
Sometimes this was because the libraries didn't exist, or it was hard
to interface to them, but often it was just because better libraries
and tools could be easily written in Lisp. It's an approach that's
insanely expensive in other languages - most companies want to cobble
things together by writing as little software as possible, especially
these days. Lisp is no magic bullet, of course. But for various reasons,
most people are quite unaware of this quarter century history of great
commercial successes using Lisp in just about every kind of application
domain that you can think of.
I think video games is probably a good domain for Lisp because
if the target platform is Mac/PC/Linux, it integrates well enough
(and is getting better), or if the target platform is some toy box,
then you have a foreign embedded cross-development situation of the
sort that Lisp has been very successfully used for many times in the past.
I don't think we're in much disagreement, except as to how much
sense it makes for someone to consider Lisp, which is pretty subjective.
Until fairly recently, most people could not even afford computers
powerful enough to run Lisp, so it wasn't an option, even if they
wanted it. My only point is to show that there's more than one way
of skinning a cat, and some people have found Lisp to be a good way.
In article <·············@news.dtpq.com>, ······@news.dtpq.com says...
> Alternatively, individuals or individual companies could decide to
> create (from scratch) their own Lisp software tools in which to
> develop their games in Lisp. (Exactly what programs need to be
> written depends on how you are going to use Lisp for the product.)
> Then, rather than re-sell their tools, they could just use them
> to their own strategic competitive advantage.
>
> Maybe they could call the resulting product "Jak and Dexter".
> http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
Maybe they could. Although they would also note that instead of being
more productive by plural "orders" of magnitude (c.f. your previous
post) i.e. factors of hundreds or thousands, they would have taken about
the same time as development teams using other languages. And instead
of an engine that is even *capable* of being re-sold, they would be left
with an engine that only one programmer understands.
- Gerry Quinn
>
>
>>You guys keep thinking that Lisp will succeed because it is
>>technologically superior. I'm happy to conceed that point, I just
>>don't think it makes any difference to the market.
>
>
> You seem to be talking about a "market" of programmers who want
> to obtain third-party "tool chains" or "middleware" with which
> to develop their games.
>
> Alternatively, individuals or individual companies could decide to
> create (from scratch) their own Lisp software tools in which to
> develop their games in Lisp. (Exactly what programs need to be
> written depends on how you are going to use Lisp for the product.)
> Then, rather than re-sell their tools, they could just use them
> to their own strategic competitive advantage.
Of course they could. However having to roll your own is an impediment
to writing AAA games. Also, you're not comparing apples with apples.
Games of the class of Half Life 2 and Halo2 (using Havoc) are much more
complex than Jak and Dexter. Writing a physics engine is very non
trivial regardless of programming language and if you have to "roll you
own" to write an equivallent game in Lisp then you have a HUGE
impediment to progress than a C++ programmer doesn't have. (Note, I hate
C++, I'm just commenting on market realities).
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <u8y8hfypu.fsf@news.dtpq.com>
Peter Ashford <··@here.there.com> writes:
> >
> >>You guys keep thinking that Lisp will succeed because it is
> >>technologically superior. I'm happy to conceed that point, I just
> >>don't think it makes any difference to the market.
> > You seem to be talking about a "market" of programmers who want to
> > obtain third-party "tool chains" or "middleware" with which to
> > develop their games.
> > Alternatively, individuals or individual companies could decide to
> > create (from scratch) their own Lisp software tools in which to
> > develop their games in Lisp. (Exactly what programs need to be
> > written depends on how you are going to use Lisp for the product.)
> > Then, rather than re-sell their tools, they could just use them to
> > their own strategic competitive advantage.
>
> Of course they could. However having to roll your own is an
> impediment to writing AAA games. Also, you're not comparing apples
> with apples. Games of the class of Half Life 2 and Halo2 (using Havoc)
> are much more complex than Jak and Dexter. Writing a physics engine
> is very non trivial regardless of programming language and if you have
> to "roll you own" to write an equivallent game in Lisp then you have a
> HUGE impediment to progress than a C++ programmer doesn't have. (Note,
> I hate C++, I'm just commenting on market realities).
YMMV
Christopher C. Stacy wrote:
> Peter Ashford <··@here.there.com> writes:
>
>
>>>>You guys keep thinking that Lisp will succeed because it is
>>>>technologically superior. I'm happy to conceed that point, I just
>>>>don't think it makes any difference to the market.
>>>
>>>You seem to be talking about a "market" of programmers who want to
>>>obtain third-party "tool chains" or "middleware" with which to
>>>develop their games.
>>>Alternatively, individuals or individual companies could decide to
>>>create (from scratch) their own Lisp software tools in which to
>>>develop their games in Lisp. (Exactly what programs need to be
>>>written depends on how you are going to use Lisp for the product.)
>>>Then, rather than re-sell their tools, they could just use them to
>>>their own strategic competitive advantage.
>>
>>Of course they could. However having to roll your own is an
>>impediment to writing AAA games. Also, you're not comparing apples
>>with apples. Games of the class of Half Life 2 and Halo2 (using Havoc)
>>are much more complex than Jak and Dexter. Writing a physics engine
>>is very non trivial regardless of programming language and if you have
>>to "roll you own" to write an equivallent game in Lisp then you have a
>>HUGE impediment to progress than a C++ programmer doesn't have. (Note,
>>I hate C++, I'm just commenting on market realities).
>
>
> YMMV
It's got nothing to do with *my* milage. The market works this way.
Disagree with any of these and you're nuts :o) :
(1) Physics engines are a lot of work to get right
(2) Physics engines are required for some modern AAA games
(3) Physics engines for AAA games exist only currently for C++
Therefore:
(4) Writing AAA games which require physics is going to be much easier
in C++ (where it's a commodity) than any other language where you have
to roll your own.
Sorry, that is just a fact. There's no 'milage' or interpretation involved.
I'm not sure this is relevant, but there's a system called Abigail
that does naive physics in Lisp. It works under CLIM --- the "movie"
part even works under McCLIM if you fix a few things in Abigail. It
has stick figure animations, calculated in real time, of people
walking around playing with a ball, bouncing a ball and a couple
others.
--
Fred Gilham ······@csl.sri.com
It's a sign of the times that a party that stands for recognizing
the limits imposed by the Constitution is regarded as extremist,
unelectable, radical, outside the mainstream. -- Joseph Sobran
In article <··············@snapdragon.csl.sri.com>,
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
>I'm not sure this is relevant, but there's a system called Abigail
>that does naive physics in Lisp. It works under CLIM --- the "movie"
>part even works under McCLIM if you fix a few things in Abigail. It
>has stick figure animations, calculated in real time, of people
>walking around playing with a ball, bouncing a ball and a couple
>others.
Yeah, well, that's easy, elementary physics. When you're
calculating lots of interpenetrating objects, with complicated
collision geometry, correctly *AND* quickly, then say something.
Commercial middleware like Havok have got the hard cases solved well
enough, something that takes all the development time. Things like
basic physics or a scene graph are "solved problems" -- they're
published in books and/or given out as homework problems. Good physics
that's also fast enough for consoles is nowhere near a solved problem,
and your choice of language won't help you one iota in *coming up* with
algorithms to cover all the weirdball edge cases. [Note: I didn't
say *implementing* the algorithms. The problem isn't there, so leave
any language fanaticism outside.]
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Nathan Mates wrote:
> In article <··············@snapdragon.csl.sri.com>,
> Fred Gilham <······@snapdragon.csl.sri.com> wrote:
>
>>I'm not sure this is relevant, but there's a system called Abigail
>>that does naive physics in Lisp. It works under CLIM --- the "movie"
>>part even works under McCLIM if you fix a few things in Abigail. It
>>has stick figure animations, calculated in real time, of people
>>walking around playing with a ball, bouncing a ball and a couple
>>others.
>
>
> Yeah, well, that's easy, elementary physics. When you're
> calculating lots of interpenetrating objects, with complicated
> collision geometry, correctly *AND* quickly, then say something.
> Commercial middleware like Havok have got the hard cases solved well
> enough, something that takes all the development time. Things like
> basic physics or a scene graph are "solved problems" -- they're
> published in books and/or given out as homework problems. Good physics
> that's also fast enough for consoles is nowhere near a solved problem,
> and your choice of language won't help you one iota in *coming up* with
> algorithms to cover all the weirdball edge cases. [Note: I didn't
> say *implementing* the algorithms. The problem isn't there, so leave
> any language fanaticism outside.]
>
That's rather my point - doing these things well enough to work for
games in general is extremely non trivial, and getting someone else to
do it for you is a major bonus to productivity (and, in the case of
physics engines, sanity)
Fred Gilham wrote:
> I'm not sure this is relevant, but there's a system called Abigail
> that does naive physics in Lisp. It works under CLIM --- the "movie"
> part even works under McCLIM if you fix a few things in Abigail. It
> has stick figure animations, calculated in real time, of people
> walking around playing with a ball, bouncing a ball and a couple
> others.
>
Physics simulations and physics simulations that you can use in AAA
games are quite different things.
In article <·····················@news.xtra.co.nz>, ··@here.there.com
says...
> Disagree with any of these and you're nuts :o) :
>
> (1) Physics engines are a lot of work to get right
> (2) Physics engines are required for some modern AAA games
> (3) Physics engines for AAA games exist only currently for C++
>
> Therefore:
>
> (4) Writing AAA games which require physics is going to be much easier
> in C++ (where it's a commodity) than any other language where you have
> to roll your own.
>
> Sorry, that is just a fact. There's no 'milage' or interpretation involved.
That seems like a flawed conclusion. It is probably a rather
simple task to wrap any "C++-only" physics engine to allow
it to be called from whatever language you'd want to be
calling it from, including Lisp.
Christer Ericson
Sony Computer Entertainment, Santa Monica
Christer Ericson wrote:
> In article <·····················@news.xtra.co.nz>, ··@here.there.com
> says...
>
>>Disagree with any of these and you're nuts :o) :
>>
>>(1) Physics engines are a lot of work to get right
>>(2) Physics engines are required for some modern AAA games
>>(3) Physics engines for AAA games exist only currently for C++
>>
>>Therefore:
>>
>>(4) Writing AAA games which require physics is going to be much easier
>>in C++ (where it's a commodity) than any other language where you have
>>to roll your own.
>>
>>Sorry, that is just a fact. There's no 'milage' or interpretation involved.
>
>
> That seems like a flawed conclusion. It is probably a rather
> simple task to wrap any "C++-only" physics engine to allow
> it to be called from whatever language you'd want to be
> calling it from, including Lisp.
>
> Christer Ericson
> Sony Computer Entertainment, Santa Monica
Have you seen Havoc? It doesn't have a thin interface, it's designed to
slot right into your code. I've done a few things in Java and OpenGL
which have convinced me that the thin wrapper approach is very powerful
for non C languages, but something like Havoc simply doesn't *have* a
thin interface - you'd have to write a considerable ammount of C++ to
make a thin interface to map it to your local language.
Christer Ericson <················@NOTplayTHISstationBIT.sony.com>
wrote in ·······························@news.verizon.net:
> In article <·····················@news.xtra.co.nz>,
> ··@here.there.com says...
>> Disagree with any of these and you're nuts :o) :
>>
>> (1) Physics engines are a lot of work to get right
>> (2) Physics engines are required for some modern AAA games
>> (3) Physics engines for AAA games exist only currently for C++
>>
>> Therefore:
>>
>> (4) Writing AAA games which require physics is going to be much
>> easier in C++ (where it's a commodity) than any other language
>> where you have to roll your own.
>>
>> Sorry, that is just a fact. There's no 'milage' or
>> interpretation involved.
>
> That seems like a flawed conclusion. It is probably a rather
> simple task to wrap any "C++-only" physics engine to allow
> it to be called from whatever language you'd want to be
> calling it from, including Lisp.
>
Yes it's a simple task. Create memory buffer, share it with graphic
library then batch fill memory buffer and set bit you are done, then
wait, or periodically check if GFX is done. Graphic library would
take information about memory buffer, returns if all was set
properly, and without delay reads first batch. (simillary in the way
of communicating between programs and devices)
The problems arises because you don't know if there wouldn't be bug
in the graphic library, hope thread implementation of graphic library
will not blast priorities of your threads, in most cases they'd do,
but it's not too hard a problem... (well sometimes it's dissasembly
currable hard problem).
Memory caching problems? Will it take too much, or too little.
The interface looks butt ugly problem.
You'd lose also a nice JIT inlining and escape analisis, and some
other "benefits" of JIT compiled languages.
If you are smart and though about a recompilling at runtime, you are
out of luck C++ engine will not alow this.
How many C++ engines supports this universal way of communication? If
none then you'd need to do a little extension of the engine, and risk
messing things really hard.
Communication between library designers, and program designers
problem isn't inter - language dependant.
So this is a short list of potential problems.
BTW I preffer term world engine.
> You guys keep thinking that Lisp will succeed because it is
> technologically superior. I'm happy to conceed that point, I just don't
> think it makes any difference to the market.
I mean, that I'm happy to conceed that Lisp may be technologically
superior, not that this means it will succeed in the game market.
Peter Ashford wrote:
>> You guys keep thinking that Lisp will succeed because it is
>> technologically superior. I'm happy to conceed that point, I just
>> don't think it makes any difference to the market.
>
>
> I mean, that I'm happy to conceed that Lisp may be technologically
> superior, not that this means it will succeed in the game market.
Whew! For a second there I thought a Usenet debate had resulted in
agreement. Damn near had a heart attack. Be careful, will ya? The
monkeys lost it, had to lock 'em down for the day.
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
I prefer to use SQL for most 3D Engine development, anyone else feel the
same?
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
··························@twister.nyc.rr.com...
>
>
> Peter Ashford wrote:
> >> You guys keep thinking that Lisp will succeed because it is
> >> technologically superior. I'm happy to conceed that point, I just
> >> don't think it makes any difference to the market.
> >
> >
> > I mean, that I'm happy to conceed that Lisp may be technologically
> > superior, not that this means it will succeed in the game market.
>
> Whew! For a second there I thought a Usenet debate had resulted in
> agreement. Damn near had a heart attack. Be careful, will ya? The
> monkeys lost it, had to lock 'em down for the day.
>
> :)
>
> kenny
>
> --
> Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
> Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
>
Pablo wrote:
> I prefer to use SQL for most 3D Engine development, anyone else feel the
> same?
Haw haw. At least PostgreSQL already has a complete GIS extension. You can
query for triangles. Hours of fun!
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
In article <·····················@news.xtra.co.nz>,
Peter Ashford <··@here.there.com> wrote:
> Christopher C. Stacy wrote:
> > Peter Ashford <··@here.there.com> writes:
> >
> >
> >>"Appropriate tool chains" are NOT easy to create. That's the reason
> >>that there are specialists in physics, character animation, graphics
> >>engines etc...
> >
> >
> > How many times have you done this in Lisp?
>
> I have never done it in Lisp. However, I DO work making middleware for
> games, and I know LISP as well.
>
> I'm not saying that making middleware in Lisp is harder than C++ - I'm
> sure it isn't, I'm saying that all the current middleware is written in
> C++ and it's hard to make an AAA title without using middleware. As
> there is currently no Lisp middleware like Havoc or the Unreal Engine, I
> conclude that writing an AAA game in Lisp faces a lot more work than
> doing the same in C++ where I can choose commodity items as middleware.
>
> I'm sick of getting misinterpretted on this - I'm not criticing Lisp, I
> LIKE Lisp - I'm saying that a whole field of products that are
> indespensible to modern AAA game construction do not exist for Lisp, and
> that's an issue if you chose to use Lisp to write games.
But one guy (me) farting around for a year already has the beginnings of
an OpenGL scene graph manager, with support for OpenAL, arbitrary
graphics formats, and anti-aliased or 3D text. The graph is managed by
my Cells hack, which is simply brilliant for simulations.
You are absolutely right that the infrastructure is not there now, but I
look at some of these open source projects and see maybe 15 person-years
of work. Even if it is more like 30, hell, that is C++ years. Translated
to Lisp years, a few good Lispniks could...
..gee, since you like Lisp so well, you should sign on with my Cello
project. Frank and I are within hailing distance of an OS X port, which
would join win32 and Linux (again Frank). We could use your games
experience to prioritize features to be added, and identify which C/C++
libs to FFI to or (better) translate to Lisp should that ever make sense.
kenny
>>>>"Appropriate tool chains" are NOT easy to create. That's the reason
>>>>that there are specialists in physics, character animation, graphics
>>>>engines etc...
>>>
>>>
>>>How many times have you done this in Lisp?
>>
>>I have never done it in Lisp. However, I DO work making middleware for
>>games, and I know LISP as well.
>>
>>I'm not saying that making middleware in Lisp is harder than C++ - I'm
>>sure it isn't, I'm saying that all the current middleware is written in
>>C++ and it's hard to make an AAA title without using middleware. As
>>there is currently no Lisp middleware like Havoc or the Unreal Engine, I
>>conclude that writing an AAA game in Lisp faces a lot more work than
>>doing the same in C++ where I can choose commodity items as middleware.
>>
>>I'm sick of getting misinterpretted on this - I'm not criticing Lisp, I
>>LIKE Lisp - I'm saying that a whole field of products that are
>>indespensible to modern AAA game construction do not exist for Lisp, and
>>that's an issue if you chose to use Lisp to write games.
>
>
> But one guy (me) farting around for a year already has the beginnings of
> an OpenGL scene graph manager, with support for OpenAL, arbitrary
> graphics formats, and anti-aliased or 3D text. The graph is managed by
> my Cells hack, which is simply brilliant for simulations.
No offense, but every man and his dog has written a games engine / scene
graph. Myself included - both in C++ and Java. That's no where near
the amount of work that goes into a product like Havoc which is designed
with the flexibility to be able to fit into arbitrary production pipelines.
> You are absolutely right that the infrastructure is not there now, but I
> look at some of these open source projects and see maybe 15 person-years
> of work. Even if it is more like 30, hell, that is C++ years. Translated
> to Lisp years, a few good Lispniks could...
It's worth noting that nothing open source has really achieved great
success as AAA games middleware. The closest would probably be SDL
which has been mainly useful for porting to the Linux platform. All the
OSS projects such as Ogre, Crystal Space et al., have no impact on games
houses - and that's with dozens of smart and dedicated contributing
authors. The same is true in the Java games development scene where
projects like LWJGL and Xith3D have lots of contributors, produce good
work yet matter not a jot to the games development world.
> ..gee, since you like Lisp so well, you should sign on with my Cello
> project. Frank and I are within hailing distance of an OS X port, which
> would join win32 and Linux (again Frank). We could use your games
> experience to prioritize features to be added, and identify which C/C++
> libs to FFI to or (better) translate to Lisp should that ever make sense.
Good luck with Cello, but I'm not short of personal projects... what I'm
short of is time! However, I have become interested in seeing what I
can do on Win32 in lisp, so I'll have a wee look at that and see how it
goes. What Lisp / OpenGL implementation would you recommend for Win32?
Peter Ashford wrote:
> No offense, but every man and his dog has written a games engine
My secret is that I use monkeys, dozens of them. Labs are bright, but
when it comes to programming I'll take a good rhesus any time.
> OSS projects such as Ogre, Crystal Space et al., have no impact on games
Thx for the input. Is that because they suck, or because things like
Havoc are better? How much so?
> Good luck with Cello, but I'm not short of personal projects... what I'm
> short of is time! However, I have become interested in seeing what I
> can do on Win32 in lisp, so I'll have a wee look at that and see how it
> goes. What Lisp / OpenGL implementation would you recommend for Win32?
Uhhh, Cello? You can use AllegroCL or Lispworks. A lazy stab at a
CormanCL port came up empty.
Not sure how I missed it, but a CLisp port should be a breeze based on
what I see of the FFI as I play with cells-gtk. Of course if you are
going to get intense on the CPU, bear in mind that CLisp is a byte-code
deal.
AllegroCL is by far the superior IDE, but some people like Lispworks. On
the other hand, many people like programming Lisp with Emacs and ILisp
(and now SLime), which is terrible compared to an integrated IDE, so my
mileage may not be the best to heed. But if you have the bucks, save
yourself a world of distractions and get AllegroCL.
Lispworks has the charm of offering OpenGL off the shelf. And if you
ever ship, no runtime licensing. Franz (AllegroCL) wants a pound of
flesh for distributing. You gotta talk to them to find out. They may be
worth it, though with Lispworks as an alternative....
The Opengl bindings in Cello are incomplete. But I have just seen what
FFIGEN can do in yet another lisp/gtk offering announced today:
lambda-gtk (on common-lisp.net).
I should get around to throwing gl.h and glu.h at FFIGEN and doing some
proper bindings, but anyone could do that.
Over on the Lisp cliki I found links to other opengl bindings, but i
could not make sense of them and just tossed off my own. You might do
better with some of those old bindings.
Cello includes FTGL for superb text in OpenGL as well as OpenAL support
and ImageMagick for pulling in graphics files. And Cells. Plus anything
you happen to do could help extend Cello. Oh, it uses Freeglut on win32
and Linux, Apple's Glut on OS X. MIT license.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> Peter Ashford wrote:
>
>
>> No offense, but every man and his dog has written a games engine
>
>
> My secret is that I use monkeys, dozens of them. Labs are bright, but
> when it comes to programming I'll take a good rhesus any time.
LOL! :o)
>> OSS projects such as Ogre, Crystal Space et al., have no impact on games
>
>
> Thx for the input. Is that because they suck, or because things like
> Havoc are better? How much so?
The OSS is cool - it's written by tallented hard working programmers.
But those projects tend to do the stuff which is cool, not the boring
stuff which is neccessary - like writing exporters from Max, Maya, XSI
which can have multiple layers of filters (including custom filters) in
them to extract data. They don't do things in platform neutral ways,
they don't support consoles, they don't have integrated debuggers. A
whole bunch of things which are independantly small but add up to a
whole lot. But I suspect the biggest issue is that game companies
invest a lot of cash in their products and want certainty - things like
support and knowing that there's someone to call when things go wrong.
That, and the fact that things like Unreal and Havoc *are* tuned to run
at peak performance on the target platforms and if they aren't, some
irate programmer has already screamed at the middleware company to fix
it, so it already works well by the time you get to it :o)
I guess the fact that some people's livelyhood is attached to the
middleware doing what it promises is a big difference.
Peter Ashford wrote:
> Kenny Tilton wrote:
>
>>
>>
>> Peter Ashford wrote:
>>
>>
>>> No offense, but every man and his dog has written a games engine
>>
>>
>>
>> My secret is that I use monkeys, dozens of them. Labs are bright, but
>> when it comes to programming I'll take a good rhesus any time.
>
>
> LOL! :o)
>
>>> OSS projects such as Ogre, Crystal Space et al., have no impact on games
>>
>>
>>
>> Thx for the input. Is that because they suck, or because things like
>> Havoc are better? How much so?
>
>
> The OSS is cool - it's written by tallented hard working programmers.
> But those projects tend to do the stuff which is cool, not the boring
> stuff which is neccessary - like writing exporters from Max, Maya, XSI
> which can have multiple layers of filters (including custom filters) in
> them to extract data. They don't do things in platform neutral ways,
> they don't support consoles, they don't have integrated debuggers.
Ah, yes, all the "grown-up" stuff that OSS people pretend does not
matter. <duck> Well, I guess it is a chicken-egg deal. The OSS stuff
will get the boring stuff when enough people get involved because they
see enough functionality to make them want to get involved.
I am doing the same with Cello, adding cool stuff because (a) it is more
fun and (b) it seems to offer the best chance of attracting help. I want
to do text-to-speech next, then mebbe an importer for some "standard"
format (VRML? XML?) which modeling tools might export, if there be such
a thing.
thx for the input.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Christopher C. Stacy
Subject: Re: C++ sucks for games.... oh really?
Date:
Message-ID: <u1xegcw1p.fsf@news.dtpq.com>
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <·············@news.dtpq.com>, ······@news.dtpq.com says...
> > Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > >
> > > What puzzles me is, if Lisp is so good, where are the shareware and
> > > freeware Lisp games?
> >
> > This is your own personal puzzle, of course.
>
> If it doesn't puzzle you, how about explaining it to the rest of us?
If you pay me.
Peter Ashford wrote:
>>> Dude, I'm writing openGL / Java code - I *know* that you can write
>>> good games without using C++. HOWEVER what I or you do has no effect
>>> on the game studios out there who have millions invested in staff
>>> knowledge and tool chains built around C++.
>>
>>
>>
>> Fine, fine, fine! Like any dinosaur, C++ has a lot of inertia, for all
>> the reasons you stated. Do you think COBOL/VSAM had no inertia? Staff
>> knowledge? Existing software?
>>
>> But you said "...and probably never will". Bzzt!
>
>
> I also said "game studios" and "tool chains"
>
> Those were never programmed in COBOL, and studios with products that
> cost as much as they currently do and employ as large teams as they
> currently do have NEVER existed before in the history of computing, so
> your analogy is not at all to the point. Your analogy works for
> business computing, and in that context I'd agree, That wasn't what I
> was talking about however.
>
.....
>
>
> And the edge Lisp has over C++ is close to an order
>
>> of magnitude, so this will be an exceptionally quick transition.
>
>
> Don't berate me, I like LISP.
"Berate: To rebuke or scold angrily and at length."
Hunh? Anyway, I hear you saying that it takes larger teams than we have
ever seen before to produce software costing more than we have ever seen
before in C++.
We almost agree. :) C++ is so counter-productive (even C++ gurus Eckel
and Martin agree dynamic languages make development much faster) that
they indeed make an existing tool chain and huge programming team
necessary to produce a new game. Lisp will liberate the studios from
their enslavement to that investment.
Language chauvinism? Everyone throws around Naughty Dog as an example of
Lisp and games, but one implication has been missed: serious game
developers did not just use Lisp, they undertook the cost of developing
a (subset) Lisp compiler (console assembler) so they could program
consoles in Lisp. Maybe they knew what they were doing:
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
"Naughty Dog has been making computer and video games for over 15 years.
Company founders Andy Gavin and Jason Rubin started writing video games
as teenagers, and produced several titles for Electronic Arts while
still in College.
"Gavin learned Lisp in 1992 while working on his Ph.D. in Computer
Science at MIT. While there, he and Rubin developed a fighting game
entitled "Way of the Warrior." The high-quality graphics, sound and
artificial intelligence of the game attracted several publishing offers
� including one from Universal Interactive Studios (with whom they
signed a three-project deal in 1994)."
So they know their way around games. And were already writing games
before they knew Lisp. And they liked Lisp so much that they undertook
the cost of writing a Lisp compiler. How come?
"Naughty Dog co-founder Andy Gavin, says the unique capabilities of Lisp
enabled fast development and execution of character and object control �
something that was needed to fully realize the numerous 3D creatures and
devices which interact with the player in real-time (60 frames per second).
"Lisp was just the best solution for this job," comments Gavin. "With
leading edge game systems like ours, you have to deal with complicated
behaviors and real-time action. Languages like C are very poor with
temporal constructs. C is just very awkward for a project like this.
Lisp, on the other hand, is ideal.
"As Gavin explains, "With Lisp, one can rapidly develop meta constructs
for behaviors and combine them in new ways. In addition, Lisp allows the
redefinition of the language to easily add new constructs; particularly
those needed to deal with time-based behaviors and layering of actions.
Contrary to popular belief, there is nothing inherently slow about Lisp.
It is easy to construct a simple dialect which is just as efficient as
C, but retains the dynamic and consistent qualities that make Lisp a
much more effective expression of one�s programming intentions."
> I prefer CLISP thanks :o)
Killer FFI, I see. great for talking to an existing C tool chain. :)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> Peter Ashford wrote:
>
>>>> Dude, I'm writing openGL / Java code - I *know* that you can write
>>>> good games without using C++. HOWEVER what I or you do has no
>>>> effect on the game studios out there who have millions invested in
>>>> staff knowledge and tool chains built around C++.
>>>
>>>
>>>
>>>
>>> Fine, fine, fine! Like any dinosaur, C++ has a lot of inertia, for
>>> all the reasons you stated. Do you think COBOL/VSAM had no inertia?
>>> Staff knowledge? Existing software?
>>>
>>> But you said "...and probably never will". Bzzt!
>>
>>
>>
>> I also said "game studios" and "tool chains"
>>
>> Those were never programmed in COBOL, and studios with products that
>> cost as much as they currently do and employ as large teams as they
>> currently do have NEVER existed before in the history of computing, so
>> your analogy is not at all to the point. Your analogy works for
>> business computing, and in that context I'd agree, That wasn't what I
>> was talking about however.
>>
> .....
>
>>
>>
>> And the edge Lisp has over C++ is close to an order
>>
>>> of magnitude, so this will be an exceptionally quick transition.
>>
>>
>>
>> Don't berate me, I like LISP.
>
>
> "Berate: To rebuke or scold angrily and at length."
Don't be a pedant, I like LISP. :o)
<snip stuff about Naughty Dog>
You're preaching to the converted. I already like LISP, as noted before.
The fact that ND can do their own thing is cool, but most companies use
lots of tools (like middleware) that assume C++. If you can get lots of
middleware, tools and console compilers for LISP then you might make
some progress, but middleware providers have small niches that they live
in. They won't go out on a limb and produce a LISP version of a product
for a non-existent market and the market won't grow without the tools.
That's the inertia effect I refered to before.
Again, I dont doubt at all that LISP is suitable for games, I just think
that if you look realistically at the commercial pressures surrounding
games development houses and middleware producers, that a change to LISP
is hardly a likely thing.
Peter Ashford wrote:
> Kenny Tilton wrote:
>
>>
>>
>> Peter Ashford wrote:
>>
>>> And the edge Lisp has over C++ is close to an order
>>>
>>>> of magnitude, so this will be an exceptionally quick transition.
>>>
>>>
>>>
>>>
>>> Don't berate me, I like LISP.
>>
>>
>>
>> "Berate: To rebuke or scold angrily and at length."
>
>
> Don't be a pedant, I like LISP. :o)
Pedant?
"1. One who pays undue attention to book learning and formal rules.
2. One who exhibits one's learning or scholarship ostentatiously."
Lemme help, I think you want "proselytize". :) (Now /that/ is being
pedantic, tho you started it with all the big words.)
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
>>>> Don't berate me, I like LISP.
>>>
>>>
>>>
>>>
>>> "Berate: To rebuke or scold angrily and at length."
>>
>>
>>
>> Don't be a pedant, I like LISP. :o)
>
>
> Pedant?
>
> "1. One who pays undue attention to book learning and formal rules.
> 2. One who exhibits one's learning or scholarship ostentatiously."
>
> Lemme help, I think you want "proselytize". :) (Now /that/ is being
> pedantic, tho you started it with all the big words.)
>
> :)
LOL
On Tue, 16 Nov 2004 00:49:41 +1300, Peter Ashford <··@here.there.com>
wrote:
> Appologies for digging up this rather old thread, but I'd not read
> comp.games.development.programming.misc for a wee while and the title of
> this thread just made me laugh out loud.
>
> It's like standing in front of the pyramids and saying "Stones suck for
> construction". Jeez, C++ may have some flaws (lots, even), but it's
> done kinda okay in the game development stakes ;o)
>
Agreed :)
This thread has been on any topic known to man.
I think it was started on Lisp sucks for games.
And then someone turned the rounds.
C is good at low level.
Lisp is good at data strucures.
C++ data strucures are more laborious.
So we have a good old combo C + Lisp.
comments?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> On Tue, 16 Nov 2004 00:49:41 +1300, Peter Ashford <··@here.there.com>
> wrote:
>
>> Appologies for digging up this rather old thread, but I'd not read
>> comp.games.development.programming.misc for a wee while and the title
>> of this thread just made me laugh out loud.
>>
>> It's like standing in front of the pyramids and saying "Stones suck
>> for construction". Jeez, C++ may have some flaws (lots, even), but
>> it's done kinda okay in the game development stakes ;o)
>>
>
> Agreed :)
>
> This thread has been on any topic known to man.
> I think it was started on Lisp sucks for games.
> And then someone turned the rounds.
> C is good at low level.
> Lisp is good at data strucures.
> C++ data strucures are more laborious.
> So we have a good old combo C + Lisp.
>
> comments?
>
Well, I like both C++ and Lisp, so I ain't playing favourites =)
I guess when you start talking about modern gaming targets, however,
(e.g.: consoles) then C or C++ is really the only game in town.
Peter Ashford <··@here.there.com> writes:
>
> Appologies for digging up this rather old thread, but I'd not read
> comp.games.development.programming.misc for a wee while and the title of
> this thread just made me laugh out loud.
>
> It's like standing in front of the pyramids and saying "Stones suck for
> construction". Jeez, C++ may have some flaws (lots, even), but it's
> done kinda okay in the game development stakes ;o)
Perhaps a better pyramid analogy would be:
Slave labor and primitive tools such for construction.
--
Thomas A. Russ, USC/Information Sciences Institute
Maahes wrote:
>>Suppose that an alien encounters a message from Earth which looks like
>>
>> A + B * C / D - E * F
>>
>>The alien might be able to deduce what the operators are, and then it
>>is stuck.
>>
>>Now the same alien receives:
>>
>>(- (+ A (/ (* B C) D)) (* E F))
>
> Clipped all the other funny stuff.
>
> BTW, another fine example of why C is easier to read than Lisp.
> Of course, if you wanted to write clean code in a team environment, you
> would be expected to use:
>
> A + (B * C / D) - (E * F)
>
> so that there is no misunderstanding of your code. Certainly not needed, but
> makes it easier to read at a glance, which is what I would say is the
> highest priority when designing a language to be used in a team
> environment..
This might be easier to read for people who don't have much experience
reading Lisp code, but it's technically inferior. What I like about Lisp
syntax is its regularity, so:
(+ 5 6) => 11 - that's obvious
(+ 5 6 7) => 18 - that's nice
(+ 5 6 7 8) => 26 - just what you expect
(apply #'+ some-list-of-numbers) - if you don't know the number of
summands upfront
[apply takes a function and applies it to a list of arguments. So (apply
#'+ '(1 2 3)) is the same as (+ 1 2 3). #'+ is the function associated
with the name +.]
(+ 5) => 5 - even works for one argument
(+) => 0 - and for zero arguments
0 is the neutral element for addition. 1 is the neutral element for
multiplication, so:
(*) => 1
Especially the last three cases seem strange - why would one want to
write this? But in (apply #'+ some-list), some-list may be an empty
list, so you definitely want the neutral element as a result in that case.
This kind of regularity makes the Lisp syntax very convenient for
writing code generators (like macros, but also in other situations)
because you don't have to deal with too many special cases. Just emit an
operator like + and *, and then as many arguments as you need, including
none. Code generators are very valuable for tackling large projects.
That's true for almost all languages, as far as I can see. Furthermore,
it's good to be able to read such regular syntax because it helps in
reading and debugging generated code, especially because it really
doesn't take more practice than one or two weeks of actual coding in Lisp.
(Lisp syntax shares the advantage of regularity with, say, XML. One of
the problems with XML, though, is that XML eats up a lot of vertical
space on the screen because of the required end tags which makes XML
syntax relatively inefficient for coding since seeing more code at once
helps to better understand it. With Lisp syntax, all the closing
parentheses for a top-level expression can usually be lined up after the
expression's last token, which is extremely efficient and very
straightforward to handle when you have a good text editor that supports
Lisp syntax well.)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Maahes" <······@internode.on.net> writes:
> A + (B * C / D) - (E * F)
>
> so that there is no misunderstanding of your code. Certainly not needed, but
> makes it easier to read at a glance, which is what I would say is the
> highest priority when designing a language to be used in a team
> environment..
Ah, so Lisp is designed to make sure there is no misunderstanding of
your code, and is therefore excellent for use in a team environment.
> Gee, I just love this thread... Will it ever end. I can see this stuff going
> round in circles for weeks :)
:)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
·······@taeus.com (Jerry Coffin) writes:
> int fact(int x) {
> if (x == 0);
> return 1;
> return x * fact(x-1);
> }
>
> and:
>
> (define (fact x) (if (= x 0)
> (1
> (* x (fact (- x 1))))))
>
For the record, my eyes jumped to the extra parenthesis before the 1
right away, but it took me a number of seconds to spot the extra ; in
the C code. It is telling that Lisp programmers really do look at the
beginning of forms, and (1 ...) is immediately obvious as an invalid
form. I am both a C and a Lisp programmer---I have programmed in C
far longer than Lisp---and one thing I remember always hating was
discovering that 2 hours spent debugging compilation errors could be
attributed to a misplaced semi-colon. Of course, once I started using
Emacs seriously, this problem faded; much the same for Lisp.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Jerry Coffin wrote:
> With that given, tests have repeatedly shown that C is far more
> readable than Lisp. Just for an obvious example, consider finding
> problems in code, such as:
>
> int fact(int x) {
> if (x == 0);
> return 1;
> return x * fact(x-1);
> }
>
> and:
>
> (define (fact x) (if (= x 0)
> (1
> (* x (fact (- x 1))))))
>
> In my testing, C programmers find the problem in the C code an average
> of more than five times as fast as Lisp programmers find the problem
> in the Lisp code.
Strange. I found the Lisp problem slightly faster than
I found the C problem; about 3 seconds for the C and
about 2 seconds for the Lisp. (I consider myself a fairly
expert programmer in both languages, and I have written
a lot more C and C++ than Lisp recently; I don't think
the difference can be explained by my being much better
at Lisp than at C.)
> In addition, C compilers almost universally give
> SOME sort of complaint pointing (at least indirectly) to the problem
> in the C code (typically pointing out the dead code) while Lisp
> compilers (and interpreters, the last time I looked) generally accept
> the latter code without so much as a peep.
Really? The equivalent Common Lisp code produces an error
at compile time in CMU CL and at definition time in CLISP.
Your code seems to be in Scheme; the Scheme implementations
I've tried are much less satisfactory.
> > One syntactic sdidiocy is patched over
> > with another. What a false economy; just so that you could have these
> > prefix operators and whatnot, you have to type extra punctuation even
> > when you are not using them!
>
> Lisp hardly provides a suitable platform from which to launch such a
> diatribe. Rather the contrary -- Lisp has more extra punctuation than
> nearly any other language extant.
Not true, actually.
> In any case, while counting keystrokes has some meaning when
> evaluating calculators (yes, I still use HPs), typing in punctuation
> on a normal keyboard rarely seems to be a real source of major
> problems. If terseness is your measure of choice anyway, then any
> choice other than APL seems nearly indefensible for you.
On a large scale, Lisp is capable of being extraordinarily terse.
That doesn't tend to show up in toy programs, though, so it
doesn't get noticed so readily by newcomers to the language.
--
Gareth McCaughan
.sig under construc
In article <··············@g.mccaughan.ntlworld.com>,
Gareth McCaughan <················@pobox.com> wrote:
> Jerry Coffin wrote:
>
> > With that given, tests have repeatedly shown that C is far more
> > readable than Lisp. Just for an obvious example, consider finding
> > problems in code, such as:
> >
> > int fact(int x) {
> > if (x == 0);
> > return 1;
> > return x * fact(x-1);
> > }
> >
> > and:
> >
> > (define (fact x) (if (= x 0)
> > (1
> > (* x (fact (- x 1))))))
> >
> > In my testing, C programmers find the problem in the C code an average
> > of more than five times as fast as Lisp programmers find the problem
> > in the Lisp code.
>
> Strange. I found the Lisp problem slightly faster than
> I found the C problem; about 3 seconds for the C and
> about 2 seconds for the Lisp. (I consider myself a fairly
> expert programmer in both languages, and I have written
> a lot more C and C++ than Lisp recently; I don't think
> the difference can be explained by my being much better
> at Lisp than at C.)
Jeez, your eyes did not shriek aloud at that semi-colon at the end of a
line beginning "if ..."?!
You over-estimate yourself on C (which I have not done in anger for nine
years).
As for a Lisp excerpt beginning "(1 ", well, ...
PWUAHHHAAHAHHAHAAHAHAAHHAAAAA....
You all need to just stop this idiotic thread. There is one simple idea,
to be respected or rejected: those who are saying "lisp roolz" are also
people who know one or more of C, Java, C++, Python, Perl, and Ruby, and
they are saying Lisp is so dramatically more effective for them that
they would not use anything else (if their bosses let them). meanwhile,
there are no such ranters for other languages which also know Lisp.
Draw your own conclusions.
kt
Kenneth Tilton wrote:
> In article <··············@g.mccaughan.ntlworld.com>,
> Gareth McCaughan <················@pobox.com> wrote:
>
> > Jerry Coffin wrote:
> >
> > > With that given, tests have repeatedly shown that C is far more
> > > readable than Lisp. Just for an obvious example, consider finding
> > > problems in code, such as:
> > >
> > > int fact(int x) {
> > > if (x == 0);
> > > return 1;
> > > return x * fact(x-1);
> > > }
> > >
> > > and:
> > >
> > > (define (fact x) (if (= x 0)
> > > (1
> > > (* x (fact (- x 1))))))
> > >
> > > In my testing, C programmers find the problem in the C code an average
> > > of more than five times as fast as Lisp programmers find the problem
> > > in the Lisp code.
> >
> > Strange. I found the Lisp problem slightly faster than
> > I found the C problem; about 3 seconds for the C and
> > about 2 seconds for the Lisp. (I consider myself a fairly
> > expert programmer in both languages, and I have written
> > a lot more C and C++ than Lisp recently; I don't think
> > the difference can be explained by my being much better
> > at Lisp than at C.)
>
> Jeez, your eyes did not shriek aloud at that semi-colon at the end of a
> line beginning "if ..."?!
Yes, they did. And at the "(1 ..." in the Lisp code.
I'm sorry if you think taking a couple of seconds to
spot a typo at 1.30am local time is proof of incompetence.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> Kenneth Tilton wrote:
>>Jeez, your eyes did not shriek aloud at that semi-colon at the end of a
>>line beginning "if ..."?!
>
>
> Yes, they did. And at the "(1 ..." in the Lisp code.
> I'm sorry if you think taking a couple of seconds to
> spot a typo at 1.30am local time is proof of incompetence.
Naw, I was just being a d*ckhead. That is what /I/ do at 1:30am when I
get back from the pub.
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Naw, I was just being a d*ckhead. That is what /I/ do at 1:30am when I
> get back from the pub.
Yeah, that's what happens when you leave the pub early and have time to
kill before you get your unemployed ass to bed somewhere around 5:00.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, Rahul Jain <·····@nyct.net>
wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Naw, I was just being a d*ckhead. That is what /I/ do at 1:30am when I
> > get back from the pub.
>
> Yeah, that's what happens when you leave the pub early and have time to
> kill before you get your unemployed ass to bed somewhere around 5:00.
Last I heard you were some oot-greet java monkey scrambling for the
bananas some investment bank was throwing your way.
Me, I do Lisp 24-7 unless I need some C glue to add a C++ library to a
portable, 3d, native lisp application framework.
So... which one of us is unemployed?
kt
ps. Do not spend too long on a witty comeback. The bank, aka "your
daddy", wants you in by 8am.
k
Kenneth Tilton <·······@nyc.rr.com> writes:
> Me, I do Lisp 24-7 unless I need some C glue to add a C++ library to a
> portable, 3d, native lisp application framework.
Let me know when it's been ported so that it runs on my system and so
that it draws squares without half of a segment in the wrong place.
;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, Rahul Jain <·····@nyct.net>
wrote:
> Kenneth Tilton <·······@nyc.rr.com> writes:
>
> > Me, I do Lisp 24-7 unless I need some C glue to add a C++ library to a
> > portable, 3d, native lisp application framework.
>
> Let me know when it's been ported so that it runs on my system and so
> that it draws squares without half of a segment in the wrong place.
>
> ;)
(1) Get a new graphics card.
(2) Place the old card under your pillow. While lying a-bed, the Open
Source fairy will leave a port under your pillow.
You want the Java port, right?
kt
Kenneth Tilton <·······@nyc.rr.com> writes:
> In article <··············@nyct.net>, Rahul Jain <·····@nyct.net>
> wrote:
>
>> Kenneth Tilton <·······@nyc.rr.com> writes:
>>
>> > Me, I do Lisp 24-7 unless I need some C glue to add a C++ library to a
>> > portable, 3d, native lisp application framework.
>>
>> Let me know when it's been ported so that it runs on my system and so
>> that it draws squares without half of a segment in the wrong place.
>>
>> ;)
>
> (1) Get a new graphics card.
> (2) Place the old card under your pillow. While lying a-bed, the Open
> Source fairy will leave a port under your pillow.
Why do I need a $2000 graphics card and an OS that's for high-end 3d
workstation usage to run a simple, portable application? I still have
the same Radeon 9700 Pro I had when we started this discussion.
Unfortunately, I can't run Cells. Well, I guess I could run it and get
1+ second latency on every single operation.
> You want the Java port, right?
That would probably be less portable than Cells already is... Cells
probably runs on SGI IRIX (actually, that's one of the few platforms
where it would always work correctly, since all their machines are
high-end 3d workstations), but are there any decent and recent JVMs for
it? But at least the Java port could stand a fighting chance of running
on my machine as long as you didn't try to use Java3D... but you would,
so it wouldn't run... :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, Rahul Jain <·····@nyct.net>
wrote:
> Kenneth Tilton <·······@nyc.rr.com> writes:
>
> > In article <··············@nyct.net>, Rahul Jain <·····@nyct.net>
> > wrote:
> >
> >> Kenneth Tilton <·······@nyc.rr.com> writes:
> >>
> >> > Me, I do Lisp 24-7 unless I need some C glue to add a C++ library to a
> >> > portable, 3d, native lisp application framework.
> >>
> >> Let me know when it's been ported so that it runs on my system and so
> >> that it draws squares without half of a segment in the wrong place.
> >>
> >> ;)
> >
> > (1) Get a new graphics card.
> > (2) Place the old card under your pillow. While lying a-bed, the Open
> > Source fairy will leave a port under your pillow.
>
> Why do I need a $2000 graphics card and an OS that's for high-end 3d
> workstation usage to run a simple, portable application? I still have
> the same Radeon 9700 Pro I had when we started this discussion.
The 9700 Pro? is that all? C'mon, Nancy, get a serious card in there.
The 9800 pro will give you 50% more gpix/sec, the X800 will almost
triple your output. I thought you had a job.
> Unfortunately, I can't run Cells. Well, I guess I could run it and get
> 1+ second latency on every single operation.
The only operation you need is a lobotomy. Cells is the dataflow hack.
Cello was last seen running 30fps, only partially tuned. On a frickin
laptop. You know, if you give up crack you can afford the X800.
Wait till I finish the Cello port to my G5/Radon 9800/256. Yah, baby!!!
Frank and I outlived the day, and came safe home, standing a tip-toe
over OS X (whose Glut had a bug). The Yobbos never showed, and must
think themselves accursed they were not here.
:)
kt
Kenneth Tilton <·······@nyc.rr.com> writes:
> In article <··············@nyct.net>, Rahul Jain <·····@nyct.net>
> wrote:
>
>> Why do I need a $2000 graphics card and an OS that's for high-end 3d
>> workstation usage to run a simple, portable application? I still have
>> the same Radeon 9700 Pro I had when we started this discussion.
>
> The 9700 Pro? is that all? C'mon, Nancy, get a serious card in there.
> The 9800 pro will give you 50% more gpix/sec, the X800 will almost
> triple your output. I thought you had a job.
Still not good enough. I want my GUIs to not have strange visual
artifacts, not just be fast. But how is it portable if it requires
special hardware support to be usable and even more specialized hardware
support to look clean?
>> Unfortunately, I can't run Cells. Well, I guess I could run it and get
>> 1+ second latency on every single operation.
>
> The only operation you need is a lobotomy. Cells is the dataflow hack.
Heh.
> Cello was last seen running 30fps, only partially tuned. On a frickin
> laptop. You know, if you give up crack you can afford the X800.
Cello is "partially tuned" for running on special hardware. It's not a
question of whether I can afford an X800. It's a question of whether
some guy in Poland who wants to run my application can. But why should I
give up crack when someone unemployed like you is always on it?
Actually, are I'm not sure that broken border you described on the
square was due to your OpenGL implementation and not due to excessive
quantities of crack. ;)
> Wait till I finish the Cello port to my G5/Radon 9800/256. Yah, baby!!!
> Frank and I outlived the day, and came safe home, standing a tip-toe
> over OS X (whose Glut had a bug). The Yobbos never showed, and must
> think themselves accursed they were not here.
Cool graphics hacks are always fun (especially munching squares!), but I
prefer application-worthy solutions when I'm using GUI toolkits.
:)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Cello is "partially tuned" for running on special hardware. It's not a
> question of whether I can afford an X800. It's a question of whether
> some guy in Poland who wants to run my application can.
You are confused. If you have an application with modest graphics
requirements, then your friend in Poland will be fine. If your
application is Halo, your friend's only hope is a GPU. This has nothing
to do with Cello. Except...
Cello automatically does the minimum of frames. See a recent discussion
here on how OpenGL display lists turned out to be a natural for Cells.
And it really is automatic. You just write your display logic, with no
concern for anything other than getting it right. Your code does not
have to worry about when to update what. That happens automatically, and
then a glut redisplay gets posted automatically.
In the case of the kind of simple-ass application I would expect you to
produce, nothing much ever happens, so nothing much ever needs to be
done. When they click on a tic-tac-toe box, you get a redraw on the
mousedown and one on the mouseup. Can your Polish friend's CPU handle it?
> Still not good enough. I want my GUIs to not have strange visual
> artifacts...
Still betting against OpenGL? <sigh>
Meanwhile, Cello is now happily displaying text in bitmap, pixmap,
polygon, outline, texture, and extruded polygon mode on Windows, Linux,
and OS X via AllegroCL, Lispworks, and OpenMCL.
Write any interesting Java today?
:)
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> When they click on a tic-tac-toe box, you get a redraw on the
> mousedown and one on the mouseup.
Does Cello then redraw the whole screen (with cached display
lists), or just the changed region like most toolkits would?
I'm not really familiar with OpenGL so I don't know what is
feasible there.
In article <··············@Astalo.kon.iki.fi>,
Kalle Olavi Niemitalo <···@iki.fi> wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > When they click on a tic-tac-toe box, you get a redraw on the
> > mousedown and one on the mouseup.
>
> Does Cello then redraw the whole screen (with cached display
> lists), or just the changed region like most toolkits would?
> I'm not really familiar with OpenGL so I don't know what is
> feasible there.
Just a reminder: we now have OpenGL as a serious player, with its own
GPU. Rahul's 9800 Pro runs at 380mhz and has 128mb ram because he was
too cheap to spring for 256mb. So... yes, /OpenGL/ draws the whole
screen with its own GPU. Cello just says:
(gl-call-list (display-list window))
Cello achieves that by using compiled display lists for everything, as
well as textures wherever possible, since OpenGL will load those into
the GPU memory and keep them there as long as possible to avoid the
expense of moving them from CPU memory to the GPU.
[As with Lisp, one has to make a certain effort as a developer to get
the most out of OpenGL, but the opportunities are there, well-designed,
and not that hard to figure out.]
Meanwhile, OpenGL makes display lists insanely efficient and
programmer-friendly by dispatching nested lists dynamically. Think
"Lisp". I can change a function called by a running application and get
the new behavior the first time the function gets called after I
recompile it.
If every tic-tac-toe square has its own display list, the flow goes like
this:
the app gets a mouse-up event
one of the squares decides it should draw, say, an "X"
the display list for the square gets rebuilt
a redisplay gets posted
the app gets a display event
the app tells openGL to play the one display list for the window
The key is that a display list is a first-class object referenced by
name, so the composite list which includes the square does not need to
be rebuilt when the list for the square gets rebuilt -- the latter will
get picked up dynamically by its container list just like a modified
Lisp function gets picked up by previously compiled callers.
Two very nice things here. First, in the bad ol' days of update regions,
the application had to translate twice, once from component to global
window region, to trigger an update/paint event, and a second time to
translate from update region to component. That is so much fun. Not!!!
Every bit of screen schmutz you have seen using bitmapped graphics comes
from the damn near impossibility of getting that right.
Second, update regions are "dumb". Suppose I have several things masked
in part by something which now disappears. Well, all the things masked,
however little, must be re-rendered. With display lists, the display
list of the container of the lost thing must be re-built not to include
calling that thing's list, but nothing else. And that process will be as
fast as iterating over the remaining things and /compiling/ (not
executing) a call of each list, which is nothing but an integer. zoom
zoom zoom.
kenny
ps. cl-openal has now been ported to OS X. :) That just leaves
ImageMagick. kt
That's interesting. Can it do clipping? Say, you have a something like
a star-shaped polygon with rotating text as a child node, is it
possible to have the child clipped against the parent? I don't
remember if there was a straightforward way to do that in GL. Also, in
this case does not the rotating child node's (or its parent node's?)
DL have to be recompiled every cycle, that would seem like a expensive
operation, especially if have a lot of them spinning around. Do you
use nested display lists all the way down or are there parts of the
tree which are rendered dynamically? Just curious...
In article <····························@posting.google.com>,
·······@yahoo.com (tkneste) wrote:
> That's interesting. Can it do clipping?
Out the wazoo. glScissor, glClipPlane, glStencilMask, and of course good
ol' faux clipping via occlusion.
> Say, you have a something like
> a star-shaped polygon with rotating text as a child node, is it
> possible to have the child clipped against the parent? I don't
> remember if there was a straightforward way to do that in GL.
For an irregular shape I think you would be using the Stencil functions.
I have not played with those, but they allow pixel-wise clipping.
> Also, in
> this case does not the rotating child node's (or its parent node's?)
> DL have to be recompiled every cycle, that would seem like a expensive
> operation, especially if have a lot of them spinning around.
You would rebuild the parent d/l. To be efficient, the parent star shape
should build and remember d/ls dedicated to the stencil and background
(mebbe they can be the same). Then you can rebuild the list like this:
glnewlist
glcalllist <background d/l>
glcalllist <stencil d/l>
foreachchild:
with matrix
rotate
translate
glcalllist <child d/l>
glendlist
Note that when building a list in compile mode, OpenGL is not doing any
rendering. It is simply recording the sequence of calls and parameters.
This is why glcalllist is dynamic ala Lisp -- the list does not get
played for real until glcalllist occurs in a rendering context.
So the above logic does insanely little work.
> Do you
> use nested display lists all the way down or are there parts of the
> tree which are rendered dynamically? Just curious...
"all display lists all the time" (tm)
Note that, once you call a list on container, that is that. There is no
callback mechanism. So you can start at the top of the scene graph
without a list and work your way down. At any level you can mingle DLs
with direct rendering, but once you hit a list, that is that.
Hey, what's an article from Kenny without a report of conquests new? We
made a deal with the devil and used the ImageMagick binaries which
require X11, though we never hit that functionality.
cl-magick, cl-ftgl, cl-openal, and cl-opengl (natch) are now humming
away nicely on OS X under OpenMCL. Stay tuned for the screenshots. :)
kenny
Kenneth Tilton <·······@nyc.rr.com> writes:
> glnewlist
[...]
> glendlist
Aha, so that's how OpenGL display lists are made. If an error
occurs while a display list is being defined, do you use
UNWIND-PROTECT to call glendlist anyway, or is there a GL
function that just aborts the whole thing at top level?
Kalle Olavi Niemitalo wrote:
> Kenneth Tilton <·······@nyc.rr.com> writes:
>
>
>> glnewlist
>
> [...]
>
>> glendlist
>
>
> Aha, so that's how OpenGL display lists are made. If an error
> occurs while a display list is being defined, do you use
> UNWIND-PROTECT to call glendlist anyway, or is there a GL
> function that just aborts the whole thing at top level?
Error-handling? I am supposed to worry about error-handling? :)
(a) OpenGL does nothing in re errors... uh, I lie. It will set an error
code which can be interrogated.
(b) OK, you are talking about a fault-tolerant system? Good thinking.
And this, as we all know, is where Lisp rocks. And why Lisp is a great
platform for OpenGL, because we can take all the unwind boilerplate and
stick it in a WITH-DISPLAY-LIST macro.
Without that, since nested glnewlist calls are a no-no, and with a
glnewlist left twisting slowly in the wind, the app would be toast
since... well, hang on, my guess is that the next call to glnewlist
would fail as recursive, but with my usual level of error-checking I
would gleefully render away the second list into the dangling list, then
end that list with the glendlist call intended for the second list.
At this point the first list would be garbage (part of the first and
allof the second rendered under the partial state set up by the first)
and the second list would be unchanged. (glnewlist is a misnomer; first
one allocates lists with (I forget), then one calls glnewlist to begin
writing to the list ID parameter).
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
KT> [...] set up by the first) and the second list would be
KT> unchanged. (glnewlist is a misnomer; first one allocates lists
KT> with (I forget), then one calls glnewlist to begin writing to
KT> the list ID parameter).
glgenlists reserves the ID I believe. Real memory allocation happens
by opaque magic as you call things inside a glnewlist/glendlist pair.
I never figured out if the engine actually leaks memory if you
glnewlist more than once on an ID w/o gldeletelisting it. I assumed
it would so I code accordingly. What do you do?
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
>
>
> KT> [...] set up by the first) and the second list would be
> KT> unchanged. (glnewlist is a misnomer; first one allocates lists
> KT> with (I forget), then one calls glnewlist to begin writing to
> KT> the list ID parameter).
>
> glgenlists reserves the ID I believe.
That's it.
> Real memory allocation happens
> by opaque magic as you call things inside a glnewlist/glendlist pair.
> I never figured out if the engine actually leaks memory if you
> glnewlist more than once on an ID w/o gldeletelisting it.
That struck me as putting the list ID back in the available pool, such
that some subsequent call to glGenLists might return it to a second
user. Not good. But you have been getting away with it? Maybe glNewList
implicitly reserves?
> I assumed
> it would so I code accordingly. What do you do?
Gleefully re-using the ID without worrying about it. But I have had a
puzzling performance behavior which looks like GC: the spinning shape
spins and spins at 30+ fps then freezes or moves like once a second for
a few seconds, then takes off again. I do not see CL gc-ing.
Could it be that OpenGl needs a better GC algorithm? ie, it is not
leaking memory, but i am setting myself up for a GC-ish hit by letting
OpenGL pile up the garbage?
I will try the glDeleteLists trick to see if this clears up the pause.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
> I will try the glDeleteLists trick to see if this clears up the pause.
Nope.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
>> I will try the glDeleteLists trick to see if this clears up the
>> pause.
KT> Nope.
Hmm, no change in memory usage at all? That doesn't sound right. Oh
btw what I do with disp. lists is kosher:
http://www.opengl.org/resources/faq/technical/displaylist.htm#0030
cheers,
BM
In article <··············@p4.internal>,
Bulent Murtezaoglu <··@acm.org> wrote:
> >>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
> [...]
> >> I will try the glDeleteLists trick to see if this clears up the
> >> pause.
>
> KT> Nope.
>
> Hmm, no change in memory usage at all? That doesn't sound right.
I think we have misunderstood each other. I have a scene graph with an
unchanging population. Each node has its own display list. Container
nodes render some decoration, then call their children's lists.
I was simply calling glnewlist on the same list name for a widget any
time it changed appearance. I call gldeletelist on each list as a node
leaves the scene graph, here only when I close the whole window.
i thought you were saying glnewlist might be dumb and not notice that
the list already used some storage, and so you called gldeletelist
before reusing a list (by calling glnewlist). That would be pretty bad
of glnewlist, and I guess all we are saying is that it does clean up
when glnewlist is called on an existing list.
I am not leaving lists altogether undeleted.
kt
>>>>> "KT" == Kenneth Tilton <·······@nyc.rr.com> writes:
[...]
KT> I think we have misunderstood each other.
It is more likely that I misspoke.
KT> I have a scene graph
KT> with an unchanging population. Each node has its own display
KT> list. Container nodes render some decoration, then call their
KT> children's lists.
This much is fine.
KT> I was simply calling glnewlist on the same list name for a
KT> widget any time it changed appearance. I call gldeletelist on
KT> each list as a node leaves the scene graph, here only when I
KT> close the whole window.
This is what I was not sure you were doing.
KT> i thought you were saying glnewlist might be dumb and not
KT> notice that the list already used some storage, and so you
KT> called gldeletelist before reusing a list (by calling
KT> glnewlist). [...]
I was! But turns out it isn't. (The man page doesn't explicitly
say so but Paul Martz does:
http://groups.google.com/groups?threadm=9884nl%247j%241%40fcnews.fc.hp.com
Lovely. Thanks Kenny.
BM
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
KT> That struck me as putting the list ID back in the available
KT> pool, such that some subsequent call to glGenLists might
KT> return it to a second user. Not good. But you have been
KT> getting away with it? Maybe glNewList implicitly reserves?
I am scared to look at that bit of code right now, but I think I do
nothing that would require getting away with anything. That is, I
don't reuse the ID unless glgenlists happens to give it to me again.
But if I don't need that list any more, I gldelete it. (Um, actually
I might be fibbing: I use the same ID on purpose when I use display
list IDs as hooks to hang other lists from. So I use a
(gl-call-list foo)
inside a big display list and change the foo list w/o recompiling
the big list. This comes in handy for changing transformations and
stuff.)
[...]
KT> Gleefully re-using the ID without worrying about it.
Well you probably code at 50x my speed, so you don't have time to worry!
KT> But I
KT> have had a puzzling performance behavior which looks like GC:
KT> the spinning shape spins and spins at 30+ fps then freezes or
KT> moves like once a second for a few seconds, then takes off
KT> again. I do not see CL gc-ing.
Hah. The driver is probably swapping your garbage out of GPU memory to
CPU memory using some kind of LRU criterion.
KT> Could it be that OpenGl needs a better GC algorithm? ie, it is
KT> not leaking memory, but i am setting myself up for a GC-ish
KT> hit by letting OpenGL pile up the garbage?
I don't think OpenGl _has_ a GC algorithm. That's why I was worrying
about list allocations and such.
KT> I will try the glDeleteLists trick to see if this clears up
KT> the pause.
Please report back!
cheers,
BM
In article <··············@p4.internal>,
Bulent Murtezaoglu <··@acm.org> wrote:
> >>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
> [...]
> KT> That struck me as putting the list ID back in the available
> KT> pool, such that some subsequent call to glGenLists might
> KT> return it to a second user. Not good. But you have been
> KT> getting away with it? Maybe glNewList implicitly reserves?
>
> I am scared to look at that bit of code right now, but I think I do
> nothing that would require getting away with anything. That is, I
> don't reuse the ID unless glgenlists happens to give it to me again.
Ooooooh. i thought you were doing a deletelist 42 just before a newlist
42 to make sure opengl was not leaking.
But I cannot change display lists for a given node in a scene graph,
because my container assumes it is not changing, ie, it does not rebuild
its list when I change appearance, because the contract says my display
list name will not change. That is where the efficiency comes from. As
you describe here:
> But if I don't need that list any more, I gldelete it. (Um, actually
> I might be fibbing: I use the same ID on purpose when I use display
> list IDs as hooks to hang other lists from. So I use a
>
> (gl-call-list foo)
>
> inside a big display list and change the foo list w/o recompiling
> the big list. This comes in handy for changing transformations and
> stuff.)
That is how Cello works all the time, top to bottom. It is
all-display-lists-all-the-time over here.
>
> [...]
> KT> Gleefully re-using the ID without worrying about it.
>
> Well you probably code at 50x my speed, so you don't have time to worry!
You just need more monkeys.
:)
kt
Kenneth Tilton <·······@nyc.rr.com> writes:
> Rahul's 9800 Pro runs at 380mhz and has 128mb ram because he was
> too cheap to spring for 256mb.
I'm still using a Radeon 64 DDR that I once bought for >1000 FIM
(now 168 EUR).
> So... yes, /OpenGL/ draws the whole screen with its own GPU.
Does that work reasonably fast if using X11 over a network?
I presume it can be implemented efficiently, if OpenGL already
makes a distinction between CPU and GPU data, but I don't know
how good the existing implementations are. IIRC, XFree86 had
trouble with this.
> Second, update regions are "dumb". Suppose I have several things masked
> in part by something which now disappears. Well, all the things masked,
> however little, must be re-rendered.
That rendering can be very fast if you know the update region and
cache the rendered contents of containers, like Borland's Turbo
Vision did in text modes. I hear such caching is now getting
fashionable again, for fancy transparency effects (which I guess
your display lists provide for free).
In article <··············@Astalo.kon.iki.fi>,
Kalle Olavi Niemitalo <···@iki.fi> wrote:
> Kenneth Tilton <·······@nyc.rr.com> writes:
>
> > Rahul's 9800 Pro runs at 380mhz and has 128mb ram because he was
> > too cheap to spring for 256mb.
>
> I'm still using a Radeon 64 DDR that I once bought for >1000 FIM
> (now 168 EUR).
We better take up a collection for you. :) But of course, my point is
that I do not think you run faster by yanking even the slowest GPU and
making your CPU do the work via MesaGL.
Rahul somehow thought that using Cello /requires/ one to do an insane
amount of rendering. No, your app decides that. Cello just optimizes
rendering, even if you are using MesaGL, by updating the bare minimum at
each frame. Whatever GPU you have is just gravy.
>
> > So... yes, /OpenGL/ draws the whole screen with its own GPU.
>
> Does that work reasonably fast if using X11 over a network?
> I presume it can be implemented efficiently, if OpenGL already
> makes a distinction between CPU and GPU data, but I don't know
> how good the existing implementations are. IIRC, XFree86 had
> trouble with this.
I fear I know nothing of the issues. From first principles, I should
think handling an update event on a remote display by transmitting
nothing more than: "(gl-call-list 42)" would be efficient. I guess the
problem is talking to the GPU while building lists? From first
principles, it is hard to imagine anything more efficient than simply
sending all the gl calls and their parameters over a pipe, especially
when display lists and textures let you move stuff to the GPU once and
then reuse to your heart's content.
>
> > Second, update regions are "dumb". Suppose I have several things masked
> > in part by something which now disappears. Well, all the things masked,
> > however little, must be re-rendered.
>
> That rendering can be very fast if you know the update region and
> cache the rendered contents of containers,...
Sounds like a plan.
> like Borland's Turbo
> Vision did in text modes. I hear such caching is now getting
> fashionable again, for fancy transparency effects (which I guess
> your display lists provide for free).
Display lists are great, but in 3D and with lighting there is still the
rest of the pipeline to be executed, such as bitwise occlusion and
lighting application. So if you are just doing 2D and blitting bits into
the graphics buffer you can go a lot faster. otoh, turn off lighting and
do boring 2D graphics in OpenGL and you scream as well.
Rahul is just a java monkey working for some bank, so he is unaware of
things like games and especially MMORPGs, which have actually cut deeply
into television viewing by males of certain age groups. That means there
will be all the money in the world going into GPUs for years to come.
I am a non-gamer myself, but my drinking buddies down at the pub are all
addicted, and just playing with OpenGL and OpenAL enough to do my
Amazing Spinning Shapes demo for Cello has me feeling like I just
discovered programming and the hires graphics of the Apple II.
OpenGL roolz, and Lisp is about to become the premier cross-platform
OpenGL development platform. Yah, baby!!
kt
>> Does that work reasonably fast if using X11 over a network?
>> I presume it can be implemented efficiently, if OpenGL already
>> makes a distinction between CPU and GPU data, but I don't know
>> how good the existing implementations are. IIRC, XFree86 had
>> trouble with this.
>
Yep. See below.
> I fear I know nothing of the issues. From first principles, I should
> think handling an update event on a remote display by transmitting
> nothing more than: "(gl-call-list 42)" would be efficient.
That would be the theory. Unfortunately, when I last checked, indirect
OpenGL coming in off the network on the widely-used XFree and
derivatives could not be accelerated even on XFree-supported platforms
with hardware-accelerated direct rendering (i.e. mostly Linux and BSD).
Basically, in XFree, anything that wasn't direct-rendered couldn't be
hardware rendered due to the code paths for direct and indirect being
separate - everything OpenGL coming in indirect was software-rendered
(i.e. handed off to Mesa by the GLcore XFree module instead of the
hardware drivers), even though (with different code), it could have
been hardware-rendered.
This was (almost certainly still is) a defect of the particular
implementation, not of OpenGL+X in general.
So anyway, it was an architectural problem that was "on the roadmap" to
be fixed at some stage back when "Precision Insight" was working on the
XFree DRI, but I haven't looked at the issue recently.
*** [N.B. if you are looking for new X developments for linux
workstations these days, go to freedesktop.org, not XFree.org
If you've been living in a cave isolated from the linux world for the
past two years, there was a hostile fork due to an annoying license
change and general developer dissatisfaction with the direction of
XFree. The freedesktop.org fork has pretty much won.]
I would guess that hardware-accelerated indirect rendering would
probably be considered a useful feature by the freedesktop crowd (one
of the non-licensing reasons for the freedesktop fork was because of
apparent XFree reluctance to add features), so I would guess they
wouldn't be actively opposed to it (as some might conceivably be due to
e.g. increased code complexity), but it would not necessarily be a high
priority for them.
Rahul Jain <·····@nyct.net> writes:
> [.....] It's a question of whether some guy in Poland who wants to run my
> application can. [.....]
> --
> [.....] Quantum Mechanicist
Is your friend's name Marek?
Regards, Szymon.
Kenny Tilton wrote:
> Gareth McCaughan wrote:
...
>> Yes, they did. And at the "(1 ..." in the Lisp code.
>> I'm sorry if you think taking a couple of seconds to
>> spot a typo at 1.30am local time is proof of incompetence.
>
> Naw, I was just being a d*ckhead. That is what /I/ do at 1:30am when I
> get back from the pub.
Fair enough. :-)
--
Gareth McCaughan
.sig under construc
On Wed, 10 Nov 2004 19:57:52 +0000, Kenneth Tilton wrote:
> In article <···············@pcepsft001.cern.ch>,
>
>> (case x
>> (1 'a)
>> (2 'b))
>
> I think you mean:
>
> (case x
> (1
> 'a)
> (2
> 'b))
>
> :)
>
> kt
Not according to the examples in the HyperSpec:
http://www.lispworks.com/reference/HyperSpec/Body/m_case_.htm
;-)
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
"Computer Whizz" <···········@hotmail.com> writes:
> Now here it is much better for C/C++ IMO.
> parameters are passed using the ()'s to group them together, and the
> function outside. While in Lisp, the function and parameters are in exactly
> the same place.
No, the operator is in the beginning of the evaluated form and the
parameters are the rest of it. I can't see how that's "the same place"
any more than the reception is in the same place as the janitor's
closet. They're in the same building, sure, but the reception is right
at the entrance.
> For me it's exactly like writing this post but removing all the comma's,
> full stops etc and just leaving the words and spaces - the flow seems to
> dissapear.
English has a different syntax, and an amazingly complex one. The flow
of lisp code is determined by the parens, which humans infer using the
indentation applied by the editor.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <·····@nyct.net> wrote in message
···················@nyct.net...
> "Computer Whizz" <···········@hotmail.com> writes:
>
>> Now here it is much better for C/C++ IMO.
>> parameters are passed using the ()'s to group them together, and the
>> function outside. While in Lisp, the function and parameters are in
>> exactly
>> the same place.
>
> No, the operator is in the beginning of the evaluated form and the
> parameters are the rest of it. I can't see how that's "the same place"
> any more than the reception is in the same place as the janitor's
> closet. They're in the same building, sure, but the reception is right
> at the entrance.
>
Yes - but "our" buildings have walls between the rooms.
(OK - I sound like an ass a little there... Still, Lisp programmers seem all
happy and ine saying "I can read Lisp code OK" when it's not you - but the
editor reading it out for you.
I might use a simple syntax highlisghter to show variables/functions/static
text but I can just as easily judge and evaluate raw C/C++/most other
languages - even if they've been typed by a monkey with no actual use of the
tab key... )
>> For me it's exactly like writing this post but removing all the comma's,
>> full stops etc and just leaving the words and spaces - the flow seems to
>> dissapear.
>
> English has a different syntax, and an amazingly complex one. The flow
> of lisp code is determined by the parens, which humans infer using the
> indentation applied by the editor.
>
> --
> Rahul Jain
> ·····@nyct.net
> Professional Software Developer, Amateur Quantum Mechanicist
That's where they differ more prominently! C/C++/whatever IS (at least in my
mind) very similar to English. It has words following each other in a
"flow".
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <···········@hotmail.com> writes:
> "Rahul Jain" <·····@nyct.net> wrote in message
> ···················@nyct.net... > "Computer Whizz"
> <···········@hotmail.com> writes: > No, the operator is in the
> beginning of the evaluated form and the > parameters are the rest of
> it. I can't see how that's "the same place" > any more than the
> reception is in the same place as the janitor's > closet. They're in
> the same building, sure, but the reception is right > at the
> entrance.
> >
>
> Yes - but "our" buildings have walls between the rooms.
> (OK - I sound like an ass a little there... Still, Lisp programmers seem all
> happy and ine saying "I can read Lisp code OK" when it's not you - but the
> editor reading it out for you.
> I might use a simple syntax highlisghter to show variables/functions/static
> text but I can just as easily judge and evaluate raw C/C++/most other
> languages - even if they've been typed by a monkey with no actual use of the
> tab key... )
Obfuscated C is just as bad as obfuscated Lisp. It is amazing to me
that you make these claims about Lisp without having gotten a good
deal of experiences actually using it.
> >> For me it's exactly like writing this post but removing all the comma's,
> >> full stops etc and just leaving the words and spaces - the flow seems to
> >> dissapear.
> >
> > English has a different syntax, and an amazingly complex one. The flow
> > of lisp code is determined by the parens, which humans infer using the
> > indentation applied by the editor.
> >
> > --
> > Rahul Jain
> > ·····@nyct.net
> > Professional Software Developer, Amateur Quantum Mechanicist
>
> That's where they differ more prominently! C/C++/whatever IS (at least in my
> mind) very similar to English. It has words following each other in a
> "flow".
If what way is Lisp different?
Grem
"Computer Whizz" <···········@hotmail.com> writes:
> "Rahul Jain" <·····@nyct.net> wrote in message
> ···················@nyct.net...
>> "Computer Whizz" <···········@hotmail.com> writes:
>>
>>> Now here it is much better for C/C++ IMO.
>>> parameters are passed using the ()'s to group them together, and the
>>> function outside. While in Lisp, the function and parameters are in
>>> exactly
>>> the same place.
>>
>> No, the operator is in the beginning of the evaluated form and the
>> parameters are the rest of it. I can't see how that's "the same place"
>> any more than the reception is in the same place as the janitor's
>> closet. They're in the same building, sure, but the reception is right
>> at the entrance.
>>
>
> Yes - but "our" buildings have walls between the rooms.
So do ours. I hope you see that the elements of the form are separated
by somehow...
> (OK - I sound like an ass a little there... Still, Lisp programmers seem all
> happy and ine saying "I can read Lisp code OK" when it's not you - but the
> editor reading it out for you.
> I might use a simple syntax highlisghter to show variables/functions/static
> text but I can just as easily judge and evaluate raw C/C++/most other
> languages - even if they've been typed by a monkey with no actual use of the
> tab key... )
That's not a problem. I have an editor that can indent properly. But how
easily do you spot the
if (foo());
do_whatever();
something_else();
problem?
>> English has a different syntax, and an amazingly complex one. The flow
>> of lisp code is determined by the parens, which humans infer using the
>> indentation applied by the editor.
>
> That's where they differ more prominently! C/C++/whatever IS (at least in my
> mind) very similar to English. It has words following each other in a
> "flow".
You mean that there's no nesting? No well-defined structure? Lisp code
flows. You just look at the banks of the river and ignore the actual
river that's flowing. The banks merely shape the flow of the river.
Don't stare at them.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Computer Whizz" <···········@hotmail.com> writes:
> And no - the trouble with Lisp to begin with is trying to find the "core" ()
> and work outwards from there - kind of backward to my natural way of
> thinking... Like reading right-to-left.
> The one's I've quoted are short.
Not even the compiler is supposed to read your code from the inner
parens and work out. The compiler must arrange for evaluation of the
code from left to right, as this is how the code is read (being based on
the English language).
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Andr� Thieme wrote:
> Frank Buss schrieb:
>
>> Andr� Thieme <······························@justmail.de> wrote:
>>
>>
>>>C++ does not have complex numbers, Lisp does, and you write them down
>>>this way:
>>>#C(real i)
>>>for example #C(3 3)
>>
>>
>> C++ has complex numbers, defined as a template:
>>
>> http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html
>>
>
> Yes, that's right. However, they are still not so easy accessible like
> the infix operators in our earlier discussions. Therefore complex
> numbers would need to be included in the base language. If you need them
> for just one part in your program, then do this in C++:
> (+ #C(3 4) 25)
>
At this point I'd like to point out that, although complex numbers are part
of the standad CL library, if they weren't, it would be fairly easy to add
them.
Add a "complex" type, shadow the built-in arithmetic functions to make them
understand it, add a read-macro to make the #C(n m) syntax work... all in
all, not terribly much work, and you'd end up with the exact same syntax
that is used for the (built-in) complex types we have today.
Of course, the concept of a built-in type does tend to blur somewhat when a
simple two-key chord lets me look at the compiler's/library's definition of
any given function.
The point is, if someone needs anything CL lacks, they can simply add it. If
you need matrix-capable functions you can write them yourself, and they'll
work just like the built-in arithmetic functions even if you want to call
them something different.
That, for me, is one of the greatest features of CL.
Svein Ove Aas <·········@aas.no> wrote in message news:<············@services.kq.no>...
> Andr� Thieme wrote:
>
> > Frank Buss schrieb:
> >
> >> Andr� Thieme <······························@justmail.de> wrote:
> >>
> >>
> >>>C++ does not have complex numbers, Lisp does, and you write them down
> >>>this way:
> >>>#C(real i)
> >>>for example #C(3 3)
> >>
> >>
> >> C++ has complex numbers, defined as a template:
> >>
> >> http://www.roguewave.com/support/docs/sourcepro/stdlibref/complex.html
> >>
> >
> > Yes, that's right. However, they are still not so easy accessible like
> > the infix operators in our earlier discussions. Therefore complex
> > numbers would need to be included in the base language. If you need them
> > for just one part in your program, then do this in C++:
> > (+ #C(3 4) 25)
> >
> At this point I'd like to point out that, although complex numbers are part
> of the standad CL library, if they weren't, it would be fairly easy to add
> them.
Also, I'd like to point out that some things you can do with Lisp
complex numbers are difficult in C++.
Firstly, if you use CLOS methods for arithmetic operations, you can
support all of the combinations. C++ can only do this statically,
because dynamic dispatch (virtual functions) is done on what is
effectively the leftmost argument of a method (i.e. the object, or
``this'' pointer).
In Lisp, some block of code can receive two numbers whose type is not
statically apparent, and call an operation. The right operation is
selected based on both their types. This is called multiple dispatch:
the method selection takes into account the type of all objects---the
run-time type---somewhat analogously to how C++ overload resolution
does it over static types.
There are hacks to do this in C++ such as the Visitor Pattern.
Dynamically dispatch on the left argument to get to implementation i
of virtual function X, which then dynamically dispatches an
implementation of Y_i on the right argument. If you want three
arguments, the complexity explodes further; you then want to write a
Perl script to just generate the tedious C++ from a condensed spec.
Secondly, the Lisp numeric type system incorporates the idea that
value influences type. For instance, a complex number whose imaginary
part is zero is a real number. Or a rational number whose denominator
is one has integer type. The return value of an arithmetic computation
does not have some fixed declared type; the type is determined by the
value that is produced. If you divide 2 and 3, you get the rational
2/3. If you divide 4 by 2 using exactly the same function, you get
integer 2. Take the square root of -1 with (sqrt -1) and you get the
complex number #c(0 1). And so on.
Lastly, the two components of a complex number are not necessarily
real numbers. They can be fixed integers or bignums. This is largely
transparent.
For example, suppose you add these two complex numbers like this:
(+ #c(-1 -1) #c(1 1))
The result is 0. That is, to say, *integer* zero. Not a complex zero,
or real zero. The real and imaginary parts of these complexes are
integers, and they all nicely cancel out to produce a pure zero.
These types of robust properties of the Lisp numeric tower make it
useful for solving numeric problems, with clear, concise code in which
The Right Thing happens.
> I like the more natural way than that used in Lisp - that's all.
'Natural' here is a synonym for 'conforms to my unreasoning prejudices'.
In other words, you are rejecting the syntax because it's different
from what you're used to, and that difference is bubbling up out
of your unexamined subconscious as a felling of 'unnaturalness'.
Paul
Computer Whizz wrote:
>>(+ 2/3 2/3 1/3) => 5/3
> Jesus!
> *covers eyes*
> It took me a couple of minutes to decipher that...
If the syntax of "(+ 2/3 2/3 1/3)" confuses you, then I expect you will
have massive problems when you encounter C++'s templates, parameterized
types, and STL!! :-) :-) :-)
But I expect those are pleasures that still lie in store for you!
For instance, cam you understand the following easily?
It's just a random snippet from yesterday's std C++ list.
template <typename E, typename T>
friend std::basic_ostream< E, T>& operator<<
( std::basic_ostream< E, T>& os, const A& obj)
If you can, but still experience difficulty with "(+ 2/3 2/3 1/3)", then
I expect you have a mind that works in a very interesting way....
"Alex Gian" <········@junkmail.for.alex.com> wrote in message
······················@fe1.news.blueyonder.co.uk...
> Computer Whizz wrote:
>>>(+ 2/3 2/3 1/3) => 5/3
>> Jesus!
>> *covers eyes*
>> It took me a couple of minutes to decipher that...
>
> If the syntax of "(+ 2/3 2/3 1/3)" confuses you, then I expect you will
> have massive problems when you encounter C++'s templates, parameterized
> types, and STL!! :-) :-) :-)
>
> But I expect those are pleasures that still lie in store for you!
> For instance, cam you understand the following easily?
> It's just a random snippet from yesterday's std C++ list.
>
> template <typename E, typename T>
> friend std::basic_ostream< E, T>& operator<<
> ( std::basic_ostream< E, T>& os, const A& obj)
>
> If you can, but still experience difficulty with "(+ 2/3 2/3 1/3)", then I
> expect you have a mind that works in a very interesting way....
Why do people always think it's the easiest, fraction part of the original
post I referred to?
Simply because I replied right at the end? Perhaps it's reading that Lisp,
meaning the middle to the last then the first - or some other peculiarity?
*dodges flames from last comment*
And I understand most of that C++ statement, as I haven't fully covered
Types yet... I also need to do some practice as I've only compiled a handful
of my own dodgy code.
--
=========
Comp Whizz
=========
(The C++ beginner)
Computer Whizz wrote:
>
> "Alex Gian" <········@junkmail.for.alex.com> wrote in message
> ······················@fe1.news.blueyonder.co.uk...
>> Computer Whizz wrote:
>>>>(+ 2/3 2/3 1/3) => 5/3
>>> Jesus!
>>> *covers eyes*
>>> It took me a couple of minutes to decipher that...
>>
>> If the syntax of "(+ 2/3 2/3 1/3)" confuses you, then I expect you will
>> have massive problems when you encounter C++'s templates, parameterized
>> types, and STL!! :-) :-) :-)
>>
>> But I expect those are pleasures that still lie in store for you!
>> For instance, cam you understand the following easily?
>> It's just a random snippet from yesterday's std C++ list.
>>
>> template <typename E, typename T>
>> friend std::basic_ostream< E, T>& operator<<
>> ( std::basic_ostream< E, T>& os, const A& obj)
>>
>> If you can, but still experience difficulty with "(+ 2/3 2/3 1/3)", then
>> I expect you have a mind that works in a very interesting way....
>
> Why do people always think it's the easiest, fraction part of the original
> post I referred to?
> Simply because I replied right at the end? Perhaps it's reading that Lisp,
> meaning the middle to the last then the first - or some other peculiarity?
> *dodges flames from last comment*
>
> And I understand most of that C++ statement, as I haven't fully covered
> Types yet... I also need to do some practice as I've only compiled a
> handful of my own dodgy code.
>
Well, he didn't *have* to write it that way; I find it overly complex
myself, no pun intended. The (complex) function dynamically constructs
complex numbers, but when it's done with constants, I'd prefer something
like this:
(+ #C(3 3) #C(3 -3) 3) => 9
It's still a bit confusing, but I challenge you to come up with anything
simpler in C++. More usefully, the compiler will constant-fold this down to
9 in the first place (function calls or no function calls), whereas the C++
compiler I tried it in notably didn't.
Computer Whizz wrote:
> And I understand most of that C++ statement, as I haven't fully covered
> Types yet... I also need to do some practice as I've only compiled a handful
> of my own dodgy code.
>
Good luck with your C++, anyway.
When you get to the standard C++ lbraries (STL), you may find it helpful
to study the influence that Lisp had on them.
I know it helped me undestand them better...
--
My apologies for not leaving a handy e-mail address for spammers.
Use alex_gian ATT yahoo Decimal cawm (if you must)
You know how to compose this...
Szymon <············@o2.pl> writes:
> Petter Gustad <·············@gustad.com> writes:
>
> > [.....]
>
> > (+ (complex 3 3) (complex 3 -3) 3) => 9
>
> why not
>
> (+ #C(3 3) #C(3 -3) 3)
I did not want to introduce a new syntax (i.e. a reader macro) and
confuse the OP (maybe suggest that I had written C# backwards :-). It
appears that he was confused enough already. Hence I chose to use the
complex function since it represents the same syntax as he had been
shown earlier in the thread, even though it's more verbose.
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?
Sashank Varma <····@vanderbilt.edu> writes:
> 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.
You surely mean in the sixties.
Andreas
--
Wherever I lay my .emacs, there's my $HOME.
"Computer Whizz" <···········@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�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
[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.
--
······@flippac.org
"Philippa Cowderoy" <······@flippac.org> wrote in message
·····································@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.
>
> --
> ······@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
=========
On Thu, 28 Oct 2004, Computer Whizz wrote:
>
> "Philippa Cowderoy" <······@flippac.org> wrote in message
> ·····································@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.
--
······@flippac.org
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
"Andr� Thieme" <······························@justmail.de> wrote in message
·················@ulric.tng.de...
> Computer Whizz schrieb:
>
>>
>> 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
In C you'd get a type mismatch or the fact that the correct parameters
aren't passed... But if there's a variable named xy that's passed to a
function with variable... I'll just stop myself there shall I...
"...and if we went to the moon and back, and added 3 to the square root
of..."
I'll just say that I find C syntax easier to use and that's that.
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <···········@hotmail.com> writes:
> "Andr� Thieme" <······························@justmail.de> wrote in message
> ·················@ulric.tng.de...
> > Computer Whizz schrieb:
> >
> >>
> >> 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
>
> In C you'd get a type mismatch or the fact that the correct parameters
> aren't passed... But if there's a variable named xy that's passed to a
> function with variable... I'll just stop myself there shall I...
> "...and if we went to the moon and back, and added 3 to the square root
> of..."
Its not clear what would happen. Does f() have a declaration? Is xy
a variable or a function? If a function, does it have a declaration?
And what about z?
A Lisp compiler will give a number of warnings about unrecognized
symbols and mismatched/missing parameters in the scenario- without the
need of any additional context that a reader will need to decypher
what a C compiler will do.
> I'll just say that I find C syntax easier to use and that's that.
Spend some time with Lisp and you'll find C syntax isn't "easier".
And really, you can't honestly make that statement until you're
familiar with both anyhow.
Gregm
Computer Whizz schrieb:
> "Andr� Thieme" <······························@justmail.de> wrote in
message ·················@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
Andr� Thieme <······························@justmail.de> wrote:
> But imagine to do this in C++:
> foo(+, 10, 15);
you can do something like this in C++ with templates and predicates, but it
doesn't look so simple as in Lisp:
http://www.devx.com/tips/Tip/12955
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss schrieb:
> Andr� Thieme <······························@justmail.de> wrote:
>
>
>>But imagine to do this in C++:
>>foo(+, 10, 15);
>
>
> you can do something like this in C++ with templates and predicates, but it
> doesn't look so simple as in Lisp:
>
> http://www.devx.com/tips/Tip/12955
Noone said that such a thing is not possible in a turing complete
programming language. We are discussing about how complicate Lisp is,
because you usually don't write 10*3+4 but (+ (* 10 3) 4). If this is
complicated, what is foo(+, 10, 15) in that case?
Andr�
--
http://tinyurl.com/64x7y
Andr� Thieme <······························@justmail.de> wrote:
> Noone said that such a thing is not possible in a turing complete
> programming language. We are discussing about how complicate Lisp is,
> because you usually don't write 10*3+4 but (+ (* 10 3) 4). If this is
> complicated, what is foo(+, 10, 15) in that case?
a nice example I've wrote some months ago to compare C++ and Lisp. The
C++ version:
template <class T>
struct SquaredSum {
T operator()(const T& sum, const T& next) const {
return sum + next * next;
}
};
typedef vector<double> DoubleVector;
DoubleVector v;
v.push_back(-1.2);
v.push_back(0.99);
v.push_back(23);
DoubleVector::value_type length = accumulate(v.begin(), v.end(),
DoubleVector::value_type(0), SquaredSum<DoubleVector::value_type>());
cout << sqrt(length);
The Lisp version:
(reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23)))
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> wrote:
> The Lisp version:
>
> (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23)))
sorry, is a bit longer :-)
(sqrt (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23))))
But the C++ version is longer, too, because I've omitted all the includes,
"using namespace std" and the main-function.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Frank Buss <··@frank-buss.de> wrote:
>
>> The Lisp version:
>>
>> (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23)))
>
> sorry, is a bit longer :-)
>
> (sqrt (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23))))
>
> But the C++ version is longer, too, because I've omitted all the includes,
> "using namespace std" and the main-function.
>
The others are fair, but I don't think you could include main in that
statement of omission.
Recall the purpose of main: It works as the starting point for a standalone
executable. An interactive C++ REPL presumably wouldn't require you to type
it in between each expression, so we'll drop that.
A Lisp program that was meant to create a standalone executable would, in
fact, include pretty much the same amount of code as that main function to
do it.
That said... Oh my, is that really the best C++ code for the purpose?
Svein Ove Aas <·········@aas.no> writes:
> Oh my, is that really the best C++ code for the purpose?
Use of the vector, functor, and accumulate function aren't really
necessary. One could use an array of doubles and a simple for-loop.
double const vals[] = { -1.2, .99, 23 };
double sum = 0;
for ( size_t i = 0; i != 3; ++i )
sum += vals[i] * vals[i]; // or std::pow( vals[i], 2 )
return sum;
But code like this will tend to evolve toward a more generic
expression, usually with no loss in efficiency. Hence replacing type
double with a template-supplied numeric type, the array with a
template-supplied iterator pair, the algorithm with std::accumulate(),
and the squaring function with a binary functor, all pulled apart in
the name of "separation of concerns."
--
Steven E. Harris
Steven E. Harris wrote:
> Svein Ove Aas <·········@aas.no> writes:
>
>> Oh my, is that really the best C++ code for the purpose?
>
> Use of the vector, functor, and accumulate function aren't really
> necessary. One could use an array of doubles and a simple for-loop.
>
> double const vals[] = { -1.2, .99, 23 };
> double sum = 0;
> for ( size_t i = 0; i != 3; ++i )
> sum += vals[i] * vals[i]; // or std::pow( vals[i], 2 )
> return sum;
>
> But code like this will tend to evolve toward a more generic
> expression, usually with no loss in efficiency. Hence replacing type
> double with a template-supplied numeric type, the array with a
> template-supplied iterator pair, the algorithm with std::accumulate(),
> and the squaring function with a binary functor, all pulled apart in
> the name of "separation of concerns."
>
Right then.
I'll stick with Lisp, if you don't mind.
Svein Ove Aas <·········@aas.no> wrote:
> That said... Oh my, is that really the best C++ code for the purpose?
I'm not a very good C++ programmer, who knows all details of templates and
predicates, so I think it can be simplified, but I don't think that it can
be done as simple as in Lisp. That's the reason why most C++ programmers
doesn't use such concepts or other intersting ideas, like template
metaprogramming.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Frank Buss <··@frank-buss.de> wrote:
>
> > The Lisp version:
> >
> > (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23)))
>
> sorry, is a bit longer :-)
>
> (sqrt (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23))))
(sqrt (apply '+ (mapcar '* #1='(-1.2 0.99 23) #1#)))
;)
or less lispy, but more concise [and less memory
consuming]:
(sqrt (loop for i in '(-1.2 0.99 23) sum (* i i)))
Regards, Szymon.
Szymon <············@o2.pl> wrote:
> (sqrt (apply '+ (mapcar '* #1='(-1.2 0.99 23) #1#)))
nice reader macro trick.
> or less lispy, but more concise [and less memory
> consuming]:
>
> (sqrt (loop for i in '(-1.2 0.99 23) sum (* i i)))
and there are other useful reader macros. If all numbers are know at
compile time, you can write it like this:
#.(sqrt (loop for i in '(-1.2 0.99 23) sum (* i i)))
and it doesn't consume any time or memory at runtime :-)
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Andr� Thieme <······························@justmail.de> wrote in message news:<············@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)
These are the technical, objective advantages of Lisp syntax:
- precedence and associativity do not exist, and so there are no
ambiguities
- every well-formed syntax corresponds to a data structure. There is a
bidirectional conversion path between a data structure and syntax,
allowing Lisp programs to manipulate Lisp source code.
- a few simple rules can be applied to format Lisp syntax in a
readable way, even if it has very deep nesting. Lisp can be written as
a sideways tree (think of a Windows tree control, for instance):
a +--- b +-- e
| |
| +-- f
|
+--- c
|
+--- d --- e
Just add parentheses and keep basically the same shape:
(a (b e
f)
c
(d e))
From this you can tell right away that there is a main list headed by
the main connective A, with three other constituents. They all start
on separate lines and are at the same indentation level.
This formatting can be applied to very deep expressions to make sense
out of them.
You cannot nicely format deeply nested infix expressions, because the
connectives are sandwiched between the constituents; they do not
nicely pop out on one side for a sideways diagram.
In the prefix notation, the main connective comes first, which allows
you to put the other ones to the left and on separate lines, without
rearranging the lexical order of the tokens.
Given (+ a b) you can write that as:
(+ a
b)
But given A + B, you cannot write that as:
A
+
B
because the order has been permuted. Your compiler won't take it.
There isn't any nice order in which you can separate the connective
from the constituent expressions.
Sometimes I use this style in C++,
A +
B
So that say ((A || B) && C) && !(X || Y) becomes (oh boy, I can't even
see what the main connective is):
((A || B) && C) &&
!(X || Y)
then
((A ||
B) &&
C) &&
!(X ||
Y)
Blech, anomaly with the ! operator which is prefix. This quickly
becomes way too ugly and the main connective doesn't stick out; it's
still buried. The first && sticks out to the far right, looking more
prominent. Maybe:
((A ||
B) &&
C) &&
!(X ||
Y)
now we at least have a sideways tree shape of sorts. But this is ugly
as sin. If we translate to Lisp we get:
(and (and (or a
b)
c)
(not (or x
y)))
Beautiful. I can mentally convert that to a combinational logic
circuit diagram flowing right to left.
We can selectively fold obvious pieces to one line:
(and (and (or a b)
c)
(not (or x y)))
(and (and (or a b) c)
(not (or x y)))
(and (and (or a b) c) (not (or x y)))
These kinds of transformations are easy to do back and forth,
particularly with Lisp-aware editors.
Even in the completly flat version, I know right away that the main
opeation is an AND, without having to parse through the whole thing.
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
·································@posting.google.com...
>
> These are the technical, objective advantages of Lisp syntax:
Objective is right.
>
> - precedence and associativity do not exist, and so there are no
> ambiguities
>
> - every well-formed syntax corresponds to a data structure. There is a
> bidirectional conversion path between a data structure and syntax,
> allowing Lisp programs to manipulate Lisp source code.
>
> - a few simple rules can be applied to format Lisp syntax in a
> readable way, even if it has very deep nesting. Lisp can be written as
> a sideways tree (think of a Windows tree control, for instance):
>
> a +--- b +-- e
> | |
> | +-- f
> |
> +--- c
> |
> +--- d --- e
>
> Just add parentheses and keep basically the same shape:
>
> (a (b e
> f)
> c
> (d e))
That is horrible in my eyes, almost as horrible as the C++ mess you made
below.
>
> From this you can tell right away that there is a main list headed by
> the main connective A, with three other constituents. They all start
> on separate lines and are at the same indentation level.
All I can tell if that there's a mess.
>
> This formatting can be applied to very deep expressions to make sense
> out of them.
>
> You cannot nicely format deeply nested infix expressions, because the
> connectives are sandwiched between the constituents; they do not
> nicely pop out on one side for a sideways diagram.
>
> In the prefix notation, the main connective comes first, which allows
> you to put the other ones to the left and on separate lines, without
> rearranging the lexical order of the tokens.
>
> Given (+ a b) you can write that as:
>
> (+ a
> b)
>
> But given A + B, you cannot write that as:
>
> A
> +
> B
Why?
A +
B - is fine enough.
>
> because the order has been permuted. Your compiler won't take it.
> There isn't any nice order in which you can separate the connective
> from the constituent expressions.
>
> Sometimes I use this style in C++,
>
> A +
> B
>
> So that say ((A || B) && C) && !(X || Y) becomes (oh boy, I can't even
> see what the main connective is):
>
> ((A || B) && C) &&
> !(X || Y)
That is good enough. You can see that The first and last needs to be true
etc.
I think that two liner is fine, breaks the code into two suitable parts.
>
> then
>
> ((A ||
> B) &&
> C) &&
> !(X ||
> Y)
>
> Blech, anomaly with the ! operator which is prefix. This quickly
> becomes way too ugly and the main connective doesn't stick out; it's
> still buried. The first && sticks out to the far right, looking more
> prominent. Maybe:
>
> ((A ||
> B) &&
> C) &&
> !(X ||
> Y)
Now this is just a right mess... I need to parse the WHOLE thing into your
head and try to seperate it out.
>
> now we at least have a sideways tree shape of sorts. But this is ugly
> as sin. If we translate to Lisp we get:
>
> (and (and (or a
> b)
> c)
> (not (or x
> y)))
>
> Beautiful. I can mentally convert that to a combinational logic
> circuit diagram flowing right to left.
Beauty is in the eye of the beholder indeed!
I can mentally convert that into a bit less of a mess.
But perhaps it's that I don't convert it into such a diagram but merely
understand what happens to lead into the next. I can see the Lisp is easier
for a diagram - but personally harder for me to understand.
>
> We can selectively fold obvious pieces to one line:
>
> (and (and (or a b)
> c)
> (not (or x y)))
>
> (and (and (or a b) c)
> (not (or x y)))
Alot better - just like the C++ example above.
>
> (and (and (or a b) c) (not (or x y)))
>
> These kinds of transformations are easy to do back and forth,
> particularly with Lisp-aware editors.
>
> Even in the completly flat version, I know right away that the main
> opeation is an AND, without having to parse through the whole thing.
In my eyes the two liner C++ code looks better since the && is on the right,
in the middle of the two - where I naturally look when I want to know what
is happening...
The Lisp two-liner is actually nicer on the eye, it just looks cleaner. But
I can't be sure that isn't because of all the lower case.
As alot of things, it's subjective on your mindset - so I'm questioning if
I'm actually adding to this discussion, or am simply getting tired of this
whole thread as neither syntax will come out on top - since it's ALL
subjective.
Let the replies of "this is better because" continue...
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <···········@hotmail.com> writes:
> The Lisp two-liner is actually nicer on the eye, it just looks
> cleaner. But I can't be sure that isn't because of all the lower case.
Heh. If only you knew the irony and history that makes this statement so
funny!!
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
This thread brings up a good question. Although I don't know Lisp and
looks too complicated for someone like me I hear only the greatest
things about it from most experts in most programming languages. I hear
it probably the most flexible language in the world and can do things
in ways other languages cant.
My question is why is everyone not using Lisp or why is Lisp not more
popular in all programming fields?
Stede
·········@yahoo.com" <········@yahoo.com> writes:
> This thread brings up a good question. Although I don't know Lisp and
> looks too complicated for someone like me I hear only the greatest
> things about it from most experts in most programming languages. I hear
> it probably the most flexible language in the world and can do things
> in ways other languages cant.
>
> My question is why is everyone not using Lisp or why is Lisp not more
> popular in all programming fields?
For one possible answer, check out _Wisdom of Crowds_ by James
Surowiecky, particulary the section on "plank road fever". While the
overall thesis of his book is that crowds can be quite smart, he also
discusses several situations in which the wisdom of crowds breaks
down--such as when too many people start basing their decisions on
decisions made previously by other people.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
·········@yahoo.com" <········@yahoo.com> writes:
> My question is why is everyone not using Lisp or why is Lisp
> not more popular in all programming fields?
Ever been to McDonalads?
>
> ((A || B) && C) &&
> !(X || Y)
>
>
> (and (and (or a b) c)
> (not (or x y)))
>
I guess this just shows how pointless this entire thread is, since I find
the first example much cleaner and easier to understand than the second.
On Sun, 31 Oct 2004 17:42:02 +1000, Maahes <······@internode.on.net> wrote:
>
>>
>> ((A || B) && C) &&
>> !(X || Y)
>>
>>
>> (and (and (or a b) c)
>> (not (or x y)))
>>
>
> I guess this just shows how pointless this entire thread is, since I find
> the first example much cleaner and easier to understand than the second.
>
Well, the Lisp code here is artificially restricting 'and' to be a bin-op, try:
(and (or a b)
c
(not (or x y)))
That's a bit nicer. Depending on the intent of the code, we might even write:
(and (or a b)
c
(not x)
(not y))
Both of these rewrites expose the structure of the expression better than the
C code can.
-- MMN
"Maahes" <······@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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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" <·····@nyct.net> wrote in message
···················@nyct.net...
> "Maahes" <······@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
> ·····@nyct.net
> Professional Software Developer, Amateur Quantum Mechanicist
> 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" <·····@nyct.net> wrote in message
> ···················@nyct.net...
>> "Maahes" <······@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
>> ·····@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" <······@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�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> 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)))))
>
> most Lisp implementations optimizes the tail-recursion to a jump, so
> chances are good, that it is as fast as a normal loop.
But your make-down-list function is not tail recursive: it takes
the result of the recursive call and gives it to CONS, instead of
returning it directly. This makes it impossible to optimize the
recursion to a jump.
Kalle Olavi Niemitalo <···@iki.fi> wrote:
> But your make-down-list function is not tail recursive: it takes
> the result of the recursive call and gives it to CONS, instead of
> returning it directly. This makes it impossible to optimize the
> recursion to a jump.
yes, you are right. Perhaps not so good as an example for tail-recursion:
(defun make-down-list (n &optional list)
(let ((list (append list (list n))))
(if (> n 0)
(make-down-list (1- n) list)
list)))
But I'm sure it can be written simpler, even as a recursion.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss on Thu, 28 Oct 2004 22:14:12 +0000 (UTC) writes:
> yes, you are right. Perhaps not so good as an example for tail-recursion:
>
> (defun make-down-list (n &optional list)
> (let ((list (append list (list n))))
> (if (> n 0)
> (make-down-list (1- n) list)
> list)))
>
> But I'm sure it can be written simpler, even as a recursion.
(defun make-down-list (n &optional list)
(if (= n -1)
(reverse list)
(make-down-list (1- n) (cons n list))))
This walks the list only one time.
--
Marco Parrone <·····@autistici.org> [0x45070AD6]
Marco Parrone on Thu, 28 Oct 2004 23:11:33 GMT writes:
> (defun make-down-list (n &optional list)
> (if (= n -1)
> (reverse list)
> (make-down-list (1- n) (cons n list))))
>
> This walks the list only one time.
s/(= n 1)/(< n 0)/
If you want to have mercy for who will call it with a negative argument.
--
Marco Parrone <·····@autistici.org> [0x45070AD6]
Marco Parrone on Thu, 28 Oct 2004 23:20:01 GMT writes:
>> (defun make-down-list (n &optional list)
>> (if (= n -1)
>> (reverse list)
>> (make-down-list (1- n) (cons n list))))
>>
>> This walks the list only one time.
>
> s/(= n -1)/(< n 0)/
>
> If you want to have mercy for who will call it with a negative argument.
Even better:
(defun make-down-list (max &optional (current 0) list)
(if (> current max)
list
(make-down-list max (1+ current) (cons current list))))
--
Marco Parrone <·····@autistici.org> [0x45070AD6]
> 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" <······@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
"Maahes" <······@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
> I'm sure you're quite happy dealing with nested parens when writing
> arithemtic. Is there some reason why parens around code is different?
absolultely NOT. Sometimes its unavoidable, especially complex IF
statements, but its never a good thing when we have to do a line with lots
of brackets, because its hard to read at a glance.
> Can they handle the semicolons? If so, parentheses won't present any
> additional difficulty. But by all means, even if you don't use it at
I'll leave you to rethink that first statement coz I don't think it
justifies an argument.
> work, spend some time learning Lisp- it will certainly make you a
> better C/C++/Java programmer.
>
entirely possible.
> Gregm
>
"Maahes" <······@internode.on.net> writes:
> > I'm sure you're quite happy dealing with nested parens when writing
> > arithemtic. Is there some reason why parens around code is different?
>
> absolultely NOT. Sometimes its unavoidable, especially complex IF
> statements, but its never a good thing when we have to do a line with lots
> of brackets, because its hard to read at a glance.
You may rest assured that no-one who has become familiar with writing
Lisp code has trouble with parentheses- which is what they are called-
not brackets. Likewise, anyone who has become familiar with C doesn't
have trouble with semicolons and curly braces.
> > Can they handle the semicolons? If so, parentheses won't present any
> > additional difficulty. But by all means, even if you don't use it at
>
> I'll leave you to rethink that first statement coz I don't think it
> justifies an argument.
I think it does. You see parentheses as problematic when it comes to
understanding Lisp. I say semicolons are the same with C. Obviously
you don't have trouble with semicolons, or braces for that matter-
because you know C-like languages. My point is that semicolons,
braces, parentheses are syntactical stuff that you learn quickly. I
think the bigger problem you'll face is unlearning C, meaning,
identifying and overcoming some of the unconscious design rules you've
picked up about how software "should" be. Lisp takes a fundamentally
different view in some respects- not as different as something like
Prolog, but if you really want to start grokking Lisp, you'll end up
having to relearn some things.
>
> > work, spend some time learning Lisp- it will certainly make you a
> > better C/C++/Java programmer.
> >
> entirely possible.
>
You'll look at programming differently afterwards.. good luck!
Gregm
In comp.lang.lisp Greg Menke <··········@toadmail.com> wrote:
> You may rest assured that no-one who has become familiar with writing
> Lisp code has trouble with parentheses- which is what they are called-
> not brackets. Likewise, anyone who has become familiar with C doesn't
> have trouble with semicolons and curly braces.
That's a dialect difference, not an error.
British usage (as I understand it, at least) refers to brackets, square
brackets, and curly brackets where American usage refers to parentheses,
brackets, and braces.
--
Karl A. Krueger <········@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.
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...
Alex Drummond wrote:
> Yes, it is tricky to keep count of the brackets.
Huh. People say that a lot, but it isn't, really. Mentally maintain one
integer index, and start a scan. Inc on "(", Dec on ")".
While I agree it is easiest to use a syntax-highlighting editor with
paren-matching facilities, it's really not hard to do a straight
traversal and just freaking count (unless the section in question is
very large indeed) - Here I assume you were taught to count, I
suppose...
Inconsistencies are glaringly obvious either because
you don't reach zero (or a particular number associated with a
subexpression for "advanced" counters) when you should or you go
negative.
It's not like you have to worry about how ; interacts with {} or magic
"blah:" words that introduce subsections terminated either by other
reserved words ending in : or }, or what have you.
"Maahes" <······@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�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
"Maahes" <······@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.
In comp.lang.lisp Mario S. Mommer <········@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 <········@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.
"Maahes" <······@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...
Usually you use a Lisp aware editor like Emacs (or even Vi) to take
care of the parens for you. You can even write functions that look a
lot like C functions:
[31]> (defun fac (n)
(let ((f 1))
(loop for i from 1 to n
do (setf f (* f i))
finally return f)))
FAC
[32]> (fac 3)
6
[33]> (fac 5)
120
[34]> (fac 0)
1
[35]> (fac 1000)
402387260077093773543702433923003985719374864210714632543799910429938512398629020592044208486969404800479988610197196058631666872994808558901323829669944590997424504087073759918823627727188732519779505950995276120874975462497043601418278094646496291056393887437886487337119181045825783647849977012476632889835955735432513185323958463075557409114262417474349347553428646576611667797396668820291207379143853719588249808126867838374559731746136085379534524221586593201928090878297308431392844403281231558611036976801357304216168747609675871348312025478589320767169132448426236131412508780208000261683151027341827977704784635868170164365024153691398281264810213092761244896359928705114964975419909342221566832572080821333186116811553615836546984046708975602900950537616475847728421889679646244945160765353408198901385442487984959953319101723355556602139450399736280750137837615307127761926849034352625200015888535147331611702103968175921510907788019393178114194545257223865541461062892187960223838971476088506276862967146674697562911234082439208160153780889893964518263243671616762179168909779911903754031274622289988005195444414282012187361745992642956581746628302955570299024324153181617210465832036786906117260158783520751516284225540265170483304226143974286933061690897968482590125458327168226458066526769958652682272807075781391858178889652208164348344825993266043367660176999612831860788386150279465955131156552036093988180612138558600301435694527224206344631797460594682573103790084024432438465657245014402821885252470935190620929023136493273497565513958720559654228749774011413346962715422845862377387538230483865688976461927383814900140767310446640259899490222221765904339901886018566526485061799702356193897017860040811889729918311021171229845901641921068884387121855646124960798722908519296819372388642614839657382291123125024186649353143970137428531926649875337218940694281434118520158014123344828015051399694290153483077644569099073152433278288269864602789864321139083506217095002597389863554277196742822248757586765752344220207573630569498825087968928162753848863396909959826280956121450994871701244516461260379029309120889086942028510640182154399457156805941872748998094254742173582401063677404595741785160829230135358081840096996372524230560855903700624271243416909004153690105933983835777939410970027753472000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Oh, I guess C an Java might have one minor problem with not properly
dealing with numbers that don't fit into a machine word.
> I'll probably go off and learn some more lisp now, since all these posts
> have made me think there might be a fabulous language there if you can get
> past the excessive use of brackets...
>
> And its certainly a simple enough language to write your own compiler so
> maybe I can play with that for a game. I doubt I'd have any luck convincing
> anyone at work that our scripting language should be Lisp though... I don't
> think most of our designers could handle all those brackets...
Scheme is something you could write a compiler for in a reasonable
time. Common Lisp is a bit more complex.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
"David Steuber" <·····@david-steuber.com> wrote in message
···················@david-steuber.com...
> "Maahes" <······@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...
FWIW you really do not notice all those parens after you get used to lisp
expressions and they are less intinidating when you realize they take the
place of all of ,;}) in C/C++ (not in every instance of course)
Besides, not everyone (myself included) would write the above as it is, I
never use recursion for an iterative problem.
(defun make-down-list (n)
(loop for i from n downto 0
collect i))
>> And its certainly a simple enough language to write your own compiler so
>> maybe I can play with that for a game. I doubt I'd have any luck
>> convincing
>> anyone at work that our scripting language should be Lisp though... I
>> don't
>> think most of our designers could handle all those brackets...
>
> Scheme is something you could write a compiler for in a reasonable
> time. Common Lisp is a bit more complex.
I think he may have meant "compiler" in the sense of macros are like
compilers for your own domain specific language on top of lisp rather than
re-implementing the language(?).
Stick with Commn Lisp.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Maahes" <······@internode.on.net> writes:
> 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.
That's not what lispers mean by "bottom up".
--jon
"Maahes" <······@internode.on.net> writes:
> 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.
No, you type the code exactly as you read it: from left to right. You
could type the C code by doing list.push(i) first and then adding the
for loop and then doing the reverse, but I'm sure that won't make any
sense to you. In the same way, what you describe makes no sense to me.
Although, I would write that code in Lisp as:
(loop for i below 11 collect i)
;)
The main thing you fail to realize, due to the complexity of C syntax,
is that C code has just as much structure as Lisp code (more actually,
because the structure goes immediately to semantically significant
constructs), but that structure is obfuscated by the variety of
characters used to delimit various semantic constructs. In Lisp, we just
have one set of characters to delimit all constructs and the semantics
are determined by the operator at the beginning of a form.
> 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.
The bindings list of a LET form is just that, a list, so it needs to
have that extra level of nesting.
> 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.
Your problem is that you're looking at the parens, not at the shape of
the code. Do you actually look for the semicolons at the end of every
statement in C or do you simply let your editor line up the code so that
all statements in the same block have their starting line indented to
the same level and any further lines (because of lots of chained
function calls or because of lots of parameters split up onto multiple
lines) indented further in?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
[ ... ]
> Although, I would write that code in Lisp as:
>
> (loop for i below 11 collect i)
...and in C++ you (or at least I) would quite possibly write it using
std::generate_n.
> The main thing you fail to realize, due to the complexity of C syntax,
I don't find C's syntax particularly complex at all -- though I'm the
first to admit that this may be due (in part) to having used it nearly
as long as I have Lisp.
> is that C code has just as much structure as Lisp code (more actually,
> because the structure goes immediately to semantically significant
> constructs),
I have to admit this is an argument that surprises me -- while I agree
that C code generally has more (and better) structure that most Lisp
code, this is the first time I've seen even the most rabid advocate of
a language claim that its lack of structure was actually an advantage.
> but that structure is obfuscated by the variety of
> characters used to delimit various semantic constructs.
The syntax of C obfuscates structure only to the least perspicacous of
observers.
> In Lisp, we just
> have one set of characters to delimit all constructs and the semantics
> are determined by the operator at the beginning of a form.
...or at the end, or in a property list, or just about anywhere else
you feel like putting it. I won't bore you with the (ancient) code
that did it, but I have some old Lisp here that accepts input in
postfix format (as non-list S-expressions, natch) and prints turns
them into normal infix notation.
[ ... ]
> Your problem is that you're looking at the parens, not at the shape of
> the code.
I suspect what he's really missing is the fact that Lisp is almost
always written using an editor that's aware of Lisp syntax to at least
a fairly reasonable degree, so indentation and some sort of
highlighting to match parentheses is extremely common -- though in
fairness it should be pointed out that it's common primrarily because
machine help is nearly an absolute necessity to compensate for the
paucity of Lisp syntax.
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) writes:
> Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
>
>> The main thing you fail to realize, due to the complexity of C syntax,
>
> I don't find C's syntax particularly complex at all -- though I'm the
> first to admit that this may be due (in part) to having used it nearly
> as long as I have Lisp.
The description of the structure of C code is objectively more complex
than for Lisp code.
>> is that C code has just as much structure as Lisp code (more actually,
>> because the structure goes immediately to semantically significant
>> constructs),
>
> I have to admit this is an argument that surprises me -- while I agree
> that C code generally has more (and better) structure that most Lisp
> code, this is the first time I've seen even the most rabid advocate of
> a language claim that its lack of structure was actually an advantage.
This is what allows Lisp to be what it is: a language where you add
features as you want them. With a complex microsyntax, the structure of
the parsed code won't be the same as the structure of the code itself.
Is a for loop really 3 individual syntactic elements one after the
other, or is it one element with three parts? if/else blocks become even
more complex. How would I define a new type of operator like that so
that the parser is able to cope with it? In Lisp, the parser already can
cope with arbitrarily structured code, because the code contains its own
structure.
>> but that structure is obfuscated by the variety of
>> characters used to delimit various semantic constructs.
>
> The syntax of C obfuscates structure only to the least perspicacous of
> observers.
My comment above about a for loop's syntax should explain what I was
talking about.
>> In Lisp, we just
>> have one set of characters to delimit all constructs and the semantics
>> are determined by the operator at the beginning of a form.
>
> ...or at the end, or in a property list, or just about anywhere else
> you feel like putting it.
In that case, you're not writing Lisp code. You're defining some data
structure that's manipulated by some code into Lisp code, maybe. The
specification of Lisp's evaluation semantics is as I said.
> I won't bore you with the (ancient) code
> that did it, but I have some old Lisp here that accepts input in
> postfix format (as non-list S-expressions, natch) and prints turns
> them into normal infix notation.
It's not inputting Lisp code, then. It's using a custom parser.
>> Your problem is that you're looking at the parens, not at the shape of
>> the code.
>
> I suspect what he's really missing is the fact that Lisp is almost
> always written using an editor that's aware of Lisp syntax to at least
> a fairly reasonable degree, so indentation and some sort of
> highlighting to match parentheses is extremely common -- though in
> fairness it should be pointed out that it's common primrarily because
> machine help is nearly an absolute necessity to compensate for the
> paucity of Lisp syntax.
Of course, but I find that I can't deal with Java code effectively
without the same features, either. I ignore microsyntactic noise in both
Lisp and Java, I suppose.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> I suspect what he's really missing is the fact that Lisp is almost
> always written using an editor that's aware of Lisp syntax to at least
> a fairly reasonable degree, so indentation and some sort of
> highlighting to match parentheses is extremely common -- though in
> fairness it should be pointed out that it's common primrarily because
> machine help is nearly an absolute necessity to compensate for the
> paucity of Lisp syntax.
That's been mentioned several times so far in this thread. I just don't see
it as an excuse to say the language is ok, coz an editor helps you program
it.
The same as saying obscure coding standards are ok, coz a debugger can be
used to show you whats going on..
In article <··········@duster.adelaide.on.net>,
Maahes <······@internode.on.net> wrote:
> > I suspect what he's really missing is the fact that Lisp is almost
> > always written using an editor that's aware of Lisp syntax to at
> > least a fairly reasonable degree, so indentation and some sort of
> > highlighting to match parentheses is extremely common -- though in
> > fairness it should be pointed out that it's common primrarily
> > because machine help is nearly an absolute necessity to compensate
> > for the paucity of Lisp syntax.
>
> That's been mentioned several times so far in this thread. I just
> don't see it as an excuse to say the language is ok, coz an editor
> helps you program it.
> The same as saying obscure coding standards are ok, coz a debugger can
> be used to show you whats going on..
I think it's more accurate to say in Lisp's case that its more regular
syntax helps the editor be much better at manipulating it than it would
otherwise be capable of. For example, I know of no editors that support
manipulating C structure at the syntactic level the way emacs lets you
work with S-expressions. Once you learn how to use these features it is
/very/ powerful. (And it spoils you - editing C is not very fun for me
anymore because of the lack of editor support I'm used to with Lisp.)
So, even if raw C were better than raw Lisp, Lisp + emacs is still
better than C + any C-aware editor I'm aware of, including emacs.
(If anyone does know of an editor that allows manipulation of C in a
structured way in addition to as a bunch of characters, I'd love to know
about it - I write C for my job.)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing <·············@lavos.net> writes:
> For example, I know of no editors that support
> manipulating C structure at the syntactic level the way emacs lets you
> work with S-expressions. Once you learn how to use these features it is
> /very/ powerful. (And it spoils you - editing C is not very fun for me
> anymore because of the lack of editor support I'm used to with Lisp.)
Yes, I am constantly irritated that I don't get a single conceptual
block (such as an entire for loop or a single addend in a summation)
with a single keystroke when I'm at work coding Java. I have to keep
grabbing bits until I get what I want and even then sometimes I end up
getting more than I want... This is one consequence of the obfuscation
of the syntactic structure of C code. The syntax depends on the
semantics. In Lisp, you just go to the matching paren and you have one
conceptual unit of code.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Possibly a good psychological example of the differences between C
programmers and Lisp programmers. C Programmers generally hate the idea of
an editor that understood conceptual blocks. I know I do. I like to program
left to right in text and don't want the compiler inserting brackets and
such.
"Rahul Jain" <·····@nyct.net> wrote in message
···················@nyct.net...
> Brian Downing <·············@lavos.net> writes:
>
>> For example, I know of no editors that support
>> manipulating C structure at the syntactic level the way emacs lets you
>> work with S-expressions. Once you learn how to use these features it is
>> /very/ powerful. (And it spoils you - editing C is not very fun for me
>> anymore because of the lack of editor support I'm used to with Lisp.)
>
> Yes, I am constantly irritated that I don't get a single conceptual
> block (such as an entire for loop or a single addend in a summation)
> with a single keystroke when I'm at work coding Java. I have to keep
> grabbing bits until I get what I want and even then sometimes I end up
> getting more than I want... This is one consequence of the obfuscation
> of the syntactic structure of C code. The syntax depends on the
> semantics. In Lisp, you just go to the matching paren and you have one
> conceptual unit of code.
>
> --
> Rahul Jain
> ·····@nyct.net
> Professional Software Developer, Amateur Quantum Mechanicist
In article <········@duster.adelaide.on.net>,
"Maahes" <······@internode.on.net> wrote:
> Possibly a good psychological example of the differences between C
> programmers and Lisp programmers. C Programmers generally hate the idea of
> an editor that understood conceptual blocks. I know I do. I like to program
> left to right in text and don't want the compiler inserting brackets and
> such.
You misunderstand. Lispniks still edit text as so many characters. We
just have /at our disposal/ when we choose to call on them sundry mad
useful tools for editing blocks of code in one go.
Just to make this clear, occasionally while dicing and slicing the code
I temporarily have parens unbalanced. For the duration of that state,
and in that narrow section of text, there are some blocks I can see
which I cannot grab in one go, precisely because the power tools do not
stop me from mashing things up any way I like while editing, and until I
get the parens rebalanced the editor will grab the wrong stuff.
And what you have no way of knowing since you cannot edit this way is
how often when editing one can usefully grab all the logic from, say,
one branch of an IF statement. (Answer: allllll the time.)
This to me is why the parens which scare non-Lispniks so much actually
make editing, formatting, and reading code vastly easier (after about
three weeks of practice).
kenny
> You misunderstand. Lispniks still edit text as so many characters. We
> just have /at our disposal/ when we choose to call on them sundry mad
> useful tools for editing blocks of code in one go.
>
QUOTE:
> Yes, I am constantly irritated that I don't get a single conceptual
> block (such as an entire for loop or a single addend in a summation)
> with a single keystroke when I'm at work coding Java.
That sounds like the editor is inserting stuff to me.
"Maahes" <······@internode.on.net> writes:
>> You misunderstand. Lispniks still edit text as so many characters. We
>> just have /at our disposal/ when we choose to call on them sundry mad
>> useful tools for editing blocks of code in one go.
>>
>
> QUOTE:
>> Yes, I am constantly irritated that I don't get a single conceptual
>> block (such as an entire for loop or a single addend in a summation)
>> with a single keystroke when I'm at work coding Java.
>
> That sounds like the editor is inserting stuff to me.
It probably wasn't clear: I was talking about selection. But I do have
automated code generation scripts in my editor because there's so much
noise in the syntax. Effectively, those scripts are a decompression
algorithm to decompress my ideas into the masses of Java code needed to
express a simple pattern.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Maahes" <······@internode.on.net> writes:
> Possibly a good psychological example of the differences between C
> programmers and Lisp programmers. C Programmers generally hate the
> idea of an editor that understood conceptual blocks. I know I do. I
> like to program left to right in text and don't want the compiler
> inserting brackets and such.
The compiler does not insert brackets and such. It's quite common to
have an *editor* (like emacs) to do so when you type a command to
request it to do so.
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?
Maahes wrote:
> I'm not even sure why there are 2 brackets around the lst 0.
(Should be (lst '()), anyway, as someone already commented.
> This seems to make a mockery of Lisp having consistent syntax.
No, its perferctly consistent.
It's because you might want to initialise more than one variable for the
loop. So,
(let ((i 0)(j 100)) (...))
would coreespond to C++'s
for (int i=0, int j=100; <testcondition>; <loop-ops, e.g i++,j-->) {}
--
My apologies for not leaving a handy e-mail address for spammers.
Use alex_gian ATT yahoo Decimal cawm (if you must)
You know how to compose this...
In article <··············@yahoo.com>, ··········@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? 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...
- Gerry Quinn
-----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/customer_apps/animation_graphics/naughtydog.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)
iD8DBQFBfkqNKHEUoQoCFcIRAkTtAJ0R1RxJ3EQB6VKy4TCC3foNCNa4jwCeKwup
UWXzHD90kcK+pL6984OEZMk=
=IVnR
-----END PGP SIGNATURE-----
In article <············@rena.mat.uc.pt>, ····@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/customer_apps/animation_graphics/naughtydog.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
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
In article <······················@twister.nyc.rr.com>,
·······@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
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?
"Thomas Schilling" <······@yahoo.de> wrote in message
·····················@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#))funcfunc($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)
"Computer Whizz" <···········@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
"jayessay" <······@foo.com> wrote in message
···················@rigel.goldenthreadtech.com...
> "Computer Whizz" <···········@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" <···········@hotmail.com> wrote in message news:<············@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 )
Carl Muller wrote:
> "Computer Whizz" <···········@hotmail.com> wrote in message
> news:<············@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?
"Computer Whizz" <···········@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" <···········@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)
...
.
Computer Whizz schrieb:
> 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?
If the person is a newbi, how can he/she know that not all programming
languages look like that? ;-)
Also: give it a try for three days. There will be no problem anymore.
Andr�
--
"If Java is your hammer every problem will look like a thumb"
"Andr� Thieme" <······························@justmail.de> wrote in message
·················@ulric.tng.de...
> Computer Whizz schrieb:
>
>> 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?
>
> If the person is a newbi, how can he/she know that not all programming
> languages look like that? ;-)
>
> Also: give it a try for three days. There will be no problem anymore.
>
>
> Andr�
> --
> "If Java is your hammer every problem will look like a thumb"
I shall investigate it pretty soon, as I shall be getting alot more free
time... I shall then just pop in to your lisp newsgroup to post my
thoughts... Don't expect anything of me though - the mindset is boggling!
--
=========
Comp Whizz
=========
(The C++ beginner)
"Computer Whizz" <···········@hotmail.com> wrote in message
·················@newsg3.svr.pol.co.uk...
>> Also: give it a try for three days. There will be no problem anymore.
>>
> I shall investigate it pretty soon, as I shall be getting alot more free
> time... I shall then just pop in to your lisp newsgroup to post my
> thoughts... Don't expect anything of me though - the mindset is boggling!
Look forward to your visit. But forget what other people expect of you,
expect more from yourself. Pop in and *listen*, don't pop in and post
ill-considered thoughts.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Computer Whizz" <···········@hotmail.com> writes:
> I shall investigate it pretty soon, as I shall be getting alot more free
> time... I shall then just pop in to your lisp newsgroup to post my
> thoughts... Don't expect anything of me though - the mindset is boggling!
I came from a C/C++ background myself. I've done a little Java, but
not much. Also, my C++ mostly predates templates. The last compiler
I used was the first one from the vendor to support STL. Lisp is
different.
I actually found that it is a bit easier to transition through another
language. Perl, while very much C based, helps to start breaking away
from some of the constraints that C forces you into. Python (I
haven't really done much with this either) probably goes even further.
I am still doing a lot of C like thinking. But the more problems I
solve in Lisp, the more I appreciate the language. It is a fun
experience for me.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
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
"Alex Drummond" <··········@ucl.ac.uk> wrote in message
·················@uns-a.ucl.ac.uk...
> Computer Whizz wrote:
>
> 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
Easy tiger - I'm not 100% against any language... Just because I didn't like
Java doesn't mean I'm gonna trash it.
I just thing having that form, which is full of ()'s and doesn't REALLY
identify between various things, looks really - well - messy. Other
languages in my eyes look VERY uniform and have a "flow" to them, Lisp
doesn't seem to from the examples shown here... And I'm not going to go
researching into Lisp while I'm doing another 1001 things.
--
=========
Comp Whizz
=========
(The C++ beginner)
> I just thing having that form, which is full of ()'s and doesn't REALLY
> identify between various things, looks really - well - messy. Other
> languages in my eyes look VERY uniform and have a "flow" to them, Lisp
> doesn't seem to from the examples shown here... And I'm not going to go
> researching into Lisp while I'm doing another 1001 things.
But the syntax of Lisp is completely uniform, as I just exlained! There is
basically only one bit of syntax.
Alex
Computer Whizz wrote:
>
> "Alex Drummond" <··········@ucl.ac.uk> wrote in message
> ·················@uns-a.ucl.ac.uk...
>> Computer Whizz wrote:
>>
>> 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
>
> Easy tiger - I'm not 100% against any language... Just because I didn't
> like Java doesn't mean I'm gonna trash it.
>
> I just thing having that form, which is full of ()'s and doesn't REALLY
> identify between various things, looks really - well - messy. Other
> languages in my eyes look VERY uniform and have a "flow" to them, Lisp
> doesn't seem to from the examples shown here... And I'm not going to go
> researching into Lisp while I'm doing another 1001 things.
>
Computer Whizz schrieb:
> "Alex Drummond" <··········@ucl.ac.uk> wrote in message
> ·················@uns-a.ucl.ac.uk...
>
>>Computer Whizz wrote:
>>
>>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
>
>
> I'm not 100% against any language...
That's good
> I just thing having that form, which is full of ()'s and doesn't REALLY
> identify between various things, looks really - well - messy.
First of all: the paranthesis are a very good thing. It was pointed out
in other postings that you usually need the same amount of parans in C
like you do in Lisp. If we would not have some great editors today I
would have to agree, all the parans would be a problem. However, with
todays technology you will not look at them anymore. You could even give
them a color close to background color. From the indentation you can see
with some days of training very fast what happens.
Lisp has dialects. They are still in the Lisp-family and work for many
things very well. Take a look at this Dylan (this is a Lisp) code:
define method distance (x1, y1, x2, y2)
sqrt((x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1))
end method distance;
I hope there are not too many parens in this expression, but I think the
C++ version would also need some.
> Other languages in my eyes look VERY uniform and have a "flow" to them,
> Lisp doesn't seem to from the examples shown here...
It's just a matter of training.
Andr�
--
http://tinyurl.com/64x7y
"Computer Whizz" <···········@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#))funcfunc($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?
"Peter Lewerin" <·············@swipnet.se> wrote in message
·································@posting.google.com...
> "Computer Whizz" <···········@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)
In article <················@news.cis.dfn.de>, ······@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 <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <······················@twister.nyc.rr.com>,
> ·······@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
Gerry Quinn <······@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
In article <··············@g.mccaughan.ntlworld.com>,
················@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
> 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 <··············@g.mccaughan.ntlworld.com>,
> ················@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
In article <··························@news.indigo.ie>,
······@DELETETHISindigo.ie says...
> [...]
> 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.
How about learning it in order to perhaps get a clue about
what you're talking about. (I realize it's a novel thought
for you, but you really should try it some time.)
Christer Ericson
Sony Computer Entertainment, Santa Monica
In article <·························@news.verizon.net>,
················@NOTplayTHISstationBIT.sony.com says...
> In article <··························@news.indigo.ie>,
> ······@DELETETHISindigo.ie says...
> > [...]
> > 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.
>
> How about learning it in order to perhaps get a clue about
> what you're talking about. (I realize it's a novel thought
> for you, but you really should try it some time.)
Have you heard of the concept "secondary source"? You don't need to
host a brain slug to know it's a bad idea. You just look at the people
who host them.
I am familiar with the basic concepts of Lisp, I am familiar with the
arguments in favour of Lisp put forward by enthusiasts, and I am
familiar with the generally weak profile of Lisp enthusiasts in terms of
actually delivering product. The success of one group of talented
developers despite a plainly idiotic choice of development tools
notwithstanding. [I even quoted them, the Lisp users, to justify my
opinions.]
Learning to use Lisp idiomatically would take some time. I can find
better uses for that time. I don't buy the crap about it
revolutionising thinking processes, because of the general lack of
revolutionary Lisp-based software. So it's just another language. I
have programmed in about a dozen languages - I don't keep count. If I
need to learn one of the various versions of Lisp sometime, I'll learn
it.
Nowhere in my posts have I criticised any element of Lisp as a language
per se. But based on observation I have criticised the notion that
games development productivity would be enhanced dramatically by a
switch to Lisp, which was the thrust of the posts on this thread,
particularly the initial one. Since you yourself have now admitted that
you prefer to stick with C++, it is rather clear that similar arguments
hold sway with you.
- Gerry Quinn
>>>>> "GQ" == Gerry Quinn <······@DELETETHISindigo.ie> writes:
[...]
GQ> I am familiar with the basic concepts of Lisp, I am familiar
GQ> with the arguments in favour of Lisp put forward by
GQ> enthusiasts, and I am familiar with the generally weak profile
GQ> of Lisp enthusiasts in terms of actually delivering product. [...]
"Enthusiasts" who do things for fun are not expected to deliver
"product" regardless of what langauge they use. If you have reason to
say this about people who use lisp professionally compared to users of
other languages, then perhaps you could tell us that reason? (AI
that wasn't in the 80s doesn't count).
cheers,
BM
In article <··············@p4.internal>, ··@acm.org says...
> >>>>> "GQ" == Gerry Quinn <······@DELETETHISindigo.ie> writes:
> [...]
> GQ> I am familiar with the basic concepts of Lisp, I am familiar
> GQ> with the arguments in favour of Lisp put forward by
> GQ> enthusiasts, and I am familiar with the generally weak profile
> GQ> of Lisp enthusiasts in terms of actually delivering product. [...]
>
> "Enthusiasts" who do things for fun are not expected to deliver
> "product" regardless of what langauge they use. If you have reason to
> say this about people who use lisp professionally compared to users of
> other languages, then perhaps you could tell us that reason? (AI
> that wasn't in the 80s doesn't count).
Take away the Lisp evangelists who are using Lisp professionally, and
you won't be left with a lot. This thread was posted on a games
development newsgroup, by somebody called NeoLisper, who I doubt has
produced a game in Lisp or any other language.
Lots of people develop games for fun in C, C++, Delphi, Java, Flash and
VB.
I think the nub of the issue is that, if you take away the relatively
useless ability to write self-modifying code, what Lisp is mainly good
for is representing complicated algorithms. But representing
complicated algorithms is a solved problem on any modern high-level
language, and any extra benefits from Lisp are likely to be minimal for
99% of programming tasks.
People who have just begun a project, or indeed who have never completed
a real project, are apt to overestimate the importance of algorithms in
programming. They tend to be only a tiny part of nearly all finished
products, particularly games. Any small win on algorithm definition
will be swallowed up by Lisp's many disadvantages.
- Gerry Quinn
>>>>> "GQ" == Gerry Quinn <······@DELETETHISindigo.ie> writes:
[question and non-answer elided]
GQ> I think the nub of the issue is that, if you take away the
GQ> relatively useless ability to write self-modifying code,
I don't understand where this self-modifying code idea is coming from.
Do you mean the ability to write code that writes code? Self
modifying code, in the usage I am familiar with, means changing the
code (not data) in memory as the code itself runs. An example would be
changing jump destinations in running code by modifying the immediate
operand of the jump instruction to get home-made memory-indirect jumps
in ISA's that lack such things. These tricks may have been (ok were)
cute 15-20 years ago, but they tend to stall the deep pipelines in
modern processors. Perhaps the usage/meaning of the term has shifted
due to this?
GQ> what
GQ> Lisp is mainly good for is representing complicated
GQ> algorithms.
This is like saying "what lawyers are good for is winning cases."
(But to stretch the analogy, the lawyer in question lets you draw up
interesting contracts too).
GQ> But representing complicated algorithms is a
GQ> solved problem on any modern high-level language, and any
GQ> extra benefits from Lisp are likely to be minimal for 99% of
GQ> programming tasks.
I assume this 99% number is coming from the same place you got the
data about professional lisp users not finishing projects. But I
would agree that most programming tasks, where 'most' is measured
by headcounts, LOC or programmer-hours are indeed mundane.
The claim is that the extra benefits from Lisp come in handy (or might
even be essential in some sense) for _interesting_ programming tasks.
What I mean by 'interesting' are things the programmer and the
customer (and quite possibly anyone else) have not done/used before.
This doesn't necessarily mean researchy open ended stuff (where your
deliverable is not likely to be a finished program anyway.) It can
mean things that are just becoming practical (eg: viaweb and such) or
problems nobody really tried to re-solve with modern tools/knowledge
(eg ITA and such).
cheers,
BM
In article <··············@p4.internal>, ··@acm.org says...
> >>>>> "GQ" == Gerry Quinn <······@DELETETHISindigo.ie> writes:
> [question and non-answer elided]
>
> GQ> I think the nub of the issue is that, if you take away the
> GQ> relatively useless ability to write self-modifying code,
>
> I don't understand where this self-modifying code idea is coming from.
> Do you mean the ability to write code that writes code? Self
> modifying code, in the usage I am familiar with, means changing the
> code (not data) in memory as the code itself runs. An example would be
> changing jump destinations in running code by modifying the immediate
> operand of the jump instruction to get home-made memory-indirect jumps
> in ISA's that lack such things. These tricks may have been (ok were)
> cute 15-20 years ago, but they tend to stall the deep pipelines in
> modern processors. Perhaps the usage/meaning of the term has shifted
> due to this?
I would say "self-modifying code" includes any program in which code is
generated and executed as part of the expected output of the program.
It's no longer running itself as originally written.
I know there are inevitable ambiguities and special cases, simply
because there is no real dividing line between code (to be executed) and
data (to be manipulated). I would augment my definition above to
exclude cases in which there is a 'hierarchy of execution levels'. I
would not consider code that runs a cellular automaton that performs a
computation to be self-modifying, for example. The generated code has
to have approximate 'parity of esteem' with the original code.
> GQ> what
> GQ> Lisp is mainly good for is representing complicated
> GQ> algorithms.
>
> This is like saying "what lawyers are good for is winning cases."
> (But to stretch the analogy, the lawyer in question lets you draw up
> interesting contracts too).
You see, you make my point for me. Lisp-ers see one real benefit of
Lisp but they do not realise it is not nearly so important as they
imagine.
> GQ> But representing complicated algorithms is a
> GQ> solved problem on any modern high-level language, and any
> GQ> extra benefits from Lisp are likely to be minimal for 99% of
> GQ> programming tasks.
>
> I assume this 99% number is coming from the same place you got the
> data about professional lisp users not finishing projects. But I
> would agree that most programming tasks, where 'most' is measured
> by headcounts, LOC or programmer-hours are indeed mundane.
>
> The claim is that the extra benefits from Lisp come in handy (or might
> even be essential in some sense) for _interesting_ programming tasks.
> What I mean by 'interesting' are things the programmer and the
> customer (and quite possibly anyone else) have not done/used before.
> This doesn't necessarily mean researchy open ended stuff (where your
> deliverable is not likely to be a finished program anyway.) It can
> mean things that are just becoming practical (eg: viaweb and such) or
> problems nobody really tried to re-solve with modern tools/knowledge
> (eg ITA and such).
But that claim cannot be justified because so many interesting
programming tasks are completed in other languages.
I honestly don't believe there is ANY programming task (excluding those
referring specifically to Lisp!) for which Lisp is in any way essential.
Sure the programming tasks on the page referred to are interesting, but
they are not all *that* special.
- Gerry Quinn
> I would say "self-modifying code" includes any program in which code is
> generated and executed as part of the expected output of the program.
> It's no longer running itself as originally written.
Well, you can do that in Lisp, but it's not usually encouraged. Usually you
generate the code at compile time (using macros) and thus there is no
self-modifying code by your definition.
You're also using a somewhat odd definition of "self-modifying". This is
generally taken to mean code which actually changes existing code at
runtime, rather than just adding more code.
But let's say we accept your definition. Virtually no-one is advocating Lisp
because it has the ability to generate code at runtime. This can be useful
in a few special cases, but it's not usually talked about in pro-Lisp
propaganda -- macros get much more attention.
> I honestly don't believe there is ANY programming task (excluding those
> referring specifically to Lisp!) for which Lisp is in any way essential.
> Sure the programming tasks on the page referred to are interesting, but
> they are not all *that* special.
Maybe we can put that down to Lisp and C++ being Turing Complete ;)
Alex
Gerry Quinn wrote:
> In article <··············@p4.internal>, ··@acm.org says...
>> >>>>> "GQ" == Gerry Quinn <······@DELETETHISindigo.ie> writes:
>> [question and non-answer elided]
>>
>> GQ> I think the nub of the issue is that, if you take away the
>> GQ> relatively useless ability to write self-modifying code,
>>
>> I don't understand where this self-modifying code idea is coming from.
>> Do you mean the ability to write code that writes code? Self
>> modifying code, in the usage I am familiar with, means changing the
>> code (not data) in memory as the code itself runs. An example would be
>> changing jump destinations in running code by modifying the immediate
>> operand of the jump instruction to get home-made memory-indirect jumps
>> in ISA's that lack such things. These tricks may have been (ok were)
>> cute 15-20 years ago, but they tend to stall the deep pipelines in
>> modern processors. Perhaps the usage/meaning of the term has shifted
>> due to this?
>
> I would say "self-modifying code" includes any program in which code is
> generated and executed as part of the expected output of the program.
> It's no longer running itself as originally written.
>
> I know there are inevitable ambiguities and special cases, simply
> because there is no real dividing line between code (to be executed) and
> data (to be manipulated). I would augment my definition above to
> exclude cases in which there is a 'hierarchy of execution levels'. I
> would not consider code that runs a cellular automaton that performs a
> computation to be self-modifying, for example. The generated code has
> to have approximate 'parity of esteem' with the original code.
>
>> GQ> what
>> GQ> Lisp is mainly good for is representing complicated
>> GQ> algorithms.
>>
>> This is like saying "what lawyers are good for is winning cases."
>> (But to stretch the analogy, the lawyer in question lets you draw up
>> interesting contracts too).
>
> You see, you make my point for me. Lisp-ers see one real benefit of
> Lisp but they do not realise it is not nearly so important as they
> imagine.
>
>> GQ> But representing complicated algorithms is a
>> GQ> solved problem on any modern high-level language, and any
>> GQ> extra benefits from Lisp are likely to be minimal for 99% of
>> GQ> programming tasks.
>>
>> I assume this 99% number is coming from the same place you got the
>> data about professional lisp users not finishing projects. But I
>> would agree that most programming tasks, where 'most' is measured
>> by headcounts, LOC or programmer-hours are indeed mundane.
>>
>> The claim is that the extra benefits from Lisp come in handy (or might
>> even be essential in some sense) for _interesting_ programming tasks.
>> What I mean by 'interesting' are things the programmer and the
>> customer (and quite possibly anyone else) have not done/used before.
>> This doesn't necessarily mean researchy open ended stuff (where your
>> deliverable is not likely to be a finished program anyway.) It can
>> mean things that are just becoming practical (eg: viaweb and such) or
>> problems nobody really tried to re-solve with modern tools/knowledge
>> (eg ITA and such).
>
> But that claim cannot be justified because so many interesting
> programming tasks are completed in other languages.
>
> I honestly don't believe there is ANY programming task (excluding those
> referring specifically to Lisp!) for which Lisp is in any way essential.
> Sure the programming tasks on the page referred to are interesting, but
> they are not all *that* special.
>
> - Gerry Quinn
In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > I would say "self-modifying code" includes any program in which code is
> > generated and executed as part of the expected output of the program.
> > It's no longer running itself as originally written.
>
> Well, you can do that in Lisp, but it's not usually encouraged. Usually you
> generate the code at compile time (using macros) and thus there is no
> self-modifying code by your definition.
>
> You're also using a somewhat odd definition of "self-modifying". This is
> generally taken to mean code which actually changes existing code at
> runtime, rather than just adding more code.
I disagree - it is in fact rare for code to be changed per se. What
would be the point in writing code whose only purpose is to be written
over? Whether original code is erased or not is completely irrelevant
to the issue of whether code is self-modifying. The *program* is still
self-modifying.
> But let's say we accept your definition. Virtually no-one is advocating Lisp
> because it has the ability to generate code at runtime. This can be useful
> in a few special cases, but it's not usually talked about in pro-Lisp
> propaganda -- macros get much more attention.
I believe it was part of the belief some years ago that Lisp was somehow
the way to create AI. But I accept that things may have moved on.
Albeit only as far as macros.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > > I would say "self-modifying code" includes any program in which code is
> > > generated and executed as part of the expected output of the program.
> > > It's no longer running itself as originally written.
> >
> > Well, you can do that in Lisp, but it's not usually encouraged. Usually you
> > generate the code at compile time (using macros) and thus there is no
> > self-modifying code by your definition.
> >
> > You're also using a somewhat odd definition of "self-modifying". This is
> > generally taken to mean code which actually changes existing code at
> > runtime, rather than just adding more code.
>
> I disagree - it is in fact rare for code to be changed per se. What
> would be the point in writing code whose only purpose is to be written
> over? Whether original code is erased or not is completely irrelevant
> to the issue of whether code is self-modifying. The *program* is still
> self-modifying.
Because I might get tired of typing something like:
(let ((addr-1 (get-html-value "addr-1"))
(addr-2 (get-html-value "addr-2"))
(city (get-html-value "city"))
(state (get-html-value "state"))
(zip (get-html-value "zip"))
(other-value (some-function (get-html-value "other")))
(name (get-html-value "username")))
...some code...
)
so I write a macro to transform some code and now I can
write thusly:
(with-form-values (addr-1 addr-2 city state zip (name "username")
(other-value "other" some-function))
...some code...)
which is transformed into the top code.
Now I have eliminated a source of typos and made the code much more
readable. Note that a function will not work for this because I am
establishing lexical bindings for "...some code..."
--
Jock Cooper
www.fractal-recursions.com
In article <··············@jcooper02.sagepub.com>, ·····@mail.com
says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > I disagree - it is in fact rare for code to be changed per se. What
> > would be the point in writing code whose only purpose is to be written
> > over? Whether original code is erased or not is completely irrelevant
> > to the issue of whether code is self-modifying. The *program* is still
> > self-modifying.
>
> Because I might get tired of typing something like:
>
> (let ((addr-1 (get-html-value "addr-1"))
> (addr-2 (get-html-value "addr-2"))
[--]
> so I write a macro to transform some code and now I can
> write thusly:
>
> (with-form-values (addr-1 addr-2 city state zip (name "username")
> (other-value "other" some-function))
> ...some code...)
>
> which is transformed into the top code.
>
> Now I have eliminated a source of typos and made the code much more
> readable. Note that a function will not work for this because I am
> establishing lexical bindings for "...some code..."
Sure, that's a reason why you might want to use this. And I think, if
you are making the point that this should not be called 'self-modifying
code' in the proper sense, you do have a point - you are manipulating
strings in a way that might be handled elsewise in another language. If
you look at the above, it's really data you are manipulating, not code.
> --
> Jock Cooper
> www.fractal-recursions.com
Downloaded your 'UltraFractal'. I was curious to see if it was written
in Lisp, but it doesn't appear so. [Not that that invalidates anything
you say.]
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··············@jcooper02.sagepub.com>, ·····@mail.com
> says...
> > Gerry Quinn <······@DELETETHISindigo.ie> writes:
> >
> > > I disagree - it is in fact rare for code to be changed per se. What
> > > would be the point in writing code whose only purpose is to be written
> > > over? Whether original code is erased or not is completely irrelevant
> > > to the issue of whether code is self-modifying. The *program* is still
> > > self-modifying.
> >
> > Because I might get tired of typing something like:
> >
> > (let ((addr-1 (get-html-value "addr-1"))
> > (addr-2 (get-html-value "addr-2"))
> [--]
> > so I write a macro to transform some code and now I can
> > write thusly:
> >
> > (with-form-values (addr-1 addr-2 city state zip (name "username")
> > (other-value "other" some-function))
> > ...some code...)
> >
> > which is transformed into the top code.
> >
> > Now I have eliminated a source of typos and made the code much more
> > readable. Note that a function will not work for this because I am
> > establishing lexical bindings for "...some code..."
>
> Sure, that's a reason why you might want to use this. And I think, if
> you are making the point that this should not be called 'self-modifying
> code' in the proper sense, you do have a point - you are manipulating
> strings in a way that might be handled elsewise in another language. If
> you look at the above, it's really data you are manipulating, not code.
No, I am not manipulating strings or data, I am manipulating code.
Although C macros work on strings, Lisp macros do not, despite the
fact that the Lisp source code does reside in a file. This is because
the Lisp reader parses the expressions for me and hands my macro a
data structure. This particular example is rather simple, but there
are plenty of other uses of macros in which a code 'tree' is
traversed, examined and transformed. This is far more powerful than
simple string substitution as C has.
Another example:
(ITER (WITH specials = (get-sorted-specials unsorted-list))
(WITH result = '())
(FOR (sym . str) IN specials)
(FOR char0 = (char str 0))
(FOR char1 = (and (= 2 (length str)) (char str 1)))
(FOR lchar0 PREVIOUS char0 INITIALLY nil)
(FOR pair = (assoc char0 result :test #'char=))
(if (null pair)
(push (setf pair (cons char0 nil)) result)
(case lchar0
(#\a (COLLECT char0 into a-list))
(#\b (COLLECT char0 into b-list))))
(FOR new = (cons char1 sym))
(push new (cdr pair))
(FINALLY (return result)))
ITER is a macro, and it does not get a big string to process. It gets
a forms (fyi a form is either an atom or a list of atoms and/or
forms), which it examines and transforms to build the resulting code.
Here, some of those forms contain symbols defined by ITER, some are
'ordinary' lisp. The ITER symbols can be anywhere in the code block,
ITER will find them and handle them properly in the result. I
capitalized them above. Notice the COLLECT words down in the IF's
else form. Lisp macros are so powerful because the macro operates on
the parse tree of the code. It is trivial for ITER to locate the
COLLECT words and insert the code for them.
Again I also want to stress that I can't use a function to do this type
of abstraction; I want all of the resulting code (including transformed
bits and other bits just used as is) to be in the same lexical scope.
Below is what the ITER macro expands into for the above code. I show
you all this to give you an idea of the amazing amount of crap that
can be cut out of your programs if you use macros to abstract away the
scaffolding.
(LET* ((SPECIALS (GET-SORTED-SPECIALS UNSORTED-LIST))
(RESULT 'NIL)
(#:LIST36 NIL)
(SYM NIL)
(STR NIL)
(CHAR0 NIL)
(CHAR1 NIL)
(LCHAR0 NIL)
(PAIR NIL)
(A-LIST NIL)
(#:END-POINTER37 NIL)
(#:TEMP38 NIL)
(B-LIST NIL)
(#:END-POINTER39 NIL)
(NEW NIL)
(#:POST-SAVE-CHAR0-40 NIL))
(BLOCK NIL
(TAGBODY
(SETQ #:LIST36 SPECIALS)
(SETQ LCHAR0 NIL)
(SETQ #:POST-SAVE-CHAR0-40 NIL)
LOOP-TOP-NIL
(IF (ATOM #:LIST36) (GO LOOP-END-NIL))
(LET ((#:G3840 (CAR #:LIST36)))
(SETQ SYM (CAR #:G3840))
(SETQ STR (CDR #:G3840))
#:G3840)
(SETQ #:LIST36 (CDR #:LIST36))
(PROGN (SETQ LCHAR0 #:POST-SAVE-CHAR0-40))
(SETQ CHAR0 (CHAR STR 0))
(PROGN (SETQ #:POST-SAVE-CHAR0-40 CHAR0))
(SETQ CHAR1 (IF (= 2 (LENGTH STR)) (CHAR STR 1)))
(SETQ PAIR (ASSOC CHAR0 RESULT :TEST #'CHAR=))
(IF (NULL PAIR)
(SETQ RESULT (CONS (SETQ PAIR (CONS CHAR0 NIL)) RESULT))
(LET ((#:G3841 LCHAR0))
#:G3841
(IF (EQL #:G3841 '#\a)
(PROGN
NIL
(PROGN
(SETQ #:TEMP38 (LIST CHAR0))
(SETQ #:END-POINTER37
(IF A-LIST
(SETF (CDR #:END-POINTER37) #:TEMP38)
(SETQ A-LIST #:TEMP38)))
A-LIST))
(IF (EQL #:G3841 '#\b)
(PROGN
NIL
(PROGN
(SETQ #:TEMP38 (LIST CHAR0))
(SETQ #:END-POINTER39
(IF B-LIST
(SETF (CDR #:END-POINTER39) #:TEMP38)
(SETQ B-LIST #:TEMP38)))
B-LIST))))))
(SETQ NEW (CONS CHAR1 SYM))
(LET* ((#:G3844 NEW)
(#:G3843 PAIR)
(#:G3842 (CONS #:G3844 (CDR #:G3843))))
(COMMON-LISP::%RPLACD #:G3843 #:G3842))
(GO LOOP-TOP-NIL)
LOOP-END-NIL
(RETURN RESULT))
NIL))
However, there are those who feel that defining new syntax is too
powerful a feature for a language, they should stay clear of this sort
of thing.
>
> > --
> > Jock Cooper
> > www.fractal-recursions.com
>
> Downloaded your 'UltraFractal'. I was curious to see if it was written
> in Lisp, but it doesn't appear so. [Not that that invalidates anything
> you say.]
Actually Ultra Fractal was written by Frederik Slijkerman and is available
(as you must have found) at www.ultrafractal.com. I just used it to create
the various images and animations on my site. I believe UF is written in
Delphi.
In article <··············@jcooper02.sagepub.com>, ·····@mail.com
says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > > Now I have eliminated a source of typos and made the code much more
> > > readable. Note that a function will not work for this because I am
> > > establishing lexical bindings for "...some code..."
> >
> > Sure, that's a reason why you might want to use this. And I think, if
> > you are making the point that this should not be called 'self-modifying
> > code' in the proper sense, you do have a point - you are manipulating
> > strings in a way that might be handled elsewise in another language. If
> > you look at the above, it's really data you are manipulating, not code.
>
> No, I am not manipulating strings or data, I am manipulating code.
> Although C macros work on strings, Lisp macros do not, despite the
> fact that the Lisp source code does reside in a file. This is because
> the Lisp reader parses the expressions for me and hands my macro a
> data structure. This particular example is rather simple, but there
> are plenty of other uses of macros in which a code 'tree' is
> traversed, examined and transformed. This is far more powerful than
> simple string substitution as C has.
There is no firm dividing line between data and code. Data is
structured code. Code is executable data. Your first example looks
more like data to me, your second looks more like self-modifying code.
But in any case, this kind of stuff can be dealt with in any high-level
language.
> However, there are those who feel that defining new syntax is too
> powerful a feature for a language, they should stay clear of this sort
> of thing.
And their are those who are more interested in 'clever' programming than
in producing useful software - they will doubtless love it.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> And their are those who are more interested in 'clever' programming than
> in producing useful software - they will doubtless love it.
You cannot dismiss a powerful feature of a programming language by
disparaging the motivations of those who use the feature. The feature is
powerful, and that is that.
As for those who use the feature, it is always about producing software.
Great athletes do not make fancy moves to show off*, they do it to fake
the fullback out of his jockstrap on their way to the goal.
If you check that Lisp newbie survey, you will find a whole category for
folks who, before they discovered Lisp, had crudely re-invented some
unusual capability of Lisp, precisely because they were reaching for the
expressive power it promised.
Does every programmer feel held back by Java/C++/whatever? No. We once
discovered a consultant had cut and pasted fifteen lines of Vax Basic
twenty times; changing each time the three variables to make the code
work in the new context, rather than create a function with three
parameters.
But any good programmer is certainly held back by lesser languages. I
found Lisp because, well, there is another category in the survey, for
those who went on an active search for a better way before they even
knew there was a better way, simply because they sensed that they were
being held back by their languages.
kenny
Kenneth Tilton <·······@nyc.rr.com> wrote in message news:<·····························@nyctyp02-ge0.rdc-nyc.rr.com>...
> But any good programmer is certainly held back by lesser languages. I
> found Lisp because, well, there is another category in the survey, for
> those who went on an active search for a better way before they even
> knew there was a better way, simply because they sensed that they were
> being held back by their languages.
"Certainly" ?
I'd rather say for a good programmer there's no such thing as a
"lesser language". You either get the job done or you don't.
Everything else are sorry excuses.
~velco
·····@fadata.bg (Momchil Velikov) writes:
> I'd rather say for a good programmer there's no such thing as a
> "lesser language". You either get the job done or you don't.
> Everything else are sorry excuses.
Yes, thanks to Greenspun's Tenth Law.
--
__Pascal Bourguignon__
In article <····························@posting.google.com>,
·····@fadata.bg (Momchil Velikov) wrote:
> Kenneth Tilton <·······@nyc.rr.com> wrote in message
> news:<·····························@nyctyp02-ge0.rdc-nyc.rr.com>...
> > But any good programmer is certainly held back by lesser languages. I
> > found Lisp because, well, there is another category in the survey, for
> > those who went on an active search for a better way before they even
> > knew there was a better way, simply because they sensed that they were
> > being held back by their languages.
>
> "Certainly" ?
>
> I'd rather say for a good programmer there's no such thing as a
> "lesser language".
Well, let's not get into word-quibbles. 6502 assembler is a fine
language, but the subject here is getting real projects done. Folks
worked out a while ago that an HLL would let programmers think at a
higher level of abstraction without mug cost; a good compiler might even
outdo some handcoded assembly language. So 6502 is sweet, but as far as
productivity goes it simply does not measure up.
As Eckel said, the key is programmer productivity, and an order of
magnitude improvement in that is worth a few cycles one might save by
coding in assembler (tho I guess he was contrasting Python with C++,
which is quite a bit more than a few cycles.).
> You either get the job done or you don't.
Well, I keep pointing out that Lisp programmers tend also to kick ass in
more popular languages. They do get the job done. And they find Lisp
precisely because they are the best programmers and have ideas their
current languages cannot handle.
The guy who cuts and pastes code because they are not sure of the syntax
of a function in Vax Basic is most certainly not noticing metapatterns
in code which could be handled by procedural macros.
> Everything else are sorry excuses.
Same answer. Who needs an excuse when they are the best in the shop and
deliver C++ or Java or Cobol faster than anyone else in the shop?
kenny
Kenneth Tilton <·······@nyc.rr.com> writes:
> Well, let's not get into word-quibbles. 6502 assembler is a fine
> language, but the subject here is getting real projects done. Folks
> worked out a while ago that an HLL would let programmers think at a
> higher level of abstraction without mug cost; a good compiler might even
> outdo some handcoded assembly language. So 6502 is sweet, but as far as
> productivity goes it simply does not measure up.
Yes, it does. Just implement a lisp on 6502 and you're done.
> As Eckel said, the key is programmer productivity, and an order of
> magnitude improvement in that is worth a few cycles one might save by
> coding in assembler (tho I guess he was contrasting Python with C++,
> which is quite a bit more than a few cycles.).
Of course, the difference is made by a programmer who would try to do
all his application in 6502 and the one who will implement the lisp on
6502 and do the application in lisp.
--
__Pascal Bourguignon__
In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
·······@nyc.rr.com says...
>
> But any good programmer is certainly held back by lesser languages. I
> found Lisp because, well, there is another category in the survey, for
> those who went on an active search for a better way before they even
> knew there was a better way, simply because they sensed that they were
> being held back by their languages.
And if Lisp programmers were demonstrably more productive and effective,
I'd take such claims seriously. As, more importantly, would those who
tend to hire programmers.
[Likewise for 'agile' programmers, or 'test-driven' programmers, or
'generic' programmers, or any other of the many varieties of silver
bullet programmers.]
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> And if Lisp programmers were demonstrably more productive and effective,
> I'd take such claims seriously.
There's at least one data point:
http://www.flownet.com/gat/papers/lisp-java.pdf
rg
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
> ·······@nyc.rr.com says...
> >
> > But any good programmer is certainly held back by lesser languages. I
> > found Lisp because, well, there is another category in the survey, for
> > those who went on an active search for a better way before they even
> > knew there was a better way, simply because they sensed that they were
> > being held back by their languages.
>
> And if Lisp programmers were demonstrably more productive and effective,
> I'd take such claims seriously.
Claims? What claims? Those are good programmers who answered my survey
by saying they went looking for a better way and found it. Do you think
that survey is a mass conspiracy to promote Lisp? If so, why have C++
guru's joined the conspiracy?:
http://www.mindview.net/WebLog/log-0025
Titled: "Thinking About Computing -- Bruce Eckel's Web Log"
Highlight film: "In recent years my primary interest has become
programmer productivity. Programmer cycles are expensive, CPU cycles are
cheap, and I believe that we should no longer pay for the latter with
the former.
How can we get maximal leverage on the problems we try to solve?
Whenever a new tool (especially a programming language) appears, that
tool provides some kind of abstraction that may or may not hide needless
detail from the programmer. I have come, however, to always be on watch
for a Faustian bargain, especially one that tries to convince me to
ignore all the hoops I must jump through in order to achieve this
abstraction. Perl is an excellent example of this...
"....This began with a 2-month love affair with Perl, which gave me
productivity through rapid turnaround. (The affair was terminated
because of Perl's reprehensible treatment of references and classes...
" After I had worked with Python (free at www.Python.org) for awhile a
language which can build large, complex systems I began noticing that
despite an apparent carelessness about type checking, Python programs
seemed to work quite well without much effort, and without the kinds of
problems you would expect from a language that doesn't have the strong,
static type checking that we've all come to "know" is the only correct
way of solving the programming problem.
" This became a puzzle to me: if strong static type checking is so
important, why are people able to build big, complex Python programs
(with much shorter time and effort than the strong static counterparts)
without the disaster that I was so sure would ensue?
" This shook my unquestioning acceptance of strong type checking
(acquired when moving from C to C++, where the improvement was
dramatic)...
" But deciding that [Java's] checked exceptions seem like more trouble
than they're worth (the checking, not the exception. I believe that a
single, consistent error reporting mechanism is essential) did not
answer the question "why does Python work so well, when conventional
wisdom says it should produce massive failures?"
The recurring theme here is much greater productivity (even in Perl)
when one can shed the syntactic strait jackets and find some other way
to get to program correctness. And that is what I am talking about when
I say some folks found Lisp because they knew there had to be a better
way, that they were being held back.
Gerry, the simple fact is that you would be much more productive in Lisp
than you are in C++. Python, too, but that is still pretty slow and a
bit of a hack as languages go. Here is another C++ guru:
http://www.artima.com/weblogs/viewpost.jsp?thread=4639
I will let Eckels summarize what you will find there (watch for the
phrase "could be much more productive"):
"Robert Martin is one of the long-time inhabitants of the C++ community.
He's written books and articles, consulted, taught, etc. A pretty
hard-core, strong- static type checking guy. Or so I would have thought,
until I read this weblog entry. Robert came to more or less the same
conclusion I have, but he did so by becoming "test infected" first, then
realizing that the compiler was just one (incomplete) form of testing,
then understanding that a weakly-typed language could be much more
productive but create programs that are just as robust as those written
in strongly-typed languages, by providing adequate testing."
As for how crazy this all sounds:
" Of course, Martin also recieved [sic] the usual "how can you possibly
think this?" comments. Which is the very question that lead [sic] me to
begin struggling with the strong/weak typing concepts in the first
place. And certainly both of us began as strong static type checking
advocates. It's interesting that it takes an earth-shaking experience
like becoming test-infected or learning a different kind of language to
cause a re-evaluation of beliefs."
kenny
In article <·····························@nyctyp01-ge0.rdc-nyc.rr.com>,
·······@nyc.rr.com says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> >
> > And if Lisp programmers were demonstrably more productive and effective,
> > I'd take such claims seriously.
>
> Claims? What claims? Those are good programmers who answered my survey
> by saying they went looking for a better way and found it.
[Followed by some claims by two guys. Guys who may be eminent in the
computing field but whose primary work seems to be writing and
consulting. Guys who therefore have a vested interest in language churn
and silver bullets.]
What exactly did they *build* with their various flavour-of-the-month
languages?
> Gerry, the simple fact is that you would be much more productive in Lisp
> than you are in C++. Python, too, but that is still pretty slow and a
> bit of a hack as languages go.
Why is that a fact? Can you point me to the Windows games and
screensavers written in these languages?
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
>> Claims? What claims? Those are good programmers who answered my survey
>> by saying they went looking for a better way and found it.
>
> [Followed by some claims by two guys. Guys who may be eminent in the
> computing field but whose primary work seems to be writing and
> consulting. Guys who therefore have a vested interest in language churn
> and silver bullets.]
>
> What exactly did they *build* with their various flavour-of-the-month
> languages?
Anybody else's irony meter pinging its glass casing? Lisp, with roots 40+
years old and a decade old ANSI standard being referred to as "flavour of
the month"!
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
In article <·····················@clgrps13>, ·····@mercury.bc.ca says...
> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> ·······························@news.indigo.ie...
> >> Claims? What claims? Those are good programmers who answered my survey
> >> by saying they went looking for a better way and found it.
> >
> > [Followed by some claims by two guys. Guys who may be eminent in the
> > computing field but whose primary work seems to be writing and
> > consulting. Guys who therefore have a vested interest in language churn
> > and silver bullets.]
> >
> > What exactly did they *build* with their various flavour-of-the-month
> > languages?
>
> Anybody else's irony meter pinging its glass casing? Lisp, with roots 40+
> years old and a decade old ANSI standard being referred to as "flavour of
> the month"!
But didn't one of them write about how great and productive Perl was for
a couple of months before he decided it was actually crap and went on to
Python or something?
Again, I don't have a clue what software he developed during these two
months of fevered Perl productivity...
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> wrote
> But didn't one of them write about how great and productive Perl was for
> a couple of months before he decided it was actually crap and went on to
> Python or something?
No, that was Bruce Eckel at <URL:
http://www.mindview.net/WebLog/log-0025>.
AFAIK, he hasn't been converted to Lisp yet, so he is *still* doomed
to a tantalizing and hopeless search for a usable programming language
;-)
Gerry Quinn wrote:
> In article <·····················@clgrps13>, ·····@mercury.bc.ca says...
>> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
>> ·······························@news.indigo.ie...
>> >> Claims? What claims? Those are good programmers who answered my survey
>> >> by saying they went looking for a better way and found it.
>> >
>> > [Followed by some claims by two guys. Guys who may be eminent in the
>> > computing field but whose primary work seems to be writing and
>> > consulting. Guys who therefore have a vested interest in language
>> > churn and silver bullets.]
>> >
>> > What exactly did they *build* with their various flavour-of-the-month
>> > languages?
>>
>> Anybody else's irony meter pinging its glass casing? Lisp, with roots
>> 40+ years old and a decade old ANSI standard being referred to as
>> "flavour of the month"!
>
> But didn't one of them write about how great and productive Perl was for
> a couple of months before he decided it was actually crap and went on to
> Python or something?
>
> Again, I don't have a clue what software he developed during these two
> months of fevered Perl productivity...
>
The search for something better goes ever on.
Hopefully he'll end up with Lisp eventually, but maybe he's happy as he is.
I had a brief romance with Python myself before I found Lisp, but that means
nothing at this point; I'm *sticking* with Lisp, as, apparently, are
everyone else.
Svein Ove Aas <·········@aas.no> wrote in message news:<············@services.kq.no>...
> Gerry Quinn wrote:
>
> > In article <·····················@clgrps13>, ·····@mercury.bc.ca says...
> >> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> >> ·······························@news.indigo.ie...
> >> >> Claims? What claims? Those are good programmers who answered my survey
> >> >> by saying they went looking for a better way and found it.
> >> >
> >> > [Followed by some claims by two guys. Guys who may be eminent in the
> >> > computing field but whose primary work seems to be writing and
> >> > consulting. Guys who therefore have a vested interest in language
> >> > churn and silver bullets.]
> >> >
> >> > What exactly did they *build* with their various flavour-of-the-month
> >> > languages?
> >>
> >> Anybody else's irony meter pinging its glass casing? Lisp, with roots
> >> 40+ years old and a decade old ANSI standard being referred to as
> >> "flavour of the month"!
> >
> > But didn't one of them write about how great and productive Perl was for
> > a couple of months before he decided it was actually crap and went on to
> > Python or something?
> >
> > Again, I don't have a clue what software he developed during these two
> > months of fevered Perl productivity...
> >
> The search for something better goes ever on.
> Hopefully he'll end up with Lisp eventually, but maybe he's happy as he is.
>
> I had a brief romance with Python myself before I found Lisp, but that means
> nothing at this point; I'm *sticking* with Lisp, as, apparently, are
> everyone else.
People tend to stick with Common Lisp because there is nowhere else to
go without compromising something. Not having access to the source
code as a data structure is a very, very bad hit to have to take, so
that rules out the vast majority of languages.
Before I got into Lisp, I was quite a bit into meta-programming. I'm
one of those guys who used Lex and Yacc countless times. It was hard
for me to complete a project without some custom language being used
in it somewhere. :)
In Lisp you can just integrate the custom language into the program,
and nobody thinks it's a big deal. Other Lisp programmers accept and
understand what you have done as a matter of course.
You are allowed to think along the lines: how do I extend the language
so that it meets the challenges of my current problem?
After a while, you really get used to this.
Once some great programmer said that no matter what language he works
in, he thinks in just one language.
Programmers who think in Fortran tend to believe that all languages
are basically just syntactic sugars for the same thing. They prove
that to themselves by continously encountering success in testing
their ability to write Fortran in any language they encounter. Lisp
just appears as Fortran with parentheses.
The Lisp programmer's internal language isn't Fortran, with its
imperative statements, loops and variables. The internal language is
an empty abstract syntax tree, to which that programmer is willing to
assign any semantics whatsoever.
When you think that way, then languages which don't let you encode
those semantics just get in your way, because you have to do the
translation of your internal language in your head, and then use your
fingers to spit out the translation. You have to do the tedious job of
the compiler that you are not able to write. In Lisp, you write that
compiler, insert it into your program, and then write in the real
language in which you conceived the solution. Other people then see
and understand your language directly, instead of having to guess at
it by reverse-engineering a hand-written translation.
In article <····························@posting.google.com>,
···@ashi.footprints.net says...
> The Lisp programmer's internal language isn't Fortran, with its
> imperative statements, loops and variables. The internal language is
> an empty abstract syntax tree, to which that programmer is willing to
> assign any semantics whatsoever.
>
> When you think that way, then languages which don't let you encode
> those semantics just get in your way, because you have to do the
> translation of your internal language in your head, and then use your
> fingers to spit out the translation. You have to do the tedious job of
> the compiler that you are not able to write. In Lisp, you write that
> compiler, insert it into your program, and then write in the real
> language in which you conceived the solution. Other people then see
> and understand your language directly, instead of having to guess at
> it by reverse-engineering a hand-written translation.
So if you asked a Fortran programmer to acquaint you with the thoughts
of Aristotle, he would give you an English translation of his works.
Whereas a Lisp programmer would give you the original, plus a copy of
'Teach Yourself Ancient Greek'.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <····························@posting.google.com>,
> ···@ashi.footprints.net says...
> > The Lisp programmer's internal language isn't Fortran, with its
> > imperative statements, loops and variables. The internal language is
> > an empty abstract syntax tree, to which that programmer is willing to
> > assign any semantics whatsoever.
> >
> > When you think that way, then languages which don't let you encode
> > those semantics just get in your way, because you have to do the
> > translation of your internal language in your head, and then use your
> > fingers to spit out the translation. You have to do the tedious job of
> > the compiler that you are not able to write. In Lisp, you write that
> > compiler, insert it into your program, and then write in the real
> > language in which you conceived the solution. Other people then see
> > and understand your language directly, instead of having to guess at
> > it by reverse-engineering a hand-written translation.
>
> So if you asked a Fortran programmer to acquaint you with the thoughts
> of Aristotle, he would give you an English translation of his works.
> Whereas a Lisp programmer would give you the original, plus a copy of
> 'Teach Yourself Ancient Greek'.
Argument by analogy! I love these!! Seriously, I checked out your web
site, and I think it might be helpful to turn the challenge "Show me the
Lisp game!" around: what exactly do you think Lisp might not be able to
handle in writing such games? The logic? The graphics? The GUI?
Performance? Other?
After all the ranting about how different is Lisp, at one level it
really is just a conventional HLL, with functions, iteration, objects,
structures, arrays, etc, etc.
All your games could be done easily in Lisp, and because Lisp is so much
more productive you could put more time and energy into the graphics and
gameplay logic and still finish sooner.
kenny
In article <·····························@nycmny-nntp-rdr-03-ge1.rdc-
nyc.rr.com>, ·······@nyc.rr.com says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> Argument by analogy! I love these!! Seriously, I checked out your web
> site, and I think it might be helpful to turn the challenge "Show me the
> Lisp game!" around: what exactly do you think Lisp might not be able to
> handle in writing such games? The logic? The graphics? The GUI?
> Performance? Other?
My biggest concern (leaving pure language and re-use considerations out
of it) would be easy integration with standard Windows controls and
features. I would also require the creation of reasonably compact
downloadable .exes that would work reliably on just about any Windows
machine, and would not require downloading of added libraries or
environments.
Compare Java, as an example. I could write all my games in Java, though
two of my screensavers would be unusably slow. But the buttons would
look odd and to my mind ugly, unless I messed around with an interface
to the native API. And many people would need to download a runtime.
Even if I preferred Java to C++ (and in fact I prefer C++) I would not
use it unless it had major advantages for some purpose. (I've done some
applets.)
> After all the ranting about how different is Lisp, at one level it
> really is just a conventional HLL, with functions, iteration, objects,
> structures, arrays, etc, etc.
>
> All your games could be done easily in Lisp, and because Lisp is so much
> more productive you could put more time and energy into the graphics and
> gameplay logic and still finish sooner.
But this is the thing - you go on about how Lisp is "so much more
productive" but there's no evidence of it! My 'Concentration' clone
(see else-thread) is about the same length as Michael Naunton's and took
about the same time to write. No doubt each one has its own advantages,
and might be more or less comprehensible to any given person. But the
key point is that IT DOESN'T MATTER. The time it takes to sling
together a few algorithms and produce a basic pre-designed game is
insignificant. Even if Lisp were ten times more productive in this
regard, it wouldn't make any difference. Produce a finished reasonably
original game, even a small one, and see!
Productivity in messing around with small programs that are not for
general release is not really an advantage. I'll grant you there is a
bit more cruft in a typical small C++ program, but that may be because
we typically start off in a more basic environment. In the long run,
all that matters is that we can keep the amount of visible cruft within
reason all the way to the finished product.
Call it prejudice if you like, but I *trust* C++, like C before it, to
not fail in this regard. Even for apps much much bigger than mine.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> But this is the thing - you go on about how Lisp is "so much more
> productive" but there's no evidence of it!
There is this website called Google where you can go
and type things like "lisp comparison C++" and it
lists relevant web pages and if you click on the
links you can go to those web pages and read
what others have said on the issue. When I typed
that query, Google responded that there were no
matches, proving that you're right...er, no, wait,
it did find a number of matches. So I clicked on
a few and found some interesting, honest evaluations.
http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
http://www.lisp.org/table/compare.htm
http://www.python.org/doc/essays/comparisons.html
http://www.flownet.com/gat/papers/lisp-java.pdf
http://www.norvig.com/java-lisp.html
http://www.memorymanagement.org/articles/lang.html
http://http.cs.berkeley.edu/~fateman/papers/software.pdf
http://lemonodor.com/archives/000180.html
http://www.franz.com/success/customer_apps/data_mining/cadabra.lhtml
Those are from the first few pages that this website
called Google returns. I was unwilling to search
any longer for what I consider the most detailed
comparison of Lisp, C++, and Java by programmers at
an observatory looking for the best language in which
to continue software development. Maybe Googgle will
favor you with the link I could not find.
>>>>> "SV" == Sashank Varma <····@vanderbilt.edu> writes:
SV> ... I was unwilling to search any longer for what
SV> I consider the most detailed comparison of Lisp, C++, and Java
SV> by programmers at an observatory looking for the best language
SV> in which to continue software development. Maybe Googgle will
SV> favor you with the link I could not find.
Well Google wasn't being very agreeable (the original link no longer
works) but a bit stubborn searching (having the orginal on file helped)
gave this link:
http://act-r.psy.cmu.edu/~douglass/Douglass/Agents/Lisp/psflang-report.pdf
If you had something else in mind, I'd also be very interested to read
that.
cheers,
BM
In article <··············@p4.internal>,
Bulent Murtezaoglu <··@acm.org> wrote:
> >>>>> "SV" == Sashank Varma <····@vanderbilt.edu> writes:
> SV> ... I was unwilling to search any longer for what
> SV> I consider the most detailed comparison of Lisp, C++, and Java
> SV> by programmers at an observatory looking for the best language
> SV> in which to continue software development. Maybe Googgle will
> SV> favor you with the link I could not find.
>
> Well Google wasn't being very agreeable (the original link no longer
> works) but a bit stubborn searching (having the orginal on file helped)
> gave this link:
>
> http://act-r.psy.cmu.edu/~douglass/Douglass/Agents/Lisp/psflang-report.pdf
>
> If you had something else in mind, I'd also be very interested to read
> that.
No, that's the one. Thanks for the pointer.
In article <··························@news.vanderbilt.edu>,
····@vanderbilt.edu says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> > But this is the thing - you go on about how Lisp is "so much more
> > productive" but there's no evidence of it!
>
> There is this website called Google where you can go
> and type things like "lisp comparison C++" and it
> lists relevant web pages and if you click on the
> links you can go to those web pages and read
> what others have said on the issue.
But they don't address the point I was making:
"The time it takes to sling together a few algorithms and produce a
basic pre-designed game is insignificant. Even if Lisp were ten times
more productive in this regard, it wouldn't make any difference. [...]
Productivity in messing around with small programs that are not for
general release is not really an advantage."
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> But they don't address the point I was making:
>
> "The time it takes to sling together a few algorithms and produce a
> basic pre-designed game is insignificant. Even if Lisp were ten times
> more productive in this regard, it wouldn't make any difference. [...]
> Productivity in messing around with small programs that are not for
> general release is not really an advantage."
What /is/ your point here? You seem to imply that Lisp doesn't have
an productivity advantage for anything larger than a small toy program.
If that's what you mean, you're wrong.
--
(espen)
In article <··························@news.indigo.ie>,
······@DELETETHISindigo.ie says...
> [...]
> But they don't address the point I was making:
>
> "The time it takes to sling together a few algorithms and produce a
> basic pre-designed game is insignificant. Even if Lisp were ten times
> more productive in this regard, it wouldn't make any difference. [...]
> Productivity in messing around with small programs that are not for
> general release is not really an advantage."
Tell me, is your point based on:
a) your extensive experience writing large programs,
b) your extensive experience with Lisp, or perhaps
c) your complete lack of experience with either.
Christer Ericson
Sony Computer Entertainment, Santa Monica
In article <··························@news.verizon.net>,
················@NOTplayTHISstationBIT.sony.com says...
> In article <··························@news.indigo.ie>,
> ······@DELETETHISindigo.ie says...
> > [...]
> > But they don't address the point I was making:
> >
> > "The time it takes to sling together a few algorithms and produce a
> > basic pre-designed game is insignificant. Even if Lisp were ten times
> > more productive in this regard, it wouldn't make any difference. [...]
> > Productivity in messing around with small programs that are not for
> > general release is not really an advantage."
>
> Tell me, is your point based on:
>
> a) your extensive experience writing large programs,
> b) your extensive experience with Lisp, or perhaps
> c) your complete lack of experience with either.
It is based on my extensive experience in writing programs that are
large compared to the toy programs being discussed.
Christer, I suggest you back off. I didn't insult you when you made a
fool of yourself on the "Fibonacci Serie : looking for a fast recursive
algorithm" thread on c.g.d.p.algorithms a few weeks ago, even though you
gave the distinct impression of having jumped in simply to seize what
seemed like an opportunity to prove me wrong. [Well, having failed on
algorithmic complexity theory, you DID eventually get me on a spelling
error. Kudos, man.]
If you have something interesting to contribute about the benefits or
otherwise of Lisp for games development, or an argument other than ad
hominem as to why the point I make above is invalid, I am sure we would
all enjoy reading it.
- Gerry Quinn
In article <··························@news.indigo.ie>,
······@DELETETHISindigo.ie says...
> In article <··························@news.verizon.net>,
> ················@NOTplayTHISstationBIT.sony.com says...
> > In article <··························@news.indigo.ie>,
> > ······@DELETETHISindigo.ie says...
> > > [...]
> > > But they don't address the point I was making:
> > >
> > > "The time it takes to sling together a few algorithms and produce a
> > > basic pre-designed game is insignificant. Even if Lisp were ten times
> > > more productive in this regard, it wouldn't make any difference. [...]
> > > Productivity in messing around with small programs that are not for
> > > general release is not really an advantage."
> >
> > Tell me, is your point based on:
> >
> > a) your extensive experience writing large programs,
> > b) your extensive experience with Lisp, or perhaps
> > c) your complete lack of experience with either.
>
> It is based on my extensive experience in writing programs that are
> large compared to the toy programs being discussed.
>
> Christer, I suggest you back off.
No, seriously, do you have any experience whatsoever with
either large programs or Lisp? If not, what grounds do
you have for making this point?
Christer Ericson
Sony Computer Entertainment, Santa Monica
In article <·························@news.verizon.net>,
················@NOTplayTHISstationBIT.sony.com says...
> In article <··························@news.indigo.ie>,
> ······@DELETETHISindigo.ie says...
> > > > But they don't address the point I was making:
> > > >
> > > > "The time it takes to sling together a few algorithms and produce a
> > > > basic pre-designed game is insignificant. Even if Lisp were ten times
> > > > more productive in this regard, it wouldn't make any difference. [...]
> > > > Productivity in messing around with small programs that are not for
> > > > general release is not really an advantage."
> > >
> > > Tell me, is your point based on:
> > >
> > > a) your extensive experience writing large programs,
> > > b) your extensive experience with Lisp, or perhaps
> > > c) your complete lack of experience with either.
> >
> > It is based on my extensive experience in writing programs that are
> > large compared to the toy programs being discussed.
> >
> > Christer, I suggest you back off.
>
> No, seriously, do you have any experience whatsoever with
> either large programs or Lisp? If not, what grounds do
> you have for making this point?
I answered you: obviously I have experience with programs *large enough*
to be able to make this point. The games on my website are quite large
enough. Any game bigger than about 2 KLOC that has significant non-code
elements is large enough. With the exception of Naughty Dog's not
particularly successful experiments with using Lisp [I make no comment
about the games themselves - I know they have been well-received but I
haven't played them], my games seem in fact to be about as large as any
game that has ever been developed in Lisp. Which justifies my
observation in another way. If it's so great, why isn't it competing in
the marketplace?
And furthermore:
With regard to "slinging together a few algorithms and producing a basic
pre-designed game", you may note that I've done that in C++ and two
others have done it in Lisp on this thread, taking about two hours each.
And now if we want to extend this rather trivial but playable game, we
will have to sit back and think about user interfaces, graphics,
gameplay options, etc. We'll have a little bit of algorithmic work to
do if we want to create AIs, but again it will be a tiny part of it.
Probably it will take longer to select / create a series of AI faces to
respond to game state than it will to code the AI for 'Concentration',
(though it must be admitted that this is as primitive as AI gets). In
other words, MAKING FINISHED GAMES IS NOT ABOUT EASE OF EXPRESSING
ALGORITHMS. And I see no reason to suppose that it will become so in
larger projects, even in _James Bond's 3D Concentration 2005_. So,
irrespective of any experience I may or may not have, I consider the
point substantially justified by argument on this very thread.
Now, are you going to address the point, or continue with the ad
hominems. Or do you in fact accept its validity, but merely object to
me saying it?
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> With regard to "slinging together a few algorithms and producing a
> basic pre-designed game", you may note that I've done that in C++
> and two others have done it in Lisp on this thread, taking about two
> hours each.
Do you consider the concentration game to be simple enough that
any "competent" programmer ought to be able to throw it together in
two hours?
Should we take into consideration the total years of programming
experience of the folks who threw them together?
Is it relevant as to how long each of you has been programming in
the language that you used to throw it together in two hours?
It seems to me that the point you make about it taking as long in
lisp as in C++ (where the original claim was lisp was more
productive) can not be substantiated meaningfully without this extra
context.
--jon
OK, I'm going to voice my thoughts on this issue, since the main
reason I started programming was to write games. I've gone from C to
C++ to misc other languages, and now Lisp. I think that C++ is
probably the best language to write a game in IF it is meant to be
commercial and up fast. This is just because of the fact that there
are a lot of C++ libraries already written. Not so for Lisp. (NOTE:
Keep up the good work Kenny!)
However, I think that the key point is that C++ is very fast at
complex math operations. This is important for objects that are
rasterized, floating cameras, etc. Even though Lisp has dozens of
types ranging from bignum to fixnum to integer, it is still slower
than C++ at complex math operations. Lisp needs a library that it can
load at run-time that provides faster math types. Not nessecarily C++
style types, but maybe similar.
The again, I am still pretty new to Lisp so maybe there are ways that
floating cameras and such can be implemented without too much
trouble... if this is the case, please let me know. Also, quaternions,
which are really easy to construct in C++; I can't figure out how to
in Lisp. (NOTE: Incorrect use of semicolon in previous sentence). Does
anyone know how to do quaternions in Lisp here?
Finally, there is the matter of the GC. I don't really have any good
ideas on this, except that there may need to be a different algorithm
in place for game GCs.
--
Certum quod factum.
Philip Haddad
> However, I think that the key point is that C++ is very fast at
> complex math operations. This is important for objects that are
> rasterized, floating cameras, etc. Even though Lisp has dozens of
> types ranging from bignum to fixnum to integer, it is still slower
> than C++ at complex math operations. Lisp needs a library that it can
> load at run-time that provides faster math types. Not nessecarily C++
> style types, but maybe similar.
This is not entirely correct. Many (but not all) Common Lisp
implementations compile to native code. Use such an implementation.
Be willing to declare the types of variables in inner loops. Play
with it a while. You will find (as I did) that numerical programs
will be essentially the same speed as C. CMUCL is especially strong
in this regard.
rif
ps. I *do* feel that CL's lack of "inline" non-homogeneous arrays
(i.e. arrays of structures) gives C/C++ advantages for certain kinds
of programs which need to be simultaneously quite fast and extremely
memory efficient, but that's a different story.
In article <···············@five-percent-nation.mit.edu>, ···@mit.edu
says...
>
> This is not entirely correct. Many (but not all) Common Lisp
> implementations compile to native code. Use such an implementation.
> Be willing to declare the types of variables in inner loops. Play
> with it a while. You will find (as I did) that numerical programs
> will be essentially the same speed as C. CMUCL is especially strong
> in this regard.
From what I've seen, Lisp is deployable (more neatly than Java) on the
main target platform for indie games and it should be fast enough for
many projects, if not all of them.
I certainly think Lisp is a viable language for developing games,
although nothing has convinced me that it's better than C++. Probably a
proliferation of finished PC games would do more to convince me than all
the argument in the world.
- Gerry Quinn
Hello!
rif <···@mit.edu> wrote:
>ps. I *do* feel that CL's lack of "inline" non-homogeneous arrays
>(i.e. arrays of structures) gives C/C++ advantages for certain kinds
>of programs which need to be simultaneously quite fast and extremely
>memory efficient, but that's a different story.
Would it help making arrays of (unsigned-byte 8) or (unsigned-byte 32)
and writing inlined accessor functions then?
Kind regards,
Hannah.
> >ps. I *do* feel that CL's lack of "inline" non-homogeneous arrays
> >(i.e. arrays of structures) gives C/C++ advantages for certain kinds
> >of programs which need to be simultaneously quite fast and extremely
> >memory efficient, but that's a different story.
>
> Would it help making arrays of (unsigned-byte 8) or (unsigned-byte 32)
> and writing inlined accessor functions then?
>
> Kind regards,
>
> Hannah.
It will help for some but not all applications. If you want to have a
struct whose fields are all the same type, and that type can be
inlined in arrays, then you can just allocate a big array of that type
and build syntax to do the right thing. If your structs contain
fields of different types (say, (unsigned-byte 32)'s *and*
double-float's), then you have to either pay a memory penalty or move
to a "multiple arrays" setup (what would naturally be an array of
structs, where each struct is a two int's and a double-float, becomes
an array of ints and an array of double-floats). If you're accessing
the arrays more-or-less sequentially, this is fine, and in fact may be
more efficient than the alternatives on modern hardware (thanks to
Duane Rettig for pointing this out). If you're random accessing the
arrays, you're going to get a lot less locality of reference, and it's
going to hurt you a lot.
I think this would be a pretty delicious extension to CMUCL (or any
other CL that compiles to native code). I declare a structure type,
and get inlined arrays that can hold the structure type. I agree that
the consequences are undefined if I try to put anything else in the
array.
rif
Hi rif,
>> Would it help making arrays of (unsigned-byte 8) or (unsigned-byte 32)
>> and writing inlined accessor functions then?
>>
>> Kind regards,
>>
>> Hannah.
>
> It will help for some but not all applications. If you want to have a
> struct whose fields are all the same type, and that type can be inlined
> in arrays, then you can just allocate a big array of that type and build
> syntax to do the right thing. If your structs contain fields of
> different types (say, (unsigned-byte 32)'s *and* double-float's), then
> you have to either pay a memory penalty or move to a "multiple arrays"
> setup (what would naturally be an array of structs, where each struct is
> a two int's and a double-float, becomes an array of ints and an array of
> double-floats).
Not necessarily. Here's single array access for (unsigned-byte 32)'s and
double-float's for CMUCL and SBCL:
(let ((a (make-array 99 :element-type '(unsigned-byte 32)
:initial-element 0)))
(defun get-int (i)
(aref a (* i 3)))
(defun set-int (i j)
(setf (aref a (* i 3)) j))
(defun get-df (i)
(#+cmu kernel:make-double-float #+sbcl sb-kernel:make-double-float
(aref a (+ (* i 3) 1)) (aref a (+ (* i 3) 2))))
(defun set-df (i j)
(setf (aref a (+ (* i 3) 1)) (#+cmu kernel:double-float-high-bits
#+sbcl sb-kernel:double-float-high-bits j))
(setf (aref a (+ (* i 3) 2)) (#+cmu kernel:double-float-low-bits
#+sbcl sb-kernel:double-float-low-bits j))
j))
* (set-df 10 3.14d0)
3.14d0
* (get-df 10)
3.14d0
* (set-int 10 34)
34
* (get-int 10)
34
Your structure could only have one slot for an array. You could build
function or macro syntax to access the individual elements.
Not as efficient as you'd like but it's still only an extra array
lookup for each integer.
Regards,
Adam
[ I'm glad you narrowed to c.l.l; I dislike cross-posting]
Adam Warner <······@consulting.net.nz> writes:
> Hi rif,
>
> >> Would it help making arrays of (unsigned-byte 8) or (unsigned-byte 32)
> >> and writing inlined accessor functions then?
> >>
> >> Kind regards,
> >>
> >> Hannah.
> >
> > It will help for some but not all applications. If you want to have a
> > struct whose fields are all the same type, and that type can be inlined
> > in arrays, then you can just allocate a big array of that type and build
> > syntax to do the right thing. If your structs contain fields of
> > different types (say, (unsigned-byte 32)'s *and* double-float's), then
> > you have to either pay a memory penalty or move to a "multiple arrays"
> > setup (what would naturally be an array of structs, where each struct is
> > a two int's and a double-float, becomes an array of ints and an array of
> > double-floats).
>
> Not necessarily. Here's single array access for (unsigned-byte 32)'s and
> double-float's for CMUCL and SBCL:
[ example elided ... ]
Allegro CL provides a direct interface to such access; although rif noted
that it is not quite as efficient if all speed is necessary, and you have
pointed out that your example isn't quite as efficient as it would be
if the array had been specialized specifically for the type accessed,
we still run into situations where the C-style union access is necessary,
and so we have created a direct interface to this foreign type accessing.
These foreign types can be mapped over either lisp or foreign-allocated
objects, and are properly aligned and padded for correct access and
interface with C. Discussion is at
http://www.franz.com/support/documentation/7.0/doc/ftype.htm
Here is an example. I threw in an extra char object to show the
alignment properties of the accessors. Note that I'm doing this
at the top level, but when they are compiled at proper optimization
levels, they are completely open-coded and the only inefficiecies
are that the double access must cons a double-float to hold the value,
as do the ints require bignum consing.
CL-USER(1): (use-package :ff)
T
CL-USER(2): (defvar *a*
(make-array 99 :element-type '(unsigned-byte 32)
:initial-element 0))
*A*
CL-USER(3): (def-foreign-type complex-struct
(:struct
(dummy :char)
(int-or-doub (:union
(int (:struct
(lo :int)
(hi :int)))
(doub :double)))))
#<FOREIGN-FUNCTIONS::FOREIGN-STRUCTURE COMPLEX-STRUCT>
CL-USER(4): (setf (fslot-value-typed 'complex-struct :lisp *a*
'int-or-doub 'doub)
1.0d0)
1.0d0
CL-USER(5): (setq lo (fslot-value-typed 'complex-struct :lisp *a*
'int-or-doub 'int 'lo))
0
CL-USER(6): (setq hi (fslot-value-typed 'complex-struct :lisp *a*
'int-or-doub 'int 'hi))
1072693248
CL-USER(7): (format t "~x" *)
3ff00000
NIL
CL-USER(8): *a*
#(0 0 1072693248 0 0 0 0 0 0 0 ...)
CL-USER(9): :inspect 1.0d0
A NEW double-float = 1.0d0 [#x3ff00000 00000000] @ #x106541d2
[1i] CL-USER(10): :i q
CL-USER(11): (setf (fslot-value-typed 'complex-struct :lisp *a*
'int-or-doub 'int 'hi)
#x3fe00000)
1071644672
CL-USER(12): (fslot-value-typed 'complex-struct :lisp *a*
'int-or-doub 'doub)
0.5d0
CL-USER(13): :inspect *
A NEW double-float = 0.5d0 [#x3fe00000 00000000] @ #x10656ce2
[1i] CL-USER(14):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Hi Duane Rettig,
>> Not necessarily. Here's single array access for (unsigned-byte 32)'s and
>> double-float's for CMUCL and SBCL:
...
> http://www.franz.com/support/documentation/7.0/doc/ftype.htm
>
> Here is an example. I threw in an extra char object to show the
> alignment properties of the accessors. Note that I'm doing this
> at the top level, but when they are compiled at proper optimization
> levels, they are completely open-coded and the only inefficiecies
> are that the double access must cons a double-float to hold the value,
> as do the ints require bignum consing.
Great to see! I hope it is also possible to manipulate (unsigned-byte 32)'s
inline without always having to cons a bignum, as CMUCL and SBCL can, e.g.:
(declaim (optimize (speed 3)))
(let ((a (make-array
1 :element-type '(unsigned-byte 32) :initial-element 3405691582)))
(format t "#x~X #x~X"
(ldb (byte 16 16) (aref a 0)) (ldb (byte 16 0) (aref a 0))))
There's no optimisation note for the code above because the implementation
operates upon the raw 32-bit integer, not a bignum. If I print the raw
value then it must be coerced to a bignum:
(declaim (optimize (speed 3)))
(let ((a (make-array
1 :element-type '(unsigned-byte 32) :initial-element 3405691582)))
(print (aref a 0))
(format t "#x~X #x~X"
(ldb (byte 16 16) (aref a 0)) (ldb (byte 16 0) (aref a 0))))
; in:
; let ((a
; (make-array 1
; :element-type
; '(unsigned-byte 32)
; :initial-element
; 3405691582)))
; (PRINT (AREF A 0))
;
; note: doing unsigned word to integer coercion (cost 20)
I should be able to avoid bignum consing when accessing 32-bit arrays of
24 bit pixels. Nice.
At this point in time my ideal Lisp implementation would have a
non-copying garbage collector, pointer access, machine size integers,
C-style arrays and great type inference. I'm willing to trade off the cost
of separately storing type bits for the prospect of optimal speed code
with sufficient declarations and inference.
Heap fragmentation would be a problem for the virtual machine to address
through sufficient swap space (the allocator would also try to avoid
fragmentation). Having objects fixed in memory potentially reduces a level
of indirection and simplifies pointer-based access and manipulation.
Combined with a cheaper calling convention than C for Lisp functions and a
sufficiently smart compiler this implementation, if it actually existed,
would be objectively faster than C. Alternatively the implementation could
compile to C using the same calling conventions and for sufficiently
declared code would have similar performance characteristics to C.
The way type bits are implemented in Lisp usually benefits dynamic code at
the expense of statically declared code. For example CPU instruction sets
usually include specific opcodes to increment registers. If like SBCL
fixnums have two lower tag bits then incrementing a fixnum actually
requires adding 4 to a register each time, which is likely to be slower
(larger opcodes/having to consume a register to store the amount to add).
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> At this point in time my ideal Lisp implementation would have a
> non-copying garbage collector, pointer access, machine size integers,
> C-style arrays and great type inference. I'm willing to trade off the cost
> of separately storing type bits for the prospect of optimal speed code
> with sufficient declarations and inference.
>
> Heap fragmentation would be a problem for the virtual machine to address
> through sufficient swap space (the allocator would also try to avoid
> fragmentation). Having objects fixed in memory potentially reduces a level
> of indirection and simplifies pointer-based access and manipulation.
This all sounds like a nice problem to give to a lisp machine. But you
can't have tag bits and word-sized integers at the same time, unless
you do the static type-less compilation (i.e. the type is assumed and isn't
carried around at runtime) that is currently provided by CL implementations
in the form of unboxed compilation.
> Combined with a cheaper calling convention than C for Lisp functions and a
> sufficiently smart compiler this implementation, if it actually existed,
> would be objectively faster than C. Alternatively the implementation could
> compile to C using the same calling conventions and for sufficiently
> declared code would have similar performance characteristics to C.
This is an interesting point of view. It gets into an issue of competition
with C that we don't normally see, because it deals with things that C
normally can't do. For example (let's just go with a simple one, for now),
how do you enter a C function that has the equivalent of this functionality?
(defun foo (x y &optional z)
...)
Answer; it normally can't be done in C - the C conventions would have to
be extended to allow for knowledge of how many arguments are actually
passed in a function call. This can of course be done, by passing extra
arguments, but is bound to be slower than we do it in CL implementations
which compile directly to native code, rather than to C.
Lisp is sometimes thought of as being slower than C, mostly because
we tend to compete with C on its own turf, or with equivalent
functionalities. I'm sure if you were to require benchmarks that
included &optional &key and &rest arguments, CL would blow away the
best such implementations from even the best C compilers. And in order
to do some of the things that we do (such as using the clc instruction
to flag a normal one-value return) the only way C would be able to approach
CL's efficiency at returning multiple values would be to drop into an asm{}
statement.
> The way type bits are implemented in Lisp usually benefits dynamic code at
> the expense of statically declared code. For example CPU instruction sets
> usually include specific opcodes to increment registers. If like SBCL
> fixnums have two lower tag bits then incrementing a fixnum actually
> requires adding 4 to a register each time, which is likely to be slower
> (larger opcodes/having to consume a register to store the amount to add).
Actually, most cpu instruction sets don't distinguish between incrementing
by one and incrementing by 4 or 8. The x86-based architectures do, but
even that has gone away with the AMD64/Intel-IA-32e architecture, where
the range of single-byte INC and DEC instructions were stolen to create
the new REX (register extentsion) prefix for these two 64-bit architectures.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Hi Duane Rettig,
> Adam Warner <······@consulting.net.nz> writes:
>
>> At this point in time my ideal Lisp implementation would have a
>> non-copying garbage collector, pointer access, machine size integers,
>> C-style arrays and great type inference. I'm willing to trade off the cost
>> of separately storing type bits for the prospect of optimal speed code
>> with sufficient declarations and inference.
>>
>> Heap fragmentation would be a problem for the virtual machine to address
>> through sufficient swap space (the allocator would also try to avoid
>> fragmentation). Having objects fixed in memory potentially reduces a level
>> of indirection and simplifies pointer-based access and manipulation.
>
> This all sounds like a nice problem to give to a lisp machine. But you
> can't have tag bits and word-sized integers at the same time, unless
> you do the static type-less compilation (i.e. the type is assumed and isn't
> carried around at runtime) that is currently provided by CL implementations
> in the form of unboxed compilation.
I'd consider boxing everything. Make fixnums word-sized integers that
cons. In the event of sufficient declarations and inference unboxed
compilation is performed. There's also no conversion cost in making a
fixnum a word-sized integer (e.g. having to shift the bits).
Like I said, I'd be willing to use a Lisp that is slower when dynamic
types are needed in order that the basic data structures better match
static languages.
>> Combined with a cheaper calling convention than C for Lisp functions
>> and a sufficiently smart compiler this implementation, if it actually
>> existed, would be objectively faster than C. Alternatively the
>> implementation could compile to C using the same calling conventions
>> and for sufficiently declared code would have similar performance
>> characteristics to C.
>
> This is an interesting point of view. It gets into an issue of
> competition with C that we don't normally see, because it deals with
> things that C normally can't do. For example (let's just go with a
> simple one, for now), how do you enter a C function that has the
> equivalent of this functionality?
>
> (defun foo (x y &optional z)
> ...)
>
> Answer; it normally can't be done in C - the C conventions would have to
> be extended to allow for knowledge of how many arguments are actually
> passed in a function call. This can of course be done, by passing extra
> arguments, but is bound to be slower than we do it in CL implementations
> which compile directly to native code, rather than to C.
Duane, note that I'm not a C programmer. I just know about some of its
limitations like the issue you raise, and which I agree with. I was
thinking more about the costs of the Unix/C ABI which can make function
calls to shared libraries more expensive than a Lisper may desire. We want
function calls to be blindingly fast.
The Parrot/Perl6 internals mailing list has a discussion over the calling
conventions of its virtual machine. In many ways the virtual machine is
extremely impressive for building a dynamic language. But it appears it
just isn't fast at global function calls which makes it less attractive
for Lisp. Even CLISP leaves it for dead.
This is my Common Lisp code to stress the function call interface
(NB: these declarations are not recognised by CLISP):
(defun fib (n)
(declare (optimize (debug 0) (safety 0) (speed 3)) (fixnum n))
(if (<= n 2)
1
(the fixnum (+ (fib (- n 2)) (fib (- n 1))))))
This is my translation into Parrot's intermediate code:
.sub _main
$N0=time
$I0=_fib(35)
$N1=time
$N1=$N1-$N0
print $I0
print "\n"
print $N1
print "\n"
end
.end
.sub _fib
.param int n
if n<=2 goto return1
sub n,1
$I1=_fib(n)
sub n,1
$I0=_fib(n)
$I1=$I0+$I1
.pcc_begin_return
.return $I1
.pcc_end_return
return1:
.pcc_begin_return
.return 1
.pcc_end_return
end
.end
I ran the Parrot code with the fast JIT engine. CLISP bytecode was 7.7
times faster for (time (fib 35)). And it would have even handled bignums.
SBCL was 91 times faster.
From Perl6 internals: "The fibonacchi benchmark [NB: I haven't seen it. I
wrote my own] (or other call-bound code) spends more then half of
equivalent CPU cycles in level 2 cache misses. This makes Parrot
incompetitively slow and thus unattractive for potential users."
It's supposedly twice as slow as Python. But the calling conventions
aren't going to be changed.
Parrot is impressive. They've even implemented strings of graphemes for
correct handling of Unicode characters (a grapheme is one or more code
points). I was even surprised by its floating point performance. But its
global function call performance leaves me concerned.
> Lisp is sometimes thought of as being slower than C, mostly because we
> tend to compete with C on its own turf, or with equivalent
> functionalities. I'm sure if you were to require benchmarks that
> included &optional &key and &rest arguments, CL would blow away the best
> such implementations from even the best C compilers. And in order to do
> some of the things that we do (such as using the clc instruction to flag
> a normal one-value return) the only way C would be able to approach CL's
> efficiency at returning multiple values would be to drop into an asm{}
> statement.
Indeed. I'd just prefer a Lisp where we compete with C on its own turf and
still win. Citing your now-infamous 20% slower than C comment:
For example; a running pointer into an array can't normally be kept in
a register when a gc might move that array, unless there is also some
way to "forward" that running pointer. Instead, a lisp might need to
always keep a pointer to the array itself,and use fixnum indices (which
don't get changed during a gc) and then always perform object/offset
style accesses, rather than accessing whatever is directly under the
pointer. Keeping two registers instead of one represents what is
called "register pressure", and contributes to inefficiency in the
generated code.
These issues can be avoided with a non-copying garbage collector.
Especially with 64-bit Lisps any fragmentation can be transparently
offloaded to the operating system's virtual memory subsystem. Disk space
is cheap. Let unusable fragments just swap out to lie dormant. There will
be cases where only a small portion of a page is live and the whole page
has to be swapped back in. But overall it should be faster referring to
statically located objects.
Not to mention that you don't lose half your memory (necessary for copying
the live objects).
>> The way type bits are implemented in Lisp usually benefits dynamic code
>> at the expense of statically declared code. For example CPU instruction
>> sets usually include specific opcodes to increment registers. If like
>> SBCL fixnums have two lower tag bits then incrementing a fixnum
>> actually requires adding 4 to a register each time, which is likely to
>> be slower (larger opcodes/having to consume a register to store the
>> amount to add).
>
> Actually, most cpu instruction sets don't distinguish between
> incrementing by one and incrementing by 4 or 8. The x86-based
> architectures do, but even that has gone away with the
> AMD64/Intel-IA-32e architecture, where the range of single-byte INC and
> DEC instructions were stolen to create the new REX (register extentsion)
> prefix for these two 64-bit architectures.
This is great to know!
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> I'd consider boxing everything. Make fixnums word-sized integers that
> cons. In the event of sufficient declarations and inference unboxed
> compilation is performed. There's also no conversion cost in making a
> fixnum a word-sized integer (e.g. having to shift the bits).
I think this approach would be the right thing to do for a static Lisp
subset to C translator like Thinlisp (which currently does fixnums
with tag bits and shifts), using a caller-boxes scheme, maybe
supplemented by some additional mandatory type declarations. The
problem is deciding where to keep objects. Consing numbers on the heap
is bad for locality and introduces aliasing issues, not to mention
giving more work to the garbage collector. The other approach is to
use a two word struct for each object (I think the Newlisp interpreter
does this), where the first word is a giant tag bit, and the other
word is the pointer/integer/single-float. The problem with this
approach is you're using twice as much cache for everything boxed (and
this would be really bad on 64 bit machines, because at least the
current AMD processors haven't increased cache sizes significantly
over 32-bit AMD processors). The benefits are that you stack-allocate
the box structs when passing them (they should only be passed by
value), and the really big win is that since all types are declared at
compile-time, you can lay out the tag word to include all the types in
your program. Then you can easily use arrays of C structs that don't
need to know anything about type tags, and I guess other layout
optimizations as well. So I think the latter strategy would end up a
bit better. Of course, neither applies when you're dealing with a
typed array of numbers, but that's something that regular Common Lisp
compilers handle very well already, which brings me to the point that
really both approaches are a loss, one that having "free" access to C
types won't offset.
Vladimir
Philip Haddad wrote:
> OK, I'm going to voice my thoughts on this issue, since the main
> reason I started programming was to write games. I've gone from C to
> C++ to misc other languages, and now Lisp. I think that C++ is
> probably the best language to write a game in IF it is meant to be
> commercial and up fast. This is just because of the fact that there
> are a lot of C++ libraries already written. Not so for Lisp. (NOTE:
> Keep up the good work Kenny!)
> However, I think that the key point is that C++ is very fast at
> complex math operations. This is important for objects that are
> rasterized, floating cameras, etc.
Thx for the encouragement, but if someone hired me tomorrow to do a
first-person shooter, I would simply research the best open game engines
and write the bindings. If it was C++, we would grind out the necessary
"C" glue. The game play would be in Lisp. We might even build a language
On Lisp which non-techies could use to script scenarios.
The game engine would include scene graph management for optimized
rendering and a physics engine for optimal simulation of the game world.
I would not be worried so much about speed as I would be about
development cost, but you would get your C/C++* if that is your concern.
Probably the greater speed advantage would come from (hopefully) better
algorithms in mature libraries.
kenny
* This also facilitates pulling off "a Corman", in which one reassures
management that one is using C++. :)
k
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <··············@spiritus.delamancha.org>,
········@delamancha.org says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > With regard to "slinging together a few algorithms and producing a
> > basic pre-designed game", you may note that I've done that in C++
> > and two others have done it in Lisp on this thread, taking about two
> > hours each.
>
> Do you consider the concentration game to be simple enough that
> any "competent" programmer ought to be able to throw it together in
> two hours?
>
> Should we take into consideration the total years of programming
> experience of the folks who threw them together?
>
> Is it relevant as to how long each of you has been programming in
> the language that you used to throw it together in two hours?
That's a valid point. You would need fluency with the language,
familiarity with relevant libraries, and familiarity with game
programming idioms. If any beginning programmer, in whatever language,
is about to shoot himself because it looks like Concentration is going
to take him several days - don't do it! You WILL get better!
Of course there is another point as well - how much does the
productivity of beginners count? It counts for something (look at the
popularity of Basic) but does it count for large single-purpose
projects?
> It seems to me that the point you make about it taking as long in
> lisp as in C++ (where the original claim was lisp was more
> productive) can not be substantiated meaningfully without this extra
> context.
Well, there is truth in that, but on the other hand, "how fast can an
experienced programmer do it" is probably a pretty relevant metric. As
for inexperienced programmers, I don't think Lisp is going to take over
from VB any time soon...
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Well, there is truth in that, but on the other hand, "how fast can an
> experienced programmer do it" is probably a pretty relevant metric. As
> for inexperienced programmers, I don't think Lisp is going to take over
> from VB any time soon...
Lisp is not being targeted particularly at Visual Basic programmers
at the moment, so your prediction makes sense. But it says nothing
about whether they would like it better. Historical experience has
shown that beginner programmers do very well with Lisp-like languagues
compared against traditional BASIC. One thing that's missing from a
more modern comparison is the "visual" (drag-and-drop-and-properties)
programming environment for Lisp.
Jon Boone wrote:
>
> It seems to me that the point you make about it taking as long in
> lisp as in C++ (where the original claim was lisp was more
> productive) can not be substantiated meaningfully without this extra
> context.
When I wrote my version of concentration I did not have it in my mind
that I wanted to show that I was more productive. In this thread there
has been a desire for verification that (Common) Lisp is even capable
of being used for any application (let alone a game). I just wanted to
show that it 1) can be, 2) has reasonable performance and 3) is deliverable
in a fairly small footprint. Also I hope some people will actually
look at the Lisp code who have not seen Lisp before. (It does not bite)
Wade
Sashank Varma <····@vanderbilt.edu> wrote in
·······························@news.vanderbilt.edu:
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
>> But this is the thing - you go on about how Lisp is "so much
>> more productive" but there's no evidence of it!
>
> There is this website called Google where you can go
> and type things like "lisp comparison C++" and it
<snip>
> a few and found some interesting, honest evaluations.
>
> http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
> http://www.lisp.org/table/compare.htm
> http://www.python.org/doc/essays/comparisons.html
> http://www.flownet.com/gat/papers/lisp-java.pdf
> http://www.norvig.com/java-lisp.html
> http://www.memorymanagement.org/articles/lang.html
> http://http.cs.berkeley.edu/~fateman/papers/software.pdf
> http://lemonodor.com/archives/000180.html
> http://www.franz.com/success/customer_apps/data_mining/cadabra.lh
> tml
<snip>
This applies to the post of Ron Garret as well.
So let's just take one of them for verification. It looks like I
had http://www.flownet.com/gat/papers/lisp-java.pdf offline on my
computer. So we might look at that.
It starts with big name "Lisp as an Alternative to Java". So I hope
I'd talk about the right article.
From first few looks it seems it was done in around winter 2000. It
also reffered to some study that used 1.2.? version of JVM. So at
the first we should say IT'S AN OUTDATED study, that shouldn't be
used for any current comparisons, at least with Java.
Then they talked about the development time. 2 - 8.5 LISP
4 - 63 Java
3 - 25 C / C++
It seems strange. It shouldn't be so high for Java. (and for C if
not messing with pointers it should be more like 17 hours) Perhaps
that it depended on experience with programmer. Lets look how many
hour they have behind them. (I have just over 3000 if someone would
like to do some criticism.) LISP 6.5 years
Java 7.7 years
C / C++ 9.6 years
7.7? What version of Java was available when they started with
programming? Difficult counting 2000 - 7.7. I remmembered one
person talked something about company that required programmers
with 5 years experience back in the 1996. Wait a minute I remmeber
he said also something about... When was first version of JVM? Beta
was released in late 1995. Release version of the JVM was released
in the 1996. So that programmers was... I REFUSE to consider this
article as too much valid, if there are programers with longer
experience with the language than age of the language's compiler.
(They said they were volunteers from usenet so they were unlikely
people that builded the Java compiler.)
So we might consider that lower values as somewhat relevant.
However we don't know if they accounted for breaks and toilets, so
we could repair it by a factor of 2 hours. We will add 2 hours to
lower value, and subtract 2 hours from larger value. Now all times
are equal so we could say they spend around 2 hours with that
problem and rest of the time with retyping it into theirs favorite
language.
That 63 hours of programming in Java is only one result. It seems
to be caused by 50 hours of learning Java and 13 hours of typing
that algorithm into the language.
Median of Java is lower than C, it's expected behaviour. (If both
sides are using Eclipse, experienced programmers and perfect
libraries for development, Java time is around 0.8 of C. However it
would be stupid to do any races.)
Lower median of LISP could be caused be problem very easy to
program in LISP, or by students that did such problem recently in
the school.
Conclusion. That article has nearly no informations.
Should I expect that everyone is verifying Internet articles from 3
independent sources and in case of program tests, he does them as
well?
[newsgroups trimmed as I don't read the others]
Raghar <······@mail.com> writes:
> So let's just take one of them for verification. It looks like I
> had http://www.flownet.com/gat/papers/lisp-java.pdf offline on my
> computer. So we might look at that.
[snip]
> Then they talked about the development time. 2 - 8.5 LISP
> 4 - 63 Java
> 3 - 25 C / C++
> It seems strange. It shouldn't be so high for Java. (and for C if
> not messing with pointers it should be more like 17 hours) Perhaps
> that it depended on experience with programmer. Lets look how many
> hour they have behind them. (I have just over 3000 if someone would
> like to do some criticism.) LISP 6.5 years
> Java 7.7 years
> C / C++ 9.6 years
> 7.7? What version of Java was available when they started with
> programming?
Since this is about _programmer experience_, not _language
experience_, the fact that Java was not yet seven years old at the
time is not a problem. This could be more clearly stated, and is in
the FAQ for the paper (linked from the papers page on the web site
it's available from), but it's not a reason to reject the paper.
On Thu, 11 Nov 2004 11:36:35 +0000, Gerry Quinn wrote:
> My biggest concern (leaving pure language and re-use considerations out
> of it) would be easy integration with standard Windows controls and
> features. I would also require the creation of reasonably compact
> downloadable .exes that would work reliably on just about any Windows
> machine, and would not require downloading of added libraries or
> environments.
Windows? Are you serious? Do people really still use that monstrosity?
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
On Thu, 11 Nov 2004, William Bland wrote:
> On Thu, 11 Nov 2004 11:36:35 +0000, Gerry Quinn wrote:
>
> > My biggest concern (leaving pure language and re-use considerations out
> > of it) would be easy integration with standard Windows controls and
> > features. I would also require the creation of reasonably compact
> > downloadable .exes that would work reliably on just about any Windows
> > machine, and would not require downloading of added libraries or
> > environments.
>
> Windows? Are you serious? Do people really still use that monstrosity?
>
Only the vast, vast majority of home users, who're Gerry's target market.
Personally I use it because I'm a gamer, and to a lesser extent because I
can't be bothered to figure out how to duplicate my desktop setup under X.
I do seem to make a bit more of an effort to write portable code than
Gerry does though.
--
······@flippac.org
In article <·······························@SLINKY>, ······@flippac.org
says...
> On Thu, 11 Nov 2004, William Bland wrote:
> > On Thu, 11 Nov 2004 11:36:35 +0000, Gerry Quinn wrote:
> >
> > > My biggest concern (leaving pure language and re-use considerations out
> > > of it) would be easy integration with standard Windows controls and
> > > features. I would also require the creation of reasonably compact
> > > downloadable .exes that would work reliably on just about any Windows
> > > machine, and would not require downloading of added libraries or
> > > environments.
> >
> > Windows? Are you serious? Do people really still use that monstrosity?
>
> Only the vast, vast majority of home users, who're Gerry's target market.
>
> Personally I use it because I'm a gamer, and to a lesser extent because I
> can't be bothered to figure out how to duplicate my desktop setup under X.
> I do seem to make a bit more of an effort to write portable code than
> Gerry does though.
My 'Concentration' game is a bad example because everything is in a
CWnd-derived class. Such a class is already given up to Satan, and can
commit no further sin.
A more substantial game would have a 'game' object separate from the
'windows' object, and the game logic classes would be fairly portable.
[I do allow use of CPoint, CRect, etc. and CString, but even if MS
didn't have portable versions of these, I could knock up code to
replicate their functionality in a couple of days (I would rewrite all
but CString, which I would translate to <string>). Other than that, the
only MS-dependency is that it's compiled and tested only on MSVC. This
probably does introduce the odd portability hit, but I think it should
not be excessive, particularly as I tend to eschew 'fancy' code.]
- Gerry Quinn
Quoth Philippa Cowderoy on or about 2004-11-11:
> Personally I use [Windows] because ... I
> can't be bothered to figure out how to duplicate my desktop setup under X.
You shouldn't duplicate you Windows desktop, you should improve upon it :-)
My X terminal is *just* how I like it:
http://www.nongnu.org/stumpwm / http://ratpoison.sf.net
http://144.132.79.25/~twb/img/xwd/current.png
-t
On Fri, 12 Nov 2004, Trent Buck wrote:
> Quoth Philippa Cowderoy on or about 2004-11-11:
> > Personally I use [Windows] because ... I
> > can't be bothered to figure out how to duplicate my desktop setup under X.
>
> You shouldn't duplicate you Windows desktop, you should improve upon it :-)
>
I'm aware there's more possibility under X, but there's not much beyond
the windows desktop and a rearrangeable taskbar I need. Though I guess
it'd be nice to be able to drop app windows into splitter panes - IIRC
it's Ion I should play about with for that? A big issue for me is
notification from apps that don't have the focus, I effectively run
everything maximised and swap between what may as well be screens.
A friend on IRC's offered to help out when I next feel like booting a *nix
flavour on here, I'll be taking him up on it at some point.
--
······@flippac.org
Philippa Cowderoy wrote:
<snip>
>
> I'm aware there's more possibility under X, but there's not much beyond
> the windows desktop and a rearrangeable taskbar I need. Though I guess
> it'd be nice to be able to drop app windows into splitter panes - IIRC
> it's Ion I should play about with for that?
>
I use Ion3. It allows you to have both non-floating windows split into
frames, and you can also have a more traditional 'floating' desktop as
well, either at the same time or in different workspaces.
>.A big issue for me is
> notification from apps that don't have the focus, I effectively run
> everything maximised and swap between what may as well be screens.
Ion has a tatle bar for each app (which end up looking like 'tabs' when
one has multiple apps open. When a dialog pops up on an app that does
not have focus, the titlebar turns red. that's god enough for me.
Ion is also scriptable in Lua, which should be well known to game
developers. I have a few crazy lua hacks to set up my environment for
lisp hacking to be just the way i like it!
I love ion3, as i never use the rodent, and can't stand windows that
overlap.
drewc
On Fri, 12 Nov 2004 21:59:42 GMT, drewc <·····@rift.com> wrote:
> Philippa Cowderoy wrote:
> <snip>
>> I'm aware there's more possibility under X, but there's not much beyond
>> the windows desktop and a rearrangeable taskbar I need. Though I guess
>> it'd be nice to be able to drop app windows into splitter panes - IIRC
>> it's Ion I should play about with for that?
>
> I use Ion3. It allows you to have both non-floating windows split into
> frames, and you can also have a more traditional 'floating' desktop as
> well, either at the same time or in different workspaces.
>
>
> >.A big issue for me is
> > notification from apps that don't have the focus, I effectively run
> > everything maximised and swap between what may as well be screens.
>
> Ion has a tatle bar for each app (which end up looking like 'tabs' when
> one has multiple apps open. When a dialog pops up on an app that does
> not have focus, the titlebar turns red. that's god enough for me.
>
> Ion is also scriptable in Lua, which should be well known to game
> developers. I have a few crazy lua hacks to set up my environment for
> lisp hacking to be just the way i like it!
>
> I love ion3, as i never use the rodent, and can't stand windows that
> overlap.
>
> drewc
Funny.. Sounds like my Windows desctop ;)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Fri, 12 Nov 2004, drewc wrote:
> Ion has a tatle bar for each app (which end up looking like 'tabs' when
> one has multiple apps open. When a dialog pops up on an app that does
> not have focus, the titlebar turns red. that's god enough for me.
>
Is there a decent way of getting an IRC client to turn the titlebar red or
similar on eg receipt of any private message going to a window that
doesn't have focus?
--
······@flippac.org
Quoth Philippa Cowderoy on or about 2004-11-12:
> >> Personally I use [Windows] because ... I can't be bothered to
> >> figure out how to duplicate my desktop setup under X.
> > You shouldn't duplicate you Windows desktop, you should improve upon it :-)
> Though I guess it'd be nice to be able to drop app windows into
> splitter panes - IIRC it's Ion I should play about with for that?
Ion or WMI, or ratpoison or stump (see previous post).
- Ion is the oldest and most featureful, it uses Lua (turing-complete) for
configuration. It is relatively difficult to configure.
- Ratpoison is newer and more minimalist, it uses a simple command set
based on GNU Screen, and it feels a lot like screen / emacs. It
relies on forking to a shell for flow-control.
- WMI is based on Ion and Ratpoison, but it feels like vi rather than
emacs.
- StumpWM is basically ratpoison **written in Common Lisp + CLX**.
I've found ratpoison is quite easy to test new WM ideas in; I wrote a
script to make it do the Exposé thing, for example. Real soon now I'm
going to get StumpWM to load, then it's going to be *really* fun.
-trent
On Thu, 11 Nov 2004 13:33:05 GMT, William Bland
<·······@abstractnonsense.com> wrote:
> On Thu, 11 Nov 2004 11:36:35 +0000, Gerry Quinn wrote:
>
>> My biggest concern (leaving pure language and re-use considerations out
>> of it) would be easy integration with standard Windows controls and
>> features. I would also require the creation of reasonably compact
>> downloadable .exes that would work reliably on just about any Windows
>> machine, and would not require downloading of added libraries or
>> environments.
>
> Windows? Are you serious? Do people really still use that monstrosity?
>
> Cheers,
> Bill.
Have you ever developed commercially? lol
Only a academic can afford to ignore 80% of the market potential.
I like Lisp. I like CAPI. But what do I do when people ask as about mouse
scroll that
dosn't work or tool-bars that don't move.
I'd write the interface in Microsoft Visual C++.
Much hated but the origin of hundreds of thousand of commercial Windows
programs.
Tested and proven.
Quality assurance is also making sure that you environment can adapt any
needs you are likely to have.
Most of commercial code is boiler plate. It consists of calling functions
in some library. So for this Lisp is not much terser.
Sure Lisp is great for algorithm's, but this is just a small percentage
of the code in a commercial app.
More important, for conserving time, is how much time you need to
get to the necessary library functions. As such, I fear, Lisp
might well loose.
Totally depends on your app, of course.
For web based apps, Allegro 7 seems to fit the bill.
Still when it comes to Windows interfaces Lisp still has a ways to go.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Thu, 11 Nov 2004 15:25:18 +0100, John Thingstad wrote:
> On Thu, 11 Nov 2004 13:33:05 GMT, William Bland
> <·······@abstractnonsense.com> wrote:
>
>> On Thu, 11 Nov 2004 11:36:35 +0000, Gerry Quinn wrote:
>>
>>> My biggest concern (leaving pure language and re-use considerations out
>>> of it) would be easy integration with standard Windows controls and
>>> features. I would also require the creation of reasonably compact
>>> downloadable .exes that would work reliably on just about any Windows
>>> machine, and would not require downloading of added libraries or
>>> environments.
>>
>> Windows? Are you serious? Do people really still use that monstrosity?
>>
>> Cheers,
>> Bill.
>
> Have you ever developed commercially? lol
Only for eight years. I guess I'm still a bit of a newbie.
> Only a academic can afford to ignore 80% of the market potential.
I haven't been an academic for eight years. None of my market is on
Windows.
OK, I'm sorry, the Windows thing was a cheap shot. I'm lucky enough to
work server-side, where users don't know or care what OS and programming
language you use.
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
On Thu, 11 Nov 2004 14:34:08 GMT, William Bland
<·······@abstractnonsense.com> wrote:
>
> OK, I'm sorry, the Windows thing was a cheap shot. I'm lucky enough to
> work server-side, where users don't know or care what OS and programming
> language you use.
>
> Cheers,
> Bill.
My last job was for Opera Software (www.opera.com).
Opera is a Web browser, mail/news and IRC interface.
There presentation is everything!
As you said. Different jobs, different experiences.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
William Bland <·······@abstractnonsense.com> writes:
> OK, I'm sorry, the Windows thing was a cheap shot. I'm lucky enough to
> work server-side, where users don't know or care what OS and programming
> language you use.
Most (about 95%) of the users of the end-user program I'm the main
developer of, use Windows. But I rarely do development on Windows,
I do most of the development of that application on linux, and some
on my Mac laptop. The cross platform wonder that let's me do this
is Xanalys LispWorks :-)
--
(espen)
On Thu, 11 Nov 2004 15:56:20 +0100, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
> William Bland <·······@abstractnonsense.com> writes:
>
>> OK, I'm sorry, the Windows thing was a cheap shot. I'm lucky enough to
>> work server-side, where users don't know or care what OS and programming
>> language you use.
>
> Most (about 95%) of the users of the end-user program I'm the main
> developer of, use Windows. But I rarely do development on Windows,
> I do most of the development of that application on linux, and some
> on my Mac laptop. The cross platform wonder that let's me do this
> is Xanalys LispWorks :-)
What exactly are you developing?
I seem to remeber something about an interface to the stock exchange in
Oslo
but seem unable to find it.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> What exactly are you developing?
> I seem to remeber something about an interface to the stock exchange in
> Oslo
> but seem unable to find it.
http://www.netfonds.no/manual_pt.php
--
(espen)
>>>>> "EV" == Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
EV> [...] But I rarely do development on
EV> Windows, I do most of the development of that application on
EV> linux, and some on my Mac laptop. The cross platform wonder
EV> that let's me do this is Xanalys LispWorks :-) -- (espen)
I second that. Apart from some sound etc. bits that requires #+win32
I've had the same pleasant experience. You pay twice the price for this
convenience, of course (LW pro in both platforms) but it is worth it.
One of these days I'll figure out how to get a dos/shell window from
windows under vmware in an xterm on the linux host and I'll be able to
go from 'it works' to exe w/o seeing the windows desktop.
cheers,
BM
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> William Bland <·······@abstractnonsense.com> writes:
>
> > OK, I'm sorry, the Windows thing was a cheap shot. I'm lucky enough to
> > work server-side, where users don't know or care what OS and programming
> > language you use.
>
> Most (about 95%) of the users of the end-user program I'm the main
> developer of, use Windows. But I rarely do development on Windows,
> I do most of the development of that application on linux, and some
> on my Mac laptop. The cross platform wonder that let's me do this
> is Xanalys LispWorks :-)
I suspect that most "MS-Windows Developers" work like that too.
Probably an important factor as why we see so many BSOD in public
appliances...
--
__Pascal Bourguignon__
On 11 Nov 2004 17:45:23 +0100, Pascal Bourguignon <····@mouse-potato.com>
wrote:
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
>
>> William Bland <·······@abstractnonsense.com> writes:
>>
>> > OK, I'm sorry, the Windows thing was a cheap shot. I'm lucky enough
>> to
>> > work server-side, where users don't know or care what OS and
>> programming
>> > language you use.
>>
>> Most (about 95%) of the users of the end-user program I'm the main
>> developer of, use Windows. But I rarely do development on Windows,
>> I do most of the development of that application on linux, and some
>> on my Mac laptop. The cross platform wonder that let's me do this
>> is Xanalys LispWorks :-)
>
> I suspect that most "MS-Windows Developers" work like that too.
> Probably an important factor as why we see so many BSOD in public
> appliances...
>
Most Lisp programmers perhaps.
In all C++ development for Windows I have done we've used Windows.
Client programming under Windows isn't bad. Much better than the tools for
Unix.
(I'm still talking about C++)
I dare say most Windows programmers actually develop under windows.
They gripe about Micro$oft but still use Visual C++.
C++ isn't productive or pretty but it gets the job done.
Even today I'd still choose C++ over Java any day.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> On Thu, 11 Nov 2004 13:33:05 GMT, William Bland
> <·······@abstractnonsense.com> wrote:
>
> > On Thu, 11 Nov 2004 11:36:35 +0000, Gerry Quinn wrote:
> >
> >> My biggest concern (leaving pure language and re-use considerations out
> >> of it) would be easy integration with standard Windows controls and
> >> features. I would also require the creation of reasonably compact
> >> downloadable .exes that would work reliably on just about any Windows
> >> machine, and would not require downloading of added libraries or
> >> environments.
> >
> > Windows? Are you serious? Do people really still use that monstrosity?
> >
> > Cheers,
> > Bill.
>
> Have you ever developed commercially? lol
> Only a academic can afford to ignore 80% of the market potential.
Only the home market is 80%.
A lot of corporate server-based computing is done on Unix.
On Thu, 11 Nov 2004 19:26:04 GMT, Christopher C. Stacy
<······@news.dtpq.com> wrote:
>
> Only the home market is 80%.
> A lot of corporate server-based computing is done on Unix.
corperate server market yes..
Since Windows server truly sucks the I wonder why the number isn't heigher.
Corperate market no.
Most desctop computer's run Windows.
The number is still approx 80 %.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Thu, 11 Nov 2004 20:34:23 +0100, John Thingstad
<··············@chello.no> wrote:
> Corperate market no.
> Most desctop computer's run Windows.
> The number is still approx 80 %.
>
I should perhaps add that this number is difficult to verify since many
people
overwrite the Windows that came with the machine with Linux and 40 %
download Linux from
the net so they are not counted. So the number of windows users is
probably artificially high.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> On Thu, 11 Nov 2004 20:34:23 +0100, John Thingstad
> <··············@chello.no> wrote:
>
> > Corperate market no.
> > Most desctop computer's run Windows.
> > The number is still approx 80 %.
> >
>
> I should perhaps add that this number is difficult to verify since
> many people
> overwrite the Windows that came with the machine with Linux and 40 %
> download Linux from
> the net so they are not counted. So the number of windows users is
> probably artificially high.
I would love to believe this. Certainly I have wiped Windows from a
machine and just booted Linux. Make that two machines. But I don't
think the typical user does that. I doubt that even a full percent of
Windows machines get converted to Linux or *BSD. At least not
machines that are newer than one or two years old.
I'm currently running OS X on a PowerBook G4 and Debian Linux on an
Intel box that was built from parts.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> > I should perhaps add that this number is difficult to verify since
> > many people
> > overwrite the Windows that came with the machine with Linux and 40 %
> > download Linux from
> > the net so they are not counted. So the number of windows users is
> > probably artificially high.
>
> I would love to believe this. Certainly I have wiped Windows from a
> machine and just booted Linux. Make that two machines. But I don't
> think the typical user does that. I doubt that even a full percent of
> Windows machines get converted to Linux or *BSD. At least not
> machines that are newer than one or two years old.
>
> I'm currently running OS X on a PowerBook G4 and Debian Linux on an
> Intel box that was built from parts.
It doesn't matter. It's easy to have more than 50% market share when
all the OS sold by your competitors are installed on computers sold
bundled with your own. (NeXTSTEP/ix84, OPENSTEP/ix86, Solaris/ix86,
BeOS/ix86, etc). And it's best when your OS being sold and paid for
IS NOT used, since that means less support.
Either you have to buy Solaris/sparc, a Macintosh, or build yourself
your PC from parts, to avoid the Microsoft tax.
--
__Pascal Bourguignon__
Pascal Bourguignon wrote:
> ...
> Either you have to buy Solaris/sparc, a Macintosh, or build yourself
> your PC from parts, to avoid the Microsoft tax.
i bought my last two systems from local stores that put them together
according to specs. they charged extra if you wanted windows installed
(the official price, >$200), but were happy to sell you a bare system
without charging for windows
hs
In article <················@mjolner.upc.no>, ··············@chello.no
says...
> On Thu, 11 Nov 2004 20:34:23 +0100, John Thingstad
> <··············@chello.no> wrote:
>
> > Corperate market no.
> > Most desctop computer's run Windows.
> > The number is still approx 80 %.
> >
> I should perhaps add that this number is difficult to verify since many
> people
> overwrite the Windows that came with the machine with Linux and 40 %
> download Linux from
> the net so they are not counted. So the number of windows users is
> probably artificially high.
On the other hand, it has been suggested that most who buy a PC with
only Linux installed overwrite it with a pirated version of Windows!
Anyway, I think the number of people is only one consideration. The Mac
may have no more home users than Linux, but Mac users have no
ideological hangups about buying software...
- Gerry Quinn
William Bland wrote:
>
> On Thu, 11 Nov 2004 11:36:35 +0000, Gerry Quinn wrote:
>
> > My biggest concern (leaving pure language and re-use considerations out
> > of it) would be easy integration with standard Windows controls and
> > features. I would also require the creation of reasonably compact
> > downloadable .exes that would work reliably on just about any Windows
> > machine, and would not require downloading of added libraries or
> > environments.
>
> Windows? Are you serious? Do people really still use that monstrosity?
>
unfortunately :-)
--
Karl Heinz Buchegger
········@gascad.at
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·····························@nycmny-nntp-rdr-03-ge1.rdc-
> nyc.rr.com>, ·······@nyc.rr.com says...
> > In article <··························@news.indigo.ie>,
> > Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> >
> > Argument by analogy! I love these!! Seriously, I checked out your web
> > site, and I think it might be helpful to turn the challenge "Show me the
> > Lisp game!" around: what exactly do you think Lisp might not be able to
> > handle in writing such games? The logic? The graphics? The GUI?
> > Performance? Other?
>
> My biggest concern (leaving pure language and re-use considerations out
> of it) would be easy integration with standard Windows controls and
> features.
Will the C interface do? Can do. Corman Lisp offers a nice set of
bindings so you Just Call windows API as if it were in Lisp. Same with
AllegroCL.
I gather MS is moving to C++-only deals, which gets ugly since one needs
to develop C glue.
> I would also require the creation of reasonably compact
> downloadable .exes that would work reliably on just about any Windows
> machine, and would not require downloading of added libraries or
> environments.
By compact you mean "will fit on a CD"? Can do. :)
> > All your games could be done easily in Lisp, and because Lisp is so much
> > more productive you could put more time and energy into the graphics and
> > gameplay logic and still finish sooner.
>
> But this is the thing - you go on about how Lisp is "so much more
> productive" but there's no evidence of it! My 'Concentration' clone
> (see else-thread) is about the same length as Michael Naunton's and took
> about the same time to write.
Agreed. I take it back. Lisp is like a Formula I racer (yeah!!
analogies!!). It does not pay off (much) until you have some interesting
driving to do. Concentration and, from what I can see, your games are
too simple to exercise a language. Not that they are bad games!
I was going to port Michael's version to Cells (my FRP hack) when I
realized it would have about three rules. Yawn. I do not need VisiCalc
to buy a six-pack of Bud and some pretzels.
> Call it prejudice if you like, but I *trust* C++, like C before it, to
> not fail in this regard. Even for apps much much bigger than mine.
Well, no, the last bit is exactly the issue, and has not been
established by the Concentration shoot-out.
I propose we all toss off an air traffic control system, one in C++, one
in Lisp, and one in Lisp/Cells, then see. We'll have Michael go first
again. :)
kenny
In article <·····························@nyctyp01-ge0.rdc-nyc.rr.com>,
·······@nyc.rr.com says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> > >
> > > Argument by analogy! I love these!! Seriously, I checked out your web
> > > site, and I think it might be helpful to turn the challenge "Show me the
> > > Lisp game!" around: what exactly do you think Lisp might not be able to
> > > handle in writing such games? The logic? The graphics? The GUI?
> > > Performance? Other?
> >
> > My biggest concern (leaving pure language and re-use considerations out
> > of it) would be easy integration with standard Windows controls and
> > features.
>
> Will the C interface do? Can do. Corman Lisp offers a nice set of
> bindings so you Just Call windows API as if it were in Lisp. Same with
> AllegroCL.
No, it will not! MFC has its faults, but it is better than the Windows
API. Plus, you are now selling a mixture of Lisp and C, versus pure
C++. People talk about 'multi-language' programs, with the optimal
language used for each task, but I suspect this is making a virtue out
of necessity, except on very big projects...
> I gather MS is moving to C++-only deals, which gets ugly since one needs
> to develop C glue.
I doubt that will be an issue, at least for a long time - at worst there
will be a transparent compatibility mode for programs that call the old
API functions. Observe that 16-bit Windows software still works fine
for the most part.
> > I would also require the creation of reasonably compact
> > downloadable .exes that would work reliably on just about any Windows
> > machine, and would not require downloading of added libraries or
> > environments.
>
> By compact you mean "will fit on a CD"? Can do. :)
No I don't. Bandwidth is much cheaper than it used to be, but one
cannot blithely create demos that are tens of MB in size. A MB or two
overhead would be fine, so long as the installation can be made
transparent.
> Agreed. I take it back. Lisp is like a Formula I racer (yeah!!
> analogies!!). It does not pay off (much) until you have some interesting
> driving to do. Concentration and, from what I can see, your games are
> too simple to exercise a language. Not that they are bad games!
>
> I was going to port Michael's version to Cells (my FRP hack) when I
> realized it would have about three rules. Yawn. I do not need VisiCalc
> to buy a six-pack of Bud and some pretzels.
Still, it only took us a couple of hours in Lisp and C++. You've a
captive audience of Lisp fans on this thread - maybe it would be
worthwhile! Actually (funny how these things grow on you) I was toying
with the idea of doing a 2-player Windows version - I think I worked out
an easy way to implement a realistic AI...
> > Call it prejudice if you like, but I *trust* C++, like C before it, to
> > not fail in this regard. Even for apps much much bigger than mine.
>
> Well, no, the last bit is exactly the issue, and has not been
> established by the Concentration shoot-out.
>
> I propose we all toss off an air traffic control system, one in C++, one
> in Lisp, and one in Lisp/Cells, then see. We'll have Michael go first
> again. :)
That seems wisest!
- Gerry Quinn
Kenneth Tilton wrote:
>
>
> Well, no, the last bit is exactly the issue, and has not been
> established by the Concentration shoot-out.
>
Speaking of which. I thought I would write one. LispWorks CAPI
Concentration version. Developed and tested on Windows. But should
work (may need some minor mods) on Mac and Linux.
http://www3.telus.net/public/whumeniu/concentration.lisp
Wade
On Fri, 12 Nov 2004 18:01:22 GMT, Wade Humeniuk
<····································@telus.net> wrote:
> Kenneth Tilton wrote:
>
>> Well, no, the last bit is exactly the issue, and has not been
>> established by the Concentration shoot-out.
>
> Speaking of which. I thought I would write one. LispWorks CAPI
> Concentration version. Developed and tested on Windows. But should
> work (may need some minor mods) on Mac and Linux.
>
> http://www3.telus.net/public/whumeniu/concentration.lisp
>
> Wade
Nice!
Amazing how short that program was.
Wouldn't have thought to use the WebDings font :)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> Nice!
> Amazing how short that program was.
> Wouldn't have thought to use the WebDings font :)
>
I took some time and delivered it as a standalone exe for
windows for those who do not have LWW (even the evaluation
version). Delivery means the lisp image is shaken of uneccessary
functionality before being saved.
http://www3.telus.net/public/whumeniu/concentration.zip
It is a 1.6 MB zip file. The delivery file is included. If
any wants to (and can) deliver a Mac or Linux version, be my guest.
I have lost my icon editor somewhere along the way, so I have
just defaulted the icon to the LW icon.
The actual fsl (compiled lisp file) is 27,133 bytes
The exe size is 4.12 MB. Essentially most of the exe is the
minimal runtime lisp image.
Unzip wherever you like. The executable is concentration.exe
Wade
Also if looking for other LispWorks for Windows Apps see:
http://www.download.com/The-Runner-s-Log/3000-2136_4-6893549.html?tag=lst-0-1
Its a Runner's Log program I wrote a while ago (as my first Common Lisp program
and an exercise to learn LW and CAPI).
It is a much more complex app than the concentration one.
Wade
In article <·····················@clgrps12>, whumeniu-delete-this-
···············@telus.net says...
> I took some time and delivered it as a standalone exe for
> windows for those who do not have LWW (even the evaluation
> version). Delivery means the lisp image is shaken of uneccessary
> functionality before being saved.
>
> http://www3.telus.net/public/whumeniu/concentration.zip
>
> It is a 1.6 MB zip file. The delivery file is included. If
> any wants to (and can) deliver a Mac or Linux version, be my guest.
> I have lost my icon editor somewhere along the way, so I have
> just defaulted the icon to the LW icon.
Well, that is certainly small enough to make Lisp viable for shareware
authors. And the program beats Michael's and mine for size.
One minor gameplay consideration - it would be nice if clicking on a new
tile aborted the two-second display, which otherwise is a bit
frustrating. But perhaps that only shows I am a bit too old for this
game...
I used WebDings on a game myself once. It's a handy way to get some
cheap and cheerful graphics.
- Gerry Quinn
Gerry Quinn wrote:
> Well, that is certainly small enough to make Lisp viable for shareware
> authors. And the program beats Michael's and mine for size.
>
> One minor gameplay consideration - it would be nice if clicking on a new
> tile aborted the two-second display, which otherwise is a bit
> frustrating. But perhaps that only shows I am a bit too old for this
> game...
>
I have taken your suggestion and modified it slightly. Guessing is
now a button-1 press. Aborting a line of guessing is pressing button-2
or button-3 anywhere on the board.
(center and right clicks on a right-handed three button mouse).
The concentration game is written such that one can create a game
where one has to match any n tiles (where n >= 2). Its strange playing
match 3 on a 9x6 board. Makes my head hurt. The way the
game is written if 3 tiles need to match one has to get the first
two to match before one is even allowed to select a third tile. Is
this the proper rule for Concentration? (are their official rules?).
(Note: It would be fairly simple to create a delivered game where one
could change to other sized boards in the game, CAPI would allow this to happen
dynamically in the current window.)
I have made the changes and the new zip file is at the same place.
http://www3.telus.net/public/whumeniu/concentration.zip
> I used WebDings on a game myself once. It's a handy way to get some
> cheap and cheerful graphics.
Seemed like the easiest way to get enough variety in the game.
Wade
In article <······················@edtnps84>, whumeniu-delete-this-
···············@telus.net says...
> Gerry Quinn wrote:
> > Well, that is certainly small enough to make Lisp viable for shareware
> > authors. And the program beats Michael's and mine for size.
> >
> > One minor gameplay consideration - it would be nice if clicking on a new
> > tile aborted the two-second display, which otherwise is a bit
> > frustrating. But perhaps that only shows I am a bit too old for this
> > game...
> >
> I have taken your suggestion and modified it slightly. Guessing is
> now a button-1 press. Aborting a line of guessing is pressing button-2
> or button-3 anywhere on the board.
> (center and right clicks on a right-handed three button mouse).
I just have it so that you can cancel a guess with a click. But on
retrospect, in Concentration that is cheating - I put it in
automatically because in most games it is a standard user interface. It
would only work in Concentration if no cards are turned over until all
arer selected.
> The concentration game is written such that one can create a game
> where one has to match any n tiles (where n >= 2). Its strange playing
> match 3 on a 9x6 board. Makes my head hurt. The way the
> game is written if 3 tiles need to match one has to get the first
> two to match before one is even allowed to select a third tile. Is
> this the proper rule for Concentration? (are their official rules?).
I don't know, but that's the rule I came up with also! I find you don't
need to increase the board size - sets of 3 are hard enough on small
boards!
- Gerry Quinn
Gerry Quinn wrote:
>
>
> I don't know, but that's the rule I came up with also! I find you don't
> need to increase the board size - sets of 3 are hard enough on small
> boards!
Actually I added new games in the Game Menu of various sizes yesterday evening.
(Its in the new concentration.zip)
The biggest selection from the game menu is New 8x9 Match 4.
My 11 year old son played it last night. He actually found it funner at the
more difficult levels. Took him about 15 miuntes for the biggest game.
(He was very thankful for the abort button presses)
Wade
Quoth Gerry Quinn on or about 2004-11-11:
> But this is the thing - you go on about how Lisp is "so much more
> productive" but there's no evidence of it! My 'Concentration' clone
> (see else-thread) is about the same length as Michael Naunton's and took
> about the same time to write.
Someone looking to get flamed might suggest that this is in part because
the program is small -- there is no need for capabilities Lisp provides.
I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
over C/C++: there are demonstrably things that can be expressed in Lisp
but not in C / C++.
A concrete example is defining operators that don't evaluate their
operands exactly once. For example, this specialized loop construct:
#define _aug_doseq(i,from,to) \
for (i=from; \
from<to ? i<to : i>to; \
from<to ? ++i : --i)
#define doseq(i,from,to) \
_aug_doseq((i),(from),(to))
/* example usage */
int
echo (int argc, char *argv[])
{
int i;
doseq (i, 1, argc)
printf (argv[i]);
}
...which only works if the arguments are functional. I can't think of a
way to define doseq to take arguments with side-effects without using
GNU extensions *and* having an unclosed brace in the macro.
In my opinion, Lisp is more elegant. For now I'm taking it on faith
that this is equivalent to `better', at least for high-level problems.
Game programming involves a lot of low-level stuff, right? I don't
think there's any contradiction in saying that Lisp is better for
high-level tasks and C is better for low-level tasks.
-trent
In article <·······················@harpo.marx>,
··············@bigpond.com says...
> Quoth Gerry Quinn on or about 2004-11-11:
> > But this is the thing - you go on about how Lisp is "so much more
> > productive" but there's no evidence of it! My 'Concentration' clone
> > (see else-thread) is about the same length as Michael Naunton's and took
> > about the same time to write.
>
> Someone looking to get flamed might suggest that this is in part because
> the program is small -- there is no need for capabilities Lisp provides.
>
> I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
> over C/C++: there are demonstrably things that can be expressed in Lisp
> but not in C / C++.
But there are no *tasks* fitting that description (hello, Turing-
complete).
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <·······················@harpo.marx>,
> ··············@bigpond.com says...
> > Quoth Gerry Quinn on or about 2004-11-11:
> > > But this is the thing - you go on about how Lisp is "so much more
> > > productive" but there's no evidence of it! My 'Concentration' clone
> > > (see else-thread) is about the same length as Michael Naunton's and took
> > > about the same time to write.
> >
> > Someone looking to get flamed might suggest that this is in part because
> > the program is small -- there is no need for capabilities Lisp provides.
> >
> > I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
> > over C/C++: there are demonstrably things that can be expressed in Lisp
> > but not in C / C++.
>
> But there are no *tasks* fitting that description (hello, Turing-
> complete).
He's talking about _in_, you idiot, not _with_!! Get a clue!
/Jon
>
> - Gerry Quinn
>
--
'j' - a n t h o n y at romeo/charley/november com
Quoth Gerry Quinn on or about 2004-11-12:
> > I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
> > over C/C++: there are demonstrably things that can be expressed in Lisp
> > but not in C / C++.
>
> But there are no *tasks* fitting that description (hello, Turing-
> complete).
Perhaps I was not clear. I am not saying that a given algorithm[0]
cannot be written in C / C++. I am saying that for SOME CLASSES or
algorithm, Lisp's additional features (e.g. lexical closure) allow the
algorithm to be expressed more concisely.
If the task does not lend itself to Lisp's extra features, choice of
language is essentially a matter of personal preference.
Consider: an problem involves a large number of hierarchical datatypes.
You *could* solve the problem in C, but you'll probably think `Aha! This
is an OO-type problem. They are easier to code in C++ than C.' But if
your coprogrammers were unfamiliar with C++ (and OO), they'd probably
try to write C++ code as if it were C, and complain loudly about all the
extra type-checking[1].
-trent
[0] Anything expressible as an algorithm is expressible in Turing
machine language. (Church/Turing thesis)
[1] *I* certainly did this two years ago, before I learnt C++.
On Fri, 12 Nov 2004 13:44:01 +0000, Gerry Quinn wrote:
> In article <·······················@harpo.marx>,
> ··············@bigpond.com says...
>> I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
>> over C/C++: there are demonstrably things that can be expressed in Lisp
>> but not in C / C++.
>
> But there are no *tasks* fitting that description (hello, Turing-
> complete).
>
> - Gerry Quinn
If you think Turing completeness means that all languages are equal in
expressive power, go program in BrainFuck.
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
William Bland <·······@abstractnonsense.com> writes:
> On Fri, 12 Nov 2004 13:44:01 +0000, Gerry Quinn wrote:
> > But there are no *tasks* fitting that description (hello, Turing-
> > complete).
> If you think Turing completeness means that all languages are equal in
> expressive power, go program in BrainFuck.
Or Whitespace if you're python-inclined :-)
http://www.iscblog.info/blog/display/14
--
__Pascal Bourguignon__
On Fri, 12 Nov 2004 15:34:14 GMT, William Bland
<·······@abstractnonsense.com> wrote:
> On Fri, 12 Nov 2004 13:44:01 +0000, Gerry Quinn wrote:
>
>> In article <·······················@harpo.marx>,
>> ··············@bigpond.com says...
>>> I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
>>> over C/C++: there are demonstrably things that can be expressed in Lisp
>>> but not in C / C++.
>>
>> But there are no *tasks* fitting that description (hello, Turing-
>> complete).
>>
>> - Gerry Quinn
>
> If you think Turing completeness means that all languages are equal in
> expressive power, go program in BrainFuck.
>
> Cheers,
> Bill.
One might add that McCarthy's incentive to create LISP (yeah, old style)
was inspired by the awkwardness of expressing proofs using the Turing
machine as a model..
This is becoming a battle of words.
What does expressiveness really mean?
Turing complete, terse, succinct are easier to get a grip on.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> This is becoming a battle of words.
> What does expressiveness really mean?
> Turing complete, terse, succinct are easier to get a grip on.
Terse, succinct, and expressive are all nearly synonymous to me in
this context.
There is another issue. In Perl, for example, you can write very
terse code thanks to all the funky one character variables and stuff.
Reading it afterwards can be problematic though. I suspect there is
a point where code can be too concise so that the effort to read and
understand it is higher than for slightly more verbose code.
How densely packed do you want your ideas? Saving typing is good.
Being able to read the code six months later is also good.
I've found that Lisp tempts me into writing particularly descriptive
names for symbols mostly thanks to the simple legality of the -
character in a symbol name. This is not super terse, but it can be
darn readable if the name is well choosen. Even with the long names,
functions can still be quite short. It seems like a paradox but Lisp
makes it reasonable to do.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Quoth David Steuber on or about 2004-11-14:
> There is another issue. In Perl, for example, you can write very
> terse code thanks to all the funky one character variables and stuff.
Someone once observed that if you count keystrokes instead of
characters, Perl isn't particularly amazing in this respect -- you hit
the shift key a lot.
Incidentally, parens don't need shift on my keyboard :-)
-t
Quoth Stefan Ram on or about 2004-11-15:
> Trent Buck <··············@bigpond.com> writes:
> >Incidentally, parens don't need shift on my keyboard :-)
>
> Incidentally, the first keyboard I used to type LISP-code also
> did not need shift for parentheses:
>
> http://www.total.net/~hrothgar/museum/PET2001/Chiclet.jpg
>
> A separate numeric keypad makes more sense on such a keyboard,
> when there are no numbers on the main keypad. Possibly, such a
> keyboard layout is more adapted to programming language, where
> one needs some special characters more often than in English?
Mine still has numbers above the letters; the keypad I only use for
mouse emulation.
http://144.132.79.25/~twb/img/vector/auto-map/top.png
-trent
On 14 Nov 2004 21:36:12 -0500, David Steuber <·····@david-steuber.com>
wrote:
> "John Thingstad" <··············@chello.no> writes:
>
>
> I've found that Lisp tempts me into writing particularly descriptive
> names for symbols mostly thanks to the simple legality of the -
> character in a symbol name. This is not super terse, but it can be
> darn readable if the name is well choosen. Even with the long names,
> functions can still be quite short. It seems like a paradox but Lisp
> makes it reasonable to do.
>
Some languages like Pascal need to have code expressed a certain way to
even work.
You typically spend a lot of time finding that way.
Turbo Pascal (this was a long time ago..) got around many of the
limitations of Pascal by putting strange squiggles in comments
that altered the behaviour of code.
In comparison programming in C was a relief.
Suddenly the problem was't how to express a problem but rather
which method to choose.
I would then say that C is more *expressive* than Pascal.
Similarly I feel that Smalltalk fits like a straight jacket.
If forces you to convolute the problem to fit the language.
Again you spend your time battling the language rather
than working the problem.
Lisp is 'loose and free'. I can program in the paradigm of choice.
That would depend on the problem and my taste.
I have plenty of option's of how to express the problem.
So Lisp is more *expressive* than Smalltalk.
Succinct is accurate and to the point.
No messing about like them Turbo Pascal squiggles.
The less time you spend combating the language the
more time you have to focus on the problem.
There is a direct link to productivity I think.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
In article <··············@david-steuber.com>, ·····@david-steuber.com
says...
> "John Thingstad" <··············@chello.no> writes:
>
> > This is becoming a battle of words.
> > What does expressiveness really mean?
> > Turing complete, terse, succinct are easier to get a grip on.
>
> Terse, succinct, and expressive are all nearly synonymous to me in
> this context.
I don't find that. Succinct, perhaps, but I see no special merit in
terseness. Surely the ease of recognition of common patterns and idioms
is far more important?
I speak as one who has of late taken to scoping off any part of a
function that has variables local to that part, with a pair of curly
brackets that have a line each. (Dividing functions into 'mini-
functions' that can be refactored as necessary, if you like.)
Maybe I've just got a bigger screen. (Or maybe it's because using a
mouse it's easier to scroll?
> There is another issue. In Perl, for example, you can write very
> terse code thanks to all the funky one character variables and stuff.
> Reading it afterwards can be problematic though. I suspect there is
> a point where code can be too concise so that the effort to read and
> understand it is higher than for slightly more verbose code.
>
> How densely packed do you want your ideas? Saving typing is good.
> Being able to read the code six months later is also good.
>
> I've found that Lisp tempts me into writing particularly descriptive
> names for symbols mostly thanks to the simple legality of the -
> character in a symbol name. This is not super terse, but it can be
> darn readable if the name is well choosen. Even with the long names,
> functions can still be quite short. It seems like a paradox but Lisp
> makes it reasonable to do.
Fortunately, this Lisp advantage has been incorporated into all
languages since Fortran, by way of the underscore '_' character. The
new 'camelCase' technology has also helped with giving comprehensible
names to symbols. (Of course it only works when case is significant...)
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··············@david-steuber.com>, ·····@david-steuber.com
> says...
> > "John Thingstad" <··············@chello.no> writes:
> >
> > > This is becoming a battle of words.
> > > What does expressiveness really mean?
> > > Turing complete, terse, succinct are easier to get a grip on.
> >
> > Terse, succinct, and expressive are all nearly synonymous to me in
> > this context.
>
> I don't find that. Succinct, perhaps, but I see no special merit in
> terseness. Surely the ease of recognition of common patterns and idioms
> is far more important?
If the code fits into a common idiom or pattern, it would probably be
easiest to just have a name for it. The "anamorphic if" pattern would
be a simple case where the pattern can be expressed more easily by a
name than with code structure.
Of course, every language has common idioms. In C, I would expect to
see:
i++;
rather than:
i = i + 1;
And I would expect to see if(;;){...} for infinite loops rather than
while(1){...}.
> I speak as one who has of late taken to scoping off any part of a
> function that has variables local to that part, with a pair of curly
> brackets that have a line each. (Dividing functions into 'mini-
> functions' that can be refactored as necessary, if you like.)
>
> Maybe I've just got a bigger screen. (Or maybe it's because using a
> mouse it's easier to scroll?
This is something I see a lot of in Lisp. Throw in the refactoring,
and vertical space is conserved.
> > There is another issue. In Perl, for example, you can write very
> > terse code thanks to all the funky one character variables and stuff.
> > Reading it afterwards can be problematic though. I suspect there is
> > a point where code can be too concise so that the effort to read and
> > understand it is higher than for slightly more verbose code.
> >
> > How densely packed do you want your ideas? Saving typing is good.
> > Being able to read the code six months later is also good.
> >
> > I've found that Lisp tempts me into writing particularly descriptive
> > names for symbols mostly thanks to the simple legality of the -
> > character in a symbol name. This is not super terse, but it can be
> > darn readable if the name is well choosen. Even with the long names,
> > functions can still be quite short. It seems like a paradox but Lisp
> > makes it reasonable to do.
>
> Fortunately, this Lisp advantage has been incorporated into all
> languages since Fortran, by way of the underscore '_' character. The
> new 'camelCase' technology has also helped with giving comprehensible
> names to symbols. (Of course it only works when case is significant...)
I've never liked the underscore '_' character because I have to hold
down the SHIFT key to type it. This is not so with the hyphen '-'
character. In C, I tend to use 'camelCase' to avoid the underscore.
I would prefer camel-case. C doesn't let me do the latter because of
the way the tokenizer works.
I'm also no longer convinced that case sensitivity is a good thing for
program tokens.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> I'm also no longer convinced that case sensitivity is a good thing for
> program tokens.
In a pure ASCII world you are probably right.
In a Unicode world there is no other choice: case *in*sensitivity is confusing
and ambiguous in general. It is better to simply ignore it as an issue.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak <········@STRIPCAPStelus.net> wrote in message news:<················@STRIPCAPStelus.net>...
> David Steuber <·····@david-steuber.com> writes:
> > I'm also no longer convinced that case sensitivity is a good thing for
> > program tokens.
>
> In a pure ASCII world you are probably right.
>
> In a Unicode world there is no other choice: case *in*sensitivity is confusing
> and ambiguous in general. It is better to simply ignore it as an issue.
If you program with unicode characters, I can only hope you don't
charge for it. Is it r or r?... And people complain about APL, which,
at least, wasn't ambiguous. Non-ASCII characters belong in strings and
comments.
From: Christopher C. Stacy
Subject: Re: case sensitivity (was Re: C++ sucks for games)
Date:
Message-ID: <ufz39gzwo.fsf@news.dtpq.com>
Ray Blaak <········@STRIPCAPStelus.net> writes:
> David Steuber <·····@david-steuber.com> writes:
> > I'm also no longer convinced that case sensitivity is a good thing for
> > program tokens.
>
> In a pure ASCII world you are probably right.
>
> In a Unicode world there is no other choice: case *in*sensitivity is
> confusing and ambiguous in general. It is better to simply ignore it
> as an issue.
I think maybe case (in)sensitivity is being conflated with rich
character sets and their coding implementations. One certainly wants
to be able to enter all the necessary characters for their native language.
But in which languages does the case of the letters in single words actually
change their meaning, other than to distinguish between proper and regular nouns?
Note that for compound words and phrases, I can see actual case
preservation (but still insensitive) as being preferable.
But most of the flaming I see about case sensitivity has nothing
to do with languages other than English, and I think that StudlYCaSE
is terrible in English. One good hint that it's an unnatural artifact
of infix syntax -- no dashes ("-") allowed - is that youDontSeePeople
spellingMessagesLikeThis. (setf (makes-much-more-sense *this*) t).
That's my 2c subjective analysis of the practical and aesthetic issues.
(I can't imagine I've said anything here that hasn't been
argued 1000 times, though, so I'll shut up now.)
······@news.dtpq.com (Christopher C. Stacy) writes:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
> > In a Unicode world there is no other choice: case *in*sensitivity is
> > confusing and ambiguous in general. It is better to simply ignore it
> > as an issue.
[...]
> But in which languages does the case of the letters in single words actually
> change their meaning, other than to distinguish between proper and regular
> nouns?
The canonical example I know of is: in German the lower case of "�" is "s".
The lower of "S" is also "s". Certainly "�" should not be considered the same
as "S". But how should the identifier tokens "foos", "fooS" and "foo�" compare
in a case-insensitive language?
> But most of the flaming I see about case sensitivity has nothing
> to do with languages other than English, and I think that StudlYCaSE
> is terrible in English.
It is terrible in English. So are many identifiers that are only in a single
case. So are many other identifiers in general.
My take on this is simple: use good identifiers based on how comprehensible
they are, period.
The issue of case-(in)sensitivity can be viewed as an orthogonal one. In the
presence of Unicode, being case insensitive is not worth the trouble.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
···@zedat.fu-berlin.de (Stefan Ram) writes:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
> >The canonical example I know of is: in German the lower case of
> >"�" is "s". The lower of "S" is also "s". Certainly "�" should
> >not be considered the same as "S".
> Actually, "�" already is lowercase.
[...]
> If one still insists to use capital characters, there are
> /two/ uppercase versions: the default uppercase spelling is
> "SS", while the spelling "SZ" has to be used, when the default
> spelling might cause ambiguity. So the capitalizations of
> "Masse" and "Ma�e" (two different words with different
> meanings) are "MASSE" and "MASZE", respectively.
Thanks for the correction.
So how would the these identifiers compare in a case-insensitive language:
masze, MASZE, ma�e?
My advice is still to bail on the issue can simply say: different codepoints
== different identifiers.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Followup-To set arbitrarily, it's off-topic everywhere...
Ray Blaak <········@STRIPCAPStelus.net> writes:
> So how would the these identifiers compare in a case-insensitive language:
> masze, MASZE, ma�e?
Unicode provides default case mapping algorithms, which are then tuned
for a few special cases in a few languages (Turkish, Azeri, Lithuanian).
http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf section 3.13
http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf section 5.18
Case folding is neither uppercasing nor lowercasing, but their
combination with the property that it is the smallest equivalence
relation which folds together strings which can be made equal by
uppercasing or lowercasing.
After case folding �, SS and ss are equivalent. Yes, this breaks when
� is uppercased to SZ. A dumb algorithm cannot unambiguously solve
this without breaking languages where SS and SZ are significantly
different. There is also an unsolvable problem with dotted and dotless
I/i, and Unicode tables leave a choice here. This is the closest
language-independent approximation which can be automated.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Tue, 16 Nov 2004 10:36:51 +0000, Gerry Quinn wrote:
> In article <··············@david-steuber.com>, ·····@david-steuber.com
> says...
>> "John Thingstad" <··············@chello.no> writes:
>>
>> > This is becoming a battle of words.
>> > What does expressiveness really mean?
>> > Turing complete, terse, succinct are easier to get a grip on.
>>
>> Terse, succinct, and expressive are all nearly synonymous to me in
>> this context.
>
> I don't find that. Succinct, perhaps, but I see no special merit in
> terseness. Surely the ease of recognition of common patterns and idioms
> is far more important?
Yes, excessive terseness is bad. However, I find the *existence* of common
patterns to be a sign that I haven't got my design right yet, and that I
might need a new macro.
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
In article <······························@abstractnonsense.com>,
·······@abstractnonsense.com says...
> On Tue, 16 Nov 2004 10:36:51 +0000, Gerry Quinn wrote:
> > In article <··············@david-steuber.com>, ·····@david-steuber.com
> > says...
> >> Terse, succinct, and expressive are all nearly synonymous to me in
> >> this context.
> >
> > I don't find that. Succinct, perhaps, but I see no special merit in
> > terseness. Surely the ease of recognition of common patterns and idioms
> > is far more important?
>
> Yes, excessive terseness is bad. However, I find the *existence* of common
> patterns to be a sign that I haven't got my design right yet, and that I
> might need a new macro.
David: "anamorphic if" [WTF?]
Ray: "lower case is best because it's a unicode world" [and here I
though MSVC was so primitive compared to the magical text-editors]
William: "existence of patterns shows new macro is needed" [patterns are
ubiquitous and normal, *words* are patterns for heaven's sake]
I can see that this subthread is devolving into the most primitive form
of Lisp advocacy. How long before someone claims that no respectable
language can have more or less than four letters in its name?
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Ray: "lower case is best because it's a unicode world" [and here I
> though MSVC was so primitive compared to the magical text-editors]
Actually, that's: case-sensitive is best...
Of course, maybe it's even better to have a language with ASCII-only
identifiers (or some other suitable "visual" Unicode subset) and then be case
*in*sensitive after all.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
"John Thingstad" <··············@chello.no> wrote in message news:<················@mjolner.upc.no>...
> On Fri, 12 Nov 2004 15:34:14 GMT, William Bland
> <·······@abstractnonsense.com> wrote:
>
> > On Fri, 12 Nov 2004 13:44:01 +0000, Gerry Quinn wrote:
> >
> >> In article <·······················@harpo.marx>,
> >> ··············@bigpond.com says...
> >>> I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
> >>> over C/C++: there are demonstrably things that can be expressed in Lisp
> >>> but not in C / C++.
> >>
> >> But there are no *tasks* fitting that description (hello, Turing-
> >> complete).
> >>
> >> - Gerry Quinn
> >
> > If you think Turing completeness means that all languages are equal in
> > expressive power, go program in BrainFuck.
> >
> > Cheers,
> > Bill.
>
> One might add that McCarthy's incentive to create LISP (yeah, old style)
> was inspired by the awkwardness of expressing proofs using the Turing
> machine as a model..
>
> This is becoming a battle of words.
> What does expressiveness really mean?
> Turing complete, terse, succinct are easier to get a grip on.
Expressiveness is the degree to which you don't have to tell the
computer *how*, only *what*.
Usually, that also leads to terseness, because the what is usually
shorter than the how.
On Fri, 12 Nov 2004, Gerry Quinn wrote:
> But there are no *tasks* fitting that description (hello, Turing-
> complete).
>
There're a couple of problems with taking turing complete as the point you
stop caring. The first is that it ignores issues like IO and concurrency -
operational semantics matter. The second is that it completely ignores
static semantics, where one language's version may contain proofs of
significant properties of the program that aren't present in the other.
I find the latter to be something of an issue, especially as the
equivalence of programs is in general undecidable.
--
······@flippac.org
Gerry Quinn <······@DELETETHISindigo.ie> wrote in message news:<··························@news.indigo.ie>...
> In article <·······················@harpo.marx>,
> ··············@bigpond.com says...
> > Quoth Gerry Quinn on or about 2004-11-11:
> > > But this is the thing - you go on about how Lisp is "so much more
> > > productive" but there's no evidence of it! My 'Concentration' clone
> > > (see else-thread) is about the same length as Michael Naunton's and took
> > > about the same time to write.
> >
> > Someone looking to get flamed might suggest that this is in part because
> > the program is small -- there is no need for capabilities Lisp provides.
> >
> > I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
> > over C/C++: there are demonstrably things that can be expressed in Lisp
> > but not in C / C++.
>
> But there are no *tasks* fitting that description (hello, Turing-
> complete).
Hahaha. In these newsgroups related to advanced programming languages,
there is a law in effect very similar to Godwin's. Namely, as the
thread grows longer, the probability approaches one of someone
invoking Turing equivalence as an argument against statements about
different languages having different expressiveness. The associated
tradition is identical.
In article <···························@posting.google.com>,
···@ashi.footprints.net says...
> Gerry Quinn <······@DELETETHISindigo.ie> wrote in message news:<··························@news.indigo.ie>...
> > In article <·······················@harpo.marx>,
> > > I'm a pretty new to Lisp, but I can immediately an advantage Lisp has
> > > over C/C++: there are demonstrably things that can be expressed in Lisp
> > > but not in C / C++.
> >
> > But there are no *tasks* fitting that description (hello, Turing-
> > complete).
>
> Hahaha. In these newsgroups related to advanced programming languages,
> there is a law in effect very similar to Godwin's. Namely, as the
> thread grows longer, the probability approaches one of someone
> invoking Turing equivalence as an argument against statements about
> different languages having different expressiveness. The associated
> tradition is identical.
But the point I am making is that Turing-completeness implies that all
*tasks* can in fact be expressed without using any singular
expressiveness feature of Lisp. The issue is whether a large proportion
of tasks can be 'naturally' expressed in a form unique to Lisp, and in
no other way. In other words, what tasks 'naturally' require Lisp'd
unique features, and are much harder to express without them?
I don't see why many games should have such a property.
- Gerry Quinn
Quoth Gerry Quinn on or about 2004-11-13:
> The issue is whether a large proportion
> of tasks can be 'naturally' expressed in a form unique to Lisp, and in
> no other way. In other words, what tasks 'naturally' require Lisp'd
> unique features, and are much harder to express without them?
s/require/leverage/. There is a significant difference between X
`requiring' Y and X being able to take advantage of Y. Whether
deliberately or accidentally, you seem to be conflating these two
distinct relations.
I haven't enough experience with lisp to give good examples of tasks
that leverage Lisp extras. I will give some poor examples instead.
I earlier mentioned specialization of flow control structure[0], which
cannot be written correctly in C or C++. Another is return-from, which
can only be approximated in C / C++ with the goto operator.
From any perspective, which is easier to read?:
dotimes (i, 10)
printf ("%d", i);
for (i=0; i<10; ++i)
printf ("%d", i);
-trent
[0] See doseq() in http://144.132.79.25/~twb/src/common/augment.h
In article <·······················@harpo.marx>,
··············@bigpond.com says...
> Quoth Gerry Quinn on or about 2004-11-13:
> > The issue is whether a large proportion
> > of tasks can be 'naturally' expressed in a form unique to Lisp, and in
> > no other way. In other words, what tasks 'naturally' require Lisp'd
> > unique features, and are much harder to express without them?
>
> s/require/leverage/. There is a significant difference between X
> `requiring' Y and X being able to take advantage of Y. Whether
> deliberately or accidentally, you seem to be conflating these two
> distinct relations.
>
> I haven't enough experience with lisp to give good examples of tasks
> that leverage Lisp extras. I will give some poor examples instead.
>
> I earlier mentioned specialization of flow control structure[0], which
> cannot be written correctly in C or C++. Another is return-from, which
> can only be approximated in C / C++ with the goto operator.
The thing is, these are language features, and don't address the
question above - what problems really need them? As for augment.h, it
seems to be an attempt to create macros to extend C. If you do have a
problem that needs a functional language, I think you would be better
off using one rather than abusing C!
> From any perspective, which is easier to read?:
>
> dotimes (i, 10)
> printf ("%d", i);
>
> for (i=0; i<10; ++i)
> printf ("%d", i);
For me, the second is easier, because of familiarity. But I donlt think
the first has any natural advantages to someone unfamiliar with either
language. They may ask "What's a dotime - some kind of dot?". printf()
is of course a C grotesquerie.
The easiest language to read for a naive reader would IMO be BASIC:
for i = 0 to 10
print i
next i
- Gerry Quinn
> -trent
> [0] See doseq() in http://144.132.79.25/~twb/src/common/augment.h
>
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> > From any perspective, which is easier to read?:
> >
> > dotimes (i, 10)
> > printf ("%d", i);
> >
> > for (i=0; i<10; ++i)
> > printf ("%d", i);
>
> For me, the second is easier, because of familiarity. But I donlt think
> the first has any natural advantages to someone unfamiliar with either
> language. They may ask "What's a dotime - some kind of dot?". printf()
> is of course a C grotesquerie.
>
> The easiest language to read for a naive reader would IMO be BASIC:
>
> for i = 0 to 10
> print i
> next i
>
>
Well you could also write
(loop for i from 0 to 10 do
(print i))
Quoth Gerry Quinn on or about 2004-11-14:
> The thing is, these are language features, and don't address the
> question above - what problems really need them?
I think we are debating different things. I contend[0] that, for at
least some tasks, a solution can be expressed more readily and succintly
by an experienced Lisp programmer in Lisp than an experienced C/C++
programmer in C/C++. You counter this by pointing out that solutions
can still be expressed in C/C++.
I am not disputing this. I have agreed and continue to agree with you
on this point. But as other denizens have pointed out, this is akin to
saying that all turing-complete languages are equal, simply because they
are turing-complete. I think this is a rather monochromatic view to
adopt, but until your demonstrate the ability to grade languages more
finely I see no pupose in continuing this discussion.
> As for augment.h, it
> seems to be an attempt to create macros to extend C. If you do have a
> problem that needs a functional language, I think you would be better
> off using one rather than abusing C!
I don't always get a to choose which language I use :-(
And I don't see it as abuse. I'm merely extending C upwards to the
algorithm in my head at the same time as I extend my algorithm down to
C. A dotimes loop is closer than a for loop to 'do { X } Y times',
which is how I think about some loops.
In that respect, dotimes() is to for() what for() is to while(), since
'for (I;P;M) B' is congruent to 'I; while (P) { B; M; }'.
(Oh, and C is just as functional as Lisp. The lack of memory manglement
and destructors simply makes it more difficult :-)
> printf() is of course a C grotesquerie.
Lisp's (format) isn't much better.
-trent
[0] Please note that this is an article of faith; I feel I do not have
sufficient empirical evidence to assert it as fact.
Trent Buck <··············@bigpond.com> wrote in message news:<·······················@harpo.marx>...
[ ... ]
> I think we are debating different things. I contend[0] that, for at
> least some tasks, a solution can be expressed more readily and succintly
> by an experienced Lisp programmer in Lisp than an experienced C/C++
> programmer in C/C++.
Especially if we restrict both to the base language (i.e. without
using add-on libraries) this would be almost impossible to dispute --
just for an obvious example, a program to multiply two 60-digit
numbers is clearly simpler in Lisp than in C or C++.
The same is true in the other direction as well though -- solutions to
some problems are clearly easier in C or C++ than in Lisp (e.g. many
typical engineering problems).
Unfortunately most people don't write things that fall so obviously
into an area where Lisp provides such obvious advantages -- I'm
reasonably certain my bank balance hasn't involved any 60-digit
numbers recently! :-)
Many of the examples cited by the Lispers in this thread have the same
problem. At least to me, even if we all agreed that what a computer
produced really was art, it would miss the point.
The relevance of an example program having been written in a
particular langauge depends on the problem it solves being relevant to
the problems I'm likely to want to solve. Writing a program that does
"art" (even assuming we all agreed it was art) means little to me,
because I can see little relationship between the kinds of things it
probably does and the kinds of things I want to do.
The same is true in the other direction as well, though I think the C
and C++ advocates have been a bit more sensible (or at least
restrained) in what they cite, even though obvious examples in this
direction are much more relevant (and therefore compelling) to the
kinds of things I happen to do. Nearly all of us (on both sides of the
fence) run OSes written in C, post to an Internet that runs almost
entirely on code written in C, etc. At least for the problems I happen
to enjoy solving, those examples are far more relevant. If I had a
choice between creating a drastically better art program or a
drastically better router, I'd do the router (in fact, I sort of
already am...)
Now, that's NOT meant as a commentary on the fundamental capabilities
of the languages themselves, only on the examples that have been given
in this thread. I'm well aware that if I wanted to badly enough, I
could write the software for a router in Lisp. I believe, however,
that for this particular pursuit, Lisp would present more shortcomings
than advantages. Some of the Lisp advocates seem to believe (or at
least want others to believe) that Lisp always provides advnatages
with no weaknesses, an idea with which I disagree.
Another basic point that I think a lot of people miss is that in the
end, most of us ultimately program for enjoyment -- yes, my regular
job has something about "software" in the title, but if I didn't enjoy
programming, I'd find a different job. I believe I've mentioned
previously in this thread that I've written Lisp off and on for over
20 years, and implemented Lisp a few times as well. For better or
worse, Lisp just doesn't suit me very well -- I'm glad I studied it,
and I think my programs are better for having done so, but the fact of
the matter is that as far as real enjoyment goes, my first Lisp
interpreter (written in 8080 assembly language) was simply a lot more
fun than any of the coding I've ever done IN Lisp.
I'm the first to admit, however, the people differ from each other as
well -- the fact that I enjoy one thing more than another doesn't
imply that somebody else will do the same. A person's choice of
programming language is, to a large extent, a reflection of their own
personality. This is why the statement above about their being
problems that are easier to solve in Lisp more or less misses the
point. The real question is whether I (or whoever) find those
particular problems interesting to solve, and whether I find it
interesting to solve them in the way(s) that Lisp supports. In my
case, the answer is generally no. Others obviously disagree -- and
more power to them, IMO.
Unfortunately, at least to most appearances, most Lisp advocates have
a rather different sentiment: specifically that eveybody must
acknowledge that Lisp is the ultimate answer to all possible
programming problems. IMO, they're welcome to believe that if they
want, but the need they seem to feel to carry their crusade to the
rest of the world is annoying at best, and downright anti-social most
of the time -- on the order of somebody with whom every conversation
inevitably turns into an argument in which peace can only be restored
if everybody else acknowledges the superiority of their particular
political or religious views.
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) writes:
> The same is true in the other direction as well though -- solutions
> to some problems are clearly easier in C or C++ than in Lisp
> (e.g. many typical engineering problems).
I know of two kinds of programs that are easier to write in C than
Lisp: Those that mainly interface with the very C-centric operating
systems/environments, and some casese of special-purpose
number-crunching programs where the "portable assembly"-mode of C can
provide decent performance reasonably well (so, the program as such
isn't easier to write, but getting the expected performance is). Other
than this, I know of no such "typical engineering problems".
> Unfortunately most people don't write things that fall so obviously
> into an area where Lisp provides such obvious advantages -- I'm
> reasonably certain my bank balance hasn't involved any 60-digit
> numbers recently! :-)
Let's say your bank balance is represented as an integer number of
1/100 units of some currency. In 32-bit C, you'd be able to represent
some 40 million. It'd be an interesting event to see Bill Gates come
deposit his money and you explain to him that unfortunately "the
integer wrapped around, so we can only tell you your balance modulo 40
million". And what when you need to calculate the bank's accumulated
deposits? Or the average of this over the last three decades? Would
you try to ensure that 64-bit integers are used throughout and cross
your fingers that nothing unforeseen happens?
> [..] At least for the problems I happen to enjoy solving, those
> examples are far more relevant. If I had a choice between creating a
> drastically better art program or a drastically better router, I'd
> do the router (in fact, I sort of already am...)
Funnily enough, I happen to have written a sort-of ethernet switch in
Lisp :)
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
[ ... ]
> I know of two kinds of programs that are easier to write in C than
> Lisp: Those that mainly interface with the very C-centric operating
> systems/environments, and some casese of special-purpose
> number-crunching programs where the "portable assembly"-mode of C can
> provide decent performance reasonably well (so, the program as such
> isn't easier to write, but getting the expected performance is). Other
> than this, I know of no such "typical engineering problems".
My guess is that in this case, you're either carefully maintaining
ignorance, or else for you Lisp is automatically simpler until/unless
it's _drastically_ more complex (e.g. 100 times as much code).
Just for example, I was recently looking at some C++ code for
designing FIR filters. It's part of SPUC, available at
spuc.sourceforge.net. As-delivered, the particular piece I'm looking
at (remez_fir.cpp) contains 282 lines of actual code (i.e. lines that
contain _anything_ other than white space or a comment).
I did a search for Lisp code that was apparently (about) equivalent,
and (to eliminate personal bias allowing me to pick a particularly bad
example) took the first thing Google turned up. The result was:
http://www.dxarts.washington.edu/docs/clmman/fltdes.lisp
Looking specifically at the code for Remes exchange. Using the same
criteria (lines, as delivered, that contain something other than
comment or whitespace) it's slightly longer (313 lines). Worse, while
I'm sure some people know Lisp enough better than C++ that they find
it easier to follow, it's difficult for me to imagine how that could
be. Nearly no name in the code is more than a couple of characters
long, and most are utterly meaningless, even to somebody who starts
out knowing what he's looking for.
Far worse, however, is the flow of control: the C++ code contains 9
functions, with a bunch of loops (I didn't try to count them) and the
only thing that qualifies as "unstructured" even from a completely
puritanical viewpoint is 2 break statements.
At least if I'm reading it correctly, the Lisp is a whole different
story. In fact, I'm scared to describe it -- I'd appreciate it if one
of the more frequent Lisp users would check, but are all those "go's"
what I think they are?
I have to admit that even I can hardly believe I could have stumbled
across such awful code by accident, but I've re-checked: I simply
typed "Lisp FIR filter" into Google, following the _first_ link it
came up with, clicked on "filter" in the "brief index" and then
clicked on the link to "fltdes" on about the sixth line (or so)
showing on-screen at that point. IOW, I'm pretty sure I didn't do much
where I could have influenced the choice of what code I looked at, but
unless I'm reading it entirely incorrectly, I'd be hard-put to blame
anybody for thinking I spent hours coming up with the worst piece of
garbage on the planet.
> > Unfortunately most people don't write things that fall so obviously
> > into an area where Lisp provides such obvious advantages -- I'm
> > reasonably certain my bank balance hasn't involved any 60-digit
> > numbers recently! :-)
>
> Let's say your bank balance is represented as an integer number of
> 1/100 units of some currency. In 32-bit C, you'd be able to represent
> some 40 million.
What is this "32-bit C", you speak of? About all I can think of that
you might be talking about is "C prior to the current standard". The
current standard for C includes a 'long long' data type that has a
minimum of 64 bits. This isn't exctly a brand-new standard either --
it's been around for roughly 5 years now.
> It'd be an interesting event to see Bill Gates come
> deposit his money and you explain to him that unfortunately "the
> integer wrapped around, so we can only tell you your balance modulo 40
> million". And what when you need to calculate the bank's accumulated
> deposits? Or the average of this over the last three decades? Would
> you try to ensure that 64-bit integers are used throughout and cross
> your fingers that nothing unforeseen happens?
If I want 64-bit integers used throughout, I won't _try_ do so -- I'll
use long long and it WILL happen.
As far as the rest goes, you're going back to exactly the kind of
examples I talked about before: things that are utterly remote from
what most of us care about or have any use for.
Let's face reality: I'm pretty sure my bank wouldn't tell me their
total deposits to the penny right now, not to mention for every one of
the last 30 years. Even if we assumed that it did, it would be an
amazingly large bank indeed for even a 30-year total of deposits to
exceed what fits into a 64-bit integer.
Even a ridiculous as those are, we're left with the final step, which
is the most utterly ridiculous of all: the notion that anybody in the
world cares at all about whether that number ends with 71 or 72 cents.
When you're dealing with an individual account, being accurate to the
penny matter. When (for example) large companies do their quarterly
SEC filings, they typically round to something like hundreds of
thousands of dollars -- even though they're NOWHERE close to exceeding
the range of a 64-bit integer.
[ ... ]
> Funnily enough, I happen to have written a sort-of ethernet switch in
> Lisp :)
I guess that might be a fun project, but there's really not a whole
lot to an Ethernet switch. A router is in a completely different
league. Some types of switches (e.g. ATM switches) are fairly complex,
but Ethernet switches are pretty trivial, almost regardless of the
language you choose.
--
Later,
Jerry.
The universe is a figment of its own imagination.
In article <··························@posting.google.com>,
Jerry Coffin <·······@taeus.com> wrote:
> http://www.dxarts.washington.edu/docs/clmman/fltdes.lisp
>
> Looking specifically at the code for Remes exchange. Using the same
> criteria (lines, as delivered, that contain something other than
> comment or whitespace) it's slightly longer (313 lines). Worse, while
> I'm sure some people know Lisp enough better than C++ that they find
> it easier to follow, it's difficult for me to imagine how that could
> be. Nearly no name in the code is more than a couple of characters
> long, and most are utterly meaningless, even to somebody who starts
> out knowing what he's looking for.
>
> Far worse, however, is the flow of control: the C++ code contains 9
> functions, with a bunch of loops (I didn't try to count them) and the
> only thing that qualifies as "unstructured" even from a completely
> puritanical viewpoint is 2 break statements.
>
> At least if I'm reading it correctly, the Lisp is a whole different
> story. In fact, I'm scared to describe it -- I'd appreciate it if one
> of the more frequent Lisp users would check, but are all those "go's"
> what I think they are?
Uh, if you look at the comments that file looks a hell of a lot like an
(very direct) translation of some Fortran code. So if it looks like
Fortran, that's probably why. Compare with the output of f2c.
Heck, it even says at the top:
;;; translation of most of the FORTRAN programs given in "Digital Filter
;;; Design" by Parks and Burrus
I doubt you'd find any competent Lisp programmer who would actually
write new code like that - it's nasty.
It is unfortunate that your search turns that up as the first result.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing <·············@lavos.net> wrote in message news:<·······················@attbi_s04>...
[ ... ]
> Uh, if you look at the comments that file looks a hell of a lot like an
> (very direct) translation of some Fortran code.
I probably _should_ have looked at the comments at the top, but
immediately went looking for what corresponded to what I happened to
be looking at in C++ right then. Then, when I really started _looking_
at the code, I mostly just wanted to quit looking as quickly as
possible!
I suppose I really _should_ have looked for some other code, (almost
ANY other code) but quite frankly, looking at that took away any
interest I might have had for such a search, at least for a while.
[ ... ]
> I doubt you'd find any competent Lisp programmer who would actually
> write new code like that - it's nasty.
I certainly _hope_ not!
> It is unfortunate that your search turns that up as the first result.
True -- I certainly doubt it's nowhere close to representative. OTOH,
as I understand things, part of how Google determines ranking is other
links to that site, indicating that this code is left to the obscurity
it so richly deserves. Worse, given that it does show up as the first
result of an obvious search, it probably gets seen quite a bit
(certainly more than it deserves).
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
> Brian Downing <·············@lavos.net> wrote in message news:<·······················@attbi_s04>...
>
> [ ... ]
>
>
>>Uh, if you look at the comments that file looks a hell of a lot like an
>>(very direct) translation of some Fortran code.
>
>
> I probably _should_ have looked at the comments at the top, but
> immediately went looking for what corresponded to what I happened to
> be looking at in C++ right then. Then, when I really started _looking_
> at the code, I mostly just wanted to quit looking as quickly as
> possible!
>
> I suppose I really _should_ have looked for some other code, (almost
> ANY other code) but quite frankly, looking at that took away any
> interest I might have had for such a search, at least for a while.
>
> [ ... ]
>
>
>>I doubt you'd find any competent Lisp programmer who would actually
>>write new code like that - it's nasty.
>
>
> I certainly _hope_ not!
>
>
I have taken some time to look at the code. My impression is that it is
not so bad. When writing the code the author's primary concern is the
correctness compared to a reference implementation. I also see this as the
overiding concern. As a user of the code, if there was problem I could
find the reference and do a direct check if everything was OK. If the
code was written to improve some aesthetic criteria that all important
checking would be lost. Kudos to the author of the code for keeping to
the spirit of Lisp! (to express the solution in the most natural
language of the experts). As for all the variable names being terse, all
I can say is that they have MEANING to the experts.
I also find it strange that you would choose to use a library or not based
on some aesthetic judgement. If one was to look at the internals of LINPACK
one might be appalled, but LINPACK works, its tested, its fast. Real code
tends to be cruddy inside its package, but that is hardly important. One
should not look at a gift horse in the mouth.
Wade
>>It is unfortunate that your search turns that up as the first result.
>
>
> True -- I certainly doubt it's nowhere close to representative. OTOH,
> as I understand things, part of how Google determines ranking is other
> links to that site, indicating that this code is left to the obscurity
> it so richly deserves. Worse, given that it does show up as the first
> result of an obvious search, it probably gets seen quite a bit
> (certainly more than it deserves).
>
Wade Humeniuk <····································@telus.net> wrote in message news:<······················@clgrps13>...
[ ... ]
> I have taken some time to look at the code. My impression is that it is
> not so bad.
In that case, I certainly hope I never see anything you'd admit WAS
"so bad".
Beyond that I have little left to say to you -- it would appear to me
that your views of programming are sufficiently different from my own
as to preclude any hope of a rational discussion between us on the
subject.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
>>I have taken some time to look at the code. My impression is that it is
>>not so bad.
>
> In that case, I certainly hope I never see anything you'd admit WAS
> "so bad".
>
> Beyond that I have little left to say to you -- it would appear to me
> that your views of programming are sufficiently different from my own
> as to preclude any hope of a rational discussion between us on the
> subject.
apparently you didn't read beyond the snippet you quoted. wade
proceeded to give some reasons.
also, see. Christopher Stacy's article where he expresses his suspicion
that this code is the output of a fortran>lisp translator
hs
Hartmann Schaffer <··@hartmann.schaffernet> wrote in message news:<··················@newscontent-01.sprint.ca>...
[ ... ]
> apparently you didn't read beyond the snippet you quoted.
Actually, I read the whole thing.
> wade proceeded to give some reasons.
Yes and no -- he gave excuses (not really reasons) and even those
weren't reasons to believe the code was good, but merely that it was
justifiable to continue using the code despite its poor quality.
Another look at the code itself, however, reveals the real truth: you
can argue all day long that horrible code is excusable, but the fact
remains that this is the worst code I've looked at in years (in any
language). In the end, only one conclusion is possible: attempting to
discuss programming with anybody who claims it's "not so bad" is
pointless.
> also, see. Christopher Stacy's article where he expresses his suspicion
> that this code is the output of a fortran>lisp translator
Yes, it may well be. In fact I've previously pointed out that I agree
that this is probably the case. This may tell us how this horrible
code was produced, but does nothing to change the fact that it IS
horrible.
The truly sad part is that it's a fair guess that the Fortran code has
long since been fixed. From the looks of the code, it's based on
something written in Fortran 66 (or earlier). Fortran added block
structures in the 1977 standard, and has been updated a couple more
times since then, to the point that it now supports reasonable
structure. Most Fortran programmers have embraced this sufficiently
that spaghetti code like this is rarely seen in Fortran anymore.
--
Later,
Jerry.
The universe is a figment of its own imagination.
"Jerry Coffin" <·······@taeus.com> wrote in message
································@posting.google.com...
> Hartmann Schaffer <··@hartmann.schaffernet> wrote in message
news:<··················@newscontent-01.sprint.ca>...
>
> [ ... ]
>
> > apparently you didn't read beyond the snippet you quoted.
>
> Actually, I read the whole thing.
>
> > wade proceeded to give some reasons.
>
> Yes and no -- he gave excuses (not really reasons) and even those
> weren't reasons to believe the code was good, but merely that it was
> justifiable to continue using the code despite its poor quality.
>
> Another look at the code itself, however, reveals the real truth: you
> can argue all day long that horrible code is excusable, but the fact
> remains that this is the worst code I've looked at in years (in any
> language). In the end, only one conclusion is possible: attempting to
> discuss programming with anybody who claims it's "not so bad" is
> pointless.
>
> > also, see. Christopher Stacy's article where he expresses his suspicion
> > that this code is the output of a fortran>lisp translator
>
> Yes, it may well be. In fact I've previously pointed out that I agree
> that this is probably the case. This may tell us how this horrible
> code was produced, but does nothing to change the fact that it IS
> horrible.
>
> The truly sad part is that it's a fair guess that the Fortran code has
> long since been fixed. From the looks of the code, it's based on
> something written in Fortran 66 (or earlier). Fortran added block
> structures in the 1977 standard, and has been updated a couple more
> times since then, to the point that it now supports reasonable
> structure. Most Fortran programmers have embraced this sufficiently
> that spaghetti code like this is rarely seen in Fortran anymore.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
It's Jessica Rabbit code:
I'm not bad, I was just generated that way...
All this noise about old machine generated fortran->lisp code from *a very
long time ago* - and the code works fine (when did the Remez algorithm
change?) I just spent a very short time extracting just the remes function
and supporting code from the web page cited
(http://www.dxarts.washington.edu/docs/clmman/fltdes.lisp), compiled it and
ran the example located in the header comments. It compiled, loaded and ran
without a hitch.
On visual inspection, the code could use a little error-checking to prevent
div 0 (14-15 occurances.) And I wouldn't call it production code without
mods. It's not even close to being the worst code I've seen in any
language - not by a long shot, well, except for the GO's. It's ugly, but it
works. Agree it's machine generated. If I had to work with it, I'd diagram,
refactor, add error-handling, comment and add a test harness. Probably take
a day, maybe more, probably less. At least in Lisp. Equivalent C++ code
cleanup would be difficult to determine. I have much more experience with
C++ and think that it would take longer to refactor bad code like this in
C++ than it would in Lisp. YMMV.
If anybody wants the code, let me know.
Mike
From mathworld (note the last line):
http://mathworld.wolfram.com/RemezAlgorithm.html
An algorithm for determining optimal coefficients for digital filters. The
Remez algorithm in effect goes a step beyond the minimax approximation
algorithm to give a slightly finer solution to an approximation problem.
The Remez exchange algorithm (Remez 1957) was first studied by Parks and
McClellan (1972). The algorithm is an iterative procedure consisting of two
steps. One step is the determination of candidate filter coefficients h(n)
from candidate "alternation frequencies," which involves solving a set of
linear equations. The other step is the determination of candidate
alternation frequencies from the candidate filter coefficients (Lim and
Oppenheim 1988). Experience has shown that the algorithm converges very
fast, and is widely used in practice to design optimal filters.
A FORTRAN implementation is given by Rabiner (1975). A description
emphasizing the mathematical foundations rather than digital signal
processing applications is given by Cheney (1999), who also spells Remez as
Remes (Cheney 1966, p. 96).
Brian Downing <·············@lavos.net> writes:
>
> Uh, if you look at the comments that file looks a hell of a lot like an
> (very direct) translation of some Fortran code. So if it looks like
> Fortran, that's probably why. Compare with the output of f2c.
>
> Heck, it even says at the top:
>
> ;;; translation of most of the FORTRAN programs given in "Digital Filter
> ;;; Design" by Parks and Burrus
>
> I doubt you'd find any competent Lisp programmer who would actually
> write new code like that - it's nasty.
Automatic FORTRAN -> Lisp translation programs have been seriously
used for mathematical libraries since the 1970s. I wonder if the
source code you're looking at is the result of such a translation.
Usually, such translation systems try to preserve the structure
of the original FORTRAN program.
(Otherwise, I guess this was some human accomplishing the same thing.)
·······@taeus.com (Jerry Coffin) writes:
> Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
>
> [ ... ]
>
>> I know of two kinds of programs that are easier to write in C than
>> Lisp: Those that mainly interface with the very C-centric operating
>> systems/environments, and some casese of special-purpose
>> number-crunching programs where the "portable assembly"-mode of C
>> can provide decent performance reasonably well (so, the program as
>> such isn't easier to write, but getting the expected performance
>> is). Other than this, I know of no such "typical engineering
>> problems".
>
> My guess is that in this case, you're either carefully maintaining
> ignorance, or else for you Lisp is automatically simpler
> until/unless it's _drastically_ more complex (e.g. 100 times as much
> code).
>
> Just for example, I was recently looking at some C++ code for
> designing FIR filters. It's part of SPUC, available at
> spuc.sourceforge.net. As-delivered, the particular piece I'm looking
> at (remez_fir.cpp) contains 282 lines of actual code (i.e. lines
> that contain _anything_ other than white space or a comment).
>
> I did a search for Lisp code that was apparently (about) equivalent,
> and (to eliminate personal bias allowing me to pick a particularly bad
> example) took the first thing Google turned up. The result was:
>
> http://www.dxarts.washington.edu/docs/clmman/fltdes.lisp
>
> Looking specifically at the code for Remes exchange. Using the same
> criteria (lines, as delivered, that contain something other than
> comment or whitespace) it's slightly longer (313 lines). Worse,
> while I'm sure some people know Lisp enough better than C++ that
> they find it easier to follow, it's difficult for me to imagine how
> that could be. Nearly no name in the code is more than a couple of
> characters long, and most are utterly meaningless, even to somebody
> who starts out knowing what he's looking for.
>
> Far worse, however, is the flow of control: the C++ code contains 9
> functions, with a bunch of loops (I didn't try to count them) and the
> only thing that qualifies as "unstructured" even from a completely
> puritanical viewpoint is 2 break statements.
>
> At least if I'm reading it correctly, the Lisp is a whole different
> story. In fact, I'm scared to describe it -- I'd appreciate it if one
> of the more frequent Lisp users would check, but are all those "go's"
> what I think they are?
You did read the comments at the top of the file didn't you?
Particularly this one:
;;; translation of most of the FORTRAN programs given in "Digital
;;; Filter Design" by Parks and Burrus
And "translation" may well be generous--transliteration is more like
it. This is hardly idomatic Lisp code.
But in a perverse way this shows another of Common Lisp's strengths.
While TAGBODY and GO are almost never used directly since there are
higher-level control constructs built on top of them for all your
structured programming needs, the fact that they are available does
allow Common Lisp to be used to do this kind of transliteration. Which
is another kind of expressiveness. For instance, suppose one started
from a working FORTRAN program--as these authors seem to have done.
You could do a straight transliteration into GO-full Common Lisp and
get it working. Now you have a version in Common Lisp that works and
you can hook it into your test framework and then start refactoring it
into idomatic Common Lisp while being fairly confident that you're not
breaking anything. To say nothing of the fact that you could probably
write a few ad-hoc refactoring tools in Lisp to help tidy up the
FORTRAN-esque code 'cuz of that whole code-is-data thing.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> ·······@taeus.com (Jerry Coffin) writes:
>> Just for example, I was recently looking at some C++ code for
>> designing FIR filters. It's part of SPUC, available at
>> spuc.sourceforge.net. As-delivered, the particular piece I'm
>> looking at (remez_fir.cpp) contains 282 lines of actual code (i.e.
>> lines that contain _anything_ other than white space or a comment).
Okay, beacuse I'm an idiot I spent a little while looking at that C++
code instead of doing what I'm supposed to be doing. Anyway, I started
from the end of the file and translated a couple functions into
idiomatic Common Lisp. Obviously I didn't tackle the meat of the
program but I think even the translation of these functions shows some
of the expressive benefits of Common Lisp. Here are the two C++
functions from the spuc distro:
double* remez_fir::freqSample(double A[], int numtaps, int symm) {
double x, val;
int N = numtaps;
double M = (N-1.0)/2.0;
double* h = new double[N];
if (symm == POSITIVE) {
if (N%2 != 0) {
for (int n=0; n<N; n++) {
val = A[0];
x = TWOPI * (n - M)/N;
for (int k=1; k<=M; k++) val += 2.0 * A[k] * cos(x*k);
h[n] = val/N;
}
}
else {
for (int n=0; n<N; n++) {
val = A[0];
x = TWOPI * (n - M)/N;
for (int k=1; k<=(N/2-1); k++) val += 2.0 * A[k] * cos(x*k);
h[n] = val/N;
}
}
}
else {
if (N%2 != 0) {
for (int n=0; n<N; n++) {
val = 0;
x = TWOPI * (n - M)/N;
for (int k=1; k<=M; k++) val += 2.0 * A[k] * sin(x*k);
h[n] = val/N;
}
}
else {
for (int n=0; n<N; n++) {
val = A[N/2] * sin(PI * (n - M));
x = TWOPI * (n - M)/N;
for (int k=1; k<=(N/2-1); k++) val += 2.0 * A[k] * sin(x*k);
h[n] = val/N;
}
}
}
return h;
}
bool remez_fir::isDone(int r, int ext[], double e[]) {
double min, max, current;
min = max = fabs(e[ext[0]]);
for (int i=1; i<=r; i++){
current = fabs(e[ext[i]]);
if (current < min) min = current;
if (current > max) max = current;
}
if (((max-min)/max) < 0.0001) return true;
return false;
}
And here are my Common Lisp translations. They are untested so there
may be typos or brainos in there, but this is more or less how I think
those functions might look in Common Lisp:
(defun frequency-sample (a numtaps symmetry)
(let* ((h (make-array numtaps :element-type 'double-float :initial-element 0.0d0))
(m (/ (- numtaps 1.0d0) 2.0d0))
(iters (if (oddp numtaps) m (1- (floor numtaps 2))))
(trig-fn (if (eql symmetry :positive) #'cos #'sin)))
(flet ((base-value (n)
(if (eql symmetry :positive)
(aref a 0)
(if (oddp numtaps)
0
(* (aref a (floor numtaps 2) (sin (* pi (- n m)))))))))
(loop for n from 0 below numtaps
for x = (/ (* 2 pi (- n m)) numtaps)
for val = (+ (base-value n)
(loop for k from 1 to iters
summing (* 2.0d0 (aref a k) (funcall trig-fn (* x k)))))
do (setf (aref h n) (/ val numtaps))))
h))
(defun done-p (ext e)
(loop for idx across ext
for current = (fabs (aref e idx))
maximizing current into max
minimizing current into min
finally (return (< (/ (- max min) max) 0.0001d))))
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
[ ... ]
> Okay, beacuse I'm an idiot I spent a little while looking at that C++
> code instead of doing what I'm supposed to be doing. Anyway, I started
> from the end of the file and translated a couple functions into
> idiomatic Common Lisp. Obviously I didn't tackle the meat of the
> program but I think even the translation of these functions shows some
> of the expressive benefits of Common Lisp. Here are the two C++
> functions from the spuc distro:
[ ... using one line as an example, you translated this: ]
> h[n] = val/N;
[ to this: ]
> (setf (aref h n) (/ val numtaps))))
Well, your code is clearly a lot better than what Google turned up -- as I'd expect.
IMO C++ is still the _clear_ winner (no pun, just double entendre, intended).
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) writes:
> Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
>
> [ ... ]
>
>> Okay, beacuse I'm an idiot I spent a little while looking at that
>> C++ code instead of doing what I'm supposed to be doing. Anyway, I
>> started from the end of the file and translated a couple functions
>> into idiomatic Common Lisp. Obviously I didn't tackle the meat of
>> the program but I think even the translation of these functions
>> shows some of the expressive benefits of Common Lisp. Here are the
>> two C++ functions from the spuc distro:
>
> [ ... using one line as an example, you translated this: ]
>
>> h[n] = val/N;
>
> [ to this: ]
>
>> (setf (aref h n) (/ val numtaps))))
>
> Well, your code is clearly a lot better than what Google turned up -- as I'd expect.
>
> IMO C++ is still the _clear_ winner (no pun, just double entendre, intended).
Okay. So you like C++. I like Lisp. But I have to say that that's a
strange way to compare--why do you care so much about the number of
characters in that one line when my Lisp version is half the number of
lines as the C++ version?
And for that matter why not compare:
if (N%2 != 0) { ...
to
(if (oddp N) ...
Which do you think more clearly expresses what is actually going on?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
[ ... ]
> Okay. So you like C++. I like Lisp. But I have to say that that's a
> strange way to compare--why do you care so much about the number of
> characters in that one line when my Lisp version is half the number of
> lines as the C++ version?
Because the length of an individual line and the number of lines mean
very little. My objection stems from opaquity, not length.
I'd also note that I was taking existing code as it stood, with no
rewriting or modifying. If we want something short and don't mind some
rewriting:
enum symmetry { POS, NEG};
std::vector<double> freqSample(std::vector<double> A, symmetry symm) {
double (*funcs[])(double) = {cos, sin};
std::vector<double> h;
size_t N = A.size();
double M = (N-1.0)/2.0;
int limit = N&1 ? int(M) : N/2-1;
for (int n=0; n<N; n++) {
double val = symm==POS ? A[0] : n&1 ? 0 : A[N/2] * sin(PI *
(n-M));
double x = 2.0 * PI * (n-M)/N;
for(int k=1; limit; k++)
val += 2.0 * A[k] * funcs[symm](x*k);
h.push_back(val/N);
}
return h;
}
Personally, I'm not entirely convinced that shorter is better, but
whether it is or not, this seems (to me anyway) to more or less
disprove the notion that the C++ code as longer because Lisp is more
expressive. Rather the contrary, I think the length of the C++ code
was probably a conscious decisin. In particular, both this and your
Lisp version reduce length via indirection -- which typically carries
a speed penalty.
In any case C++ has the "expressiveness" to make the code short if
that's what's desired.
> And for that matter why not compare:
>
> if (N%2 != 0) { ...
>
> to
>
> (if (oddp N) ...
>
> Which do you think more clearly expresses what is actually going on?
IMO, neither one is particularly superior to the other, but you
apparently disagree (or you wouldn't have asked).
Nonetheless, I think this does point out one of the larger
deficiencies in CL: due to the "extreme -- almost juvenile --rivalry
between dialect groups" (to quote Guy L. Steele and Richard Gabriel)
keeping the CL effort from exploding meant meant making it a union of
essentially everything then in existence, even if it meant such
silliness as having both oddp and evenp, as if one wasn't the
complement of the other, having (if memory serves) five different
functions for converting from floating point to integer, etc., ad
naseum.
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) wrote
> very little. My objection stems from opaquity, not length.
And your definition of clarity / opacity is influenced by your
language preference.
> I'd also note that I was taking existing code as it stood, with no
> rewriting or modifying. If we want something short and don't mind some
> rewriting:
>
> enum symmetry { POS, NEG};
> std::vector<double> freqSample(std::vector<double> A, symmetry symm) {
[...]
> }
To me, that's even less readable than the original C++, and it causes
unnecessary copying of structures. I think I'd refactor it like this:
void freqSample (const double * const A, const size_t N, double *
const h, const symmetry symm) {
/* requires:
* p is a valid pointer for reading in A <= p < (A + N)
* p is a valid pointer for assignment in h <= p < (h + N)
* side effect:
* changes the N first values of the h array
*/
const double M = (N - 1.0) / 2.0;
const double K = PI * 2 / N;
double baseval;
if (symm == POS) {
baseval = A[0];
} else {
baseval = N & 1 ? 0 : A[N/2];
}
for (unsigned int n = 0 ; n < N ; ++n) {
double val = baseval;
if (symm == NEG && !(N & 1)) {
val *= sin(PI * (n - M));
}
double x = K * (n - M);
for (int k = 1 ; k < M ; ++k) {
val += 2 * A[k] * (symm == POS ? cos(x * k) : sin(x *
k));
}
h[n] = val / N;
}
}
I don't have any description of the original algorithm, I've just
written this based on the codes posted here.
This can be transliterad into Lisp like this:
(defun freq-sample (A N h symm)
;; requires:
;; A is a vector readable for indexes 0 to N-1
;; h is a vector writeable for indexes 0 to N-1
;; side effect:
;; changes the N first values of the h vector
(let ((M (/ (- N 1.0) 2.0))
(K (/ (* PI 2) N))
(baseval (if (eq symm :pos)
(aref A 0)
(if (oddp N)
0
(aref A (/ N 2))))))
(loop for i below N
if (and (eq symm :neg) (evenp N))
do (setf val (* baseval (sin (* PI (- i M)))))
else
do (setf val baseval)
do (let ((x (* K (- i M))))
(loop for k from 1 below M
summing (* 2 (aref A k) (if (eq symm :pos)
(cos (* x k))
(sin (* x k))))
into val
finally (setf (aref h i) (/ val N)))))))
I have verified that this executes, but again I have no idea if it
computes the correct result.
Peter Lewerin wrote:
> This can be transliterad into Lisp like this:
>
> (defun freq-sample (A N h symm)
> ;; requires:
> ;; A is a vector readable for indexes 0 to N-1
> ;; h is a vector writeable for indexes 0 to N-1
> ;; side effect:
> ;; changes the N first values of the h vector
> (let ((M (/ (- N 1.0) 2.0))
> (K (/ (* PI 2) N))
> (baseval (if (eq symm :pos)
> (aref A 0)
> (if (oddp N)
> 0
> (aref A (/ N 2))))))
> (loop for i below N
> if (and (eq symm :neg) (evenp N))
> do (setf val (* baseval (sin (* PI (- i M)))))
> else
> do (setf val baseval)
> do (let ((x (* K (- i M))))
> (loop for k from 1 below M
> summing (* 2 (aref A k) (if (eq symm :pos)
> (cos (* x k))
> (sin (* x k))))
> into val
> finally (setf (aref h i) (/ val N)))))))
>
>
>
> I have verified that this executes, but again I have no idea if it
> computes the correct result.
And with a little playing.... :)
(defmacro sigma (range &body body)
"Think Greek Capital Sigma"
(destructuring-bind (var from below)
range
`(loop for ,var from ,from below ,below summing (progn ,@body))))
;; Seem like really useful helper functions
(defun |A[k]sin(kx)| (A x &optional (start 0) end)
(sigma (k start (or end (length A))) (* (aref A k) (sin (* k x)))))
(defun |A[k]cos(kx)| (A x &optional (start 0) end)
(sigma (k start (or end (length A))) (* (aref A k) (cos (* k x)))))
(defun freq-sample (A N h symm)
(let* ((M (/ (- N 1.0) 2.0))
(K (/ #.(* 2 pi) N))
(baseval (if (eql symm :pos) (aref A 0)
(if (oddp N) 0 (aref A (/ N 2))))))
(dotimes (i N h)
(let ((x (* K (- i M)))
(val (if (and (eql symm :neg)
(evenp N))
(* baseval (* pi (- i M)))
baseval)))
(incf val
(* 2.0 (if (eql symm :pos)
(|A[k]cos(kx)| A x 1 M)
(|A[k]sin(kx)| A x 1 M))))
(setf (aref h i) (/ val N))))))
CL-USER 5 > (freq-sample (make-array 10 :element-type 'double-float :initial-element 0.7d5)
10
(make-array 10 :element-type 'double-float :initial-element 0.0d0)
:pos)
#(1108.6910822717487 -3566.6781464609985 6999.999999999997 -13738.273538536054
44196.2606027253 44196.2606027253 -13738.273538536054 6999.999999999997
-3566.6781464609985 1108.6910822717487)
CL-USER 6 >
Wade
In article <···············@clgrps12>,
Wade Humeniuk <····································@telus.net> wrote:
> (defmacro sigma (range &body body)
> "Think Greek Capital Sigma"
> (destructuring-bind (var from below)
> range
> `(loop for ,var from ,from below ,below summing (progn ,@body))))
Might as well use DEFMACRO's built-in destructuring:
(defmacro sigma ((var from below) &body body)
"Think Greek Capital Sigma"
`(loop for ,var from ,from below ,below summing (progn ,@body)))
This way you also get the more helpful Slime docstring:
(sigma (var from below) &body body)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Wade Humeniuk <····································@telus.net> wrote
> And with a little playing.... :)
Sure, that's a more effective use of Lisp's capabilities. I was
attempting to provide implementations in C++ and Lisp that were as
similar in structure as I could manage, and still reasonably
realistic.
<unfair>Interestingly, this involved making the C++ code smarter, and
dumbing down the Lisp.</unfair>
;-)
From: Kalle Olavi Niemitalo
Subject: redundant operators in a programming language (was: C++ sucks for games)
Date:
Message-ID: <878y8wnusv.fsf_-_@Astalo.kon.iki.fi>
·······@taeus.com (Jerry Coffin) writes:
> even if it meant such silliness as having both oddp and evenp,
> as if one wasn't the complement of the other
If that's silly, then surely one should also drop the /= function
as it's the complement of =... oops, no it isn't, if called with
more than two arguments. But some other languages have == and !=
as complements and I don't hear anyone complain about that.
From: David Steuber
Subject: Re: redundant operators in a programming language (was: C++ sucks for games)
Date:
Message-ID: <87zn1cdn97.fsf@david-steuber.com>
Kalle Olavi Niemitalo <···@iki.fi> writes:
> ·······@taeus.com (Jerry Coffin) writes:
>
> > even if it meant such silliness as having both oddp and evenp,
> > as if one wasn't the complement of the other
>
> If that's silly, then surely one should also drop the /= function
> as it's the complement of =... oops, no it isn't, if called with
> more than two arguments. But some other languages have == and !=
> as complements and I don't hear anyone complain about that.
In PAIP, Norvig says to be specific. By that heuristic, it is better
to say (evenp foo) than (not (oddp foo)). I gotta agree with that.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
·······@taeus.com (Jerry Coffin) writes:
> Just for example, I was recently looking at some C++ code for
> designing FIR filters. It's part of SPUC, available at
> spuc.sourceforge.net. As-delivered, the particular piece I'm looking
> at (remez_fir.cpp) contains 282 lines of actual code (i.e. lines
> that contain _anything_ other than white space or a comment). [..]
Taking what I presume you consider a decent piece of C++ code as a
starting point, and then comparing it to the google "I feel lucky"
Common Lisp version, isn't a terribly good way to eliminate personal
bias. In fact, just "terrible" describes that method better, IMHO.
And, I suspect, don't FIR filters fit my description of one of the two
areas where the benefits of Common Lisp aren't all that clear, namely
some special purpose number crunching? I mean, when you have some
functional abstraction with a very clearly defined mathematical
relationship between input and output, and algorithms without too much
fancy control flow, then almost any language/syntax will do (sometimes
even assembly), and effortless (predictable) performance becomes the
more important factor.
Finally, it seems to me others here have showed that properly written
Common Lisp does quite a bit better than the example you found.
> What is this "32-bit C", you speak of? About all I can think of that
> you might be talking about is "C prior to the current standard". The
> current standard for C includes a 'long long' data type that has a
> minimum of 64 bits. This isn't exctly a brand-new standard either --
> it's been around for roughly 5 years now.
So since five years, no 32-bit C integer wrap-around has occured by
mistake? The whole issue is simply solved by introducing 64-bit "long
longs"? And the possibility of any computation exceeding 64 bits of
integer precision can just be ignored? Pennies can be ignored, even if
we're counting millions of transactions? Well, then I suppose C++
really is the language for you.
> If I want 64-bit integers used throughout, I won't _try_ do so --
> I'll use long long and it WILL happen.
Right, it's everyone else who make the bugs happen. What a pity it's
not you who write all software.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
[ ... ]
> Taking what I presume you consider a decent piece of C++ code as a
> starting point, and then comparing it to the google "I feel lucky"
> Common Lisp version, isn't a terribly good way to eliminate personal
> bias. In fact, just "terrible" describes that method better, IMHO.
Sounds a lot like sour grapes to me. Perhaps I didn't make it clear,
but I picked out both pieces of code in essentially the same fashion.
Other than the fact that the Lisp code was so horrendous, I probably
wouldn't have made a big deal about it in either case.
> And, I suspect, don't FIR filters fit my description of one of the two
> areas where the benefits of Common Lisp aren't all that clear, namely
> some special purpose number crunching?
Well, I certainly wouldn't consider FIR filters particularly "special
purpose" at all -- quite the contrary, they're useful (and heavily
used) in a huge variety of situations.
They're also closely related to the FFT, DCT, etc., used in many forms
of lossy compression. Now, perhaps to you "HDTV, "cell phone", "CD",
"DVD" and "MP3" all sound so obscure that something used in all of the
above qualifies as "special purpose", but here on planet earth, that's
not particularly accurate.
You've also conveniently forgotten that you claimed that even in these
cases, Lisp was still just as easy to use, while C and C++ merely
provided better performance.
Now, I've yet to see Lisp measure up in performance for these jobs,
but let's face reality: even if we totally ignored performance, none
of the Lisp code we've seen for the job so far has been anywhere close
to as nice as the C++ versions.
Now, I'll certainly admit that there are times it's worth trading off
some readability to gain performace, and other times the reverse --
but it's a lot harder to justify the Lisp code when it's slower AND
harder to read.
> I mean, when you have some
> functional abstraction with a very clearly defined mathematical
> relationship between input and output, and algorithms without too much
> fancy control flow, then almost any language/syntax will do (sometimes
> even assembly), and effortless (predictable) performance becomes the
> more important factor.
It sounds to me like you've just said that Lisp provides advantages
only when/if you've done such insufficient analysis that you shouldn't
be writing code of ANY kind yet.
> Finally, it seems to me others here have showed that properly written
> Common Lisp does quite a bit better than the example you found.
Better than that example, but the C++ code is still clearly superior.
[ ... ]
> > If I want 64-bit integers used throughout, I won't _try_ do so --
> > I'll use long long and it WILL happen.
>
> Right, it's everyone else who make the bugs happen. What a pity it's
> not you who write all software.
You seem to specialize in non-sequiters. If I decide to use a long
long, I can certainly do so. Somehow you make a jump from "large
enough integer type" to "perfectly bug-free code". If that was
actually justified, then any language that provided
arbitrary-precision integers would guarantee bug-free code, but
somehow that doesn't seem to have happened.
At the same time, it should be pointed out that on the (relatively
rare) ocassion that somebody cares, they can easily use arbitrary
precision integers in C++. Doing the same in C is possible, but you
have to use prefix-notation function calls to do nearly everything,
which is ugly (i.e. it looks like Lisp).
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) wrote
> Other than the fact that the Lisp code was so horrendous,
Well, the C++ code was quite horrendous too, so maybe it evens out.
:-)
I'm actually a bit surprised that no C++ programmers have pointed out
yet that the C++ is sloppily written, obfuscated, and potentially
dangerous. It's *not* a flattering example of C++.
In article <····························@posting.google.com>,
·············@swipnet.se says...
> ·······@taeus.com (Jerry Coffin) wrote
>
> > Other than the fact that the Lisp code was so horrendous,
>
> Well, the C++ code was quite horrendous too, so maybe it evens out.
> :-)
>
> I'm actually a bit surprised that no C++ programmers have pointed out
> yet that the C++ is sloppily written, obfuscated, and potentially
> dangerous. It's *not* a flattering example of C++.
Couldn't find it.
- Gerry Quinn
·······@taeus.com (Jerry Coffin) writes:
> Well, I certainly wouldn't consider FIR filters particularly
> "special purpose" at all -- quite the contrary, they're useful (and
> heavily used) in a huge variety of situations.
>
> They're also closely related to the FFT, DCT, etc., used in many
> forms of lossy compression. Now, perhaps to you "HDTV, "cell phone",
> "CD", "DVD" and "MP3" all sound so obscure that something used in
> all of the above qualifies as "special purpose", but here on planet
> earth, that's not particularly accurate.
Of course they are, by special purpose I did not mean "single
application". FFT and DCT etc. was exactly what I was talking about. I
consider e.g. an 8x8 iDCT transform for MPEG decoding to be a quite
special purpose function, with very clearly mathematically defined
relationship between input and output, just as I explained. That this
particular function is used in a wide array of gadgets and programs,
is really quite far besides the point.
> You've also conveniently forgotten that you claimed that even in
> these cases, Lisp was still just as easy to use, while C and C++
> merely provided better performance.
It seems to me that it is you who is conveniently forgetting that you
have been shown Lisp code that is shorter than your C++ code. Of
course you think the C++ version "nicer", but don't pretend that's
anything but your subjective opinion.
In fact, I'd find it quite interesting to discuss your example from
another sub-thread.
Compare "h[n] = val/N;" to "(setf (aref h n) (/ val numtaps))".
Never mind that any person literate in both languages see these as
identical. I think my point above is illustrated even in these two
simple lines. Because, the Lisp syntax here (setf ..) scales very well
in terms of concepts and mechanisms. Once one learns to appreciate the
expressive power of Lisp's "places", of which "(aref h n)" is an
example here, it also becomes very natural to want to express array
elements as such places, and the idea that one should introduce
special syntax for this particular and mundane concept just to save
some characters of program text, or to emulate high-school maths,
becomes ridiculous. The C++ syntax here, on the other hand, goes
nowhere. Points about syntax such as this is of course completely lost
on the casual reader of Lisp code, but they are valid and important,
nonetheless.
> Now, I'll certainly admit that there are times it's worth trading
> off some readability to gain performace, and other times the reverse
> -- but it's a lot harder to justify the Lisp code when it's slower
> AND harder to read.
Let me point out that one needs to be a minimum of literate in any
language in order to be in a position where one can make any kind of
judgement on readability. That a language which you presumably rarely,
if ever, use extensively appears obscure to you, shouldn't surprise
you.
>> I mean, when you have some functional abstraction with a very
>> clearly defined mathematical relationship between input and output,
>> and algorithms without too much fancy control flow, then almost any
>> language/syntax will do (sometimes even assembly), and effortless
>> (predictable) performance becomes the more important factor.
>
> It sounds to me like you've just said that Lisp provides advantages
> only when/if you've done such insufficient analysis that you
> shouldn't be writing code of ANY kind yet.
Well, there's this concept called "exploratory programming" that I
really like and which is impossible with C++. But that's not the issue
here. If all the programs you're writing is merely the encoding of
some perfect mathematical model of every function, data and control
flow, then good for you, but I believe that's not the reality most
programmers find themselves in.
>> > If I want 64-bit integers used throughout, I won't _try_ do so --
>> > I'll use long long and it WILL happen.
>>
>> Right, it's everyone else who make the bugs happen. What a pity
>> it's not you who write all software.
>
> You seem to specialize in non-sequiters. If I decide to use a long
> long, I can certainly do so. Somehow you make a jump from "large
> enough integer type" to "perfectly bug-free code". If that was
> actually justified, then any language that provided
> arbitrary-precision integers would guarantee bug-free code, but
> somehow that doesn't seem to have happened.
It is you who is making unwarranted jumps here. I thought it obvious
from the context that "the bugs" refers to program errors resulting
from unexpected integer wrap-arounds. My point is simply that this is
something that does happen, even if 64-bit integers have been around
for a long time. And even 64-bit isn't immune to overflow.
> At the same time, it should be pointed out that on the (relatively
> rare) ocassion that somebody cares, they can easily use arbitrary
> precision integers in C++. Doing the same in C is possible, but you
> have to use prefix-notation function calls to do nearly everything,
> which is ugly (i.e. it looks like Lisp).
What you mean is that you have to start fighting the language: You'll
have two completely separate kinds of numbers, and you'll have to
concern yourself with which operators apply to which variables
etc. And the compiler is left completely in the dark about what's
going on wrt. type inference etc., something I'd guess is true also
for C++.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
[ ... ]
> Of course they are, by special purpose I did not mean "single
> application". FFT and DCT etc. was exactly what I was talking about.
Okay, so "special purpose" in your vocabulary translates to what most
people would call "extremely general purpose".
Bottom line: we're not talking about something extremely obscure that
virtually nobody ever has a reason to deal with, or anything like
that. We're talking about something that's reasonably representative
of what quite a few people really do on quite a regular basis.
[ ... ]
> That this particular function is used in a wide array of gadgets
> and programs, is really quite far besides the point.
It may be beside whatever point it was that you were trying to make,
but if so, it would seem to indicate that your "point" was really
pretty nearly pointLESS.
> > You've also conveniently forgotten that you claimed that even in
> > these cases, Lisp was still just as easy to use, while C and C++
> > merely provided better performance.
>
> It seems to me that it is you who is conveniently forgetting that you
> have been shown Lisp code that is shorter than your C++ code.
No, I have not. There was Lisp code shorter than the SPUC code -- _my_
C++ code is shorter still.
> Of
> course you think the C++ version "nicer", but don't pretend that's
> anything but your subjective opinion.
The claim _seems_ to be that the Lisp code was better than the SPUC
code because it was shorter. If we take that as the measure, then my
C++ code is clearly better than the Lisp code that was posted.
I'm not convinced that's the case though -- both my code and the Lisp
code were shortened by introducing more indirection. While this often
increases convenience, it quite dependably slows execution speed. What
we have is a pretty clear tradeoff between size and speed. If you
don't need the speed, then the reduced size is an advantage, but
anybody making such a tradeoff should certainly realize that he hasn't
simply "improved" the code, but that he's changed the tradeoffs
involved.
> In fact, I'd find it quite interesting to discuss your example from
> another sub-thread.
>
> Compare "h[n] = val/N;" to "(setf (aref h n) (/ val numtaps))".
>
> Never mind that any person literate in both languages see these as
> identical.
Close anyway.
The still leaves room for a fairly substantial and meaningful
difference though: that C++ is easily readable by quite a few people
who aren't familiar with C++ itself, but happen to be familiar with
Pascal, Fortran, BASIC, Java, or any number of other vaguely similar
languages.
By contrast, the Lisp is more or less unique to Common Lisp. Somebody
familiar with some older Lisp (e.g. ZetaLisp or MacLisp) or with
something like Scheme could probably take a pretty fair _guess_ at
what was going on, but that's about it -- setf has been implemented as
a macro in Scheme, but unless the Schemer in question happened to also
be familiar with Common Lisp as well, he really wouldn't know what was
going on.
This goes back to the (lack of) syntax in Lisp. Knowing one language
in the Algol/Fortran group tends to make quite a bit of almost any
other in the group fairly easy to understand. In Lisp, by contrast,
learning the syntax teaches you only syntax. That lets you identify
(to some extent) which things are going to be evaluated as
functions/special forms, but that's about it. Until you know exactly
what "setf" happens to mean, you can't divine anything about what this
might mean.
I do feel obliged to point out that Lisp's paucity of syntax doesn't
_have_ to spell the disasater embodied in CL. It's only a naming
convention, but at least when it's written at all well, Scheme is
clearly better in this respect -- setf would be named setf! (and let
is let!, etc.), predicates always end in "?", and so on, so the name
of a function can provide at least some information, whereas in CL you
have no more than a totally arbitrary association between a string and
some action.
> I think my point above is illustrated even in these two
> simple lines. Because, the Lisp syntax here (setf ..) scales very well
> in terms of concepts and mechanisms. Once one learns to appreciate the
> expressive power of Lisp's "places", of which "(aref h n)" is an
> example here, it also becomes very natural to want to express array
> elements as such places, and the idea that one should introduce
> special syntax for this particular and mundane concept just to save
> some characters of program text, or to emulate high-school maths,
> becomes ridiculous.
Somehow I'm reminded of the old joke about the proud mother pointing
at her son in the parade and saying "Oh look, everybody's out of step
except my Johny."
"Once one learns to appreciate...it becomes natural" is a cheap
debating trick at best -- it basically translates to "Anybody who
disagrees with me on this point is stupid or ignorant." Unfortunately,
that's simply not a valid point.
The theoretical similarity of all Turing-complete languages has been
cited previously in this thread. There are real differences between
languages however: one is that a real language provides reasonably
syntax. Another is that a even though it is Turing complete, a real
language is defined to help solve problems in some specific category.
C++ provides a specialized syntax for array access for the simple
reason that this is often helpful in solving the problems for which it
is intended.
Lisp refuses to provide such special syntax. AFAICT, for the simple
reason that nobody has really ever pinned down what it's supposed to
be good at -- because its advocats persist in claiming that it's good
at everything. That result is a language that _could_ be good at
almost anything, but really _is_ good for almost nothing.
Lisp reminds me of one of my relatives: he's brilliant, athletic (or
used to be anyway), and good enough looking that even though he's now
past 60, he still attracts nearly every woman within miles. Deciding
what he was going to do when he grew up would have meant giving up
other things for which he really did have the potential. He refused to
do so, which has prevented him from concentrating on anything. The
result is that instead of missing out on some possibilities, he's
missed out on ALL of them.
> The C++ syntax here, on the other hand, goes
> nowhere. Points about syntax such as this is of course completely lost
> on the casual reader of Lisp code, but they are valid and important,
> nonetheless.
IOW, you like Lisp better, and dismiss all who disagree as lacking
your brilliant insights, etc., ad naseum.
Frankly, your lofty claims strike me as little more than hot air. Your
later guesses about C++ make it clear that you lack the knowledge
necessary to comment on it intelligently.
> > Now, I'll certainly admit that there are times it's worth trading
> > off some readability to gain performace, and other times the reverse
> > -- but it's a lot harder to justify the Lisp code when it's slower
> > AND harder to read.
>
> Let me point out that one needs to be a minimum of literate in any
> language in order to be in a position where one can make any kind of
> judgement on readability. That a language which you presumably rarely,
> if ever, use extensively appears obscure to you, shouldn't surprise
> you.
The code has an extra level of indirection. That has nothing to do
with my ability to read, and everything to do with how the code is
structured.
Your presumption that I rarely if ever make extensive use of the
language is simply incorrect -- in fact, if I chose to, I could put up
better arguments in its defense than you have so far (and Lisp I've
written is certainly better than the average of what's been posted so
far in this thread).
[ ... ]
> Well, there's this concept called "exploratory programming" that I
> really like and which is impossible with C++.
I believe any claim of the form "X is impossible in Y", where X is a
technique and Y is a major programming language, reflects ignorance or
dishonesty (or both) on the part of the person making the claim.
[ ... ]
> It is you who is making unwarranted jumps here. I thought it obvious
> from the context that "the bugs" refers to program errors resulting
> from unexpected integer wrap-arounds. My point is simply that this is
> something that does happen, even if 64-bit integers have been around
> for a long time. And even 64-bit isn't immune to overflow.
I see -- so treating what you said as what you meant was an
"unwarranted jump". Okay, I guess from now on I'll know better than to
trust you.
In the end, we're left with one simple fact though: while people
certainly do write buggy code in C++ on a regular and ongoing basis,
integer overflows appear to account for no more than a miniscule
percentage of that.
I think you're tilting at a windmill here -- and AFAICT, the windmill
is imaginary.
[ ... ]
> What you mean is that you have to start fighting the language: You'll
> have two completely separate kinds of numbers, and you'll have to
> concern yourself with which operators apply to which variables
> etc.
Here we seem to nearly agree, but "It's like Lisp" is a lot more
succinct way of saying it.
> And the compiler is left completely in the dark about what's
> going on wrt. type inference etc., something I'd guess is true also
> for C++.
Your guess indicates less about the subject than your ignorance of it.
--
Later,
Jerry.
The universe is a figment of its own imagination.
In article <···························@posting.google.com>,
·······@taeus.com says...
> The same is true in the other direction as well, though I think the C
> and C++ advocates have been a bit more sensible (or at least
> restrained) in what they cite, even though obvious examples in this
> direction are much more relevant (and therefore compelling) to the
> kinds of things I happen to do. Nearly all of us (on both sides of the
> fence) run OSes written in C, post to an Internet that runs almost
> entirely on code written in C, etc. At least for the problems I happen
> to enjoy solving, those examples are far more relevant. If I had a
> choice between creating a drastically better art program or a
> drastically better router, I'd do the router (in fact, I sort of
> already am...)
Well, I would be far more interested in art - I do screensavers, after
all, and a screensaver that paints would be cool. As for routers, let
alone their efficiency, I have no interest in them whatsoever!
I suspect that any 'artist' AI I did would be in C++. Even if I were
manipulating strings of interacting semantic tokens, I would likely
treat them as data. Lisp-ers would assert that I was "re-creating Lisp
in C++", perhaps with some justification. But it's do-able, and would
probably be a relatively small part of the development process...
[Obviously the above is speculative as I don't know how to make an
'artist' AI, and maybe I would be forced to consider another language if
I did figure it out.]
- Gerry Quinn
·······@taeus.com (Jerry Coffin) wrote
> Unfortunately, at least to most appearances, most Lisp advocates have
> a rather different sentiment: specifically that eveybody must
> acknowledge that Lisp is the ultimate answer to all possible
> programming problems.
I think you'd find it difficult to find even one Lisp advocate that
takes that position. There are Lisp kooks (such as the one who
started this thread), of course, but what language doesn't have its
share of those?
I think the problem is rather that most people in the programming
business are so thoroughly convinced that Lisp is a useless and
obsolete language that when they see someone advocating it, they
immediately assume that this person is insane, ignorant,
proselytizing, or all of those at the same time. In my experience,
"coming out" as a Lisp user is considered at best eccentric, at worst
rude and provocative, on the "standing up in church and announcing
that you're a gay Wiccan" level of 'provocative'.
I honestly don't care one bit what language people use for
programming, and I don't know any Lisper who does either.
On Sun, 14 Nov 2004 11:22:34 GMT, Trent Buck <··············@bigpond.com>
wrote:
>> printf() is of course a C grotesquerie.
>
> Lisp's (format) isn't much better.
>
> -trent
>
> [0] Please note that this is an article of faith; I feel I do not have
> sufficient empirical evidence to assert it as fact.
The big win in Lisp is on manipulation of complex data structures and
operations on them.
C's advantages is the closeness to the operating system and hardware.
C++ is pretty much the same.
You'r examples seem to be missing the key issues.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Gerry Quinn wrote:
> In article <·······················@harpo.marx>,
> ··············@bigpond.com says...
>>From any perspective, which is easier to read?:
>>
>> dotimes (i, 10)
>> printf ("%d", i);
>>
>> for (i=0; i<10; ++i)
>> printf ("%d", i);
>
>
> For me, the second is easier, because of familiarity. But I donlt think
> the first has any natural advantages to someone unfamiliar with either
> language. They may ask "What's a dotime - some kind of dot?". printf()
> is of course a C grotesquerie.
Additionally, you can't tell whether the loop variable ranges 1 to 10 or
0 to 9 using 'dotimes'.
> The easiest language to read for a naive reader would IMO be BASIC:
>
> for i = 0 to 10
> print i
> next i
I was going to point out that Fortran at least has the numbers 0 and 9
in the code which corresponds to the C for loop to print out the numbers
0 to 9:
do 100 i = 0, 9
write (*, *) i
100 continue
but I checked and so would the Basic one.
Pete
Pete Kirkham <·················@cafemosaic.co.uk> wrote in message news:<························@news-text.dial.pipex.com>...
> Gerry Quinn wrote:
> > In article <·······················@harpo.marx>,
> > ··············@bigpond.com says...
> >>From any perspective, which is easier to read?:
> >>
> >> dotimes (i, 10)
> >> printf ("%d", i);
> >>
> >> for (i=0; i<10; ++i)
> >> printf ("%d", i);
> >
> >
> > For me, the second is easier, because of familiarity. But I donlt think
> > the first has any natural advantages to someone unfamiliar with either
> > language. They may ask "What's a dotime - some kind of dot?". printf()
> > is of course a C grotesquerie.
>
> Additionally, you can't tell whether the loop variable ranges 1 to 10 or
> 0 to 9 using 'dotimes'.
>
> > The easiest language to read for a naive reader would IMO be BASIC:
> >
> > for i = 0 to 10
> > print i
> > next i
>
> I was going to point out that Fortran at least has the numbers 0 and 9
> in the code which corresponds to the C for loop to print out the numbers
> 0 to 9:
>
> do 100 i = 0, 9
> write (*, *) i
> 100 continue
Since the 1990 standard you can terminate the do loop in Fortran with
enddo, rather than a numbered line with continue. Most Fortran 77
compilers offered this extension. The simplest solution in Fortran is
to use an implied do loop,
write (*,"(10(i6,/))") (i,i=0,9)
where the "/" in the repeat edit descriptor "(10(i6,/))" says to print
each 'i' on a new line. Fortran rules!
Quoth Pete Kirkham on or about 2004-11-14:
> >> dotimes (i, 10)
> >> printf ("%d", i);
>
> Additionally, you can't tell whether the loop variable ranges 1 to 10 or
> 0 to 9 using 'dotimes'.
Unless a) you read the header; b) you read the documentation; or c) you
knew I borrowed it from Lisp :-)
...but point taken.
-trent
In article <························@news-text.dial.pipex.com>, pete-
············@cafemosaic.co.uk says...
> Gerry Quinn wrote:
> Additionally, you can't tell whether the loop variable ranges 1 to 10 or
> 0 to 9 using 'dotimes'.
>
> > The easiest language to read for a naive reader would IMO be BASIC:
> >
> > for i = 0 to 10
> > print i
> > next i
>
> I was going to point out that Fortran at least has the numbers 0 and 9
> in the code which corresponds to the C for loop to print out the numbers
> 0 to 9:
>
> do 100 i = 0, 9
> write (*, *) i
> 100 continue
>
> but I checked and so would the Basic one.
Good point - that puts Basic ahead even further in this regard.
- Gerry Quinn
On Sat, 13 Nov 2004 13:22:20 -0000, Gerry Quinn
<······@DELETETHISindigo.ie> wrote:
>
> But the point I am making is that Turing-completeness implies that all
> *tasks* can in fact be expressed without using any singular
> expressiveness feature of Lisp. The issue is whether a large proportion
> of tasks can be 'naturally' expressed in a form unique to Lisp, and in
> no other way. In other words, what tasks 'naturally' require Lisp'd
> unique features, and are much harder to express without them?
>
> I don't see why many games should have such a property.
>
> - Gerry Quinn
>
>
Ever seen repetitive code.
Lisp macro facility can automate much of this.
Ever spent half the time writing code to
check values and return values?
There reason you can't see it probably lack of experience
and that you don't know what to look for..
Paul Graham's "On Lisp" might give you some ideas.
http://www.paulgraham.com/onlisp.html
similarly
http://www.gigamonkeys.com/book/
shows you some practical examples on applying Lisp to a problem.
Lisp is more than the sum of it's parts.
You have to use it for a while to get the picture.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Hello!
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>[...]
>So if you asked a Fortran programmer to acquaint you with the thoughts
>of Aristotle, he would give you an English translation of his works.
>Whereas a Lisp programmer would give you the original, plus a copy of
>'Teach Yourself Ancient Greek'.
OK, that got me giggling.
But in fact, a Lisp programmer usually works from both ways. So
the result is a mixture between metaprogram and program, instead
of only metaprogram and a pure statement of the problem.
Especially as you can go to some length to extend the language
(as defined by the ANSI spec plus extensions you might use) by
quite "normal" means that are used to other programmers too
(defining library routines and data structures). Just that in
Lisp you can as seamlessly extend the language in other ways by
adding syntactic transformations (vulgo macros) or by influencing
CLOS (by using the MOP) or...
Kind regards,
Hannah.
In article <····························@posting.google.com>,
···@ashi.footprints.net says...
> Gerry Quinn <······@DELETETHISindigo.ie> wrote in message news:<··························@news.indigo.ie>...
> > In article <····························@posting.google.com>,
> > ···@ashi.footprints.net says...
> > > The Lisp programmer's internal language isn't Fortran, with its
> > > imperative statements, loops and variables. The internal language is
> > > an empty abstract syntax tree, to which that programmer is willing to
> > > assign any semantics whatsoever.
> > >
> > > When you think that way, then languages which don't let you encode
> > > those semantics just get in your way, because you have to do the
> > > translation of your internal language in your head, and then use your
> > > fingers to spit out the translation. You have to do the tedious job of
> > > the compiler that you are not able to write. In Lisp, you write that
> > > compiler, insert it into your program, and then write in the real
> > > language in which you conceived the solution. Other people then see
> > > and understand your language directly, instead of having to guess at
> > > it by reverse-engineering a hand-written translation.
> >
> > So if you asked a Fortran programmer to acquaint you with the thoughts
> > of Aristotle, he would give you an English translation of his works.
> > Whereas a Lisp programmer would give you the original, plus a copy of
> > 'Teach Yourself Ancient Greek'.
>
> That analogy would work perfectly if English lacked the expressiveness
> to capture the semantics of the ancient Greek.
If that was the only problem with the analogy, it would be a killer
analogy. Because Fortran is Turing-complete. English might not capture
the *poetry* of a work in another language, but it can surely capture
the semantics [And please, folks, spare me the Sapir-Whorf
references...]. Likewise, Lisp might express an algorithm in a fashion
that Fortran can't, but both can program a task using the algorithm.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
> ·······@nyc.rr.com says...
> >
> > But any good programmer is certainly held back by lesser languages. I
> > found Lisp because, well, there is another category in the survey, for
> > those who went on an active search for a better way before they even
> > knew there was a better way, simply because they sensed that they were
> > being held back by their languages.
>
> And if Lisp programmers were demonstrably more productive and effective,
> I'd take such claims seriously. As, more importantly, would those who
> tend to hire programmers.
>
> [Likewise for 'agile' programmers, or 'test-driven' programmers, or
> 'generic' programmers, or any other of the many varieties of silver
> bullet programmers.]
Speaking of silver bullets (defined as an order of magnitude improvement
by Brooks), I first experimented with a Lisp (in the form of Logo)
because I once saw Lisp described as a 4GL, where 4GL was defined simply
as an order of magnitude better than 3GL. This was shocking to me,
because I knew just enough Lisp to know that it was nothing like most
4GLs with their automatic database and screen building.
After three days of Logo, I understood. :)
kenny
Kenneth Tilton <·······@nyc.rr.com> writes:
> After three days of Logo, I understood. :)
Yes. It is turtles all the way down!
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > > I would say "self-modifying code" includes any program in which code is
> > > generated and executed as part of the expected output of the program.
> > > It's no longer running itself as originally written.
> >
> > Well, you can do that in Lisp, but it's not usually encouraged. Usually you
> > generate the code at compile time (using macros) and thus there is no
> > self-modifying code by your definition.
> >
> > You're also using a somewhat odd definition of "self-modifying". This is
> > generally taken to mean code which actually changes existing code at
> > runtime, rather than just adding more code.
>
> I disagree - it is in fact rare for code to be changed per se. What
> would be the point in writing code whose only purpose is to be written
> over? Whether original code is erased or not is completely irrelevant
> to the issue of whether code is self-modifying. The *program* is still
> self-modifying.
You are describing a program-generating program as self-modifying.
Using your discription every compiler which can execute its generated
code would be self-modifying (like a Common Lisp compiler). I think
many people (including myself) will disagree with you, e.g. see:
http://en.wikipedia.org/wiki/Self_modifying_code
I have only heard the term self-modifying in the context where the
program will modify the some of its following instructions. The
purpose is to implement adaptive algorithms and to save program
memory. Self modifying code has been known to cause problems with the
CPU instruction cache. However, self-modifying programs are not so
common since memory is cheap and almost all CPU's have instruction
caches where one would like to keep a high hit-ration as possible.
It's quite easy to write programs to generate and compile programs on
the fly in Common Lisp. I once wrote a microcode assembler generator.
It's a program which genereates a microcode assembler on the fly based
upon descirptions of instructions, bit-fields and mnemonics described
in Verilog (hardware description language). It will then run the
generated assembler and generate binary code for the microcode
sequencer. This is a program-generating program. It does not modify
itself. It does not overlay itself with the generated code, but it
will generate code on the fly which is executed in the assembler
stage.
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?
In article <··············@scimul.dolphinics.no>, newsmailcomp5
@gustad.com says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > > > I would say "self-modifying code" includes any program in which code is
> > > > generated and executed as part of the expected output of the program.
> > > > It's no longer running itself as originally written.
> > >
> > > Well, you can do that in Lisp, but it's not usually encouraged. Usually you
> > > generate the code at compile time (using macros) and thus there is no
> > > self-modifying code by your definition.
> > >
> > > You're also using a somewhat odd definition of "self-modifying". This is
> > > generally taken to mean code which actually changes existing code at
> > > runtime, rather than just adding more code.
> >
> > I disagree - it is in fact rare for code to be changed per se. What
> > would be the point in writing code whose only purpose is to be written
> > over? Whether original code is erased or not is completely irrelevant
> > to the issue of whether code is self-modifying. The *program* is still
> > self-modifying.
>
> You are describing a program-generating program as self-modifying.
Not unless the output of the generated program is an expected part of
output of the original program.
> Using your discription every compiler which can execute its generated
> code would be self-modifying (like a Common Lisp compiler). I think
Not if there is a division between the outputs, as there is in this
example. A compiler is not self-modifying code. It modifies the code
of a distinctly different program.
> many people (including myself) will disagree with you, e.g. see:
> http://en.wikipedia.org/wiki/Self_modifying_code
> I have only heard the term self-modifying in the context where the
> program will modify the some of its following instructions. The
> purpose is to implement adaptive algorithms and to save program
> memory. Self modifying code has been known to cause problems with the
> CPU instruction cache. However, self-modifying programs are not so
> common since memory is cheap and almost all CPU's have instruction
> caches where one would like to keep a high hit-ration as possible.
Surely the insistence that there must be some original code to be
written over is purely arbitrary and irrelevant? When code generated by
the program is executed, it is completely irrelevant whether it was
written in a portion of memory that contained some original source.
// Program A:
PUT_CODE_HERE:
NOP
NOP
NOP
NOP
GenerateCodeAt( PUT_CODE_HERE );
ExecuteCodeAt( PUT_CODE_HERE );
// Program B:
void* putCodeHere = (void*)( new opSizeItem[ 4 ] );
GenerateCodeAt( putCodeHere );
ExecuteCodeAt( putCodeHere );
They are both self-modifying, aren't they?
- Gerry Quinn
Gerry Quinn wrote:
[about "self-modifying code", under which heading Gerry apparently
includes code generated by Lisp macros. (And C++ templates? And the
C preprocessor?)]
> Surely the insistence that there must be some original code to be
> written over is purely arbitrary and irrelevant? When code generated by
> the program is executed, it is completely irrelevant whether it was
> written in a portion of memory that contained some original source.
>
> // Program A:
>
> PUT_CODE_HERE:
> NOP
> NOP
> NOP
> NOP
> GenerateCodeAt( PUT_CODE_HERE );
> ExecuteCodeAt( PUT_CODE_HERE );
>
> // Program B:
>
> void* putCodeHere = (void*)( new opSizeItem[ 4 ] );
> GenerateCodeAt( putCodeHere );
> ExecuteCodeAt( putCodeHere );
>
> They are both self-modifying, aren't they?
No, neither of them is self-modifying. There is no code
being modified in either case. There is code being
*generated*.
You are welcome to think that this is just as bad as
(what I'd call) self-modifying code. It seems fairly
clear to me that it isn't, but I don't know what your
reasons are for disapproving of self-modifying code;
maybe those reasons all apply equally to code generation.
--
Gareth McCaughan
.sig under construc
In article <··············@g.mccaughan.ntlworld.com>,
················@pobox.com says...
> Gerry Quinn wrote:
>
> [about "self-modifying code", under which heading Gerry apparently
> includes code generated by Lisp macros. (And C++ templates? And the
> C preprocessor?)]
It might or might not. What I'm pointing out, after all, is that the
details of how the modified code is generated doesn't count.
> > Surely the insistence that there must be some original code to be
> > written over is purely arbitrary and irrelevant? When code generated by
> > the program is executed, it is completely irrelevant whether it was
> > written in a portion of memory that contained some original source.
> >
> > // Program A:
> >
> > PUT_CODE_HERE:
> > NOP
> > NOP
> > NOP
> > NOP
> > GenerateCodeAt( PUT_CODE_HERE );
> > ExecuteCodeAt( PUT_CODE_HERE );
>
> No, neither of them is self-modifying. There is no code
> being modified in either case. There is code being
> *generated*.
NOP; NOP; NOP; NOP is code that is modified. Or if you object to this I
could change it to something that does something more interesting, or
would if it were not erased and replaced by alternative code.
The fact is it makes no difference. It is all about the level of the
generated code.
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <··············@g.mccaughan.ntlworld.com>,
> ················@pobox.com says...
> > Gerry Quinn wrote:
> >
> It might or might not. What I'm pointing out, after all, is that the
> details of how the modified code is generated doesn't count.
>
>
> NOP; NOP; NOP; NOP is code that is modified. Or if you object to this I
> could change it to something that does something more interesting, or
> would if it were not erased and replaced by alternative code.
>
> The fact is it makes no difference. It is all about the level of the
> generated code.
>
> - Gerry Quinn
>
Hi,
I am sorry I don't understand but if the complain is about the fact that
"generated code" is bad (though I am not sure this is what you are saying)
and that "self-modifying code" is not a important definition distinction
from "generated code" (again I am not sure whether you meant this, this
premises is only what I understood from your messages but I might be wrong),
then aren't all programming languages above machine level bad? I mean as far
as I understood it when you write a C,C++ or Lisp program what used to
happen is that it got translated into assembler code (or machine code) i.e.
assembler code got "generated" by the compiler.
I don't see the difference between C code that generates C code and compiler
that translates C code to machine code (or whatever). However I feel that
there is a conceptual difference between code that modifies itself rather
than just creating new code. But as I said I am not sure I understood fully
this branch of the thread.
In article <············@news.ox.ac.uk>, ·······@*the-mail-that-
burns*.com says...
>
> I am sorry I don't understand but if the complain is about the fact that
> "generated code" is bad (though I am not sure this is what you are saying)
> and that "self-modifying code" is not a important definition distinction
> from "generated code" (again I am not sure whether you meant this, this
> premises is only what I understood from your messages but I might be wrong),
> then aren't all programming languages above machine level bad? I mean as far
> as I understood it when you write a C,C++ or Lisp program what used to
> happen is that it got translated into assembler code (or machine code) i.e.
> assembler code got "generated" by the compiler.
There is a key difference here. The compiler is a well-tested program
that grinds all source into object code. Compilers are hard to write,
especially optimising ones, but when they are done, they are done. They
can be compared to libraries that see massive re-use. They are expected
to work just about perfectly and not have bugs.
A 'compiler' that exists to compile just one program is a different
kettle of fish. It does something complicated, perhaps more complicated
than writing the original in assembly! But it is not so well tested, it
will inevitably have obscure bugs. In short, it's too clever to be good
programming practice. (Of course there are exceptions to everything.)
Also, the standard compiler is not self-modifying, because the output of
the compiled programs is not it's real output - the compiled programs
are. That is much not the case in a compiler that compiles a single
program, because it only exists to create the output of that program.
So there is a general association between self-modifying code and
'badness'.
> I don't see the difference between C code that generates C code and compiler
> that translates C code to machine code (or whatever). However I feel that
> there is a conceptual difference between code that modifies itself rather
> than just creating new code. But as I said I am not sure I understood fully
> this branch of the thread.
The conceptual difference, as I see it, is 'who owns the output'. Is it
a different program that is fed to the compiling program, just one of
many - or is it essentially part of the same program, as in the case of
a compiler built for a specific task? Is the system modifying itself,
or something else?
Maybe that's an over-subtle way of defining self-modifying code, but it
seems to get to the nub of the issue, and hints about why it tends to be
a bad idea.
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <············@news.ox.ac.uk>, ·······@*the-mail-that-
> burns*.com says...
>>
> The conceptual difference, as I see it, is 'who owns the output'. Is it
> a different program that is fed to the compiling program, just one of
> many - or is it essentially part of the same program, as in the case of
> a compiler built for a specific task? Is the system modifying itself,
> or something else?
>
Ok I think I understand your point of view i.e. it's my "system" (composed
of many functions) changes any part of itself than it's self-modifying as
opposed to is a function actually changing re-writing itself.
>
> Maybe that's an over-subtle way of defining self-modifying code, but it
> seems to get to the nub of the issue, and hints about why it tends to be
> a bad idea.
>
I am not sure that it actually hints at why it is a bad idea - it does
explain why you think of self-modifying code that other people think is not.
Regarding the "badness" of it well I think there are a number of situations
in real world (not computer games, or at least this is not as important in
computer games) where a significant source of problems (especially when
trying to interpret visual scenes) comes from the inability to precisely
predict the nature of the enviroment in which the programs (in this dealing
with image understanding) are expected to operate. Furthermore even if you
could know all the different states that the enviroment could be in, you
wouldn't know a priori what the state of the enviroment would be in any
particular time. Consequently one (maybe not the only one) way to achieve
robust performace is a program that is capable to determine the state of the
enviroment at runtime and adapt to the enviroment that is found.
"Self-adaptive software" (I think the name was originally introduced in 1998
by a DARPA research project) is a model-based approach to building robust
systems. What happens is that in the real world the lack of adaptiveness is
bad as usually it means only that your program will work brilliantly in the
demo case but not in the actually challenging problems.
However this is a bit off the "sucks for games" alley so I'll leave it at
that. (But overall I agree the average programmer doing the average job
probably doesn't need self-adaptiveness and possibly if introduced it could
worsen the results)
In article <···········@news.ox.ac.uk>, ·······@the-mail-that-burns.com
says...
>
> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
[--]
> I am not sure that it actually hints at why it is a bad idea - it does
> explain why you think of self-modifying code that other people think is not.
> Regarding the "badness" of it well I think there are a number of situations
> in real world (not computer games, or at least this is not as important in
> computer games) where a significant source of problems (especially when
> trying to interpret visual scenes) comes from the inability to precisely
> predict the nature of the enviroment in which the programs (in this dealing
> with image understanding) are expected to operate. Furthermore even if you
> could know all the different states that the enviroment could be in, you
> wouldn't know a priori what the state of the enviroment would be in any
> particular time. Consequently one (maybe not the only one) way to achieve
> robust performace is a program that is capable to determine the state of the
> enviroment at runtime and adapt to the enviroment that is found.
> "Self-adaptive software" (I think the name was originally introduced in 1998
> by a DARPA research project) is a model-based approach to building robust
> systems. What happens is that in the real world the lack of adaptiveness is
> bad as usually it means only that your program will work brilliantly in the
> demo case but not in the actually challenging problems.
Certainly self-adaptive programming (hardware or software) is a valid
tool, and it's generally accepted that the brain uses something of the
kind.
Again, it's not something you insert willy-nilly into ordinary programs.
Self-modifying software is bad generally, not bad always.
With regard to games, self-modifying code probably had its heyday in the
80's, when it was used to insert custom bits of assembly to get the most
out of the slow processors of the day. On the PC, 'compiled sprites'
were common, for example.
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <···········@news.ox.ac.uk>, ·······@the-mail-that-burns.com
> says...
>>
>> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
>
> Certainly self-adaptive programming (hardware or software) is a valid
> tool, and it's generally accepted that the brain uses something of the
> kind.
>
> Again, it's not something you insert willy-nilly into ordinary programs.
> Self-modifying software is bad generally, not bad always.
>
> With regard to games, self-modifying code probably had its heyday in the
> 80's, when it was used to insert custom bits of assembly to get the most
> out of the slow processors of the day. On the PC, 'compiled sprites'
> were common, for example.
>
Ok so we seem to agree self-adaptive software is not bad per se but it's
application and/or programmer dependent about whether it will increase
or decrease the quality of a given software.
Gerry Quinn wrote:
[I said:]
> > [about "self-modifying code", under which heading Gerry apparently
> > includes code generated by Lisp macros. (And C++ templates? And the
> > C preprocessor?)]
[Gerry:]
> It might or might not. What I'm pointing out, after all, is that the
> details of how the modified code is generated doesn't count.
I don't think it's at all obvious that the details don't
matter. One of the reasons for avoiding self-modifying code
is that programs that use self-modifying code are hard to
understand. The way in which the code is generated can
make a difference to how hard the program is to understand.
> > > Surely the insistence that there must be some original code to be
> > > written over is purely arbitrary and irrelevant? When code generated by
> > > the program is executed, it is completely irrelevant whether it was
> > > written in a portion of memory that contained some original source.
> > >
> > > // Program A:
> > >
> > > PUT_CODE_HERE:
> > > NOP
> > > NOP
> > > NOP
> > > NOP
> > > GenerateCodeAt( PUT_CODE_HERE );
> > > ExecuteCodeAt( PUT_CODE_HERE );
> >
> > No, neither of them is self-modifying. There is no code
> > being modified in either case. There is code being
> > *generated*.
>
> NOP; NOP; NOP; NOP is code that is modified. Or if you object to this I
> could change it to something that does something more interesting, or
> would if it were not erased and replaced by alternative code.
>
> The fact is it makes no difference. It is all about the level of the
> generated code.
I don't understand that last statement. What do you mean by it?
As I hinted in the grandparent of this article, it would
be helpful if you'd explain exactly what you consider to
be the reasons for disapproving of self-modifying (or, more
generally, generated) code. There are several possible
such reasons, and some of them but not others apply (at
least in some measure) to all code generation. Also,
some of them are (at least in some measure) bogus reasons. :-)
I'd say that there are several different questions that
need to be answered about an instance of code generation
before you can tell whether it's a Bad Thing or not. For
instance, and this is far from an exhaustive list,
- Does it happen at compile time or run time or what?
- Does the code responsible for generating it make
the function of the generated code clear? Preferably,
just as clear as the function of the normally-compiled
code in the program?
- Is any other code being replaced by the generated code?
- What determines whether or not the code gets generated,
and *what* code gets generated?
- Does the same code get modified several times during
the execution of the program?
- Is it necessary to understand exactly what's going on
with the code generation, in order to understand the
program?
- What safeguards are in place to ensure that the
code generation doesn't stomp on code that isn't
meant to be modified?
So, for instance, if you're writing code that looks like
this then it's pretty majorly bad. (My apologies to anyone
reading this in, e.g., comp.lang.lisp who may be offended
by the choice of C syntax...)
int do_something(int x) {
/* blah blah blah */
}
void hack_it(int a, int b, int c, const char * s) {
char * p = &do_something;
char t;
/* write preamble: */
*p++ = 0x90;
*p++ = 0xf3;
/* write main code */
while ((t=*s++) != 0) {
switch (t) {
case 'a':
*p++ = 0x83;
*p++ = 0x1f;
*p++ = a & 0xff;
break;
/* ... other equally hideous cases .. */
}
}
/* write postamble */
*p++ = 0xaa;
*p++ = 0xdc;
do_something(b);
flush_icache(&do_something, 0x100+(char*)&do_something);
}
Spotting all the things that suck about the crawling horror above
is left as an exercise for the reader. There are rather a lot.
But there are plenty of other things that can reasonably be called
code generation, and they don't all share all those problems.
Now, you've been describing Lisp macros as "self-modifying code".
I don't know how much you know about Lisp macros, but they are
certainly an *entirely* different kettle of fish from the nasty
C code above. Different enough that I can't imagine why anyone
would call them "self-modifying code".
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> So, for instance, if you're writing code that looks like
> this then it's pretty majorly bad. (My apologies to anyone
> reading this in, e.g., comp.lang.lisp who may be offended
> by the choice of C syntax...)
Yes, you could have done it in lisp:
(defun do-something ())
(defun hack-it (args exprs)
(let ((ignored (gensym)))
(eval `(defun do-something ,(append args (list '&rest ignored))
(declare (ignore ,ignored)
(prin1 "entered do-something")
(unwind-protect (progn ,@exprs)
(prin1 "exiting do-something")))))))
To be used for example with:
(run-in-parallel-threads
(loop (apply (function do-something) '(1 2 3 4 5)) (sleep 1))
(loop for args in '((a) (x y) (z) ())
for expr in '(((print a)) ((print (+ x y)))
((setf z (z + (sin z))) (print z))
((print "Who I am?")))
do (hack-it args expr) (sleep (random 3))))
> Spotting all the things that suck about the crawling horror above
> is left as an exercise for the reader. There are rather a lot.
> But there are plenty of other things that can reasonably be called
> code generation, and they don't all share all those problems.
Well, here (and in your C source) it's rather controlled. For example,
I believe above hack-it function to be perfectly Common-Lisp
conformant.
Another case which could be frowned about would be if hack-it had
modified itself, or like this:
(defun hack-it (next-result)
(let ((result '(nil)))
(PROG1 (first result)
(SETF (first result) next-result)))
(list (HACK-IT 1) (HACK-IT 2) (HACK-IT 3)) ==> (NIL 1 2) ; on clisp
(list (HACK-IT 1) (HACK-IT 2) (HACK-IT 3)) ==> (NIL NIL NIL) ; on sbcl
But what about:
(DEFUN hack-it (payload)
(LABELS
((FIND-CAR (TOKEN TREE)
(COND
((ATOM TREE) NIL)
((EQ TOKEN (CAR TREE)) TREE)
(T (OR (FIND-CAR TOKEN (CAR TREE))
(FIND-CAR TOKEN (CDR TREE)))))))
(prog1 :result
(LET* ((SOURCE '(DEFUN hack-it (payload)
(LABELS
((FIND-CAR (TOKEN TREE)
(COND
((ATOM TREE) NIL)
((EQ TOKEN (CAR TREE)) TREE)
(T (OR (FIND-CAR TOKEN (CAR TREE))
(FIND-CAR TOKEN (CDR TREE)))))))
(prog1 :result
(LET* ((SOURCE ':QUINE)
(QUINE (COPY-TREE SOURCE)))
(SETF (CAR (FIND-CAR :QUINE QUINE)) SOURCE)
(SETF (CAR (FIND-CAR :result QUINE)) payload)
(eval QUINE))))))
(QUINE (COPY-TREE SOURCE)))
(SETF (CAR (FIND-CAR :QUINE QUINE)) SOURCE)
(SETF (CAR (FIND-CAR :result QUINE)) payload)
(eval QUINE)))))
(list (HACK-IT 1) (HACK-IT 2) (HACK-IT 3) (HACK-IT 4))
==> (:RESULT 1 2 3) ; on any Common-Lisp I believe.
> Now, you've been describing Lisp macros as "self-modifying code".
> I don't know how much you know about Lisp macros, but they are
> certainly an *entirely* different kettle of fish from the nasty
> C code above. Different enough that I can't imagine why anyone
> would call them "self-modifying code".
--
__Pascal Bourguignon__
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Surely the insistence that there must be some original code to be
> written over is purely arbitrary and irrelevant?
Did you read the wikipedia article? You seem to make you your own
definition of established terms. Same thing with object oriented
programming languages somewhere else in this thread.
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?
In article <··············@scimul.dolphinics.no>, newsmailcomp5
@gustad.com says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > Surely the insistence that there must be some original code to be
> > written over is purely arbitrary and irrelevant?
>
> Did you read the wikipedia article? You seem to make you your own
> definition of established terms.
That differs from 'wikipedia', how?
But anyway, the article starts with "In computer science, self-modifying
code is code that modifies itself on purpose." You just have to get
away from a pedantic definition of what is code. If it helps, think
about "self-modifying programs", or "self-modifying systems of
programs". That is what the issue is really about.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> I would say "self-modifying code" includes any program in which code is
> generated and executed as part of the expected output of the program.
> It's no longer running itself as originally written.
>
> I know there are inevitable ambiguities and special cases, simply
> because there is no real dividing line between code (to be executed) and
> data (to be manipulated). I would augment my definition above to
> exclude cases in which there is a 'hierarchy of execution levels'. I
> would not consider code that runs a cellular automaton that performs a
> computation to be self-modifying, for example. The generated code has
> to have approximate 'parity of esteem' with the original code.
Then lisp code is usually not self modifying. Macros simply translate
from a simple declaration of semantics to a possibly complex
implementation of those semantics. You can modify a function's
definition from within the function, but that's rarely a useful
technique. I have used it to good effect in a timed genetic algorithm
search where I had the top level be a loop that kept doing the
select-breed cycle and I could redefine the functions that selected and
bred the population without having to stop execution. The new
definitions were simply picked up on the next iteration of the loop.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> People who have just begun a project, or indeed who have never completed
> a real project, are apt to overestimate the importance of algorithms in
> programming.
I don't understand this. What are programs if they are not
expressions of algorithms?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
>
>>People who have just begun a project, or indeed who have never completed
>>a real project, are apt to overestimate the importance of algorithms in
>>programming.
>
>
> I don't understand this. What are programs if they are not
> expressions of algorithms?
/* Well, first, there's all those comments that line-noise language
programmers have to type to remind their fellow programmers (and
themselves) what this function does, and its history of bug fixes and
modifications, refactorings, etcetera */
then theres(the explicit, input, and out, parameter type declaration) {
and a;
bunch of;
similar declarations;
for the local variables used;
your algorithm here;
maybe some explicit deallocation of resources;
returning(something);
}
:-)
So programs = algorithms + bookkeeping. Outsource as much of the
bookkeeping as you can, I say!
--
Cameron MacKinnon
Toronto, Canada
On Mon, 01 Nov 2004 01:27:04 -0500, Cameron MacKinnon wrote:
> So programs = algorithms + bookkeeping. Outsource as much of the
> bookkeeping as you can, I say!
And I'd say one of the best things about Lisp is that you can teach the
language itself to do much of the bookkeeping, so that you can outsource
the bookkeeping to the compiler :-)
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
>>>>> "WB" == William Bland <·······@abstractnonsense.com> writes:
[...]
WB> And I'd say one of the best things about Lisp is that you can
WB> teach the language itself to do much of the bookkeeping, so
WB> that you can outsource the bookkeeping to the compiler :-)
Indeed. Peter Seibel's book has a cute story based on this analogy.
The Story of Mac, he calls it. Check it out:
http://www.gigamonkeys.com/book/macros-defining-our-own.html
cheers,
BM
In article <······················@golden.net>, ··········@clearspot.net
says...
> :-)
>
> So programs = algorithms + bookkeeping. Outsource as much of the
> bookkeeping as you can, I say!
I think you'll find there's a little more than that to producing a
finished product...
- Gerry Quinn
> So programs = algorithms + bookkeeping. Outsource as much of the
> bookkeeping as you can, I say!
>
Oh god, its almost reads like your saying Lisp requires less commenting :)
I can't possibly mean this, so I'm sure I've misinferred here..
If anything, Lisp looks more like assembly, where you would expect a lot of
commenting on every single line...
Maahes wrote:
>>So programs = algorithms + bookkeeping. Outsource as much of the
>>bookkeeping as you can, I say!
>>
>
>
> Oh god, its almost reads like your saying Lisp requires less commenting :)
>
> I can't possibly mean this, so I'm sure I've misinferred here..
> If anything, Lisp looks more like assembly, where you would expect a lot of
> commenting on every single line...
I just ran a quick comment count on the same code that I used elsewhere
in this thread (CMUCL's source tree in the Lisp corner, VNC in the other
corner). Lisp weighs in at:
Characters: total 16061565, comment 3020763 (18.8%)
versus
Characters: total 9947254, comment 2331753 (23.4%)
25% more flab on the challenger.
--
Cameron MacKinnon
Toronto, Canada
"Maahes" wrote:
> > So programs = algorithms + bookkeeping. Outsource as much of the
> > bookkeeping as you can, I say!
>
> Oh god, its almost reads like your saying Lisp requires less commenting :)
>
> I can't possibly mean this, so I'm sure I've misinferred here..
> If anything, Lisp looks more like assembly, where you would expect a lot of
> commenting on every single line...
Appearances can deceive. The way a programming language looks
to someone not used to it provides very little information
about subtle matters like how much commenting programs in it
require.
A very quick survey of a bit of my own code suggests that
I write slightly fewer comments in Lisp code than in C or C++.
Generally, the things I do in Lisp are harder than the things
I do in C or C++, which you'd expect to imply more commenting.
So I have some weak evidence that Lisp code doesn't need
such heavy commenting as C++ code does.
--
Gareth McCaughan
.sig under construc
> A very quick survey of a bit of my own code suggests that
> I write slightly fewer comments in Lisp code than in C or C++.
> Generally, the things I do in Lisp are harder than the things
> I do in C or C++, which you'd expect to imply more commenting.
> So I have some weak evidence that Lisp code doesn't need
> such heavy commenting as C++ code does.
>
I think all you have is weak evidence that you need to comment your Lisp
more...
In article <··········@duster.adelaide.on.net>,
"Maahes" <······@internode.on.net> wrote:
> > A very quick survey of a bit of my own code suggests that
> > I write slightly fewer comments in Lisp code than in C or C++.
> > Generally, the things I do in Lisp are harder than the things
> > I do in C or C++, which you'd expect to imply more commenting.
> > So I have some weak evidence that Lisp code doesn't need
> > such heavy commenting as C++ code does.
> >
> I think all you have is weak evidence that you need to comment your Lisp
> more...
Now here is some meat for a grand flamewar!
Comments are /strong/ evidence that the code needs to be better. Unless
of course they are simply taking up space to make their author feel
grand as he describes what the code plainly does. More likely, however,
they describe what the code did three refactorings ago.
When starting work on legacy code, first, we delete all the comments.
Then as we figure out what the code does, we correct all the variable
and function names. See Confucius on this one. The rest is easy.
Well, enough BS, Frank G has persuaded Cello the Dancing Bear to balance
atop OS X and I have a screaming GPU to bench.
:)
kenny
>> > So I have some weak evidence that Lisp code doesn't need
>> > such heavy commenting as C++ code does.
>> >
>> I think all you have is weak evidence that you need to comment your Lisp
>> more...
>
> Now here is some meat for a grand flamewar!
>
> Comments are /strong/ evidence that the code needs to be better. Unless
> of course they are simply taking up space to make their author feel
> grand as he describes what the code plainly does. More likely, however,
> they describe what the code did three refactorings ago.
>
> When starting work on legacy code, first, we delete all the comments.
> Then as we figure out what the code does, we correct all the variable
> and function names. See Confucius on this one. The rest is easy.
>
> :)
That's a bit left field, but there is some truth there.
Though if your code is at that stage, I suggest starting clean. :)
The original thread was inferring that have less comments was because the
code was so easy to read, which is a totally subjective statement. We have
reams of C++ code with NO comments at all, but I don't think this is
/strong/ evidence that C++ does need as heavy commenting as Lisp code.
"Maahes" <······@internode.on.net> writes:
> > A very quick survey of a bit of my own code suggests that
> > I write slightly fewer comments in Lisp code than in C or C++.
> > Generally, the things I do in Lisp are harder than the things
> > I do in C or C++, which you'd expect to imply more commenting.
> > So I have some weak evidence that Lisp code doesn't need
> > such heavy commenting as C++ code does.
> >
> I think all you have is weak evidence that you need to comment your Lisp
> more...
Depends which of the following two hypotheses you think more
likely.
(A) I over- or under- comment to about the same degree
whatever language I'm using.
(B) All languages require about the same level of commenting,
measured in comments per line of code. (At least for
code written by me).
I find (A) much more plausible than (B).
--
Gareth McCaughan
.sig under construc
> Depends which of the following two hypotheses you think more
> likely.
>
> (A) I over- or under- comment to about the same degree
> whatever language I'm using.
>
> (B) All languages require about the same level of commenting,
> measured in comments per line of code. (At least for
> code written by me).
>
> I find (A) much more plausible than (B).
>
(C) Languages which differ more from English (when read left->right) require
more commenting. Consequentially, you are under-commenting your Lisp.
"Maahes" <······@internode.on.net> writes:
>> Depends which of the following two hypotheses you think more
>> likely.
>>
>> (A) I over- or under- comment to about the same degree
>> whatever language I'm using.
>>
>> (B) All languages require about the same level of commenting,
>> measured in comments per line of code. (At least for
>> code written by me).
>>
>> I find (A) much more plausible than (B).
>>
>
> (C) Languages which differ more from English (when read left->right) require
> more commenting. Consequentially, you are under-commenting your Lisp.
I don't think it's true that Lisp differs more from English
than C++ does. Apparently you do. How familiar are you with
Lisp?
And, as it happens, I find (A) more plausible than (C),
at least if you're taking (C) as an absolute rule (which
is what you'd need to draw your inference about my alleged
undercommenting). There are other things that make a
considerable difference to how much commenting is needed.
--
Gareth McCaughan
.sig under construc
> And, as it happens, I find (A) more plausible than (C),
> at least if you're taking (C) as an absolute rule (which
Of course you do, hence your previous email.
"Maahes" <······@internode.on.net> writes:
> > And, as it happens, I find (A) more plausible than (C),
> > at least if you're taking (C) as an absolute rule (which
>
> Of course you do, hence your previous email.
Is that intended as a constructive contribution to the thread?
I have some evidence that (A) or something stronger -- i.e.,
less favourable to your case -- is true; I find that when I
return after an absence to old Lisp code I've written (with
whatever level of comments I put in) I generally find it
at least as easy to get back to work on as I do with old C
or C++ code I've written (with, again, whatever level of
comments I put in).
This is, of course, all anecdotal and subjective. But it's
more than you've offered in defence of your contrary claims,
which so far as I can tell amounts to "I think Lisp looks
really bad and I found it difficult when I was briefly
exposed to it in college, so it must be a terribly low-level
language and need lots of comments".
Of course, maybe you're just (counter-)trolling and I've been
thoroughly had. :-)
--
Gareth McCaughan
.sig under construc
David Steuber <·····@david-steuber.com> writes:
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > People who have just begun a project, or indeed who have never completed
> > a real project, are apt to overestimate the importance of algorithms in
> > programming.
>
> I don't understand this. What are programs if they are not
> expressions of algorithms?
Well, a big part of the programs is composed of pure sequential algorithm:
do-stuff-1
do-stuff-2
do-stuff-3
This is "algorithm" the same way 1 is a power of two...
For example the algorithm to display a small dialog box would be:
display label field
display text field
display ok button
display cancel button
Nice algorithm...
If you compare the size of CLI executable with that of GUI executable
(without counting resources), you'll get an aproximation of the
importance of algorithms in current software... (the GUI algorithms
are stored in the GUI libraries, not in the GUI executables!)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
In article <··············@david-steuber.com>, ·····@david-steuber.com
says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > People who have just begun a project, or indeed who have never completed
> > a real project, are apt to overestimate the importance of algorithms in
> > programming.
>
> I don't understand this. What are programs if they are not
> expressions of algorithms?
Others have answered. I would say that a program is a recipe for
marshalling resources to produce a particulasr output. Unless you call
things like images or lists of GUI button positions algorithms,
algorithms are just some of the resources to be marshalled. They are
important, but they are a small part of the program.
if ( player.pos.x > monster.pos.x ) monster.vel.x = monster.speed;
..is an algorithm, but it's quite trivial compared to the artwork,
gameplay and level-design issues relating to the monsters.
- Gerry Quinn
> I am familiar with the basic concepts of Lisp, I am familiar with the
> arguments in favour of Lisp put forward by enthusiasts, and I am
> familiar with the generally weak profile of Lisp enthusiasts in terms of
> actually delivering product. The success of one group of talented
> developers despite a plainly idiotic choice of development tools
> notwithstanding. [I even quoted them, the Lisp users, to justify my
> opinions.]
How many times does this have to be said?! Go to the website of a lisp
vendor and look at their success stories. For example:
http://www.franz.com/success/. Most of the projects listed there are pretty
interesting. It's ridiculous to suggest that we're basing our arguments on
the success of one set of developers.
Alex
Gerry Quinn wrote:
> In article <·························@news.verizon.net>,
> ················@NOTplayTHISstationBIT.sony.com says...
>> In article <··························@news.indigo.ie>,
>> ······@DELETETHISindigo.ie says...
>> > [...]
>> > 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.
>>
>> How about learning it in order to perhaps get a clue about
>> what you're talking about. (I realize it's a novel thought
>> for you, but you really should try it some time.)
>
> Have you heard of the concept "secondary source"? You don't need to
> host a brain slug to know it's a bad idea. You just look at the people
> who host them.
>
> I am familiar with the basic concepts of Lisp, I am familiar with the
> arguments in favour of Lisp put forward by enthusiasts, and I am
> familiar with the generally weak profile of Lisp enthusiasts in terms of
> actually delivering product. The success of one group of talented
> developers despite a plainly idiotic choice of development tools
> notwithstanding. [I even quoted them, the Lisp users, to justify my
> opinions.]
>
> Learning to use Lisp idiomatically would take some time. I can find
> better uses for that time. I don't buy the crap about it
> revolutionising thinking processes, because of the general lack of
> revolutionary Lisp-based software. So it's just another language. I
> have programmed in about a dozen languages - I don't keep count. If I
> need to learn one of the various versions of Lisp sometime, I'll learn
> it.
>
> Nowhere in my posts have I criticised any element of Lisp as a language
> per se. But based on observation I have criticised the notion that
> games development productivity would be enhanced dramatically by a
> switch to Lisp, which was the thrust of the posts on this thread,
> particularly the initial one. Since you yourself have now admitted that
> you prefer to stick with C++, it is rather clear that similar arguments
> hold sway with you.
>
> - Gerry Quinn
In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > I am familiar with the basic concepts of Lisp, I am familiar with the
> > arguments in favour of Lisp put forward by enthusiasts, and I am
> > familiar with the generally weak profile of Lisp enthusiasts in terms of
> > actually delivering product. The success of one group of talented
> > developers despite a plainly idiotic choice of development tools
> > notwithstanding. [I even quoted them, the Lisp users, to justify my
> > opinions.]
>
> How many times does this have to be said?! Go to the website of a lisp
> vendor and look at their success stories. For example:
> http://www.franz.com/success/. Most of the projects listed there are pretty
> interesting. It's ridiculous to suggest that we're basing our arguments on
> the success of one set of developers.
Only one set of game developers in that list.
- Gerry Quinn
> Only one set of game developers in that list.
So? Given that they were pretty successful, despite writing their own
compiler instead of using a production quality Lisp compiler, I think
they're good evidence that Lisp is a suitable language for games. The other
successes show that Lisp is good for complex programs in general.
Admittedly, if you don't want to write a complex game, Lisp might not be
much of an advantage.
And you might want to look at the complete list of successes
(http://www.franz.com/success/all_customer_apps.lhtml), where you can find
http://www.franz.com/success/customer_apps/animation_graphics/nichimen.lhtml.
Alex
Gerry Quinn wrote:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>> > I am familiar with the basic concepts of Lisp, I am familiar with the
>> > arguments in favour of Lisp put forward by enthusiasts, and I am
>> > familiar with the generally weak profile of Lisp enthusiasts in terms
>> > of
>> > actually delivering product. The success of one group of talented
>> > developers despite a plainly idiotic choice of development tools
>> > notwithstanding. [I even quoted them, the Lisp users, to justify my
>> > opinions.]
>>
>> How many times does this have to be said?! Go to the website of a lisp
>> vendor and look at their success stories. For example:
>> http://www.franz.com/success/. Most of the projects listed there are
>> pretty interesting. It's ridiculous to suggest that we're basing our
>> arguments on the success of one set of developers.
>
> Only one set of game developers in that list.
>
> - Gerry Quinn
In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > Only one set of game developers in that list.
>
> So? Given that they were pretty successful, despite writing their own
> compiler instead of using a production quality Lisp compiler, I think
> they're good evidence that Lisp is a suitable language for games. The other
> successes show that Lisp is good for complex programs in general.
> Admittedly, if you don't want to write a complex game, Lisp might not be
> much of an advantage.
I want to write *good* games. The simpler, the better.
In truth, I don't have problems with algorithms. The stuff I do may not
be world-shaking (as Christer Ericson likes to point out) but probably
the algorithmic content is a bit higher than the average shareware game
or screensaver.
Even for projects on this scale, algorithms are the easy bit. At least
for me. Your mileage may vary.
Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers
Gerry Quinn wrote:
>> 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.
I don't understand how it can do that, since Lisp doesn't use
self-modifying code.
For what it's worth, I've seen no evidence that Lispers are
either more or less prone than C++ers to get caught up in the
details of programming rather than actually getting things
completed. I've certainly seen Lispers in that state. I've
seen C++ers in the same state, and at least one famous (and
rather good, in its way) C++ book seems to me to be a fine
example. I don't think this tells us anything about either
language. It tells us that people who do something that's
(at least sometimes) both difficult and interesting, like
writing software, will sometimes find they're more interested
in the process than in the product. It happens plenty outside
the world of software, too.
> 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.
So a language whose programmers are enthusiastic about it
is likely to be one that isn't used for getting real work
done? That rules out almost every language I've either
used or seen except, maybe, COBOL.
> 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.
That's fine. No one, I hope, is trying to force you to do
anything you don't want to. Certainly not me.
--
Gareth McCaughan
.sig under construc
In article <··························@news.indigo.ie>,
······@DELETETHISindigo.ie says...
> > for games written with Lisp,
> > http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.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
In article <··························@news.verizon.net>,
················@NOTplayTHISstationBIT.sony.com says...
> In article <··························@news.indigo.ie>,
> ······@DELETETHISindigo.ie says...
> > > for games written with Lisp,
> > > http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.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
> 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/customer_apps/bioinformatics/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 <··························@news.verizon.net>,
> ················@NOTplayTHISstationBIT.sony.com says...
>> In article <··························@news.indigo.ie>,
>> ······@DELETETHISindigo.ie says...
>> > > for games written with Lisp,
>> > >
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.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 <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > 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/customer_apps/bioinformatics/harvard.lhtml.
Not as many as other languages.
> > 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.
Repeating mistakes does seem to be human nature.
> > 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.
Unless you are selling the technology, or unless a technology gives you
special capabilities that those not using it don't have, "getting ahead
in technology" is a fool's motivation. Mature technology is cheaper and
more reliable as a general rule.
> 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".
Template metaprogramming as such is never used by most sensible
programmers. Macros, by contrast, are ubiquitous in Lisp as I
understand it. And if the development environment had been an object-
based system with proper interfaces, it shouldn't have mattered whether
his code was comprehensible. Something for addicts of 'generic
programming' to ponder. But that's all beside the point. I don't know
what particular aspects of the program were incomprehensible to the
other developers, I just threw it out as one of the problems that
afflicted the one games development team famous for developing in Lisp
and still actually achieving something.
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>> > 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/customer_apps/bioinformatics/harvard.lhtml.
>
> Not as many as other languages.
With all due respect to conflicting subjective points of view, all it takes
is a single counter example to refute the often voiced opinion that "lisp
may very well be <yada yada> but you cannot write real world applications
with it"
I don't think any body will dispute there are fewer lisp success stories
than C++ ones but that is as useful a data point as there are many more C++
failure stories than lisp ones.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
[My apologies for the double post on c.l.lisp. The previous poster is
one of those twits who silently change follow-ups.]
> > 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/customer_apps/bioinformatics/harvard.lhtml.
Not as many as other languages.
> > 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.
Repeating mistakes does seem to be human nature.
> > 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.
Unless you are selling the technology, or unless a technology gives you
special capabilities that those not using it don't have, "getting ahead
in technology" is a fool's motivation. Mature technology is cheaper and
more reliable as a general rule.
> 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".
Template metaprogramming as such is never used by most sensible
programmers. Macros, by contrast, are ubiquitous in Lisp as I
understand it. And if the development environment had been an object-
based system with proper interfaces, it shouldn't have mattered whether
his code was comprehensible. Something for addicts of 'generic
programming' to ponder. But that's all beside the point. I don't know
what particular aspects of the program were incomprehensible to the
other developers, I just threw it out as one of the problems that
afflicted the one games development team famous for developing in Lisp
and still actually achieving something.
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>> > 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/customer_apps/bioinformatics/harvard.lhtml.
>
> Not as many as other languages.
With all due respect to conflicting subjective points of view, all it takes
is a single counter example to refute the often voiced opinion that "lisp
may very well be <yada yada> but you cannot write real world applications
with it"
I don't think any body will dispute there are fewer lisp success stories
than C++ ones but that is as useful a data point as there are many more C++
failure stories than lisp ones.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
In article <····················@edtnps84>, ·····@mercury.bc.ca says...
> > Not as many as other languages.
>
> With all due respect to conflicting subjective points of view, all it takes
> is a single counter example to refute the often voiced opinion that "lisp
> may very well be <yada yada> but you cannot write real world applications
> with it"
Indeed, it proves that games can be written in Lisp - but it does
nothing to refute the opinion that Lisp is not a good choice, or to
support the opinion encapsulated in the title of this thread.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Template metaprogramming as such is never used by most sensible
> programmers. Macros, by contrast, are ubiquitous in Lisp as I
> understand it.
They are usually how you do the thing that Lisp is for: creating new
language features.
> And if the development environment had been an object-
> based system with proper interfaces, it shouldn't have mattered whether
> his code was comprehensible. Something for addicts of 'generic
> programming' to ponder. But that's all beside the point.
And absolute buzzword-induced foolishness. Object orientation and
interfaces does not have anything to do with the issue you mention. I
have no clue what "generic programming" is, but simply having
polymorphism and definable type hierarchies does nothing to indicate
_what_ it is some operator is supposed to achieve. The current project I
am on at work is a case in point. They don't comment or document their
code because they think that if you want to know what the code does,
just read it. Of course, that's utter nonsense. Documentation tells us
not what the code does, but what the point of some code is. No amount of
polymorphism will explain the design rationales and models behind some
API or language.
> I don't know what particular aspects of the program were
> incomprehensible to the other developers, I just threw it out as one
> of the problems that afflicted the one games development team famous
> for developing in Lisp and still actually achieving something.
Then you shouldn't assume that it was something in the compiler that was
hard to understand and not some specially-designed operator in GOAL that
had semantics that weren't quite properly defined.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, ·····@nyct.net says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > And if the development environment had been an object-
> > based system with proper interfaces, it shouldn't have mattered whether
> > his code was comprehensible. Something for addicts of 'generic
> > programming' to ponder. But that's all beside the point.
>
> And absolute buzzword-induced foolishness. Object orientation and
> interfaces does not have anything to do with the issue you mention. I
> have no clue what "generic programming" is, but simply having
> polymorphism and definable type hierarchies does nothing to indicate
> _what_ it is some operator is supposed to achieve. The current project I
> am on at work is a case in point. They don't comment or document their
> code because they think that if you want to know what the code does,
> just read it. Of course, that's utter nonsense. Documentation tells us
> not what the code does, but what the point of some code is. No amount of
> polymorphism will explain the design rationales and models behind some
> API or language.
>
> > I don't know what particular aspects of the program were
> > incomprehensible to the other developers, I just threw it out as one
> > of the problems that afflicted the one games development team famous
> > for developing in Lisp and still actually achieving something.
>
> Then you shouldn't assume that it was something in the compiler that was
> hard to understand and not some specially-designed operator in GOAL that
> had semantics that weren't quite properly defined.
I don't assume that - in fact I mis-spoke when I said "development
environment" - I mean the GOAL engine.
On re-reading the article, however, it seems that what was meant was
that other programmers attempted to work on the engine itself but could
not, due to the obscurity of the code. So the engine interface may well
have been perfectly adequate, and I withdraw my comments above.
- Gerry Quinn
>
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··············@nyct.net>, ·····@nyct.net says...
>> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
>> Then you shouldn't assume that it was something in the compiler that was
>> hard to understand and not some specially-designed operator in GOAL that
>> had semantics that weren't quite properly defined.
>
> I don't assume that - in fact I mis-spoke when I said "development
> environment" - I mean the GOAL engine.
>
> On re-reading the article, however, it seems that what was meant was
> that other programmers attempted to work on the engine itself but could
> not, due to the obscurity of the code. So the engine interface may well
> have been perfectly adequate, and I withdraw my comments above.
Fair enough. Compilers tend to be rather complex beasts, especially if
you don't understand the various optimizations they are implementing.
Would you expect an average programmer to be able to understand the code
of GCC? :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> [My apologies for the double post on c.l.lisp. The previous poster is
> one of those twits who silently change follow-ups.]
KNode seems to do it for me. Sorry.
> Not as many as other languages.
Because less people use it.
> Repeating mistakes does seem to be human nature.
I guess that's why so many people use C++.
>> Because of course you can only get ahead in technology by copying what
>> everyone else is doing.
>
> Unless you are selling the technology, or unless a technology gives you
> special capabilities that those not using it don't have, "getting ahead
> in technology" is a fool's motivation. Mature technology is cheaper and
> more reliable as a general rule.
Lisp is mature, older than C++ in fact.
> Template metaprogramming as such is never used by most sensible
> programmers. Macros, by contrast, are ubiquitous in Lisp as I
> understand it. And if the development environment had been an object-
> based system with proper interfaces, it shouldn't have mattered whether
> his code was comprehensible. Something for addicts of 'generic
> programming' to ponder. But that's all beside the point. I don't know
> what particular aspects of the program were incomprehensible to the
> other developers, I just threw it out as one of the problems that
> afflicted the one games development team famous for developing in Lisp
> and still actually achieving something.
I can't buy the first sentence. What about the performance advantages of,
say, epxression templates for matrix arithmetic. Sounds sensible enough to
me. The development environment may well have been object-based. Do you
know whether or not the Lisp dialect the used was OO?
Alex
Gerry Quinn wrote:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>
> [My apologies for the double post on c.l.lisp. The previous poster is
> one of those twits who silently change follow-ups.]
>
>> > 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/customer_apps/bioinformatics/harvard.lhtml.
>
> Not as many as other languages.
>
>> > 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.
>
> Repeating mistakes does seem to be human nature.
>
>> > 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.
>
> Unless you are selling the technology, or unless a technology gives you
> special capabilities that those not using it don't have, "getting ahead
> in technology" is a fool's motivation. Mature technology is cheaper and
> more reliable as a general rule.
>
>> 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".
>
> Template metaprogramming as such is never used by most sensible
> programmers. Macros, by contrast, are ubiquitous in Lisp as I
> understand it. And if the development environment had been an object-
> based system with proper interfaces, it shouldn't have mattered whether
> his code was comprehensible. Something for addicts of 'generic
> programming' to ponder. But that's all beside the point. I don't know
> what particular aspects of the program were incomprehensible to the
> other developers, I just threw it out as one of the problems that
> afflicted the one games development team famous for developing in Lisp
> and still actually achieving something.
>
> - Gerry Quinn
In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > Unless you are selling the technology, or unless a technology gives you
> > special capabilities that those not using it don't have, "getting ahead
> > in technology" is a fool's motivation. Mature technology is cheaper and
> > more reliable as a general rule.
>
> Lisp is mature, older than C++ in fact.
Maturity of a technology is not a direct function of age. Where are the
IDEs, what is the standard version?
> > Template metaprogramming as such is never used by most sensible
> > programmers. Macros, by contrast, are ubiquitous in Lisp as I
> > understand it. And if the development environment had been an object-
> > based system with proper interfaces, it shouldn't have mattered whether
> > his code was comprehensible. Something for addicts of 'generic
> > programming' to ponder. But that's all beside the point. I don't know
> > what particular aspects of the program were incomprehensible to the
> > other developers, I just threw it out as one of the problems that
> > afflicted the one games development team famous for developing in Lisp
> > and still actually achieving something.
>
> I can't buy the first sentence. What about the performance advantages of,
> say, epxression templates for matrix arithmetic. Sounds sensible enough to
> me.
To what percentage of programmers are such things relevant?
> The development environment may well have been object-based. Do you
> know whether or not the Lisp dialect the used was OO?
You know, from the description of Common Lisp, it's hard to tell!
- Gerry Quinn
Gerry Quinn wrote:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>> > Unless you are selling the technology, or unless a technology gives you
>> > special capabilities that those not using it don't have, "getting ahead
>> > in technology" is a fool's motivation. Mature technology is cheaper
>> > and more reliable as a general rule.
>>
>> Lisp is mature, older than C++ in fact.
>
> Maturity of a technology is not a direct function of age. Where are the
> IDEs, what is the standard version?
>
Allegro CL, Lispworks CL and other commercial Lisps have their own IDEs.
These may or may not be the best available, but they do have features the
standard Free IDE - Slime - doesn't.
The standard version is, of course, Common Lisp. CL isn't a
single-implementation language. (But then, neither is C++.)
>> Lisp is mature, older than C++ in fact.
>
> Maturity of a technology is not a direct function of age. Where are the
> IDEs, what is the standard version?
The standard version is Common Lisp, which has been around for over a decade
(i.e. longer than the latest C++ standard). CL vendors mostly provide IDEs.
>> I can't buy the first sentence. What about the performance advantages of,
>> say, epxression templates for matrix arithmetic. Sounds sensible enough
>> to me.
>
> To what percentage of programmers are such things relevant?
Programmers who want high performance numeric code. Or programmers who want
to write a parser (http://spirit.sourceforge.net/). Both things which game
programmers will probably want to do at some point.
>> The development environment may well have been object-based. Do you
>> know whether or not the Lisp dialect the used was OO?
>
> You know, from the description of Common Lisp, it's hard to tell!
GOAL is not Common Lisp. You should know that Common Lisp supports OO if
you've done even a smidgen of research. In fact it was the /first/ ANSI
standardised OO language. So in terms of being standard and being OO, it
pretty much beats C++.
Alex
Gerry Quinn wrote:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>> > Unless you are selling the technology, or unless a technology gives you
>> > special capabilities that those not using it don't have, "getting ahead
>> > in technology" is a fool's motivation. Mature technology is cheaper
>> > and more reliable as a general rule.
>>
>> Lisp is mature, older than C++ in fact.
>
> Maturity of a technology is not a direct function of age. Where are the
> IDEs, what is the standard version?
>
>> > Template metaprogramming as such is never used by most sensible
>> > programmers. Macros, by contrast, are ubiquitous in Lisp as I
>> > understand it. And if the development environment had been an object-
>> > based system with proper interfaces, it shouldn't have mattered whether
>> > his code was comprehensible. Something for addicts of 'generic
>> > programming' to ponder. But that's all beside the point. I don't know
>> > what particular aspects of the program were incomprehensible to the
>> > other developers, I just threw it out as one of the problems that
>> > afflicted the one games development team famous for developing in Lisp
>> > and still actually achieving something.
>>
>> I can't buy the first sentence. What about the performance advantages of,
>> say, epxression templates for matrix arithmetic. Sounds sensible enough
>> to me.
>
> To what percentage of programmers are such things relevant?
>
>> The development environment may well have been object-based. Do you
>> know whether or not the Lisp dialect the used was OO?
>
> You know, from the description of Common Lisp, it's hard to tell!
>
> - Gerry Quinn
[Reply to myself]
Grr, apologies for trimming the followups again. Please reply to this rather
than my original post...
Alex
Alex Drummond wrote:
>>> Lisp is mature, older than C++ in fact.
>>
>> Maturity of a technology is not a direct function of age. Where are the
>> IDEs, what is the standard version?
>
> The standard version is Common Lisp, which has been around for over a
> decade (i.e. longer than the latest C++ standard). CL vendors mostly
> provide IDEs.
>
>>> I can't buy the first sentence. What about the performance advantages
>>> of, say, epxression templates for matrix arithmetic. Sounds sensible
>>> enough to me.
>>
>> To what percentage of programmers are such things relevant?
>
> Programmers who want high performance numeric code. Or programmers who
> want to write a parser (http://spirit.sourceforge.net/). Both things which
> game programmers will probably want to do at some point.
>
>>> The development environment may well have been object-based. Do you
>>> know whether or not the Lisp dialect the used was OO?
>>
>> You know, from the description of Common Lisp, it's hard to tell!
>
> GOAL is not Common Lisp. You should know that Common Lisp supports OO if
> you've done even a smidgen of research. In fact it was the /first/ ANSI
> standardised OO language. So in terms of being standard and being OO, it
> pretty much beats C++.
>
>
> Alex
>
> Gerry Quinn wrote:
>
>> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>>> > Unless you are selling the technology, or unless a technology gives
>>> > you special capabilities that those not using it don't have, "getting
>>> > ahead
>>> > in technology" is a fool's motivation. Mature technology is cheaper
>>> > and more reliable as a general rule.
>>>
>>> Lisp is mature, older than C++ in fact.
>>
>> Maturity of a technology is not a direct function of age. Where are the
>> IDEs, what is the standard version?
>>
>>> > Template metaprogramming as such is never used by most sensible
>>> > programmers. Macros, by contrast, are ubiquitous in Lisp as I
>>> > understand it. And if the development environment had been an object-
>>> > based system with proper interfaces, it shouldn't have mattered
>>> > whether
>>> > his code was comprehensible. Something for addicts of 'generic
>>> > programming' to ponder. But that's all beside the point. I don't
>>> > know what particular aspects of the program were incomprehensible to
>>> > the other developers, I just threw it out as one of the problems that
>>> > afflicted the one games development team famous for developing in Lisp
>>> > and still actually achieving something.
>>>
>>> I can't buy the first sentence. What about the performance advantages
>>> of, say, epxression templates for matrix arithmetic. Sounds sensible
>>> enough to me.
>>
>> To what percentage of programmers are such things relevant?
>>
>>> The development environment may well have been object-based. Do you
>>> know whether or not the Lisp dialect the used was OO?
>>
>> You know, from the description of Common Lisp, it's hard to tell!
>>
>> - Gerry Quinn
In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> >> I can't buy the first sentence. What about the performance advantages of,
> >> say, epxression templates for matrix arithmetic. Sounds sensible enough
> >> to me.
> >
> > To what percentage of programmers are such things relevant?
>
> Programmers who want high performance numeric code. Or programmers who want
> to write a parser (http://spirit.sourceforge.net/). Both things which game
> programmers will probably want to do at some point.
Not on this scale. Spirit is part of a library project on the STL
level. And I suspect game programmers who want maximal numerical
performance are much more likely to drop to C or ASM than to try
anything fancy with templates.
My view, perhaps controversial, is that templates are for writing
libraries that will see massive re-use. Day-to-day programming will use
such libraries, but day-to-day programming should not involve writing
templates. I would go so far as to say that most professional C++
programmers should never have to write template code at all, except for
their own education and amusement. And that's basic template code, not
elaborations on it.
> >> The development environment may well have been object-based. Do you
> >> know whether or not the Lisp dialect the used was OO?
> >
> > You know, from the description of Common Lisp, it's hard to tell!
>
> GOAL is not Common Lisp. You should know that Common Lisp supports OO if
> you've done even a smidgen of research. In fact it was the /first/ ANSI
> standardised OO language. So in terms of being standard and being OO, it
> pretty much beats C++.
When I wrote that I HAD done a smidgeon of research, and my impression
was that yes, Common Lisp has classes, but they have a very 'bolted-on'
look. They are built with Lisp macros, no doubt for ideological reasons
- perhaps as a consequence they seem to lack things we might expect such
as access specifiers. That's why I wrote what I did.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> When I wrote that I HAD done a smidgeon of research, and my impression
> was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> look.
What ever do you mean by "bolted-on"?
> They are built with Lisp macros, no doubt for ideological reasons
Most of any Common Lisp system is going to be written in Common
Lisp (which means either macros or functions).
> perhaps as a consequence they seem to lack things we might expect
> such as access specifiers.
The lack of access specifiers is a design decision, not a
by-product of implementation.
What is it that you use access specifiers for?
--jon
>>>>> "JB" == Jon Boone <········@delamancha.org> writes:
[...]
JB> The lack of access specifiers is a design decision, not a
JB> by-product of implementation.
JB> What is it that you use access specifiers for?
I know you guys are just waiting for someone to quote Erik Naggum on
c++ 'protections' by continously asking a c++ person 'why do you need
access specifiers.' So I will oblige:
"... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result is
that thieves and bums use C++ and nice people use CLOS."
happy flaming,
BM
Bulent Murtezaoglu <··@acm.org> writes:
>>>>>> "JB" == Jon Boone <········@delamancha.org> writes:
> [...]
> JB> The lack of access specifiers is a design decision, not a
> JB> by-product of implementation.
>
> JB> What is it that you use access specifiers for?
>
> I know you guys are just waiting for someone to quote Erik Naggum on
> c++ 'protections' by continously asking a c++ person 'why do you need
> access specifiers.'
Actually, I had no such intention. My purpose is to gain a better
understanding of what the access specifiers are actually used for.
I know the *theory* of how they are used, but what's the actual
practice?
When I first learned Java, I was put off by the fact that perl's
OO support didn't include mechanisms for *forcing* the protection.
This seemed wrong, because most of my exposure to OO at the time was
via C++/Java. I had done a wee bit of OO programming in Scheme
during college, but it wasn't easy for me to recall at the time.
The perl methods seem more acceptable to me now that I know CLOS.
Now I wish perl had more CLOS support, rather than more C++/Java
support.
Oh yeah, and I wish it had more parenthesis and prefix-syntax. :-)
--jon
Jon Boone <········@delamancha.org> writes:
> What is it that you use access specifiers for?
Refining interfaces and enforcing invariants.
In CL, using package system deliberately can aid in /communicating/
these intents or desires, but there's a stronger non-enforceable trust
factor involved.
--
Steven E. Harris
In article <··············@spiritus.delamancha.org>,
········@delamancha.org says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > perhaps as a consequence they seem to lack things we might expect
> > such as access specifiers.
>
> The lack of access specifiers is a design decision, not a
> by-product of implementation.
>
> What is it that you use access specifiers for?
The same thing I use the safety catch on a gun for. It stops me
shooting myself in the foot.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··············@spiritus.delamancha.org>,
> ········@delamancha.org says...
> > Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > > perhaps as a consequence they seem to lack things we might expect
> > > such as access specifiers.
> >
> > The lack of access specifiers is a design decision, not a
> > by-product of implementation.
> >
> > What is it that you use access specifiers for?
>
> The same thing I use the safety catch on a gun for. It stops me
> shooting myself in the foot.
>
> - Gerry Quinn
If the safety is the only thing keeping you from shooting yourself in
the foot, I think you should put away your gun for a while. And
perhaps re-examine your preconceptions about why access specifiers are
so important.
Gregm
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > In article <··············@spiritus.delamancha.org>,
> > ········@delamancha.org says...
> > > Gerry Quinn <······@DELETETHISindigo.ie> writes:
> >
> > > > perhaps as a consequence they seem to lack things we might expect
> > > > such as access specifiers.
> > >
> > > The lack of access specifiers is a design decision, not a
> > > by-product of implementation.
> > >
> > > What is it that you use access specifiers for?
> >
> > The same thing I use the safety catch on a gun for. It stops me
> > shooting myself in the foot.
> >
Here is one C++ guru who has decided test-driven development can protect
your foot even better than the C++ safeties:
http://www.artima.com/forums/flat.jsp?forum=106&thread=4639
And the upside then is the vastly greater speed with which one can write
code in, well, Python.
kenny
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··············@spiritus.delamancha.org>,
> ········@delamancha.org says...
>> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
>> > perhaps as a consequence they seem to lack things we might expect
>> > such as access specifiers.
>>
>> The lack of access specifiers is a design decision, not a
>> by-product of implementation.
>>
>> What is it that you use access specifiers for?
>
> The same thing I use the safety catch on a gun for. It stops me
> shooting myself in the foot.
Can you be a bit more specific? For example, do you make
extensive use of the protected specifier? Or do you stick primarily
to the public/private specifiers?
--jon
In article <··············@spiritus.delamancha.org>,
········@delamancha.org says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> >> What is it that you use access specifiers for?
> >
> > The same thing I use the safety catch on a gun for. It stops me
> > shooting myself in the foot.
>
> Can you be a bit more specific? For example, do you make
> extensive use of the protected specifier? Or do you stick primarily
> to the public/private specifiers?
I like to have as much 'protected' as practicable, while 'private' is
essentially unused. Of course that is suited to a one-man operation,
for team-work I would not so blithely share stuff with derived classes.
When you've written both base and derived class, 'protected' is enough
IMO.
Actually my latest project uses a lot of polymorphism and even (shock)
makes use of multiple inheritance, which I used to declare essentially
useless! So maybe with more extensive class hierarchies, I will find
myself starting to declare members as 'private'. Contrary to popular
belief, I do evolve my methodologies, albeit reluctantly ;-)
- Gerry Quinn
Let me start by thanking you for your honest and thoughtful
response. I appreciate the opportunity to learn more about how
others program.
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> I like to have as much 'protected' as practicable, while 'private'
> is essentially unused. Of course that is suited to a one-man
> operation, for team-work I would not so blithely share stuff with
> derived classes. When you've written both base and derived class,
> 'protected' is enough IMO.
So, unless I misunderstand the symantics of the 'protected'
specifier, thinks marked this way are accessible to the class and
any sub-classes, but no one else. Is that correct?
I believe items declared 'public' are accessible to anyone, as
they would be in C. If one does not declare an specifier, do they
not default to 'public'?
> Actually my latest project uses a lot of polymorphism and even
> (shock) makes use of multiple inheritance, which I used to declare
> essentially useless! So maybe with more extensive class
> hierarchies, I will find myself starting to declare members as
> 'private'.
Again, IIRC, 'private' items are inaccessible to everyone except
the class itself. Have I misunderstood the semantics?
> Contrary to popular belief, I do evolve my methodologies, albeit
> reluctantly ;-)
I have no doubt. It happens to all of us, sooner or later. :-)
--jon
Jon Boone posted:
>
> Let me start by thanking you for your honest and thoughtful
> response. I appreciate the opportunity to learn more about how
> others program.
>
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
>> I like to have as much 'protected' as practicable, while 'private'
>> is essentially unused. Of course that is suited to a one-man
>> operation, for team-work I would not so blithely share stuff with
>> derived classes. When you've written both base and derived class,
>> 'protected' is enough IMO.
>
> So, unless I misunderstand the symantics of the 'protected'
> specifier, thinks marked this way are accessible to the class and
> any sub-classes, but no one else. Is that correct?
Correct:
class Base
{
protected:
int k;
};
class Derived : public Base
{
Derived()
{
k = 4;
//This is perfectly legal
}
};
int main()
{
Base monkey;
monkey.k = 4;
//This is illegal
}
> I believe items declared 'public' are accessible to anyone, as
> they would be in C. If one does not declare an specifier, do they
> not default to 'public'?
They default to private.
Writing:
class Blah
{
int k;
};
is the same as writing:
class Blah
{
private:
int k;
};
Conversly, if you opt for the "struct" keyword, things default to public,
ie:
struct Blah
{
int k;
};
is the same as:
struct Blah
{
public:
int k;
};
>> Actually my latest project uses a lot of polymorphism and even
>> (shock) makes use of multiple inheritance, which I used to declare
>> essentially useless! So maybe with more extensive class
>> hierarchies, I will find myself starting to declare members as
>> 'private'.
>
> Again, IIRC, 'private' items are inaccessible to everyone except
> the class itself. Have I misunderstood the semantics?
Correct. Private items are even inaccesible to dervied classes.
-JKop
In article <··············@spiritus.delamancha.org>,
········@delamancha.org says...
>
> Let me start by thanking you for your honest and thoughtful
> response. I appreciate the opportunity to learn more about how
> others program.
>
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > I like to have as much 'protected' as practicable, while 'private'
> > is essentially unused. Of course that is suited to a one-man
> > operation, for team-work I would not so blithely share stuff with
> > derived classes. When you've written both base and derived class,
> > 'protected' is enough IMO.
>
> So, unless I misunderstand the symantics of the 'protected'
> specifier, thinks marked this way are accessible to the class and
> any sub-classes, but no one else. Is that correct?
Yes.
> I believe items declared 'public' are accessible to anyone, as
> they would be in C. If one does not declare an specifier, do they
> not default to 'public'?
No, private. [Although C++ retains the 'struct' keyword from C, and
members of a struct default to public.]
My habit is to start a class definition with:
class MyClass
{
public:
// member data
protected:
// member data
public:
// member functions
protected:
// member functions
};
(only without the comments). Ideally the first category should be
empty, and typically the fourth is biggest. Often I move stuff around
during development.
One minor dilemma I often encounter is whether to use accessor functions
to get at protected data. Ideally, I suspect, a class should have its
own internal accessors, but that is too much typing, so it remains
conceptual! I do sometimes implement it in a small way, i.e. with a
public const accessor, and a protected non-const accessor/mutator.
> > Actually my latest project uses a lot of polymorphism and even
> > (shock) makes use of multiple inheritance, which I used to declare
> > essentially useless! So maybe with more extensive class
> > hierarchies, I will find myself starting to declare members as
> > 'private'.
>
> Again, IIRC, 'private' items are inaccessible to everyone except
> the class itself. Have I misunderstood the semantics?
No, that is correct. (You can use the 'friend' keyword to make
exceptions in special cases.)
- Gerry Quinn
Gerry Quinn wrote:
> In article <··············@spiritus.delamancha.org>,
> ········@delamancha.org says...
[snip]
>> I believe items declared 'public' are accessible to anyone, as
>> they would be in C. If one does not declare an specifier, do they
>> not default to 'public'?
>
> No, private. [Although C++ retains the 'struct' keyword from C, and
> members of a struct default to public.]
>
> My habit is to start a class definition with:
>
> class MyClass
> {
> public:
> // member data
> protected:
> // member data
> public:
> // member functions
> protected:
> // member functions
> };
>
> (only without the comments). Ideally the first category should be
> empty, and typically the fourth is biggest. Often I move stuff around
> during development.
>
> One minor dilemma I often encounter is whether to use accessor functions
> to get at protected data. Ideally, I suspect, a class should have its
> own internal accessors, but that is too much typing, so it remains
> conceptual! I do sometimes implement it in a small way, i.e. with a
> public const accessor, and a protected non-const accessor/mutator.
>
There's an advantage of Lisp right there, then. It's very, very easy to
define accessor methods (or separate reader and writer methods, if that
fits better), and if you later change the contents of the slot (or remove
it), you can just remove the accessor declaration and define your own to
fit the new slot.
It's what I suspect you wanted to do, and the compiler is smart enough that
accessor calls don't neccessarily involve function calls, especially if you
use type declarations.
In article <············@services.kq.no>, ·········@aas.no says...
> Gerry Quinn wrote:
> > One minor dilemma I often encounter is whether to use accessor functions
> > to get at protected data. Ideally, I suspect, a class should have its
> > own internal accessors, but that is too much typing, so it remains
> > conceptual! I do sometimes implement it in a small way, i.e. with a
> > public const accessor, and a protected non-const accessor/mutator.
> >
> There's an advantage of Lisp right there, then. It's very, very easy to
> define accessor methods (or separate reader and writer methods, if that
> fits better), and if you later change the contents of the slot (or remove
> it), you can just remove the accessor declaration and define your own to
> fit the new slot.
>
> It's what I suspect you wanted to do, and the compiler is smart enough that
> accessor calls don't neccessarily involve function calls, especially if you
> use type declarations.
No, it's pretty easy in C++ too, just a bit of a chore. I doubt there
is any real difference.
- Gerry Quinn
In article <············@services.kq.no>, ·········@aas.no says...
> Gerry Quinn wrote:
> > One minor dilemma I often encounter is whether to use accessor functions
> > to get at protected data. Ideally, I suspect, a class should have its
> > own internal accessors, but that is too much typing, so it remains
> > conceptual! I do sometimes implement it in a small way, i.e. with a
> > public const accessor, and a protected non-const accessor/mutator.
> >
> There's an advantage of Lisp right there, then. It's very, very easy to
> define accessor methods (or separate reader and writer methods, if that
> fits better), and if you later change the contents of the slot (or remove
> it), you can just remove the accessor declaration and define your own to
> fit the new slot.
>
> It's what I suspect you wanted to do, and the compiler is smart enough that
> accessor calls don't neccessarily involve function calls, especially if you
> use type declarations.
No, it's pretty easy in C++ too, just a bit of a chore. I doubt there
is any real difference.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
>> SNIP ... (in which Gerry corrects my incomplete recollection of C++
>> access specifier semantics, including reminding me of the
>> long-forgotten 'friend' specifier, and the the default specifier is
>> private)
Thanks again for the information.
> My habit is to start a class definition with:
>
> class MyClass
> {
> public:
> // member data
> protected:
> // member data
> public:
> // member functions
> protected:
> // member functions
> };
>
> (only without the comments). Ideally the first category should be
> empty, and typically the fourth is biggest. Often I move stuff around
> during development.
Very interesting. Thanks for sharing this information.
In CLOS, as others have already pointed out, you'd make the
distinction as follows (code below the body of the text):
1. define a package
2. within the package scope, define the class
*this is basic definition stuff*
3. export from the package those things that you want to have
visible from the outside.
*this adds public status* - for use by folks outside of the
package - but is only a _suggestion_ at this point
4. if you want to completely remove access to a symbol, unintern it
after the methods that use it are defined (obviously, it can't be
:exported either)
*this adds protected status wrt methods defined while the symbol
was interned* - in other words, they will be able to access it,
but no one else will
*this adds private status wrt methods defined after the symbol
has been uninterned* - all methods after the (unintern ...), as
well as those external to the package will not be able to use it
I can't think of how to trivially support the friend semantics.
> One minor dilemma I often encounter is whether to use accessor
> functions to get at protected data. Ideally, I suspect, a class
> should have its own internal accessors, but that is too much
> typing, so it remains conceptual! I do sometimes implement it in a
> small way, i.e. with a public const accessor, and a protected
> non-const accessor/mutator.
In CLOS, you can get at slots by using (slot-value obj 'slot-name)
Since this returns a *place*, you can (setf ..) it for a mutator.
If you want, you can specify the name of an :accessor (or a :reader
/ :writer) function that CLOS will create to hide the (slot-value
..) bit.
(defpackage "my-package"
(:use "COMMON-LISP")
(:export my-package::person))
(in-package "my-package")
(defclass person ()
((name :accessor person-name :initarg :person-name :initform "Bonzo")
(age :writer person-age :initarg :person-age :initform 15)
(height :reader person-height :initarg :person-height :initform 70)))
(defclass person2 (person)
((weight :initarg :person-weight :initform 180)))
(defmethod weigh-em ((the-victim person2))
(slot-value the-victim 'weight))
(let ((bonzo (make-instance 'person2)))
(format t "~A is ~A pounds.~%"
(person-name bonzo)
(weigh-em bonzo)))
(unintern 'weight)
(let ((bob (make-instance 'person2 :person-name "Bob" :person-weight 150)))
(format t "~A is ~A pounds.~%"
(person-name bob)
(weigh-em bob))
(format t "~A is ~A pounds.~%"
(person-name bob)
(slot-value bob 'weight)))
-------------------------------------------------------------
Upon loading, this yields:
CL-USER 1 > (load "~/Desktop/person.lisp")
; Loading text file /Users/ipmonger/Desktop/person.lisp
Bonzo is 180 pounds.
Bob is 150 pounds.
Error: The slot WEIGHT is missing from #<PERSON2 100B635B> (of class #<STANDARD-CLASS PERSON2 100AFD83>), when reading the value.
1 (continue) Try loading ~/Desktop/person.lisp again.
2 Give up loading ~/Desktop/person.lisp.
3 Try loading another file instead of ~/Desktop/person.lisp.
4 (abort) Return to level 0.
5 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
my-package 3 : 1 > :c 5
-------------------------------------------------------------
At the REPL you'd do (assuming it's already loaded):
CL-USER 4 > (use-package "my-package")
T
CL-USER 5 > (make-instance 'person)
#<PERSON 100D1AE3>
CL-USER 6 > (make-instance 'person2)
Error: PERSON2 is not the name of a class
1 (continue) Try finding the class PERSON2 again
2 (abort) Return to level 0.
3 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 7 : 1 > :c 3
"Steven E. Harris" <···@panix.com> writes:
> Jon Boone <········@delamancha.org> writes:
>
>> What is it that you use access specifiers for?
>
> Refining interfaces and enforcing invariants.
>
> In CL, using package system deliberately can aid in /communicating/
> these intents or desires, but there's a stronger non-enforceable trust
> factor involved.
>
> --
> Steven E. Harris
I assume Gerry is talking about this issue.
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> I like to have as much 'protected' as practicable, while 'private' is
> essentially unused. Of course that is suited to a one-man operation,
> for team-work I would not so blithely share stuff with derived classes.
> When you've written both base and derived class, 'protected' is enough
> IMO.
>
> Actually my latest project uses a lot of polymorphism and even (shock)
> makes use of multiple inheritance, which I used to declare essentially
> useless! So maybe with more extensive class hierarchies, I will find
> myself starting to declare members as 'private'. Contrary to popular
> belief, I do evolve my methodologies, albeit reluctantly ;-)
Didn't we just discuss why CL is bad and C++ is good because C++
_trusts_ the programmer to do his memory management and pointer
arithmetic perfectly?
Do you use a garbage collector and disable pointers when you are working
in a project team? If so, what's the magic compiler flag? ;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, ·····@nyct.net says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > I like to have as much 'protected' as practicable, while 'private' is
> > essentially unused. Of course that is suited to a one-man operation,
> > for team-work I would not so blithely share stuff with derived classes.
> > When you've written both base and derived class, 'protected' is enough
> > IMO.
>
> Didn't we just discuss why CL is bad and C++ is good because C++
> _trusts_ the programmer to do his memory management and pointer
> arithmetic perfectly?
> Do you use a garbage collector and disable pointers when you are working
> in a project team? If so, what's the magic compiler flag? ;)
No, *we* didn't discuss that. But there's a difference, in any case.
Garbage is a very global issue. And pointer arithmetic is a very non-
global issue. A class doesn't use either to mess with the internals of
a different class.
- Gerry Quinn
Jon Boone <········@delamancha.org> wrote in message news:<··············@spiritus.delamancha.org>...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > When I wrote that I HAD done a smidgeon of research, and my impression
> > was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> > look.
>
> What ever do you mean by "bolted-on"?
I'd like to see a definition of ``bolted on'' which covers the Common
Lisp object system, but somehow skillfully manages to exclude the C++
object system.
A good test for determining whether an object system is bolted on is
to answer the question: are there some ``basic types'' inherited from
an older language which don't participate in the class system?
> > They are built with Lisp macros, no doubt for ideological reasons
>
> Most of any Common Lisp system is going to be written in Common
> Lisp (which means either macros or functions).
... and it is for very pragmatic reasons.
> > perhaps as a consequence they seem to lack things we might expect
> > such as access specifiers.
>
> The lack of access specifiers is a design decision, not a
> by-product of implementation.
Common Lisp supports access control, just not in the same way as C++.
Firstly, there is the package system, which lets symbols be marked as
exported, or remain unexported. The package system provides a general
mechanism for controlling feature visibility, regardless of what kind
of entities you are working with, be they classes or whatever.
Next, accessor methods can be specified for a class slot, right in the
definition of that slot for disciplined access. Without accessors,
it's less convenient to get at a slot.
If you really want to hide slots, you can use secret uninterned
symbols to name them.
The C++ style of protection is completely at odds with the very design
of the object system, because there is no notion of class scope. The
body of a method in Lisp is not in some special scope in which the
symbols denoting the variables of a class are magically bound to those
slots. The ordinary scoping rule applies.
Public versus private issues play out at the package level.
In article <····························@posting.google.com>,
···@ashi.footprints.net says...
> The C++ style of protection is completely at odds with the very design
> of the object system, because there is no notion of class scope. The
> body of a method in Lisp is not in some special scope in which the
> symbols denoting the variables of a class are magically bound to those
> slots. The ordinary scoping rule applies.
You've lost me, I'm afraid...
- Gerry Quinn
Gerry Quinn wrote:
> In article <····························@posting.google.com>,
> ···@ashi.footprints.net says...
>
>> The C++ style of protection is completely at odds with the very design
>> of the object system, because there is no notion of class scope. The
>> body of a method in Lisp is not in some special scope in which the
>> symbols denoting the variables of a class are magically bound to those
>> slots. The ordinary scoping rule applies.
>
> You've lost me, I'm afraid...
>
C++ method call: foo.munge(bar);
Equivalent Lisp call: (munge foo bar)
The C++ function specializes on the first argument, that is to say "foo".
The language doesn't support multi-methods, so if you want to specialize on
bar as well, you'll have to do it by hande.
By the same token, however, foo doesn't have any special status in the munge
generic function. Attempting to add protection would be fairly nonsensical,
since functions aren't part of classes at all; they're in an entirely
separate namespace.
The code in munge is in munge's lexical scope, but it is *not* in foo's
lexical scope; the concept doesn't even exist.
In article <············@services.kq.no>, ·········@aas.no says...
> Gerry Quinn wrote:
>
> > In article <····························@posting.google.com>,
> > ···@ashi.footprints.net says...
> >
> >> The C++ style of protection is completely at odds with the very design
> >> of the object system, because there is no notion of class scope. The
> >> body of a method in Lisp is not in some special scope in which the
> >> symbols denoting the variables of a class are magically bound to those
> >> slots. The ordinary scoping rule applies.
> >
> > You've lost me, I'm afraid...
> >
> C++ method call: foo.munge(bar);
> Equivalent Lisp call: (munge foo bar)
>
> The C++ function specializes on the first argument, that is to say "foo".
> The language doesn't support multi-methods, so if you want to specialize on
> bar as well, you'll have to do it by hande.
In other words, the statement "The body of a method in Lisp is not in
some special scope in which the symbols denoting the variables of a
class are magically bound to those slots." is garbage because it implies
the existence of a language feature in C++ that doesn't exist. [And
isn't needed.]
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In other words, the statement "The body of a method in Lisp is not in
> some special scope in which the symbols denoting the variables of a
> class are magically bound to those slots." is garbage because it
> implies the existence of a language feature in C++ that doesn't exist.
> [And isn't needed.]
What?
class Foo {
public:
Foo(int x);
int get_val();
private:
int val;
};
Foo::Foo(int x)
{ val = x; }
int Foo::get_val()
{ return val; }
It sure looks like ``val'' comes from a "special scope in which the
symbols denoting the variables of a class are magically bound to those
slots" to my naive eyes. I certainly never defined it lexically. If
C++ didn't have this magic scoping you'd have to access it as
``this->val'' (and that would only work because ``this'' is magically
bound as well).
I'm not claiming this is bad, but it does exist.
Compare with CL:
(defclass foo ()
((val :initarg :val)))
(defmethod get-val ((foo foo))
(with-slots (val) foo
val)) ; <- correct
(defmethod get-val ((foo foo))
(slot-value foo 'val)) ; <- also correct
(defmethod get-val ((foo foo))
val) ; <- error! VAL is unbound
Of course, a sane person in CL would just write:
(defclass foo ()
((val :reader get-val :initarg :val)))
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <············@services.kq.no>, ·········@aas.no says...
> > Gerry Quinn wrote:
> >
> > > In article <····························@posting.google.com>,
> > > ···@ashi.footprints.net says...
> > >
> > >> The C++ style of protection is completely at odds with the very design
> > >> of the object system, because there is no notion of class scope. The
> > >> body of a method in Lisp is not in some special scope in which the
> > >> symbols denoting the variables of a class are magically bound to those
> > >> slots. The ordinary scoping rule applies.
> > >
> > > You've lost me, I'm afraid...
> > >
> > C++ method call: foo.munge(bar);
> > Equivalent Lisp call: (munge foo bar)
> >
> > The C++ function specializes on the first argument, that is to say "foo".
> > The language doesn't support multi-methods, so if you want to specialize on
> > bar as well, you'll have to do it by hande.
>
> In other words, the statement "The body of a method in Lisp is not in
> some special scope in which the symbols denoting the variables of a
> class are magically bound to those slots." is garbage because it implies
> the existence of a language feature in C++ that doesn't exist. [And
> isn't needed.]
class A {
protected:
int n;
};
class B : public A {
protected:
void foo () {
n = ... // <== magically bound n, outside of A's lexical scope
}
};
Now imagine A only existing in a binary library.
Bj�rn
Gerry Quinn wrote:
> In article <············@services.kq.no>, ·········@aas.no says...
>> Gerry Quinn wrote:
>>
>> > In article <····························@posting.google.com>,
>> > ···@ashi.footprints.net says...
>> >
>> >> The C++ style of protection is completely at odds with the very design
>> >> of the object system, because there is no notion of class scope. The
>> >> body of a method in Lisp is not in some special scope in which the
>> >> symbols denoting the variables of a class are magically bound to those
>> >> slots. The ordinary scoping rule applies.
>> >
>> > You've lost me, I'm afraid...
>> >
>> C++ method call: foo.munge(bar);
>> Equivalent Lisp call: (munge foo bar)
>>
>> The C++ function specializes on the first argument, that is to say "foo".
>> The language doesn't support multi-methods, so if you want to specialize
>> on bar as well, you'll have to do it by hande.
>
> In other words, the statement "The body of a method in Lisp is not in
> some special scope in which the symbols denoting the variables of a
> class are magically bound to those slots." is garbage because it implies
> the existence of a language feature in C++ that doesn't exist. [And
> isn't needed.]
>
Doesn't exist isn't quite right, see below.
As for not needed, I suppose that depends on your needs. Have you never
written a method in C++ where you do different things depending on the type
of one or more of the arguments?
Method overloading can do that, somewhat, but it just doesn't look right to
write "num1.add(num2)" to get reasonable maths, or anything else where the
subject and object have equal standing. C++ does message passing, Lisp has
a more general mechanism, but if you don't need anything but message
passing then who cares?
I'm not going to discuss this further, though; it isn't worth it. I prefer
using Lisp, you prefer using C++, can't we all just get along?
I'm going to make one attempt to explain why message-passing isn't the
end-all of OO, though. This isn't meant as an attack; I'll explain how it
works in Lisp, and then you can explain how it works in C++ so I'll
understand.
Grandparent
/ \
/ \
A1 B1
/ \ / \
/ \ / \
A2 A3 B2 B3
Let's say you have a method combine(a,b), which is define for any two
instances of grandparent. Thus, you can write gp-inst1.combine(gp-inst2).
Due to inheritance, you can also use any of A1 through B3 instead of
gp-inst1. Can you do the same for gp-inst2? If not, why not? How about
combinations where neither gp-inst1 or gp-inst2 are of class gandparent?
I don't know how this would work in C++, so let me show you what can be done
in Lisp.
First consider the original "combine" method. It's method signature is
(grandparent grandparent), meaning it accepts two arguments, each of which
inherits from grandparent somewhere along the chain. This part works just
like in C++, assuming C++ will accept a B1 as an argument instead of a
grandparent.
Now, imagine that the combine function won't fullfil its contract properly
if the second argument is a B1, because there's a new field there that the
original method doesn't understand. So you define a new method with
signature (grandparent b1), and probably another called (b1 grandparent) as
well. This works just fine; you have two methods, and in this particular
very symmetric case, you might even have the second method invoke the first
to avoid duplicating code.
Here's the clue: When the Lisp system chooses a method to call (at
compile-time, if it can get away with it), it chooses the most specific
method that fits the method-call signature. In left-to-right order, in case
of ties, and the arguments don't have to be in the same class hierarchy at
all.
Assuming you've been following contract properly and all the methods
essentially do the same thing as far as the caller's concerned, it just
works. Being able to define methods with signatures such as (int double),
or Lisp's equivalent, is just a bonus.
Then there's all the stuff about :after, :before and :around methods, not to
mention specializing (defining new methods for) the methods that are used
to manage classes. Lisp classes don't have constructors, as such, but there
is a global constructor method you can specialize for your class. None of
this is impossible in C++; Lisp just makes it more convenient, and possibly
easier to debug.
You may not have run into them, but the fact is that there are some
"patterns" in C++ and Java that attempt to do *exactly* this. The visitor
pattern is an example, if other posters can be believed. Obviously, such
patterns are invisible in Lisp, in much the same way as the "class" pattern
is invisible in C++ and the "if" pattern is invisible in C.
That's a[1] major strength of Lisp, in fact: Any reasonably obvious pattern
can usually be refactored into a macro of some sort, at which point it
becomes invisible. The basic building-block of Lisp loops is GO(to), but
you rarely see it outside macros, to give a simple example.
In article <············@services.kq.no>, ·········@aas.no says...
> Gerry Quinn wrote:
>
> > In article <····························@posting.google.com>,
> > ···@ashi.footprints.net says...
> >
> >> The C++ style of protection is completely at odds with the very design
> >> of the object system, because there is no notion of class scope. The
> >> body of a method in Lisp is not in some special scope in which the
> >> symbols denoting the variables of a class are magically bound to those
> >> slots. The ordinary scoping rule applies.
> >
> > You've lost me, I'm afraid...
> >
> C++ method call: foo.munge(bar);
> Equivalent Lisp call: (munge foo bar)
>
> The C++ function specializes on the first argument, that is to say "foo".
> The language doesn't support multi-methods, so if you want to specialize on
> bar as well, you'll have to do it by hande.
In other words, the statement "The body of a method in Lisp is not in
some special scope in which the symbols denoting the variables of a
class are magically bound to those slots." is garbage because it implies
the existence of a language feature in C++ that doesn't exist. [And
isn't needed.]
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> wrote in message news:<··························@news.indigo.ie>...
> In article <····························@posting.google.com>,
> ···@ashi.footprints.net says...
>
> > The C++ style of protection is completely at odds with the very design
> > of the object system, because there is no notion of class scope. The
> > body of a method in Lisp is not in some special scope in which the
> > symbols denoting the variables of a class are magically bound to those
> > slots. The ordinary scoping rule applies.
>
> You've lost me, I'm afraid...
In C++, a class is not just a blueprint for creating objects, but it's
also a lexical namespace. An identifier X declared within class C
(that is not nested in a namespace or another class) is actually C::X.
This is not class membership but scoping.
Within the body of a member function, C::X can be referred to using
the short name X, even though X is not declared anywhere in the
lexical scope: the body of the member function is not enclosed in the
class definition but is outside of it.
By manipulating the class definition, we can introduce names into the
scopes of function bodies that are located away from that definition,
and we can seriously alter their meaning.
This is a critical language design mistake; it's in no way necessary
for ``class scope'' to exist in an object system.
In Python, which has single dispatch like C++, members are referenced
using a self symbol, so that self.x means the x member of this object,
analogous to this->x, and x just has the normal meaning, denoting a
lexical variable or whatnot.
Lisp has multiple dispatch so that there isn't even a self object. A
method with three specializable parameters has three ``self'' objects.
They are explicitly named as parameters, nothing is hidden. Class
scope imposed into the Lisp paradigm would wreak even greater havoc,
because there would be clashes between identically named members from
the different classes.
Some dialects of the Pascal language have a much criticized WITH
statement that is similar to class scope. It introduces a block of
code in which the members of a record can be accessed using just their
short, unqualified names. Like C++ class scope, the WITH statement
has the problem that when fields are added to the record, they
suddenly become visible in all these scopes, potentially shadowing
existing references to those same names in those blocks of code.
Moreover, WITH statements themselves can be nested.
Modula-3 has a much more sane, completely different WITH statement, in
which the programmer explicitly declares unqualified names and the
expressions for which they stand, such as WITH X = A[I] ... meaning
that X is like a local macro denoting A[I] over this block.
Common Lisp has something similar, called SYMBOL-MACROLET. And it also
has something called WITH-SLOTS that is implemented on
SYMBOL-MACROLET. This WITH-SLOTS feature lets the programmer create
unqualified symbols that behave like variables over a scope, but which
are bound to the slots of a class object. For instance:
(with-slots (first-name last-name number) employee-object
;; just use first-name, etc.
)
The construct explicitly names the symbols for which bindings are to
exist. There is no way to manipulate this from a remote location.
Adding more slots to the class of employee-object has no effect,
because this is all lexically scoped.
The WITH-SLOTS macro can also give alternate names, which is handy if
you have nested WITH-SLOTS forms for objects of the same class, for
instance:
(with-slots ((x0 x) (y0 y)) point0
(with-slots ((x1 x) (y1 y)) point1
(my-graphics-library::draw-line x0 y0 x1 y1)))
If you are really aching for some of the conveniences of class scope,
you can emulate it by developing some short hand over WITH-SLOTS or
SYMBOL-MACROLET.
Lexical scope means that if we see some reference to (apparently) a
variable X, we just search the enclosing forms for the innermost
definition. If we don't find one, then it's an unbound reference, or a
reference to a global/dynamic variable.
In article <····························@posting.google.com>,
···@ashi.footprints.net says...
> Gerry Quinn <······@DELETETHISindigo.ie> wrote in message news:<··························@news.indigo.ie>...
> By manipulating the class definition, we can introduce names into the
> scopes of function bodies that are located away from that definition,
> and we can seriously alter their meaning.
Not a problem, because functions are bound to classes. 'Away' is a
matter of definition. Lispers have been going on about how closing
parentheses half a mile away from their opening parentheses don't
matter. Likewise, there's a trail from function to class definition.
> This is a critical language design mistake; it's in no way necessary
> for ``class scope'' to exist in an object system.
Nonsense. There is every reason.
> Lisp has multiple dispatch so that there isn't even a self object. A
> method with three specializable parameters has three ``self'' objects.
> They are explicitly named as parameters, nothing is hidden. Class
> scope imposed into the Lisp paradigm would wreak even greater havoc,
> because there would be clashes between identically named members from
> the different classes.
That's because whatever 'class' functions you bolt on to Lisp, the
language is not object-oriented and never will be, except maybe at
package level. Deal with it.
- Gerry Quin
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> That's because whatever 'class' functions you bolt on to Lisp, the
> language is not object-oriented and never will be, except maybe at
> package level. Deal with it.
It sounds like you're claiming that encapsulation is a integral part of
"object orientation". This comes up a lot in discussions of CLOS.
We (Common Lispers) don't think encapsulation is an integral part of OO.
Instead we have a separate language feature (packages) that handle
encapsulation. ``CLOS'' is left to deal with inheritance and
polymorphism (which, incidentally, are far more powerful than their C++
counterparts).
This is a difference of opinion.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing wrote:
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>> That's because whatever 'class' functions you bolt on to Lisp, the
>> language is not object-oriented and never will be, except maybe at
>> package level. Deal with it.
>
> It sounds like you're claiming that encapsulation is a integral part of
> "object orientation". This comes up a lot in discussions of CLOS.
>
> We (Common Lispers) don't think encapsulation is an integral part of OO.
> Instead we have a separate language feature (packages) that handle
> encapsulation. ``CLOS'' is left to deal with inheritance and
> polymorphism (which, incidentally, are far more powerful than their C++
> counterparts).
>
> This is a difference of opinion.
>
I might add that you do have encapsulation, if you decide to use slot-value
for "private" slots and accessors for public slots. That probably isn't a
good idea, though, since slots might go away at some point while accessors
can be redefined to emulate the slot some other way. The canonical example
may be storing a vector as magnitude+direction vs. x-pos, y-pos and so on.
One way that works, then, is by naming private functions as "%function%",
and public functions as "function".
It works for me, and although it's just a difference in syntax, we've
already established that that's true for C++ as well. People won't be
calling %internal-method% without noticing the %'s.
In article <·······················@attbi_s03>, ·············@lavos.net
says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> > That's because whatever 'class' functions you bolt on to Lisp, the
> > language is not object-oriented and never will be, except maybe at
> > package level. Deal with it.
>
> It sounds like you're claiming that encapsulation is a integral part of
> "object orientation". This comes up a lot in discussions of CLOS.
That's part of it. But my main point is that "object orientation" means
more than "allowing objects". You have to be oriented towards classes.
If you are oriented towards functions, or macros, you are not object-
oriented.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <·······················@attbi_s03>, ·············@lavos.net
> says...
> > In article <··························@news.indigo.ie>,
> > Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> > > That's because whatever 'class' functions you bolt on to Lisp, the
> > > language is not object-oriented and never will be, except maybe at
> > > package level. Deal with it.
> >
> > It sounds like you're claiming that encapsulation is a integral part of
> > "object orientation". This comes up a lot in discussions of CLOS.
>
> That's part of it. But my main point is that "object orientation" means
> more than "allowing objects". You have to be oriented towards classes.
> If you are oriented towards functions, or macros, you are not object-
> oriented.
This statement is confusing to me- C++ is plenty oriented towards all
those things. As is every other language that claims to be
"object-oriented"- leaving aside a precise definition of that for a
moment. Lisp's model of datatypes and code makes everything a
first-class object, which seems to me to make it more thoroughly
oriented towards objects than something like C++.
Gregm
Gerry Quinn wrote:
> But my main point is that "object orientation" means
> more than "allowing objects". You have to be oriented towards classes.
> If you are oriented towards functions, or macros, you are not object-
> oriented.
If you are oriented towards classes, you are class-oriented, not
object-oriented. (I am only half-joking.)
In Common Lisp, functions, macros, classes etc., are also objects. Go
figure. ;)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Fri, 5 Nov 2004, Gerry Quinn wrote:
> That's part of it. But my main point is that "object orientation" means
> more than "allowing objects". You have to be oriented towards classes.
>
There are a number of classless OO languages whose creators would beg to
differ.
--
······@flippac.org
Gerry Quinn wrote:
> In article <····························@posting.google.com>,
> ···@ashi.footprints.net says...
>> Gerry Quinn <······@DELETETHISindigo.ie> wrote in message
>> news:<··························@news.indigo.ie>...
>
>> By manipulating the class definition, we can introduce names into the
>> scopes of function bodies that are located away from that definition,
>> and we can seriously alter their meaning.
>
> Not a problem, because functions are bound to classes. 'Away' is a
> matter of definition. Lispers have been going on about how closing
> parentheses half a mile away from their opening parentheses don't
> matter. Likewise, there's a trail from function to class definition.
>
I agree with this, and Lisp methods tend to be located even further from the
class definition, for that matter.
Besides, most C++ IDEs have something similar to M-., which lets you move
directly from the invocation or declaration of a function to its
definition.
On the subject of Lisp, though, I'd hope that most Lispers *don't* think
having closing parantheses a long way from their opener is a good thing.
Personally I always try to keep functions below a screenful, so I can see
all of it at once.
I keep telling friends not to do that in C, though, and they keep not
listening to me - even adding vertical whitespace where none is needed - so
I wouldn't be surprised at all if I someday see a 200-line Lisp function.
They probably have better memory than I do.
>> This is a critical language design mistake; it's in no way necessary
>> for ``class scope'' to exist in an object system.
>
> Nonsense. There is every reason.
>
If you're basing it on a message-passing paradigm, then there is. If you
have multiple dispatch then it doesn't make sense. Design choice, there.
Which one of those is best is a different discussion, but *for C++*, class
scope is reasonable. *For Lisp*, it isn't.
Class scope tends to play havoc with multiple inheritance, though, if that
includes automatically binding variables to the instance/class slots.
>> Lisp has multiple dispatch so that there isn't even a self object. A
>> method with three specializable parameters has three ``self'' objects.
>> They are explicitly named as parameters, nothing is hidden. Class
>> scope imposed into the Lisp paradigm would wreak even greater havoc,
>> because there would be clashes between identically named members from
>> the different classes.
>
> That's because whatever 'class' functions you bolt on to Lisp, the
> language is not object-oriented and never will be, except maybe at
> package level. Deal with it.
>
Packages are namespaces, classes are... well, classes. They're entirely
different concepts: although class/instance slots can in some ways be said
to be in a separate namespace, in reality they are just in a separate
lexical scope.
That's true for C++ too, it's just slightly harder to see because function
definitions don't have to be inside the class-definiton braces.[1] In Java
they do, IIRC.
Now, then. How can you possibly say that Lisp isn't object-oriented, when
you can even specialize methods on built-in primitive types such as lists
(okay, conses) and numbers? (And fixnums, bignums, integers, floats, and so
on.)
It was *designed* to be an object-oriented language; the Common Lisp ANSI
standard was the first object-oriented language to be standardized.
Other people have already said this, though. Why, then, do you keep claiming
this? What does Lisp lack, that stops it from being object-oriented?
1: Hmm, can you still call it a lexical scope, then? I was pretty sure the
idea of a lexical scope involved the look of the source code;
myclass::function is inside myclass's lexical scope, but it isn't actually
*written* there.
Sorry for the delayed followup, but it seems that no one has brought up
a point I consider very important in OOP and have been frustrated by
non-observance of it numerous times.
Svein Ove Aas <·········@aas.no> writes:
> On the subject of Lisp, though, I'd hope that most Lispers *don't* think
> having closing parantheses a long way from their opener is a good thing.
> Personally I always try to keep functions below a screenful, so I can see
> all of it at once.
>
> I keep telling friends not to do that in C, though, and they keep not
> listening to me - even adding vertical whitespace where none is needed - so
> I wouldn't be surprised at all if I someday see a 200-line Lisp function.
> They probably have better memory than I do.
This is actually bad object-oriented design. Functional decomposition is
essential to having a good, extensible class where you can override just
the functionality you need to override instead of having to
copy-and-paste a massive block of code or an entire class-and-methods
definition just to tweak the way one specific bit of it works.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> What is it that you use access specifiers for?
>
For protecting your implementation from the other programmers.
If you don't protect your variables and strictly define your interfaces, and
limit their power, you'll find the other programmers will completely
misusing your code. Then when you go to rewrite it to provide new features,
you'll find you can't because all the variables you want to trash are being
used in critical parts of multiple projects.
I'd really like to know what team projects the Lisp posters have worked on,
and what team games they have completed this way? Some of these things are
only learnt from doing things in a team environment on a project with a
dozen people in a couple of projects all accessing your engine interfaces
without direct guidance from you.
If any Lisp programmers have worked on games in Lisp, please let me know who
you are so I know which posters are just being theoretical and which are
speaking from experience. This thread is getting to big to be reading
everyones articles when, I suspect, most of the Lisp programmers have only
ever experienced solo lisp programs, or never taken a group Lisp project to
completion...
"Maahes" <······@internode.on.net> writes:
> > What is it that you use access specifiers for?
> >
>
> For protecting your implementation from the other programmers.
> If you don't protect your variables and strictly define your interfaces, and
> limit their power, you'll find the other programmers will completely
> misusing your code. Then when you go to rewrite it to provide new features,
> you'll find you can't because all the variables you want to trash are being
> used in critical parts of multiple projects.
If controlling well-defined interfaces is important, its easy enough
to create a Common Lisp package with the interface functions exported.
The big lie with C++ is that the access specifiers actually enforce
access- its trivial to typecast an instance's pointer and arbitrarily
manipulate the object's members. Its more correct to say the access
specifiers provide some naive compile-time limits on how instances of
a class can be manipulated. If you need to protect your object
internals from other programmers, I think you'll need a more robust
technique.
The C++ answer to this is the programmer <should> honor the intent of
the specifiers, conforming access to the given interface- which is
exactly what Common Lisp is telling you when an interface is exposed
via a package.
Gregm
> The big lie with C++ is that the access specifiers actually enforce
> access- its trivial to typecast an instance's pointer and arbitrarily
> manipulate the object's members. Its more correct to say the access
> specifiers provide some naive compile-time limits on how instances of
> a class can be manipulated. If you need to protect your object
> internals from other programmers, I think you'll need a more robust
> technique.
Next you'll be complaining that TV isn't water-proof.
Putting stuff in the "private" or "protected" section is purely for ease of
use - it's *not* intended to "protect" the internals of the class.
-JKop
JKop <····@NULL.NULL> writes:
> > The big lie with C++ is that the access specifiers actually enforce
> > access- its trivial to typecast an instance's pointer and arbitrarily
> > manipulate the object's members. Its more correct to say the access
> > specifiers provide some naive compile-time limits on how instances of
> > a class can be manipulated. If you need to protect your object
> > internals from other programmers, I think you'll need a more robust
> > technique.
>
> Next you'll be complaining that TV isn't water-proof.
>
> Putting stuff in the "private" or "protected" section is purely for ease of
> use - it's *not* intended to "protect" the internals of the class.
>
Oh I'm not complaining- its just how C++ is. My point is that access
specifiers are essentially no more than a suggestion to the programmer
about how an interface should be used.
But I don't think ease has anything to do with it. There is a
suggestion of access enforcement via the specifiers that is not backed
up by other parts of the language, and this is not usually discussed
alongside the merits of specifiers.
Gregm
In article <··········@duster.adelaide.on.net>,
"Maahes" <······@internode.on.net> wrote:
> > What is it that you use access specifiers for?
>
> For protecting your implementation from the other programmers.
> If you don't protect your variables and strictly define your interfaces, and
> limit their power, you'll find the other programmers will completely
> misusing your code. Then when you go to rewrite it to provide new features,
> you'll find you can't because all the variables you want to trash are being
> used in critical parts of multiple projects.
Okay, so access specifiers are for protection.
In article <·····················@news.indigo.ie>,
JKop <····@NULL.NULL> wrote:
> Putting stuff in the "private" or "protected" section is purely for ease of
> use - it's *not* intended to "protect" the internals of the class.
Okay, so access specifiers are *not* for protection.
What are access specifiers for again?
> What are access specifiers for again?
Here's how I go about things:
1) I'm writing a class.
2) I want an object in the class to store some data.
3) I decide whether the user needs to know anything about this data.
4) If so, I make it "public", if not I make it "private".
Why make it private? I consider it to be a synonym for "Hey user, you don't
need to read up on this bit, it's just the internal guts of my class, you
don't have to worry about it, it doesn't affect how you use the class, ie.
the interface".
Ofcourse my user can just open the header file, replace private with public
and alter my private objects willy-nilly. To this I say:
"I warned you. You're messing with the internals of the class. I haven't
documented how the internals works so either A) You've figured it out by
reading my code, or B) You're messing. Either way I assume no liablility. I
gave you a user-friendly easy-to-use class, end of story."
Similarly, when I've been given a class written by some-one else, I don't
read through the private section, why... because I don't need to! All I'm
worried about is reading the "public" section, because that's the stuff I'll
work with to get what I want out of the class.
-JKop
JKop wrote:
>
>
>> What are access specifiers for again?
>
> Here's how I go about things:
Same here:
1) I'm writing a package.
2) I want a variable in the package to store some data.
3) I decide whether the user needs to know anything about this data.
4) If so, I export it from the package, if not I don't.
Why no export? I consider it to be a synonym for "Hey user, you don't
need to read up on this bit, it's just the internal guts of my package,
you don't have to worry about it, it doesn't affect how you use the
package, ie. the interface".
Of course my user can just use the variable with a special qualified
access and alter my non-exported variables willy-nilly. To this I say:
"I warned you. You're messing with the internals of the package. I
haven't documented how the internals works so either A) You've figured
it out by reading my code, or B) You're messing. Either way I assume no
liablility. I gave you a user-friendly easy-to-use package, end of story."
Similarly, when I've been given a package written by someone else, I
don't read through the non-exported symbols. Why? Because I don't need
to! All I'm worried about is reading the exported symbols, because
that's the stuff I'll work with to get what I want out of the package.
+++++++++++++++++++
In Common Lisp, access control and the object system are orthogonal
concepts.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
>> > What is it that you use access specifiers for?
>>
>> For protecting your implementation from the other programmers.
>> If you don't protect your variables and strictly define your interfaces,
>> and
>> limit their power, you'll find the other programmers will completely
>> misusing your code. Then when you go to rewrite it to provide new
>> features,
>> you'll find you can't because all the variables you want to trash are
>> being
>> used in critical parts of multiple projects.
>
> Okay, so access specifiers are for protection.
>
> In article <·····················@news.indigo.ie>,
> JKop <····@NULL.NULL> wrote:
>
>> Putting stuff in the "private" or "protected" section is purely for ease
>> of
>> use - it's *not* intended to "protect" the internals of the class.
>
> Okay, so access specifiers are *not* for protection.
>
> What are access specifiers for again?
See first statement. I don't know where he gets the "ease of use" from.
If it was for "ease of use", we wouldn't use them coz they are a pain when
your debugging coz its harder to hack into the variables from other classes.
"Maahes" <······@internode.on.net> writes:
> > What is it that you use access specifiers for?
> >
>
> For protecting your implementation from the other programmers.
> If you don't protect your variables and strictly define your interfaces, and
> limit their power, you'll find the other programmers will completely
> misusing your code. Then when you go to rewrite it to provide new features,
> you'll find you can't because all the variables you want to trash are being
> used in critical parts of multiple projects.
>
> I'd really like to know what team projects the Lisp posters have worked on,
> and what team games they have completed this way? Some of these things are
> only learnt from doing things in a team environment on a project with a
> dozen people in a couple of projects all accessing your engine interfaces
> without direct guidance from you.
You assumed that the poster asked the question because he /did/ /not/
/know/ what to use access specifiers for. I think the poster wanted to
know what /you/ use access specifiers for to come up with a reasonable
example since there are several methods for protecting data, functions
and methods in Common Lisp.
In Common Lisp you normally use packages to protect the implementation
from other programmers. You can protect a slot (i.e. a member
variable) by specifying a reader accessor to make it read-only.
Further, you can use closures to hide the data so that nobody (not
even yourself) can access the data other than through the specified
functions, e.g.
(let ((stack nil))
(defun stack-push (element)
(push element stack)
element)
(defun stack-pop ()
(pop stack))
)
In this case there is no way you can access the stack other than
stack-push and stack-pop. This has nothing to do with CLOS (the Common
Lisp Object System). It's /one/ method for access protection.
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?
Maahes wrote:
>> What is it that you use access specifiers for?
>>
>
>
> For protecting your implementation from the other programmers.
> If you don't protect your variables and strictly define your interfaces, and
> limit their power, you'll find the other programmers will completely
> misusing your code. Then when you go to rewrite it to provide new features,
> you'll find you can't because all the variables you want to trash are being
> used in critical parts of multiple projects.
>
> I'd really like to know what team projects the Lisp posters have worked on,
> and what team games they have completed this way? Some of these things are
> only learnt from doing things in a team environment on a project with a
> dozen people in a couple of projects all accessing your engine interfaces
> without direct guidance from you.
>
> If any Lisp programmers have worked on games in Lisp, please let me know who
> you are so I know which posters are just being theoretical and which are
> speaking from experience. This thread is getting to big to be reading
> everyones articles when, I suspect, most of the Lisp programmers have only
> ever experienced solo lisp programs, or never taken a group Lisp project to
> completion...
Team programming in Lisp is eminently doable. I worked on four sizeable
team projects using Lisp for development:
1. GATE was a three-person, two year project that developed a
knowledge-based, network-aware automated testing system that was used to
find hundreds of pre-release bugs in Mac System 7. It was written in
Common Lisp.
2. The unnamed first version of the Newton operating system was a
60-person, four year project written mostly in Ralph, a Lisp dialect
that later evolved into the Dylan language. (The Dylan compiler and IDE
were written in Common Lisp.)
3. Bauhaus was the second Lisp-based version of the Newton operating
system, also written in Ralph (a third version, written in C++ and
NewtonScript, and chosen for non-technical reasons, was the one
shipped). It was a five-person, two-year project.
4. SK8 was a 10-person, five-year project to develop a general-purpose
multimedia authoring system. It was used to build perhaps a dozen
projects at Apple, some of which were later productized and some of
which were given away to educational projects. SK8 itself was eventually
released as freeware. Sk8 was written in Common Lisp.
None of them were games (though SK8 was used to build several games and
several applications that incorporated interactive video elements).
> Team programming in Lisp is eminently doable. I worked on four sizeable
> team projects using Lisp for development:
>
> 1. GATE was a three-person, two year project that developed a
> knowledge-based, network-aware automated testing system that was used to
> find hundreds of pre-release bugs in Mac System 7. It was written in
> Common Lisp.
>
> 2. The unnamed first version of the Newton operating system was a
> 60-person, four year project written mostly in Ralph, a Lisp dialect that
> later evolved into the Dylan language. (The Dylan compiler and IDE were
> written in Common Lisp.)
>
> 3. Bauhaus was the second Lisp-based version of the Newton operating
> system, also written in Ralph (a third version, written in C++ and
> NewtonScript, and chosen for non-technical reasons, was the one shipped).
> It was a five-person, two-year project.
>
> 4. SK8 was a 10-person, five-year project to develop a general-purpose
> multimedia authoring system. It was used to build perhaps a dozen projects
> at Apple, some of which were later productized and some of which were
> given away to educational projects. SK8 itself was eventually released as
> freeware. Sk8 was written in Common Lisp.
>
> None of them were games (though SK8 was used to build several games and
> several applications that incorporated interactive video elements).
Cool. I think this thread is being fuelled heavily by the cross posting.
Since it is also in comp.games, you'll get a lot of posts from people like
me that are not satisfied unless we here from someone who has shipped a 10
month project with 7+ programmers on a console title in Lisp.
Also, it doesn't help the case when you here that the version of Bauhaus
that shipped was a C++ version... why would you even consider writing a C++
version when you've already got 2 versions written in Lisp, which is
supposed to be a far better language...
In article <········@duster.adelaide.on.net>,
"Maahes" <······@internode.on.net> wrote:
> > Team programming in Lisp is eminently doable. I worked on four sizeable
> > team projects using Lisp for development:
> >
> > 1. GATE was a three-person, two year project that developed a
> > knowledge-based, network-aware automated testing system that was used to
> > find hundreds of pre-release bugs in Mac System 7. It was written in
> > Common Lisp.
> >
> > 2. The unnamed first version of the Newton operating system was a
> > 60-person, four year project written mostly in Ralph, a Lisp dialect that
> > later evolved into the Dylan language. (The Dylan compiler and IDE were
> > written in Common Lisp.)
> >
> > 3. Bauhaus was the second Lisp-based version of the Newton operating
> > system, also written in Ralph (a third version, written in C++ and
> > NewtonScript, and chosen for non-technical reasons, was the one shipped).
> > It was a five-person, two-year project.
> >
> > 4. SK8 was a 10-person, five-year project to develop a general-purpose
> > multimedia authoring system. It was used to build perhaps a dozen projects
> > at Apple, some of which were later productized and some of which were
> > given away to educational projects. SK8 itself was eventually released as
> > freeware. Sk8 was written in Common Lisp.
> >
> > None of them were games (though SK8 was used to build several games and
> > several applications that incorporated interactive video elements).
>
> Cool. I think this thread is being fuelled heavily by the cross posting.
> Since it is also in comp.games, you'll get a lot of posts from people like
> me that are not satisfied unless we here from someone who has shipped a 10
> month project with 7+ programmers on a console title in Lisp.
People keep saying that ("show me a game"), but I do not think it makes
any sense. Can one not judge a language just by looking at it and doing
a little programming and reading and googling? This "Sure that's a Lisp,
team project, but it's not a /games/, Lisp, team project!". <g>
By that reasoning, no new language would ever have been adopted. (And,
yes, Lisp is new. <g>)
kenny
Maahes wrote:
> Cool. I think this thread is being fuelled heavily by the cross posting.
> Since it is also in comp.games, you'll get a lot of posts from people like
> me that are not satisfied unless we here from someone who has shipped a 10
> month project with 7+ programmers on a console title in Lisp.
>
> Also, it doesn't help the case when you here that the version of Bauhaus
> that shipped was a C++ version... why would you even consider writing a C++
> version when you've already got 2 versions written in Lisp, which is
> supposed to be a far better language...
Because a marketing guy sits next to the CEO on a airplane trip and
convinces him that the C++ name is a better marketing tool than an
unknown new Lisp variant whose name is "Ralph".
Since then I've seen similar things happen again. For example, a much
more recent project with which I am familiar was implemented in C++
specifically so that marketing people could cynically explain to
prospective customers that C++ is better and faster than the Java
competition (though, in fact, the implementors' own numbers proved that
was not true).
In article <········@duster.adelaide.on.net>, ······@internode.on.net
says...
>
> Cool. I think this thread is being fuelled heavily by the cross posting.
> Since it is also in comp.games, you'll get a lot of posts from people like
> me that are not satisfied unless we here from someone who has shipped a 10
> month project with 7+ programmers on a console title in Lisp.
Heck, I've only asked for pointers to a few little Windows games or
screensavers similar to my own!
Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <········@duster.adelaide.on.net>, ······@internode.on.net
> says...
> >
> > Cool. I think this thread is being fuelled heavily by the cross posting.
> > Since it is also in comp.games, you'll get a lot of posts from people like
> > me that are not satisfied unless we here from someone who has shipped a 10
> > month project with 7+ programmers on a console title in Lisp.
>
> Heck, I've only asked for pointers to a few little Windows games or
> screensavers similar to my own!
Check out
http://www.franz.com/success/customer_apps/artificial_intelligence/kurzweil.lhtml
and links.
The mention about use as a screensaver seems to imply that it is
generated statically, and I'm sure that is also possible, but I've
also seen it actually running as a screensaver in the background,
generating new paintings each time.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@franz.com>, ·····@franz.com says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > Heck, I've only asked for pointers to a few little Windows games or
> > screensavers similar to my own!
>
> Check out
>
> http://www.franz.com/success/customer_apps/artificial_intelligence/kurzweil.lhtml
> and links.
>
> The mention about use as a screensaver seems to imply that it is
> generated statically, and I'm sure that is also possible, but I've
> also seen it actually running as a screensaver in the background,
> generating new paintings each time.
Yes, I had forgotten about that - it is a valid example of a good
Windows screensaver written in Lisp. Worth a download - I tried it
yesterday. [It runs as a screensaver just as normal, i.e. creating a
painting, pausing for a while, then erasing it and creating another.]
Comments: (1) the paintings are interesting, and very good for computer
generated paintings, but I would hesitate to make extraordinary claims
for them. (2) Windows integration is adequate, but no more, using very
basic GUI features, i.e. there's no evidence that it's all that easy to
make (say) a fancy Settings screen.
- Gerry Quinn
Gerry Quinn wrote:
> In article <·············@franz.com>, ·····@franz.com says...
>> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
>> > Heck, I've only asked for pointers to a few little Windows games or
>> > screensavers similar to my own!
>>
>> Check out
>>
>>
http://www.franz.com/success/customer_apps/artificial_intelligence/kurzweil.lhtml
>> and links.
>>
>> The mention about use as a screensaver seems to imply that it is
>> generated statically, and I'm sure that is also possible, but I've
>> also seen it actually running as a screensaver in the background,
>> generating new paintings each time.
>
> Yes, I had forgotten about that - it is a valid example of a good
> Windows screensaver written in Lisp. Worth a download - I tried it
> yesterday. [It runs as a screensaver just as normal, i.e. creating a
> painting, pausing for a while, then erasing it and creating another.]
>
> Comments: (1) the paintings are interesting, and very good for computer
> generated paintings, but I would hesitate to make extraordinary claims
> for them. (2) Windows integration is adequate, but no more, using very
> basic GUI features, i.e. there's no evidence that it's all that easy to
> make (say) a fancy Settings screen.
>
Okay, that's it.
This incredibly talented guy spent *how* long on teaching a computer to
paint, writing something closer to real AI than most people have ever
imagined could be possible, and what you're concerned about is /Windows
integration/?
You, sir, are amazing.
*plonk*
In article <············@services.kq.no>, ·········@aas.no says...
> Gerry Quinn wrote:
> > Comments: (1) the paintings are interesting, and very good for computer
> > generated paintings, but I would hesitate to make extraordinary claims
> > for them. (2) Windows integration is adequate, but no more, using very
> > basic GUI features, i.e. there's no evidence that it's all that easy to
> > make (say) a fancy Settings screen.
> >
> Okay, that's it.
>
> This incredibly talented guy spent *how* long on teaching a computer to
> paint, writing something closer to real AI than most people have ever
> imagined could be possible, and what you're concerned about is /Windows
> integration/?
>
> You, sir, are amazing.
> *plonk*
Dude, in the first place Windows integration is only one of the two
points I made, and it is entirely relevant to the question that was
asked. MORE relevant, in fact, than the quality of the program, which I
don't deny.
In the second place, I don't want to get involved in an artistic debate,
but I was not all *that* impressed by this much-touted example of
incredible AI. While composition is undoubtedly good (definitely his
best achievement by some considerable margin), the drawings are very
repetitive, and some aspects are quite pedestrian, notably the colouring
and the entire absence of shadow [unless you count the hair-colouring
quirk]. Given the repetition, it's clear that the AI as such is rather
limited; the images are at best doodles on a theme, at worst a
relatively shallow expression of the author's input.
As to how long it took (and presumably according to the Lisp boosters
his thirty years of work are equivalent to about 150 years of C++), I
don't see that it matters much.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> As to how long it took (and presumably according to the Lisp boosters
> his thirty years of work are equivalent to about 150 years of C++), I
> don't see that it matters much.
No Lisp boosters have said anything like this. If I take your meaning,
that you are taking an (arbitrary but often used) 5X efficiency factor
of Lisp over C, then if you were to guess that Harold Cohen has spent
1 year's worth of work on Lisp out of the 30 years of work on Aaron
(i.e. 29 years of useful enhancement of Aaron itself) then the ratio
you're using would have put the C++ work at 5 years, thus leaving 25
years of useful work on Aaron itself.
Cohen gave a talk at ILC2002
(http://www.international-lisp-conference.org/ILC2002/index.html),
where he described his work. If you follow some of the links from the
url I gave previously and read the history and look at the photos,
you'll discover that a large portion of time spent on Aaron has not
even been software-related; for example, Cohen has built several large
"robot" painters which perform the physical task of making actual
small-room-sized paintings on the floor. It would have been a shame
if several of these years of hardware work had been wasted trying to
fiddle with the underlying language.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <······················@ram.dialup.fu-berlin.de>,
···@zedat.fu-berlin.de says...
> I don't think, that a screen saver is a good choice for any
> serious program. It occupies the whole screen, when it is
> running, therefore it does not allow one to work with the
> computer the normal way. It also can not easily be monitored
> with other programs at the same time, so I feel less secure
> when running a screen saver. Moreover, it will not install,
> when the windows size is less than 1024 x 768 - can't it even
> rescale?
Like I said, the integration is not great, but it could be worse.
> >In the second place, I don't want to get involved in an artistic debate,
> >but I was not all *that* impressed by this much-touted example of
> >incredible AI.
>
> All I saw in the gallery was a parameterized picture:
A parametrised picture whose 'artistic' qualities are the matter at
issue.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <······················@ram.dialup.fu-berlin.de>,
> ···@zedat.fu-berlin.de says...
> > All I saw in the gallery was a parameterized picture:
>
> A parametrised picture whose 'artistic' qualities are the matter at
> issue.
And this differs from the art of any abstract
expressionist painter how?
If a formal model of painting is possible, then it
will be a parameterized function of some kind. The
point is this guy has produced the best such
parameterized function in existence, and he did it
in Lisp.
And this counts as evidence for C++ somehow?!
You have a real problem facing discomfirming evidence.
In article <··························@news.vanderbilt.edu>,
····@vanderbilt.edu says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> > In article <······················@ram.dialup.fu-berlin.de>,
> > ···@zedat.fu-berlin.de says...
>
> > > All I saw in the gallery was a parameterized picture:
> >
> > A parametrised picture whose 'artistic' qualities are the matter at
> > issue.
>
> And this differs from the art of any abstract
> expressionist painter how?
I pointed out some quite obvious deficiencies in the work of 'AARON'
earlier. (Not when we were talking about screensavers, but when
somebody raved at me for not giving it enough respect when the reason it
was introduced in the first place was as an example Lisp's capacity for
making screensavers, not art.)
At best AARON is at the level of generating repetitive doodles. That
may well be a fine software achievement, but I do not think it is a
great artistic achievement.
> If a formal model of painting is possible, then it
> will be a parameterized function of some kind.
If the second clause is true in any interesting sense, I would consider
the above to be close to an impossibility proof for the first clause.
> The point is this guy has produced the best such
> parameterized function in existence, and he did it
> in Lisp.
>
> And this counts as evidence for C++ somehow?!
The only way it counts as evidence for C++ is in precisely the way I
stated: its functionality as a Windows screensaver is limited.
- Gerry Quinn
·······@taeus.com (Jerry Coffin) writes:
> Sashank Varma <····@vanderbilt.edu> wrote in message news:<··························@news.vanderbilt.edu>...
>
> [ ... ]
>
> > If a formal model of painting is possible, then it
> > will be a parameterized function of some kind. The
> > point is this guy has produced the best such
> > parameterized function in existence, and he did it
> > in Lisp.
>
> This is clearly a long ways from the best that's ever been done. A
> program that simply generates and draws totally random pixels is
> obviously better -- given sufficient time, it'll inevitably produce
> something worth looking at, whereas it seems fairly clear that this
> program has been written in such a way that it can never produce
> anything artistic, even by accident.
It depends in what universe.
There are: (expt (expt 2 24) (expt 2 22)) 4-Mpixel 24-bit color
pictures. That's about (expt 10 30000000) Since there's only about
(expt 10 17) seconds in the universe (or at most (expt 10 19)), you
just DON'T have sufficient time. That's why you need to be scient
to produce something worth looking at.
> The universe is a figment of its own imagination.
--
__Pascal Bourguignon__
Pascal Bourguignon <····@mouse-potato.com> wrote in message news:<··············@naiad.informatimago.com>...
[ ... ]
> It depends in what universe.
>
> There are: (expt (expt 2 24) (expt 2 22)) 4-Mpixel 24-bit color
> pictures. That's about (expt 10 30000000) Since there's only about
> (expt 10 17) seconds in the universe (or at most (expt 10 19)), you
> just DON'T have sufficient time. That's why you need to be scient
> to produce something worth looking at.
While you're math is correct, it's only distantly related to the right
math to do. Basically, your math would be right IF you were talking
about randomly producing one specific output. The problem is that
there are MANY possible 4 megapixel pictures worth looking at. As
such, the correct question has little to do with the total number of
possiblities, and a great deal to do with the _percentage_ that are
worth looking at -- if 90% of the possible outputs qualified as art,
then random generation would typically do the job in a few seconds.
If, OTOH, only one in 2^256 arrangements is worth looking at, then the
chances of producing something interesting before the second law of
thermodynamics has its ultimate triumph are slim indeed.
The fact remains, that regardless of how unlikely it is (and I'll
openly grant that it's extremely unlikely), even the most remote
possibility is still better than none at all.
--
Later,
Jerry.
The universe is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) writes:
> Pascal Bourguignon <····@mouse-potato.com> wrote in message news:<··············@naiad.informatimago.com>...
>
> [ ... ]
>
> > It depends in what universe.
> >
> > There are: (expt (expt 2 24) (expt 2 22)) 4-Mpixel 24-bit color
> > pictures. That's about (expt 10 30000000) Since there's only about
> > (expt 10 17) seconds in the universe (or at most (expt 10 19)), you
> > just DON'T have sufficient time. That's why you need to be scient
> > to produce something worth looking at.
>
> While you're math is correct, it's only distantly related to the right
> math to do. Basically, your math would be right IF you were talking
> about randomly producing one specific output. The problem is that
> there are MANY possible 4 megapixel pictures worth looking at. As
> such, the correct question has little to do with the total number of
> possiblities, and a great deal to do with the _percentage_ that are
> worth looking at -- if 90% of the possible outputs qualified as art,
> then random generation would typically do the job in a few seconds.
> If, OTOH, only one in 2^256 arrangements is worth looking at, then the
> chances of producing something interesting before the second law of
> thermodynamics has its ultimate triumph are slim indeed.
>
> The fact remains, that regardless of how unlikely it is (and I'll
> openly grant that it's extremely unlikely), even the most remote
> possibility is still better than none at all.
The number of pictures retained in museums is closer to 1 than to any
number that would invalidate my "math".
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Pascal Bourguignon <····@mouse-potato.com> wrote in message news:<··············@thalassa.informatimago.com>...
[ ... ]
> The number of pictures retained in museums is closer to 1 than to any
> number that would invalidate my "math".
So you figure if it's not already in a museum, it can't be art?
By that theory, you've just proven that that program in question can't
possibly create art.
The bottom line is that your math is wrong and your conclusion is
wrong. A positive number, no matter how infinitesimal, is still, by
definition, greater than zero. IOW, no matter how tiny the improvement
might be, it's an improvement nonetheless.
--
Later,
Jerry.
The universe is a figment of its own imagination.
From: Christopher C. Stacy
Subject: Re: Parameterized Picture (was: C++ sucks for games)
Date:
Message-ID: <uactlaqzc.fsf@news.dtpq.com>
·······@taeus.com (Jerry Coffin) writes:
> Pascal Bourguignon <····@mouse-potato.com> wrote in message news:<··············@thalassa.informatimago.com>...
>
> [ ... ]
>
> > The number of pictures retained in museums is closer to 1 than to any
> > number that would invalidate my "math".
>
> So you figure if it's not already in a museum, it can't be art?
Approximately.
(This begs the question of whether a computer can produce art.)
Christopher C. Stacy wrote:
> ·······@taeus.com (Jerry Coffin) writes:
>
> > So you figure if it's not already in a museum, it can't be art?
>
> Approximately.
>
> (This begs the question of whether a computer can produce art.)
Sounds more like the question is "what is art?", which is much harder
to define :) Given a narrow view of what art is, certainly a computer
could produce it.
Jeff M.
--
(surf-to "http://www.retrobyte.org/")
In article <···························@posting.google.com>,
·······@taeus.com says...
> Pascal Bourguignon <····@mouse-potato.com> wrote in message news:<··············@naiad.informatimago.com>...
>
> > There are: (expt (expt 2 24) (expt 2 22)) 4-Mpixel 24-bit color
> > pictures. That's about (expt 10 30000000) Since there's only about
> > (expt 10 17) seconds in the universe (or at most (expt 10 19)), you
> > just DON'T have sufficient time. That's why you need to be scient
> > to produce something worth looking at.
>
> While you're math is correct, it's only distantly related to the right
> math to do. Basically, your math would be right IF you were talking
> about randomly producing one specific output. The problem is that
> there are MANY possible 4 megapixel pictures worth looking at. As
> such, the correct question has little to do with the total number of
> possiblities, and a great deal to do with the _percentage_ that are
> worth looking at -- if 90% of the possible outputs qualified as art,
> then random generation would typically do the job in a few seconds.
> If, OTOH, only one in 2^256 arrangements is worth looking at, then the
> chances of producing something interesting before the second law of
> thermodynamics has its ultimate triumph are slim indeed.
I think the notion that even as many as one in 2^256 could conceivably
be worth looking at indicates a poor feel for the 'law of large
numbers' as applied to cases like this.
For an easier example to analyse, consider the set of all books 4
million characters long. What proportion are worth reading?
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> wrote in message news:<··························@news.indigo.ie>...
[ ... ]
> > If, OTOH, only one in 2^256 arrangements is worth looking at, then the
> > chances of producing something interesting before the second law of
> > thermodynamics has its ultimate triumph are slim indeed.
>
> I think the notion that even as many as one in 2^256 could conceivably
> be worth looking at indicates a poor feel for the 'law of large
> numbers' as applied to cases like this.
What part of "second law of thermodynamics has its ultimate triumph"
didn't you understand? The _ultimate_ triumph of the second law of
thermodynamics is when all the energy in the universe reaches
equilibrium...
IOW, when I cited 2^256, it was intended as a constrast, not as
something that was conceivably worth searching -- rather the contrary,
I cited it as something that was obviously ridiculous to even
consider.
As far as cases like this go, the basic problem is somewhat similar to
breaking encryption by exhausting the key-space. If you honestly care
about whether I have a feel for the subject matter, feel free to read
through my old posts on sci.crypt -- and even if you don't care much
about my feel for things, some of it is worth reading in its own right
-- darned little of it though... :-)
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
[Sashank Varma:]
> > If a formal model of painting is possible, then it
> > will be a parameterized function of some kind. The
> > point is this guy has produced the best such
> > parameterized function in existence, and he did it
> > in Lisp.
[Jerry:]
> This is clearly a long ways from the best that's ever been done. A
> program that simply generates and draws totally random pixels is
> obviously better -- given sufficient time, it'll inevitably produce
> something worth looking at, whereas it seems fairly clear that this
> program has been written in such a way that it can never produce
> anything artistic, even by accident.
>
> Despite a lack of formal proof, it seems likely to me that anybody who
> can concieve the phrase "formal model of painting" (not to mention
> trying to create such a thing) is probably incapable of recognizing
> art when he sees it.
Well, Harold Cohen was a pretty eminent artist before he
started working on AARON. He's a professor at UCSD. It's
possible that he's "incapable of recognizing art when he
sees it", but it doesn't seem very plausible.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> Jerry Coffin wrote:
>
> [Sashank Varma:]
>
>>>If a formal model of painting is possible, then it
>>>will be a parameterized function of some kind. The
>>>point is this guy has produced the best such
>>>parameterized function in existence, and he did it
>>>in Lisp.
>
>
> [Jerry:]
>
>>This is clearly a long ways from the best that's ever been done. A
>>program that simply generates and draws totally random pixels is
>>obviously better -- given sufficient time, it'll inevitably produce
>>something worth looking at, whereas it seems fairly clear that this
>>program has been written in such a way that it can never produce
>>anything artistic, even by accident.
>>
>>Despite a lack of formal proof, it seems likely to me that anybody who
>>can concieve the phrase "formal model of painting" (not to mention
>>trying to create such a thing) is probably incapable of recognizing
>>art when he sees it.
>
>
> Well, Harold Cohen was a pretty eminent artist before he
> started working on AARON. He's a professor at UCSD. It's
> possible that he's "incapable of recognizing art when he
> sees it", but it doesn't seem very plausible.
And Aaron's work shows a strong relationship to Cohen's work, which
should be no surprise. Aaron might be regarded as a surprisingly
successful attempt by an artist to automate some part of his process of
invention and discovery.
As for its merits as art, it seems likely that some folks just don't
like Cohen's work.
Gareth McCaughan <················@pobox.com> wrote in message news:<··············@g.mccaughan.ntlworld.com>...
[ ... ]
> Well, Harold Cohen was a pretty eminent artist before he
> started working on AARON. He's a professor at UCSD. It's
> possible that he's "incapable of recognizing art when he
> sees it", but it doesn't seem very plausible.
Rather the contrary. IMO, being recognized as an "eminent artist"
among academia (at least at the presnt time) is nearly a guarantee of
exactly the opposite.
The fact is that if my preschool nephew had painted one of these, I'd
consider it fair -- but I definitely expect (and see) better out of
his 9 year-old brother.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
[I said:]
>> Well, Harold Cohen was a pretty eminent artist before he
>> started working on AARON. He's a professor at UCSD. It's
>> possible that he's "incapable of recognizing art when he
>> sees it", but it doesn't seem very plausible.
>
> Rather the contrary. IMO, being recognized as an "eminent artist"
> among academia (at least at the presnt time) is nearly a guarantee of
> exactly the opposite.
Not only among academia; also among practising artists.
> The fact is that if my preschool nephew had painted one of these, I'd
> consider it fair -- but I definitely expect (and see) better out of
> his 9 year-old brother.
Clearly you don't care for AARON's alleged art. Neither,
for what it's worth, do I. But I'm not going to claim on
that ground that Cohen is incompetent; in so far as artistic
ability is assessable on any basis other than "well, I
don't like *that*", Cohen is someone whose judgement is
worth respecting.
--
Gareth McCaughan
.sig under construc
·······@taeus.com (Jerry Coffin) writes:
> Gareth McCaughan <················@pobox.com> wrote in message news:<··············@g.mccaughan.ntlworld.com>...
>
> [ ... ]
>
> > Well, Harold Cohen was a pretty eminent artist before he
> > started working on AARON. He's a professor at UCSD. It's
> > possible that he's "incapable of recognizing art when he
> > sees it", but it doesn't seem very plausible.
>
> Rather the contrary. IMO, being recognized as an "eminent artist"
> among academia (at least at the presnt time) is nearly a guarantee of
> exactly the opposite.
>
> The fact is that if my preschool nephew had painted one of these, I'd
> consider it fair -- but I definitely expect (and see) better out of
> his 9 year-old brother.
Where the current Aaron excels is in the area of color, which is not
unexpected as that is what Harold Cohen was famous for in the 1960s
(in fact, in one incident a curator who had lost track of Cohen after
he moved to the States recognized a drawing of Aaron's as Cohen's
before the painter was revealed to her). Cohen has never been too
concerned about representation in his work (all it would do is clutter
Aaron's knowledge base with irrelevant details) but with more
fundamental problems of composition (most of his paintings are
actually far less representational than what Aaron does).
I think you (and most other people in this thread, too) could really
benefit from a remedial art class or two.
Vladimir
···@zedat.fu-berlin.de (Stefan Ram) writes:
> To write a good chess program, I suppose, one does not have to
> be a good chess player, more a good programmer. An AI chess
> program is "opaque", it does not play chess like its author
> would do, so one can not see the chess-playing style of its
> author "trough it".
No, but it does play endgames like those stored in it's database by
the programmer. The difference between chess and art is that the
former is a formal system (in fact, I don't think it is incorrect to
think of a chess game as one path in a non-deterministic serial
cellular automaton with very weird rules, but then again maybe I'm
reading into ANKOS too much). Others have pointed out that you can
generate art (and anything and everything else, really) by randomly
flipping bits in a bitmap (from what I can tell, Aaron works in a
scale-independent representation, but let's consider only this
representation of the final product), but there is a threshold
difference - the board is so large that a "tree search" to make
pictures is wholly unfeasible (but of course if you can come up with a
decision criterion for "art," you've certainly accomplished
something!).
> >(in fact, in one incident a curator who had lost track of Cohen
> >after he moved to the States recognized a drawing of Aaron's as
> >Cohen's before the painter was revealed to her).
>
> Possibly, because the program was not capable to develope
> something new.
Something I recall about that incident now (I read about it in Pamela
McCorduck's _Aaron's Code_) is that it happened sometime in the 70s,
back when Cohen hand-colored Aaron's drawings. He is a very distinct
colorist, and in that sense I guess it did limit the style of Aaron's
output more than it's database of subject representations.
> In the same sense, an A.I. program will not just be an
> implementation of the style, ideas or thoughts of his creator,
> but rather be an open system with an own memory, being able to
> interact, evolve and to create something new.
Well, by those criteria, no one has managed to make anything close to
an AI program in any field and likely won't for the foreseeable
future. What Harold Cohen has done (and what I think AI is really all
about, despite the current trend in connectionism) is make explicit
the rules for "making art," at least in a style similar to his own. To
go back to the chess issue for an example, I read a book called
_Blondie24_, where the authors described how they trained a
modest-sized neural network to play moderately well at checkers
(except for the endgames, oops!), then go on to hype connectionism and
how all these "self-learning" (note that they stopped training the
system when they put it into play against real opponents) systems are
the future. Not that this was hot news or anything (the book was
published in 1999), but of course they don't know _how_ (or even
really why) the network works. About the only thing close to research
they did in the book was observe (and perpetrate) gender role-play on
checkers websites (hence the name of the book). Anyway, to close my
"Perl Harbor sucked and I miss you" rant, if you want "an open system
with an own memory, being able to interact, evolve and to create
something new," you're out of luck.
Vladimir
In article <···························@posting.google.com>,
·······@taeus.com says...
> Sashank Varma <····@vanderbilt.edu> wrote in message news:<··························@news.vanderbilt.edu>...
> > You have a real problem facing discomfirming evidence.
>
> You seem to have a real problem facing logic. It's true that
> well-written programs can produce garbage output (typically when given
> bad input). It's also true that this program produces garbage output.
That is rather harsh. As I said earlier, AARON seems to show some
capability in the realm of overall picture composition, which is a
separate issue from the parameterised drawings.
As to whether it is art, my own view is that AARON itself can certainly
be considered a piece of conceptual art, whatever about its works. I
don't think they qualify.
My Brewster screensaver is effectively based on parameterised functions,
and it frequently produces very beautiful images. But I don't consider
them to be art.
Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> As to how long it took (and presumably according to the Lisp boosters
> his thirty years of work are equivalent to about 150 years of C++), I
> don't see that it matters much.
Note that it's almost 40 years now, and for most of those Aaron has
been written in C. Cohen began the current version of Aaron in 1988 (I
think), partly because a colleauge strongly recommended Lisp to him,
and partly because TI gave him an Explorer Lisp machine that he wanted
to get some use out of. Not long after, he was raving about how Lisp
enabled him to finally tackle color, something that he had been
putting off for more than a decade because of the complexity. He was
still finding opportunities for plugging Lisp in a recent talk he gave
at the Tate:
http://www.tate.org.uk/onlineevents/live/cohen.jsp
If you want to learn more about Aaron's history (if for nothing else
than finding something to criticize about Aaron that hasn't been done
to death 20 years ago) pick up a copy of Pamela McCorduck's _Aaron's
Code_.
Vladimir
On Tue, 9 Nov 2004 10:49:25 -0000, Gerry Quinn wrote:
> In article <········@duster.adelaide.on.net>, ······@internode.on.net
> says...
>>
>> Cool. I think this thread is being fuelled heavily by the cross posting.
>> Since it is also in comp.games, you'll get a lot of posts from people like
>> me that are not satisfied unless we here from someone who has shipped a 10
>> month project with 7+ programmers on a console title in Lisp.
>
> Heck, I've only asked for pointers to a few little Windows games or
> screensavers similar to my own!
Here's the source to the game Concetration. I wrote it a few days ago
for my daughter... Note that it's not production code, just a couple of
hours fun project (I added a comment or two for you.)
http://www.naunton.us/michael/cl/concentration.lisp
> Gerry Quinn
> http://bindweed.com
> Games, Kaleidoscopes, Screensavers
In article <··················@micron.bellatlantic.net>,
···@news.bellatlantic.net says...
> On Tue, 9 Nov 2004 10:49:25 -0000, Gerry Quinn wrote:
> > Heck, I've only asked for pointers to a few little Windows games or
> > screensavers similar to my own!
>
> Here's the source to the game Concetration. I wrote it a few days ago
> for my daughter... Note that it's not production code, just a couple of
> hours fun project (I added a comment or two for you.)
>
> http://www.naunton.us/michael/cl/concentration.lisp
Just for pig-iron, I wrote a clone in C++ today, based on your
description (I can't run yours). Took about the same time! Likewise,
it's not production code (in particular, it will crash if it's given no
images at all - I should have fixed that at least).
The two might be an interesting comparison for readers of the thread.
My version is for an MFC dialog app. I left out most of the AppWizard-
generated boiler plate i.e. a CWinApp-derived class whose files I didn't
open at all, and a CDialog-derived class where I only added code to one
function. All my actual code is in the text file:
http://bindweed.com/misc/concen-src.txt
There is some bitmap-twiddling done by my DibDC class (not included),
but your version makes external calls to do the same thing, so I figure
that's fair.
I was surprised to find it is actually shorter than the Lisp version in
terms of characters, though it has more lines (a lot have just one curly
bracket). I was sure it would be longer, especially since I did some
things in quite a roundabout and repetitive way.
Those who want can download the 148 KB Windows executable from:
http://bindweed.com/misc/Concen.exe
Just pop it into a directory along with some .bmp files of any size
(there must be at least one or it will crash). It's quite fun! When
you've solved the puzzle, you have to close it and run it again for
another. Perhaps I'll tidy it up a bit, add a few options and sfx and
release it as a freeware...
Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers
On Thu, 11 Nov 2004 01:56:48 -0000, Gerry Quinn wrote:
> In article <··················@micron.bellatlantic.net>,
> ···@news.bellatlantic.net says...
>> On Tue, 9 Nov 2004 10:49:25 -0000, Gerry Quinn wrote:
>
>> > Heck, I've only asked for pointers to a few little Windows games or
>> > screensavers similar to my own!
>>
>> Here's the source to the game Concetration. I wrote it a few days ago
>> for my daughter... Note that it's not production code, just a couple of
>> hours fun project (I added a comment or two for you.)
>>
>> http://www.naunton.us/michael/cl/concentration.lisp
>
> Just for pig-iron, I wrote a clone in C++ today, based on your
> description (I can't run yours). Took about the same time! Likewise,
> it's not production code (in particular, it will crash if it's given no
> images at all - I should have fixed that at least).
Thanks for taking the time to do this: it was interesting to look at
your version. My original code also failed with no images -- I added
a test to drop to the debugger in that case right before posting the
code.
> The two might be an interesting comparison for readers of the thread.
> My version is for an MFC dialog app. I left out most of the AppWizard-
> generated boiler plate i.e. a CWinApp-derived class whose files I didn't
> open at all, and a CDialog-derived class where I only added code to one
> function. All my actual code is in the text file:
> http://bindweed.com/misc/concen-src.txt
>
> There is some bitmap-twiddling done by my DibDC class (not included),
> but your version makes external calls to do the same thing, so I figure
> that's fair.
Seems fair to me.
> I was surprised to find it is actually shorter than the Lisp version in
> terms of characters, though it has more lines (a lot have just one curly
> bracket). I was sure it would be longer, especially since I did some
> things in quite a roundabout and repetitive way.
Note that one third of the Lisp code implements a simple event loop
(code to call a redraw function and a user-input function.) I included
it for completeness, but it's just library code like your MFC framework.
I think, anyway, correct me if I'm wrong.
> Those who want can download the 148 KB Windows executable from:
> http://bindweed.com/misc/Concen.exe
This is a clear win for the Win/C++ code: providing a Linux/Lisp
executable would be 10 times the size. This is the classic exe vs.
big runtime environment issue.
> Just pop it into a directory along with some .bmp files of any size
> (there must be at least one or it will crash). It's quite fun! When
> you've solved the puzzle, you have to close it and run it again for
> another. Perhaps I'll tidy it up a bit, add a few options and sfx and
> release it as a freeware...
Hehe, I quite agree with you here: as dumb as the game is, it's
actually fun to play: I've actually played it several times over the
past few days. Ah, the satisfaction of getting a tile right when you're
not quite sure :)
I have a couple of questions about extensions to this problem, e.g:
o Make it a two player gmae (i.e. fail to flip a pair and the other
player gets to turn card.)
o Make it a net game (serve over http?)
It seems to me that the first case can be handled well by just hacking
code, but the seond case requires a major rewrite (we're using a code
generator, and must add our code to its framework as text.)
Regards,
-- MMN
Michael Naunton <···@news.bellatlantic.net> writes:
> On Thu, 11 Nov 2004 01:56:48 -0000, Gerry Quinn wrote:
...
> > Those who want can download the 148 KB Windows executable from:
> > http://bindweed.com/misc/Concen.exe
>
> This is a clear win for the Win/C++ code: providing a Linux/Lisp
> executable would be 10 times the size. This is the classic exe vs.
> big runtime environment issue.
Funny, the 148 KB executable fails run on my computer.
Oh, you mean I need to install the big Microsoft Windows and MFC
runtime environment first, and only then can I run the 148 KB
executable on top of that?
And how does this differ from first installing a big Lisp runtime
environment, and then running a small fasl file on top of that?
All this alludes to, is that more computers have some C++ runtime
support installed on them by default, than is the case for Lisp.
In article <··················@micron.bellatlantic.net>,
···@news.bellatlantic.net says...
> On Thu, 11 Nov 2004 01:56:48 -0000, Gerry Quinn wrote:
> >
> > Just for pig-iron, I wrote a clone in C++ today, based on your
> > description (I can't run yours). Took about the same time! Likewise,
> > it's not production code (in particular, it will crash if it's given no
> > images at all - I should have fixed that at least).
>
> Thanks for taking the time to do this: it was interesting to look at
> your version. My original code also failed with no images -- I added
> a test to drop to the debugger in that case right before posting the
> code.
I had an ASSERT, but did not bother to convert it into a run-time
test...
> > I was surprised to find it is actually shorter than the Lisp version in
> > terms of characters, though it has more lines (a lot have just one curly
> > bracket). I was sure it would be longer, especially since I did some
> > things in quite a roundabout and repetitive way.
>
> Note that one third of the Lisp code implements a simple event loop
> (code to call a redraw function and a user-input function.) I included
> it for completeness, but it's just library code like your MFC framework.
> I think, anyway, correct me if I'm wrong.
Yes, they are both about the same size anyway. There's still some auto-
generated stuff in mine as well.
> > Those who want can download the 148 KB Windows executable from:
> > http://bindweed.com/misc/Concen.exe
>
> This is a clear win for the Win/C++ code: providing a Linux/Lisp
> executable would be 10 times the size. This is the classic exe vs.
> big runtime environment issue.
Probably not an issue for Lisp nowadays, as 1.5MB for a downloadable
executable is still nothing.
> > Just pop it into a directory along with some .bmp files of any size
> > (there must be at least one or it will crash). It's quite fun! When
> > you've solved the puzzle, you have to close it and run it again for
> > another. Perhaps I'll tidy it up a bit, add a few options and sfx and
> > release it as a freeware...
>
> Hehe, I quite agree with you here: as dumb as the game is, it's
> actually fun to play: I've actually played it several times over the
> past few days. Ah, the satisfaction of getting a tile right when you're
> not quite sure :)
>
> I have a couple of questions about extensions to this problem, e.g:
>
> o Make it a two player gmae (i.e. fail to flip a pair and the other
> player gets to turn card.)
> o Make it a net game (serve over http?)
>
> It seems to me that the first case can be handled well by just hacking
> code, but the seond case requires a major rewrite (we're using a code
> generator, and must add our code to its framework as text.)
I think the first would be a good opportunity to refactor the code a
bit. It's about as hacky as I like to get now (look at my nasty 'tree'
of if..else statements). Putting in two or more well-defined 'player'
objects that can provide input to the 'game controller' in a standard
format would be easy enough. And then we see that the game controller
is actually a server, and the clients don't need to be local. So we are
on the right road to an internet game!
Another idea is a version in which you have to flip three at a time
(more would be overkill). This would be trivial to implement. (In fact
I'd lose a member variable, as m_FirstPick and m_SecondPick would join a
vector of picks.)
Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers
In article <··················@micron.bellatlantic.net>,
···@news.bellatlantic.net says...
> On Thu, 11 Nov 2004 01:56:48 -0000, Gerry Quinn wrote:
> >
> > Just for pig-iron, I wrote a clone in C++ today, based on your
> > description (I can't run yours). Took about the same time! Likewise,
> > it's not production code (in particular, it will crash if it's given no
> > images at all - I should have fixed that at least).
>
> Thanks for taking the time to do this: it was interesting to look at
> your version. My original code also failed with no images -- I added
> a test to drop to the debugger in that case right before posting the
> code.
I had an ASSERT, but did not bother to convert it into a run-time
test...
> > I was surprised to find it is actually shorter than the Lisp version in
> > terms of characters, though it has more lines (a lot have just one curly
> > bracket). I was sure it would be longer, especially since I did some
> > things in quite a roundabout and repetitive way.
>
> Note that one third of the Lisp code implements a simple event loop
> (code to call a redraw function and a user-input function.) I included
> it for completeness, but it's just library code like your MFC framework.
> I think, anyway, correct me if I'm wrong.
Yes, they are both about the same size anyway. There's still some auto-
generated stuff in mine as well.
> > Those who want can download the 148 KB Windows executable from:
> > http://bindweed.com/misc/Concen.exe
>
> This is a clear win for the Win/C++ code: providing a Linux/Lisp
> executable would be 10 times the size. This is the classic exe vs.
> big runtime environment issue.
Probably not an issue for Lisp nowadays, as 1.5MB for a downloadable
executable is still nothing.
> > Just pop it into a directory along with some .bmp files of any size
> > (there must be at least one or it will crash). It's quite fun! When
> > you've solved the puzzle, you have to close it and run it again for
> > another. Perhaps I'll tidy it up a bit, add a few options and sfx and
> > release it as a freeware...
>
> Hehe, I quite agree with you here: as dumb as the game is, it's
> actually fun to play: I've actually played it several times over the
> past few days. Ah, the satisfaction of getting a tile right when you're
> not quite sure :)
>
> I have a couple of questions about extensions to this problem, e.g:
>
> o Make it a two player gmae (i.e. fail to flip a pair and the other
> player gets to turn card.)
> o Make it a net game (serve over http?)
>
> It seems to me that the first case can be handled well by just hacking
> code, but the seond case requires a major rewrite (we're using a code
> generator, and must add our code to its framework as text.)
I think the first would be a good opportunity to refactor the code a
bit. It's about as hacky as I like to get now (look at my nasty 'tree'
of if..else statements). Putting in two or more well-defined 'player'
objects that can provide input to the 'game controller' in a standard
format would be easy enough. And then we see that the game controller
is actually a server, and the clients don't need to be local. So we are
on the right road to an internet game!
Another idea is a version in which you have to flip three at a time
(more would be overkill). This would be trivial to implement. (In fact
I'd lose a member variable, as m_FirstPick and m_SecondPick would join a
vector of picks.)
Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, Screensavers
Maahes <······@internode.on.net> wrote:
> > 3. Bauhaus was the second Lisp-based version of the Newton operating
> > system, also written in Ralph (a third version, written in C++ and
> > NewtonScript, and chosen for non-technical reasons, was the one shipped).
> > It was a five-person, two-year project.
[...]
> Also, it doesn't help the case when you here that the version of Bauhaus
> that shipped was a C++ version... why would you even consider writing a C++
> version when you've already got 2 versions written in Lisp, which is
> supposed to be a far better language...
What part of "chosen for non-technical reasons" did you have trouble
understanding?
Michael
>> > 3. Bauhaus was the second Lisp-based version of the Newton operating
>> > system, also written in Ralph (a third version, written in C++ and
>> > NewtonScript, and chosen for non-technical reasons, was the one
>> > shipped).
>> > It was a five-person, two-year project.
>
> [...]
>> Also, it doesn't help the case when you here that the version of Bauhaus
>> that shipped was a C++ version... why would you even consider writing a
>> C++
>> version when you've already got 2 versions written in Lisp, which is
>> supposed to be a far better language...
>
> What part of "chosen for non-technical reasons" did you have trouble
> understanding?
>
The part that says what the non-technical reasons where.
Maahes wrote:
>>>>3. Bauhaus was the second Lisp-based version of the Newton operating
>>>>system, also written in Ralph (a third version, written in C++ and
>>>>NewtonScript, and chosen for non-technical reasons, was the one
>>>>shipped).
>>>>It was a five-person, two-year project.
>>
>>[...]
>>
>>>Also, it doesn't help the case when you here that the version of Bauhaus
>>>that shipped was a C++ version... why would you even consider writing a
>>>C++
>>>version when you've already got 2 versions written in Lisp, which is
>>>supposed to be a far better language...
>>
>>What part of "chosen for non-technical reasons" did you have trouble
>>understanding?
>>
>
>
> The part that says what the non-technical reasons where.
Presumably, my reply that gave those reasons solved that problem.
"mikel" <·····@evins.net> wrote in message
·························@newssvr21.news.prodigy.com...
> Maahes wrote:
>>>>>3. Bauhaus was the second Lisp-based version of the Newton operating
>>>>>system, also written in Ralph (a third version, written in C++ and
>>>>>NewtonScript, and chosen for non-technical reasons, was the one
>>>>>shipped).
>>>>>It was a five-person, two-year project.
>>>
>>>[...]
>>>
>>>>Also, it doesn't help the case when you here that the version of Bauhaus
>>>>that shipped was a C++ version... why would you even consider writing a
>>>>C++
>>>>version when you've already got 2 versions written in Lisp, which is
>>>>supposed to be a far better language...
>>>
>>>What part of "chosen for non-technical reasons" did you have trouble
>>>understanding?
>>>
>>
>>
>> The part that says what the non-technical reasons where.
>
> Presumably, my reply that gave those reasons solved that problem.
yep
"Maahes" <······@internode.on.net> writes:
> For protecting your implementation from the other programmers.
> If you don't protect your variables and strictly define your interfaces, and
> limit their power, you'll find the other programmers will completely
> misusing your code. Then when you go to rewrite it to provide new features,
> you'll find you can't because all the variables you want to trash are being
> used in critical parts of multiple projects.
Don't you document your code?
Even without documentation, Lisp does this fine. Stuff that's marked as
internal-only (prefixed with % or %% if it's really internal to the
implementation) and/or unexported from the library's package (needs to
be accessed with a double colon instead of a single one from the
outside) is stuff that isn't guaranteed to be stable, or at least won't
be announced as a change.
If you are using symbols like these from someone else's code, you
obviously know what you're doing and need to mess with the internals of
the library. You'll know to pay close attention to that code breaking
when you upgrade.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>> For protecting your implementation from the other programmers.
>> If you don't protect your variables and strictly define your interfaces,
>> and
>> limit their power, you'll find the other programmers will completely
>> misusing your code. Then when you go to rewrite it to provide new
>> features,
>> you'll find you can't because all the variables you want to trash are
>> being
>> used in critical parts of multiple projects.
>
> Don't you document your code?
>
yep, sure do. And I hated private & public and was forced to use them
because people are inherently lazy and will hack your class before asking
for an interface to do what they want unless you stop them.
On Mon, 1 Nov 2004, Gerry Quinn wrote:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > > To what percentage of programmers are such things relevant?
> >
> > Programmers who want high performance numeric code. Or programmers who want
> > to write a parser (http://spirit.sourceforge.net/). Both things which game
> > programmers will probably want to do at some point.
>
> Not on this scale. Spirit is part of a library project on the STL
> level. And I suspect game programmers who want maximal numerical
> performance are much more likely to drop to C or ASM than to try
> anything fancy with templates.
>
The ability for Spirit to exist and be used is still important though.
I've made a lot of use of similar libraries in Haskell, and it's looking
likely that this'll lead to a few things I simply couldn't have done with
parser generators.
> My view, perhaps controversial, is that templates are for writing
> libraries that will see massive re-use. Day-to-day programming will use
> such libraries, but day-to-day programming should not involve writing
> templates. I would go so far as to say that most professional C++
> programmers should never have to write template code at all, except for
> their own education and amusement. And that's basic template code, not
> elaborations on it.
>
I do have use for parametric types in my day-to-day programming, but then
I don't have to do any extra work for the parametricity. I'm tempted to
agree with you as far as day-to-day C++ goes though.
--
······@flippac.org
>> Programmers who want high performance numeric code. Or programmers who
>> want to write a parser (http://spirit.sourceforge.net/). Both things
>> which game programmers will probably want to do at some point.
>
> Not on this scale. Spirit is part of a library project on the STL
> level. And I suspect game programmers who want maximal numerical
> performance are much more likely to drop to C or ASM than to try
> anything fancy with templates.
Expression templates tend to produce faster code, unless you want to write
out all your matrix multiplications, etc. out long had. Also, you can
combine expression templates with various loop unrolling tricks using
metaprogramming. (Personally I wouldn't do anything so vile -- I'd use
Lisp ;) I totally agree that in the best case, this nasty stuff is kept
fenced off in a library.
> My view, perhaps controversial, is that templates are for writing
> libraries that will see massive re-use. Day-to-day programming will use
> such libraries, but day-to-day programming should not involve writing
> templates. I would go so far as to say that most professional C++
> programmers should never have to write template code at all, except for
> their own education and amusement. And that's basic template code, not
> elaborations on it.
I don't agree, although I see your point. For me, C++ is just unusable
without templates. But this is probably because I'm used to languages with
proper static type systems, like ML and Haskell.
> When I wrote that I HAD done a smidgeon of research, and my impression
> was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> look. They are built with Lisp macros, no doubt for ideological reasons
> - perhaps as a consequence they seem to lack things we might expect such
> as access specifiers. That's why I wrote what I did.
They're less bolted on than C++ classes (for example you can write generic
functions dispatching on built in types). It's probably possible to write a
CLOS implementation solely using macros, but as far as I know most
implementations support CLOS more directly. In what sense do classes lack
access specifiers? There's no public/private/protected as such (although
you have the option for read-only access, etc.) but that's not because
these constructs couldn't be implemented in Lisp; it's just a design
decision of CLOS. CLOS isn't based on the C++/Simula model of OO.
Alex
Gerry Quinn wrote:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>> >> I can't buy the first sentence. What about the performance advantages
>> >> of, say, epxression templates for matrix arithmetic. Sounds sensible
>> >> enough to me.
>> >
>> > To what percentage of programmers are such things relevant?
>>
>> Programmers who want high performance numeric code. Or programmers who
>> want to write a parser (http://spirit.sourceforge.net/). Both things
>> which game programmers will probably want to do at some point.
>
> Not on this scale. Spirit is part of a library project on the STL
> level. And I suspect game programmers who want maximal numerical
> performance are much more likely to drop to C or ASM than to try
> anything fancy with templates.
>
> My view, perhaps controversial, is that templates are for writing
> libraries that will see massive re-use. Day-to-day programming will use
> such libraries, but day-to-day programming should not involve writing
> templates. I would go so far as to say that most professional C++
> programmers should never have to write template code at all, except for
> their own education and amusement. And that's basic template code, not
> elaborations on it.
>
>> >> The development environment may well have been object-based. Do you
>> >> know whether or not the Lisp dialect the used was OO?
>> >
>> > You know, from the description of Common Lisp, it's hard to tell!
>>
>> GOAL is not Common Lisp. You should know that Common Lisp supports OO if
>> you've done even a smidgen of research. In fact it was the /first/ ANSI
>> standardised OO language. So in terms of being standard and being OO, it
>> pretty much beats C++.
>
> When I wrote that I HAD done a smidgeon of research, and my impression
> was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> look. They are built with Lisp macros, no doubt for ideological reasons
> - perhaps as a consequence they seem to lack things we might expect such
> as access specifiers. That's why I wrote what I did.
>
> - Gerry Quinn
In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
> > When I wrote that I HAD done a smidgeon of research, and my impression
> > was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> > look. They are built with Lisp macros, no doubt for ideological reasons
> > - perhaps as a consequence they seem to lack things we might expect such
> > as access specifiers. That's why I wrote what I did.
>
> They're less bolted on than C++ classes (for example you can write generic
> functions dispatching on built in types). It's probably possible to write a
> CLOS implementation solely using macros, but as far as I know most
> implementations support CLOS more directly. In what sense do classes lack
> access specifiers? There's no public/private/protected as such (although
> you have the option for read-only access, etc.) but that's not because
> these constructs couldn't be implemented in Lisp; it's just a design
> decision of CLOS. CLOS isn't based on the C++/Simula model of OO.
That seems clear. May it be assumed it does not claim to possess the
advantages of the C++/Simula model of OO?
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> That seems clear. May it be assumed it does not claim to possess the
> advantages of the C++/Simula model of OO?
The perceived advantages of the C++ model are rather dubious. CL
certainly does not claim to possess many of the disadvantages of that
system. The C++ model is far too static to be acceptable to Lisp (and
Smalltalk) programmers. And "data-hiding" (notice that I did not say
encapsulation) is antithetical to the general Lisp philosophy, which
is about open-ness, introspection, and empowering the programmer.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish wrote:
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
>>That seems clear. May it be assumed it does not claim to possess the
>>advantages of the C++/Simula model of OO?
>
>
> The perceived advantages of the C++ model are rather dubious. CL
> certainly does not claim to possess many of the disadvantages of that
> system. The C++ model is far too static to be acceptable to Lisp (and
> Smalltalk) programmers. And "data-hiding" (notice that I did not say
> encapsulation) is antithetical to the general Lisp philosophy, which
> is about open-ness, introspection, and empowering the programmer.
One point that should be emphasized: Common Lisp's standard object
system is the default (rather than the only) object system available.
Lispers seem to have reached consensus that it represents the best
design for general use. Since the object system is just more Lisp code,
people who desire C++ style semantics, or indeed any other style they
can dream up, can write or acquire an object system that suits them.
Contrast this with C++, where the object system is factory installed and
not user serviceable.
--
Cameron MacKinnon
Toronto, Canada
In article <······················@golden.net>, ··········@clearspot.net
says...
> Matthew Danish wrote:
> One point that should be emphasized: Common Lisp's standard object
> system is the default (rather than the only) object system available.
> Lispers seem to have reached consensus that it represents the best
> design for general use. Since the object system is just more Lisp code,
> people who desire C++ style semantics, or indeed any other style they
> can dream up, can write or acquire an object system that suits them.
>
> Contrast this with C++, where the object system is factory installed and
> not user serviceable.
The trouble is, Lisp-ers don't always seem to understand why the above
is far from being an un-alloyed good.
- Gerry Quinn
In article <··············@mapcar.org>, ··········@cmu.edu says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > That seems clear. May it be assumed it does not claim to possess the
> > advantages of the C++/Simula model of OO?
>
> The perceived advantages of the C++ model are rather dubious. CL
> certainly does not claim to possess many of the disadvantages of that
> system. The C++ model is far too static to be acceptable to Lisp (and
> Smalltalk) programmers. And "data-hiding" (notice that I did not say
> encapsulation) is antithetical to the general Lisp philosophy, which
> is about open-ness, introspection, and empowering the programmer.
I'll take that as a 'yes'.
Gerry Quinn
Gerry Quinn wrote:
> In article <··············@mapcar.org>, ··········@cmu.edu says...
>> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>> > That seems clear. May it be assumed it does not claim to possess the
>> > advantages of the C++/Simula model of OO?
>>
>> The perceived advantages of the C++ model are rather dubious. CL
>> certainly does not claim to possess many of the disadvantages of that
>> system. The C++ model is far too static to be acceptable to Lisp (and
>> Smalltalk) programmers. And "data-hiding" (notice that I did not say
>> encapsulation) is antithetical to the general Lisp philosophy, which
>> is about open-ness, introspection, and empowering the programmer.
>
> I'll take that as a 'yes'.
>
Can you list a few of those advantages, then?
I'm sure CLOS can do most of the same things, but it would be nice to know
what it lacks. Afterwards, we can do a similar comparison the other way.
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <············@uns-a.ucl.ac.uk>, ··········@ucl.ac.uk says...
>
> > > When I wrote that I HAD done a smidgeon of research, and my impression
> > > was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> > > look. They are built with Lisp macros, no doubt for ideological reasons
> > > - perhaps as a consequence they seem to lack things we might expect such
> > > as access specifiers. That's why I wrote what I did.
> >
> > They're less bolted on than C++ classes (for example you can write generic
> > functions dispatching on built in types). It's probably possible to write a
> > CLOS implementation solely using macros, but as far as I know most
> > implementations support CLOS more directly. In what sense do classes lack
> > access specifiers? There's no public/private/protected as such (although
> > you have the option for read-only access, etc.) but that's not because
> > these constructs couldn't be implemented in Lisp; it's just a design
> > decision of CLOS. CLOS isn't based on the C++/Simula model of OO.
>
> That seems clear. May it be assumed it does not claim to possess the
> advantages of the C++/Simula model of OO?
Whatever advantages the "C++/Simula model" has over the CLOS
model, obviously (and trivially) CLOS doesn't possess. I assume
you're intending to ask a less uninteresting question, but I'm
not sure quite what it is :-). Why don't you mention a few
specific advantages, and then those of us who are familiar
with CLOS can comment on them?
--
Gareth McCaughan
.sig under construc
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> That seems clear. May it be assumed it [Lisp] does not claim to
> possess the advantages of the C++/Simula model of OO?
What "advantages" are you imagining here?
Lisp has 3 different constructs to represent 3 different concepts. C++
has one that tries to be all 3 at once. If you want to use one part and
not the other, you're screwed.
Types are defined using defclass.
Scopes are created using let/lambda.
Namespaces are created using defpackage.
Yes, C++ has namespaces separately, too, but you can't choose to not
inherit the namespace of your superclass. Since you are inheriting scope
as well as type, instance variables are shadowed instead of merged. The
language can't tell whether the name clash was intentional (attempting
to add declarations to the variable - such as making the type
declaration more specific) or unintentional.
In Lisp, you never get stuck in a situation where you want to extend a
type but maintain an independent scope so that variable names don't
clash.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> [.....]
> Types are defined using defclass.
> Scopes are created using let/lambda.
What about PROGV? Does it qualify here? I think it does.
I'm just curious...
Btw, why do you omit FLET?
> Namespaces are created using defpackage.
> [.....]
Regards, Szymon.
Gerry Quinn <······@DELETETHISindigo.ie> wrote
> When I wrote that I HAD done a smidgeon of research, and my impression
> was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> look.
ROFL. CLOS fits seamlessly with non-OOP Lisp. 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. In comparison, only in
recent years has C++ begun to even approach the level of integration
between OOP and non-OOP aspects that CLOS has, but there are still
areas where they just don't mix.
> They are built with Lisp macros, no doubt for ideological reasons
More likely because that's a very good way to build language tools.
> - perhaps as a consequence they seem to lack things we might expect such
> as access specifiers. That's why I wrote what I did.
If there is anything in the Lisp macro system that precludes adding
access specifiers to slots (class members), I'd like to know about it.
In article <····························@posting.google.com>,
·············@swipnet.se says...
> Gerry Quinn <······@DELETETHISindigo.ie> wrote
>
> > When I wrote that I HAD done a smidgeon of research, and my impression
> > was that yes, Common Lisp has classes, but they have a very 'bolted-on'
> > look.
>
> ROFL. CLOS fits seamlessly with non-OOP Lisp. 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. In comparison, only in
> recent years has C++ begun to even approach the level of integration
> between OOP and non-OOP aspects that CLOS has, but there are still
> areas where they just don't mix.
You just don't get it, do you? Object-orientation is about program
architecture as well as language features. It's not about mixing and
matching a multiplicity of 'paradigms'.
Somebody else proposed that everybody design their own object system.
OO as 'language feature' is cargo-cult OO. The bamboo airport looks
just like a real one, but the planes aren't going to land.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> You just don't get it, do you? Object-orientation is about program
> architecture as well as language features. It's not about mixing and
> matching a multiplicity of 'paradigms'.
Oh really? So you shouldn't use imperative code in an OO application?
Interesting.
> Somebody else proposed that everybody design their own object system.
No. Actually, most features can be added to the object system directly,
since it can be extended using itself. If you want something radically
different, sure, you can design your own object system, just like you
can design your own control structure when that makes your program's
intended behavior easier to discern from the code.
> OO as 'language feature' is cargo-cult OO.
Yes, we're not true cultists, sorry. We don't follow the One True Way of
typopace (type/scope/namespace) object orientation in every line of our
code. We'd rather write each section of code in a way that allows that
code to make as much sense and be as maintainable as possible. We're
horrible people.
> The bamboo airport looks just like a real one, but the planes aren't
> going to land.
Except that Lisp's object system is a complete object system, even more
so that C++'s (or Java's for that matter). Even before CLOS, objects had
types and functions/objects could be polymorphic. That's why CLOS can be
implemented as simply a set of macros on top of the older Lisp
features... except for one spot: being able to define new types needs to
be done specifically for each implementation, because this functionality
already existed in older Lisps and CLOS has to integrate completely with
the rest of the type system to be complete.
As I've gone over before, other aspects of the C++ object system that
don't have to do with object orientation are implemented directly and
independently in Lisp.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, ·····@nyct.net says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > You just don't get it, do you? Object-orientation is about program
> > architecture as well as language features. It's not about mixing and
> > matching a multiplicity of 'paradigms'.
>
> Oh really? So you shouldn't use imperative code in an OO application?
> Interesting.
You should write it in its place, and not elsewhere.
> > OO as 'language feature' is cargo-cult OO.
>
> Yes, we're not true cultists, sorry. We don't follow the One True Way of
> typopace (type/scope/namespace) object orientation in every line of our
> code. We'd rather write each section of code in a way that allows that
> code to make as much sense and be as maintainable as possible. We're
> horrible people.
You can be oriented to objects, or oriented to something other than
objects. Your choice. What you can't do is say "here's the OO language
feature, we're not going to use it much but just because it's there our
programs must be object-oriented."
- Gerry Quinn
On Fri, 5 Nov 2004, Gerry Quinn wrote:
> You can be oriented to objects, or oriented to something other than
> objects. Your choice. What you can't do is say "here's the OO language
> feature, we're not going to use it much but just because it's there our
> programs must be object-oriented."
>
Nobody's said that. They've said the /language/ is OO. C++ doesn't have
much of a better claim beyond the fact the type system needed explicit
extension to add OO to it.
--
······@flippac.org
In article <·······························@SLINKY>, ······@flippac.org
says...
> On Fri, 5 Nov 2004, Gerry Quinn wrote:
>
> > You can be oriented to objects, or oriented to something other than
> > objects. Your choice. What you can't do is say "here's the OO language
> > feature, we're not going to use it much but just because it's there our
> > programs must be object-oriented."
> >
> Nobody's said that. They've said the /language/ is OO. C++ doesn't have
> much of a better claim beyond the fact the type system needed explicit
> extension to add OO to it.
The other thing is that people actually DO program C++ in an OO fashion.
Not always, but often enough. Correct me if I'm wrong, but Lisp-ers
give a distinct impression of preferring generic programming.
- Gerry Quinn
On Sat, 6 Nov 2004, Gerry Quinn wrote:
> The other thing is that people actually DO program C++ in an OO fashion.
> Not always, but often enough. Correct me if I'm wrong, but Lisp-ers
> give a distinct impression of preferring generic programming.
>
IM(limited)E, lispers code however they feel is best for the task.
Personally (as a non-lisper but with a related mindset) I often end up
with designs that look like OO designs in the large, I just don't find
traditional OO tools to be a useful means of doing programming in the
small (including the higher-level bits of code). Actually, I'll go a step
further - I don't find traditional OO tools to be a useful means of
analysing much (of my) programming in the small. I find they tend to offer
extensibility in all the wrong places, for example.
One thing I /do/ make a lot of use of is (sub)systems communicating in a
specified language. In fact, a current project has a setup that looks
suspiciously like threads-as-objects for pretty much that reason. Many of
my preferred constructs end up looking pretty close to the duals of OO
constructs, for that matter. Which makes a lot of sense if the traditional
OO constructs seem to be getting everything backwards.
--
······@flippac.org
In article <·······························@SLINKY>, ······@flippac.org
says...
> On Sat, 6 Nov 2004, Gerry Quinn wrote:
>
> > The other thing is that people actually DO program C++ in an OO fashion.
> > Not always, but often enough. Correct me if I'm wrong, but Lisp-ers
> > give a distinct impression of preferring generic programming.
>
> IM(limited)E, lispers code however they feel is best for the task.
> Personally (as a non-lisper but with a related mindset) I often end up
> with designs that look like OO designs in the large, I just don't find
> traditional OO tools to be a useful means of doing programming in the
> small (including the higher-level bits of code). Actually, I'll go a step
> further - I don't find traditional OO tools to be a useful means of
> analysing much (of my) programming in the small. I find they tend to offer
> extensibility in all the wrong places, for example.
> One thing I /do/ make a lot of use of is (sub)systems communicating in a
> specified language. In fact, a current project has a setup that looks
> suspiciously like threads-as-objects for pretty much that reason. Many of
> my preferred constructs end up looking pretty close to the duals of OO
> constructs, for that matter. Which makes a lot of sense if the traditional
> OO constructs seem to be getting everything backwards.
'Dual' is a word that has occurred to me in this context. Certainly we
can imagine (broadly) a scheme in which generic functions act as a dual
for classes in OO programming.
But the Lisp-ers on this thread seem to be heading for the notion of
making everything first-class. Which can only be its own dual.
Of course I have sub-systems that communicate too, but they are objects.
Possibly the languages they use tend to be less sophisticated, but they
serve my purposes well enough.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·······························@SLINKY>, ······@flippac.org
> says...
> > On Fri, 5 Nov 2004, Gerry Quinn wrote:
> >
> > > You can be oriented to objects, or oriented to something other than
> > > objects. Your choice. What you can't do is say "here's the OO language
> > > feature, we're not going to use it much but just because it's there our
> > > programs must be object-oriented."
> > >
> > Nobody's said that. They've said the /language/ is OO. C++ doesn't have
> > much of a better claim beyond the fact the type system needed explicit
> > extension to add OO to it.
>
> The other thing is that people actually DO program C++ in an OO fashion.
> Not always, but often enough. Correct me if I'm wrong, but Lisp-ers
> give a distinct impression of preferring generic programming.
You mean generic functions? Anyway, I would say you have gotten the
wrong impression, possibly because gurus Richard Gabriel and Paul Graham
loathe and despise OO. You may also be seeing what seems to me a general
failure of OO to win the hearts and souls of programmers. Even when they
use it, they do not use it much.
kt
In article <·····························@nyctyp01-ge0.rdc-nyc.rr.com>,
·······@nyc.rr.com says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> > The other thing is that people actually DO program C++ in an OO fashion.
> > Not always, but often enough. Correct me if I'm wrong, but Lisp-ers
> > give a distinct impression of preferring generic programming.
>
> You mean generic functions? Anyway, I would say you have gotten the
> wrong impression, possibly because gurus Richard Gabriel and Paul Graham
> loathe and despise OO. You may also be seeing what seems to me a general
> failure of OO to win the hearts and souls of programmers. Even when they
> use it, they do not use it much.
I honestly don't care how Lisp-ers like program. And gurus appeal
mainly to those who want magic new 'paradigms' and associated jargon
that makes them feel clever.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·····························@nyctyp01-ge0.rdc-nyc.rr.com>,
> ·······@nyc.rr.com says...
> > In article <··························@news.indigo.ie>,
> > Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> >
> > > The other thing is that people actually DO program C++ in an OO fashion.
> > > Not always, but often enough. Correct me if I'm wrong, but Lisp-ers
> > > give a distinct impression of preferring generic programming.
> >
> > You mean generic functions? Anyway, I would say you have gotten the
> > wrong impression, possibly because gurus Richard Gabriel and Paul Graham
> > loathe and despise OO. You may also be seeing what seems to me a general
> > failure of OO to win the hearts and souls of programmers. Even when they
> > use it, they do not use it much.
>
> I honestly don't care how Lisp-ers like program.
Correct me if I'm wrong, but above you cared enough to form "a distinct
impression of [Lisp-ers] preferring generic programming." :)
If you follow c.l.l., at least, you will find lots of threads about the
best way to use CLOS (including generic functions) for any given task.
My wild guess is that because CLOS is so much better than any other OO
model, we will see a Second Coming for OO as Lisp continues to move back
into the mainstream. ie, OO may have failed at the Grail thing only
because the implementations suck so badly.
Case in point: at least one cll reg is also a Java dude who does not
like to use inheritance in OO design. This in a language which is all OO
all the time. My, my. Java really must have blown it, I suppose by not
handling multiple inheritance, and by making the syntax so unwieldy.
otoh, my refactoring is as often about reshuffling a class hierarchy as
it is about dicing and slicing functions. And this is painless in CL
because I do not then have to run around changing type declarations all
over my code -- there are none.
kenny
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Maturity of a technology is not a direct function of age. Where are
> the IDEs, what is the standard version?
http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+226-1994+(R1999)
IDE's are availabe from several vendors. Myself and many others are
quite comfortable using emacs with slime(1) as IDE.
Petter
1)
http://common-lisp.net/project/slime/
--
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?
Gerry Quinn wrote:
> ...
> <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?
reading the points you quoted, they boil down to two arguments:
1. the programmer who considered it "code encryption" weren't familiar
with the language and either lazy or slow learners
2. they used a tool that was still in development
now imagine a post mortem from programmers who were unfamiliar with
C/C++ on a project were the C/C++ compiler is written while they develop
the product. do you think it would be any different?
> ...
hs
In article <····················@newscontent-01.sprint.ca>,
··@hartmann.schaffernet says...
> Gerry Quinn wrote:
> > 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?
>
> reading the points you quoted, they boil down to two arguments:
>
> 1. the programmer who considered it "code encryption" weren't familiar
> with the language and either lazy or slow learners
According to some they are geniuses whose decision to use Lisp should be
a guiding light for us moronic hordes. But in point of fact, I don't
see how it boils down to that. From the basic fact of problems arising,
we can't decide whether GOAL or its users were inadequate. But since
the post-mortem referred to bugs and missing features in GOAL, the
developers seem to be putting the blame on it.
> 2. they used a tool that was still in development
>
> now imagine a post mortem from programmers who were unfamiliar with
> C/C++ on a project were the C/C++ compiler is written while they develop
> the product. do you think it would be any different?
No. Those who used such an environment in such circumstances, while
mature technologies were available, would have made a stupid choice and
would probably fail. Even if they succeeded despite themselves, those
who copied them would still be idiots.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> But since the post-mortem referred to bugs and missing features in
> GOAL, the developers seem to be putting the blame on it.
And how does this claim indicate that a mature, stable Lisp
implementation suffers from the same problems? Note that the compiler
for GOAL was written in such a system. Interestingly enough, this
"failure" of a project has put out some of the best graphics for any PS2
games and has been used in multiple games. What a disaster. I thought
you were the one who was interested more in real world results than
theoretical whining.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Christer Ericson <················@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.
> 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
In article <········@duster.adelaide.on.net>, ······@internode.on.net
says...
> > [...]
> 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.
The development of the engine was staggered with production
of previous (PS1) games. As all smart production is done.
The game itself didn't take three years. Most (non-sequel)
PS2 games take about two years, so I don't see them having
any more time than any other developer.
> 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?
Several top games, even.
And, pray tell, why would "top programmers [...] who would
have made the same game in C if they had applied the same
algorithms" _deliberately_ reject C for a Lisp-based language
to write their games?
Anyway, that's not important.
The key point here is that the reason companies don't switch
from C/C++ to Lisp (or any other language) just like that,
is because there are so many other aspects to things than
just the language.
C/C++ has a critical mass, meaning it's easy to find compilers,
development environments, other tools, programmers, etc.
When comparing C/C++ to the superior, but less mainstream
language X (where X might be Lisp or whatever you want),
you have to weigh the benefits X beings against its
drawbacks.
Most companies are afraid of the drawbacks -- which is
perfectly reasonable -- which is why we see 99.5% or so
of all games being written in C++.
That does not mean C++ is better as a _language_ for
game development. It might mean it is a better _choice_
of a language for game development (given the constraints
the company is working under). These are different things.
If all other things were equal and the choice stood
between C++ and a language X that is arguably better,
it would be a no-brainer for me to instigate our studio
switching to language X for development. However, all
other things aren't equal and even though there exists
several languages X better than C++, we already have
a large investment in existing C++ code that we cannot
justify the costs of switching.
Christer Ericson
Sony Computer Entertainment, Santa Monica
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
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>"))
Paul Foley posted:
> 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.
While I understand the intention of your analogy, still...
It's incorrect in that, if one were not to make use of the 18" navals guns
or of those 8 foot diameter wheels, then the mass of these extra objects
would act as a hinderance for the vehicle: A greater force would be needed
to accelerate and deccelerate the vehicle.
While... with C++ ( comparing it to C ), the extra features in no way
hinder. So if I were to expand on your original analogy:
C is a Ferrari. C++ is a Ferrari with helicopter rotors which increase the
Ferrari's mass by 0, and its volume also by 0, also it has 18" naval guns
and 8 foot diameter wheels which increase both its mass and volume by 0.
>> 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.
Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
code) ?
Would this not be adequeately achieved with:
extern "C" {
?
-JKop
* JKop (····@NULL.NULL)
...
> While... with C++ ( comparing it to C ), the extra features in no way
> hinder.
a) So what. Why use a tool with loads of extra features that
simply aren't used?
b) There are some parts that *do* hinder and make C code not
compile as C++.
...
> Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
> code) ?
You seem not to have understood what they are.
Andreas
--
np: 4'33
Andreas Krey posted:
> * JKop (····@NULL.NULL)
> ...
>> While... with C++ ( comparing it to C ), the extra features in no way
>> hinder.
>
> a) So what. Why use a tool with loads of extra features that
> simply aren't used?
So if I tell you that you can also use a pen as a stabbing weapon, are you
suddenly not going to use it to write anymore based upon the premise that is
has an extra feature that isn't used?
> b) There are some parts that *do* hinder and make C code not
> compile as C++.
Just as how Delphi code won't compile as C++ code.
Pick a language, C or C++.
I see no reason whatsoever to not choose the latter which evolved from the
former.
If tomorrow a new programming language were to come out called "C+=2" or
"D" (yes, I know this name is taken!), then I'd abandon C++ in a heartbeat
in favour of its "latest evolution".
But for the foreseeable future, it doesn't look like C++ will change its
name. It looks like we'll just have Standard 1998, Standard 2003, and so
on...
People still programming in C is like a C++ programmer writing 1998 Standard
code -- it's been superseeded.
So I'm wondering, why do people write C code today, October 29th 2004?
> ...
>> Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
>> code) ?
>
> You seem not to have understood what they are.
What *what* are?
-JKop
JKop wrote:
>
> If tomorrow a new programming language were to come out called "C+=2" or
> "D" (yes, I know this name is taken!), then I'd abandon C++ in a heartbeat
> in favour of its "latest evolution".
Hmmm... you'd jump at "D", were it available, based only
on the name, and since you know it IS available, ... ?
Ian Wild <········@eurocontrol.int> writes:
> Hmmm... you'd jump at "D", were it available, based only on the
> name, and since you know it IS available, ... ?
Just in case you mean to imply that D is not available, there's plenty
to read here:
http://www.digitalmars.com/d/
--
Steven E. Harris
* JKop (····@NULL.NULL)
> Andreas Krey posted:
>
....
>>> Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
>>> code) ?
>>
>> You seem not to have understood what they are.
>
> What *what* are?
Static libraries and DLLs. They both contain machine code and
linkage information.
Andreas
--
np: 4'33
JKop wrote:
<snip>
> If tomorrow a new programming language were to come out called "C+=2"
<snip>
If it's going to follow the sequence semantically, it would have to be
called "C+=2, C".
Stewart.
Stewart Gordon posted:
> JKop wrote:
>
><snip>
>> If tomorrow a new programming language were to come out called "C+=2"
><snip>
>
> If it's going to follow the sequence semantically, it would have to be
> called "C+=2, C".
>
> Stewart.
C += 2, C
In the above expression, would the former not be evaluated before the
latter?
-JKop
JKop wrote:
<snip>
> C += 2, C
>
> In the above expression, would the former not be evaluated before the
> latter?
Oops, you're right.
C += 2, C - 2
(Caveat: if C is a floating point, there might be loss of precision in
the process.)
Stewart.
"JKop" <····@NULL.NULL> wrote in message
··························@news.indigo.ie...
> If tomorrow a new programming language were to come out called "C+=2" or
> "D" (yes, I know this name is taken!), then I'd abandon C++ in a heartbeat
> in favour of its "latest evolution".
Wait no more! D is here: www.digitalmars.com/d/
-Walter
···@zedat.fu-berlin.de (Stefan Ram) wrote:
> To /read/ a C++ program, one has to learn all the features of
> C++ that might appear in such a program. "C++ is already too
> large" according to Message-ID: <·····@alice.att.com> by
> Bjarne Stroustrup.
[...]
but this was a statement from 1993:
··················································@alice.att.com%3E
I don't know the details of the C++ standard, some things might be better
in the current standard.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
* Frank Buss (··@frank-buss.de)
...
> but this was a statement from 1993:
>
> ··················································@alice.att.com%3E
>
> I don't know the details of the C++ standard, some things might be better
> in the current standard.
No way. C++ is awfully convoluted and full of nasty traps many of which
you need to be actively aware of. A few days ago I had the line
clid = v;
corrupting an iterator. Now, v is a Some *, while clid is a SomeRef,
and it turned out that the SomeRef(Some *) constructor was broken
and only called because I forgot the SomeRef::operator=(Some *)
assignment operator. But class SomeRef would also have been seriously
broken if I just *omitted* the SomeRef::operator=(const SomeRef)
assignment operator.
C++ is also awfully wordy to write. Even the simple STL iteration
is a very lengthy expression. But then it is handy not to have
to do all this stuff yourself (in a typesafe way), and this is
the reason I finally (re)started to use C++.
Andreas
--
np: 4'33
JKop schrieb:
> 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
You might take a C++ compiler to get C code. In theory they should be
able to produce the same output.
Anyway, a program compiled with a C++ compiler which is not using any
features of C++ is still a C program. So if you don't use classes,
operator overloading, templates, exception handling etc.. then you are
programming in C. The fact that you use a C++ compiler to make machine
language out of your sources does not make your program any C++isher.
As soon you begin to use the more complex features of C++.. a fight will
start. You will run into problems where you need to think how you can
tell it (=what you want to achieve) the compiler. The problem itself is
history.. first you need to fight with the language to get things done,
then you can come back to the real problem itself.
Andr�
--
http://tinyurl.com/64x7y
"Maahes" <······@internode.on.net> writes:
> 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...
No, Lisp was used to make a compiler for a custom programming language
that contains features to help express operations in a way that's more
relevant to game programming and the Emotion Engine specifically. At
least this is my impression of the design of GOAL.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sat, 30 Oct 2004, Rahul Jain wrote:
> "Maahes" <······@internode.on.net> writes:
>
> > 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...
>
> No, Lisp was used to make a compiler for a custom programming language
> that contains features to help express operations in a way that's more
> relevant to game programming and the Emotion Engine specifically. At
> least this is my impression of the design of GOAL.
>
AIUI GOAL's also a Lisp variant.
--
······@flippac.org
Philippa Cowderoy <······@flippac.org> writes:
> AIUI GOAL's also a Lisp variant.
Yes, but bugs in GOAL's compiler and confusing semantics of GOAL's
operators are not a problem with the Lisp that was used to create the
compiler. Language design is hard. This is the first attempt at making
something that encapsulates the architecture of the Emotion Engine, so
I'd expect there to be some impedance mismatches.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Ok, thanx for the heads up.
So Jak and Daxter isn't even a proof that Lisp is useful for games, since
even those programmers decided they needed a variant for it to be useful...
And the "bugs in GOAL's compiler" I guess shows that Lisp isn't even prooven
to be good for writing the compiler..
:)
"Rahul Jain" <·····@nyct.net> wrote in message
···················@nyct.net...
> Philippa Cowderoy <······@flippac.org> writes:
>
>> AIUI GOAL's also a Lisp variant.
>
> Yes, but bugs in GOAL's compiler and confusing semantics of GOAL's
> operators are not a problem with the Lisp that was used to create the
> compiler. Language design is hard. This is the first attempt at making
> something that encapsulates the architecture of the Emotion Engine, so
> I'd expect there to be some impedance mismatches.
>
> --
> Rahul Jain
> ·····@nyct.net
> Professional Software Developer, Amateur Quantum Mechanicist
"Maahes" <······@internode.on.net> writes:
> Ok, thanx for the heads up.
> So Jak and Daxter isn't even a proof that Lisp is useful for games, since
> even those programmers decided they needed a variant for it to be useful...
This is how lisp always works. You customize the language to the
application domain, so that you can describe _what_ you want acheieved,
not _how_ you might want it done in some specific situation that may not
even be relevant to the final production application.
> And the "bugs in GOAL's compiler" I guess shows that Lisp isn't even prooven
> to be good for writing the compiler..
Of course, compilers written in C are always bug-free. Makes me wonder
why people were so afraid of using C++ back in the days when the
compilers were first being written.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, ·····@nyct.net says...
> "Maahes" <······@internode.on.net> writes:
>
> > Ok, thanx for the heads up.
> > So Jak and Daxter isn't even a proof that Lisp is useful for games, since
> > even those programmers decided they needed a variant for it to be useful...
>
> This is how lisp always works. You customize the language to the
> application domain, so that you can describe _what_ you want acheieved,
> not _how_ you might want it done in some specific situation that may not
> even be relevant to the final production application.
Of course, this is true of any high level language. In C++,
customisation comes mostly from defining classes and methods - the
language syntax remains consistent throughout.
Which seems like a win to me...
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Of course, this is true of any high level language.
Not really.
> In C++, customisation comes mostly from defining classes and
> methods - the language syntax remains consistent throughout.
>
> Which seems like a win to me...
It's really strange to see someone argue against something they
clearly have not the faintest idea of how works or what are the
benefits to be had. It's like seeing someone insisting on still using
horses for general transportation because they can't fit a car into
the stable, and what to do with all those horse-shoes?. It's just
uninformed.
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>, ······@cs.uit.no says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > > This is how lisp always works. You customize the language to the
> > > application domain, so that you can describe _what_ you want acheieved,
> > > not _how_ you might want it done in some specific situation that may not
> > > even be relevant to the final production application.
> > Of course, this is true of any high level language. In C++,
> > customisation comes mostly from defining classes and methods - the
> > language syntax remains consistent throughout.
> Not really.
What do you mean? Rabbit::Jump() seems a perfectly applicable example.
> > In C++, customisation comes mostly from defining classes and
> > methods - the language syntax remains consistent throughout.
> >
> > Which seems like a win to me...
>
> It's really strange to see someone argue against something they
> clearly have not the faintest idea of how works or what are the
> benefits to be had. It's like seeing someone insisting on still using
> horses for general transportation because they can't fit a car into
> the stable, and what to do with all those horse-shoes?. It's just
> uninformed.
Well, many of the boasts about Lisp seem to be about its ability to
create 'new languages' for a given problem domain. You mutter about
people not seeing the benefits, but you don't seem so keen to elucidate
them.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> What do you mean? Rabbit::Jump() seems a perfectly applicable
> example.
This is functional abstration, which is all good and well. Lisp macros
provide for syntactic (and even linguistic[*]) abstraction, which opens
up a whole new playing field. The combination of functional and
syntactic abstraction is the dynamic duo that defines Lisp's power.
> Well, many of the boasts about Lisp seem to be about its ability to
> create 'new languages' for a given problem domain. You mutter about
> people not seeing the benefits, but you don't seem so keen to
> elucidate them.
It is one of those things whose value is difficult to convey except by
personal experience. Imagine trying to convince a dedicated 1980's era
BASIC programmer of the benefits of functional abstraction. He'd say
something like "Oh, so a function is just a GOSUB with a name instead
of a line-number? Doesn't seem like much to me. Functions have
arguments and return values, you say? Well, duh, I pass arguments in
global variables, and I think anyone unable to keep their variables
straight are unfit to write programs. So this just helps weed out the
weaklings." Well, not quite.
Do you know what "functional programming" means? Some say it's
programming without side-effects, but really it's about writing your
programs in terms of functional abstraction. Or, in other words, in
terms of the function-call protocol your language provides in the form
of syntax and mechanism. Some people think this concept is the panacea
that should be applied universally to solve the software crisis. But
let's assume it's not. Still, the benefit of the clear, manifest,
predictable relationship between the program text and the result of
the program's execution is unquestionable (even if the hypothtetical
BASIC-programmer preferred his global variables). Bugs tend to creep
in when programs have side-effects (which might be called ad-hoc
protocols, contrasted to the language's function-call protocol) that
have consequences for the program that are difficult to spot by
looking at the program text. It is one of the very great benefits of
syntactic abstraction to be able to massage program text such that one
gets the best of both worlds: the clear, manifest relationship between
program text and program execution results, and also
application-specific, non-function-call protocols/side-effects
(i.e. one is not restricted to "functional programming"). (And this is
not to say that there isn't many cases of programming with
side-effects where the consequences are clear and simple without the
use of macros.)
[*] By linguistic abstraction I mean syntactic abstraction carried out
to such a degree that one cannot anymore be said to program in the
original language. Normally, syntactic abstraction integrates
naturally with the original language.
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>, ······@cs.uit.no says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
> > Well, many of the boasts about Lisp seem to be about its ability to
> > create 'new languages' for a given problem domain. You mutter about
> > people not seeing the benefits, but you don't seem so keen to
> > elucidate them.
>
> Do you know what "functional programming" means? Some say it's
> programming without side-effects, but really it's about writing your
> programs in terms of functional abstraction. Or, in other words, in
> terms of the function-call protocol your language provides in the form
> of syntax and mechanism. Some people think this concept is the panacea
> that should be applied universally to solve the software crisis. But
> let's assume it's not. Still, the benefit of the clear, manifest,
> predictable relationship between the program text and the result of
> the program's execution is unquestionable (even if the hypothtetical
> BASIC-programmer preferred his global variables). Bugs tend to creep
> in when programs have side-effects (which might be called ad-hoc
> protocols, contrasted to the language's function-call protocol) that
> have consequences for the program that are difficult to spot by
> looking at the program text. It is one of the very great benefits of
> syntactic abstraction to be able to massage program text such that one
> gets the best of both worlds: the clear, manifest relationship between
> program text and program execution results, and also
> application-specific, non-function-call protocols/side-effects
> (i.e. one is not restricted to "functional programming"). (And this is
> not to say that there isn't many cases of programming with
> side-effects where the consequences are clear and simple without the
> use of macros.)
>
> [*] By linguistic abstraction I mean syntactic abstraction carried out
> to such a degree that one cannot anymore be said to program in the
> original language. Normally, syntactic abstraction integrates
> naturally with the original language.
Let me point out something. If you do twenty projects in this fashion
you will have twenty new languages. Surely that vitiates any benefit of
a particular language, even if it is marginally better suited to the
problem domain of a given project?
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Let me point out something. If you do twenty projects in this
> fashion you will have twenty new languages.
No, you won't. You don't use linguistic abstraction (a "new language")
unless there is a very good reason to do so. Using syntactic
abstraction (i.e. a small set of operators with special evaluation
rules integrated in the standard language) should be used with caution
in order to avoid the babylonic effect you mention---much as one must
be careful with the functional abstractions one introduces in a
program. That is, functional abstraction is "cheaper" in the sense
that the evaluation rules in this case is fixed and thus in some sense
more predictable/readable. But do recall what I said: use syntactic
abstraction when it is clear that the program semantics (side-effects
and associated rules of use--i.e. protocol) in question are unwieldy,
and a macro can capture this well.
> Surely that vitiates any benefit of a particular language, even if
> it is marginally better suited to the problem domain of a given
> project?
You can make the observation that it is possible to write highly
obfuscated code using macros. But that's a very poor argument, I'm
sure you would agree. Using macros properly has the opposite effect as
what you're hinting at. And don't be blind to the concept that each of
the twenty projects by necessity will have a multitude of more-or-less
informal rules, idioms, etc. that cannot be captured in the
programming language, but which any programmer that is to work on that
code will have to internalize one way or another. Macros can be
understood as a mechanism that allows the programming language to
capture more such aspects of a project.
--
Frode Vatvedt Fjeld
In article <·························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> Let me point out something. If you do twenty projects in this fashion
> you will have twenty new languages. Surely that vitiates any benefit of
> a particular language, even if it is marginally better suited to the
> problem domain of a given project?
On one hand, I agree with you. But all significant programs
develop their own "vocabulary," one that matches the domain
at hand. The hard part about understanding a large program
is rarely mastering the details of the language in which it
is written. Rather, it is understanding the underlying
model of the domain scattered throughout its functions,
methods, classes, etc.
On the other hand, though, I disagree. Someone once claimed
that Lisp is a "programmable programming language". It is
the best available tool for building new domain-specific
languages. Why settle for a tool that is less-featured in
this regard. (This is the heart of the admittedly trollish
tenth rule of programming due to Greenspun.)
Of course, we can respectfully disagree about whether this
is the right approach to building large programs. Perhaps
it is a defining characteristic of the Lisp community that
they think this way: When faced with a complex domain, one
"grows Lisp up" to meet it.
In article <··························@news.vanderbilt.edu>,
····@vanderbilt.edu says...
> In article <·························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> > Let me point out something. If you do twenty projects in this fashion
> > you will have twenty new languages. Surely that vitiates any benefit of
> > a particular language, even if it is marginally better suited to the
> > problem domain of a given project?
>
> On one hand, I agree with you. But all significant programs
> develop their own "vocabulary," one that matches the domain
> at hand. The hard part about understanding a large program
> is rarely mastering the details of the language in which it
> is written. Rather, it is understanding the underlying
> model of the domain scattered throughout its functions,
> methods, classes, etc.
>
> On the other hand, though, I disagree. Someone once claimed
> that Lisp is a "programmable programming language". It is
> the best available tool for building new domain-specific
> languages. Why settle for a tool that is less-featured in
> this regard. (This is the heart of the admittedly trollish
> tenth rule of programming due to Greenspun.)
>
> Of course, we can respectfully disagree about whether this
> is the right approach to building large programs. Perhaps
> it is a defining characteristic of the Lisp community that
> they think this way: When faced with a complex domain, one
> "grows Lisp up" to meet it.
Fair comment. But put this way, whichever side you prefer, you can
hardly see it as an especially important or 'life-changing' advantage of
Lisp, can you?
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> Fair comment. But put this way, whichever side you prefer, you can
> hardly see it as an especially important or 'life-changing' advantage of
> Lisp, can you?
Well it's life-changing for those whose life it changed.
I know, that's a bit circular. Most programmers come
to Lisp after having mastered more mainstream languages.
In my days, the natural progression was Basic->Pascal->C.
I don't know what it is these days - perhaps Visual Basic
->Java->C++? Those that "convert" to Lisp wonder why
others do not. There are of course pragmatic reasons
(i.e., number of jobs) and matters of taste (i.e., do
you resonate with the material in Graham's "On Lisp"?).
But to a convert -- at least to this convert -- some of
the reasons seems merely conservative or reactionary.
An additional problem is that relatively few programmers
make the reverse progression, from Lisp-like languages
to more mainstream languages. I'm not speaking here of
those who were exposed to Scheme in an introductory class
and found it weird. I'm speaking of people who spent a
few years immersed in Lisp, mastered its idioms, and
moved on to more mainstream languages because they
thought them techically superior. (Ray Blaack, who was
participating in this thread, indicated that he is one of
the few exceptions in this regard.)
These are some of the reasons why advocacy debates between
Lispers and users of more mainstream languages rarely
yield new converts for either side.
Sashank Varma <····@vanderbilt.edu> writes:
> I'm speaking of people who spent a few years immersed in Lisp, mastered its
> idioms, and moved on to more mainstream languages because they thought them
> techically superior. (Ray Blaack, who was participating in this thread,
> indicated that he is one of the few exceptions in this regard.)
Actually, I in fact think Lisp *is* techically superior. I just don't use it
in my job. I wish I could.
I use Java and C# instead. I avoid C++ like the plague and only use it if
forced to maintain a legacy project. I avoid VB as well.
It would be great to be able to use Common Lisp, Scheme, Dylan, etc on real
projects. For that matter, it would also be great to be a games developer.
PS: its "Blaak". "Blaack" sounds like spitting up a hairball :-).
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
On Thu, 4 Nov 2004, Gerry Quinn wrote:
> Fair comment. But put this way, whichever side you prefer, you can
> hardly see it as an especially important or 'life-changing' advantage of
> Lisp, can you?
>
Not as a lisp-only feature, but I'm certainly finding that level of thing
highly useful in Haskell - and it's having a serious effect on my
day-to-day programming.
--
······@flippac.org
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> Well, many of the boasts about Lisp seem to be about its ability to
> create 'new languages' for a given problem domain. You mutter about
> people not seeing the benefits, but you don't seem so keen to
> elucidate them.
Gerry, if you're actually interested in exploring what Lisp has to
offer, you might be interested in taking a look at the draft chapters
of my soon-to-be-published book on Common Lisp, available at:
<http://www.gigamonkeys.com/book/>
It is written exactly for people like yourself--experienced
programmers in other languages who are perhaps skeptical of the claims
Lisp advocates make. It contains several chapters of "practical"
projects including building a parser for ID3 tags in MP3 files and a
Shoutcast server, many of which use the "build and embedded language"
approach made possible by Lisp's macros.
Anyway, the chapters on the web are first drafts so there may be some
unpolished bits and even a few forward references that I need to
straighten out but quite a few people have told me that it is in good
enough shape to help them at least see what the heck us Lispers are
going on and on about all the time.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
In article <··············@javamonkey.com>, ·····@javamonkey.com says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > Well, many of the boasts about Lisp seem to be about its ability to
> > create 'new languages' for a given problem domain. You mutter about
> > people not seeing the benefits, but you don't seem so keen to
> > elucidate them.
>
> Gerry, if you're actually interested in exploring what Lisp has to
> offer, you might be interested in taking a look at the draft chapters
> of my soon-to-be-published book on Common Lisp, available at:
>
> <http://www.gigamonkeys.com/book/>
It looks like a good primer. One comment I would make, though, is that
at a glance everything seems to be a parser of some sort. A touch of
hammer and nail syndrome?
- Gerry Quinn
[Followups set to comp.lang.lisp]
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··············@javamonkey.com>, ·····@javamonkey.com says...
>> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>>
>> > Well, many of the boasts about Lisp seem to be about its ability to
>> > create 'new languages' for a given problem domain. You mutter about
>> > people not seeing the benefits, but you don't seem so keen to
>> > elucidate them.
>>
>> Gerry, if you're actually interested in exploring what Lisp has to
>> offer, you might be interested in taking a look at the draft chapters
>> of my soon-to-be-published book on Common Lisp, available at:
>>
>> <http://www.gigamonkeys.com/book/>
>
> It looks like a good primer. One comment I would make, though, is that
> at a glance everything seems to be a parser of some sort. A touch of
> hammer and nail syndrome?
Hmmm. If it is weighted toward one kind of program it probably has
more to do with my interests and the set of things that can be
explained without assuming a lot of prior domain knowledge.
At any rate there are quite a few things--most of them I'd say--that
aren't parsers: an in-memory database, a test framework, a Shoutcast
server, a web interface for the Shotcast server, an HTML generation
library. In fact there are only two parsers--the binary data parser
from chapter 20 is used to write the ID3 parser in chapter 22. And if
I get a chance to write chapter 28 (a bit at risk at the moment for
time and space reasons) it'll be about text parsing, a la Yacc, ANTLR,
etc.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
On Wed, 03 Nov 2004 17:14:41 +0000, Peter Seibel wrote:
> And if
> I get a chance to write chapter 28 (a bit at risk at the moment for
> time and space reasons) it'll be about text parsing, a la Yacc, ANTLR,
> etc.
I really hope you do - I've been eagerly waiting to read that chapter
since I do a lot of parsing (mostly using ANTLR) in my day job. I'd be
really interested to see what you have to say on the topic.
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
Peter Seibel <·····@javamonkey.com> writes:
> I get a chance to write chapter 28 (a bit at risk at the moment for
> time and space reasons) it'll be about text parsing, a la Yacc, ANTLR,
> etc.
You mean using zebu, meta or other parser generators? Cool! I think
zebu is great, but I wish it had a lexical analyzer generator as well.
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?
Petter Gustad <·············@gustad.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
>> I get a chance to write chapter 28 (a bit at risk at the moment for
>> time and space reasons) it'll be about text parsing, a la Yacc, ANTLR,
>> etc.
>
> You mean using zebu, meta or other parser generators? Cool! I think
> zebu is great, but I wish it had a lexical analyzer generator as well.
Yeah, it's a parser generator based on META (but without the reader
macros and with some other foo of my own devising. Like ANTLR it uses
the same basic framework to define both lexers (parsers on characters)
and parsers (parsers on tokens emitted by a lexer).
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Petter Gustad <·············@gustad.com> writes:
> You mean using zebu, meta or other parser generators? Cool! I think
> zebu is great, but I wish it had a lexical analyzer generator as well.
Last time I used Zebu, it generated a lexical analyzer for me. What
are you missing?
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish <··········@cmu.edu> writes:
> Petter Gustad <·············@gustad.com> writes:
> > You mean using zebu, meta or other parser generators? Cool! I think
> > zebu is great, but I wish it had a lexical analyzer generator as well.
>
> Last time I used Zebu, it generated a lexical analyzer for me. What
> are you missing?
It's a simplistic lexical analyzer generator, that just uses regexp in
a predetermined maner. Have a look at flex to see what you're lacking.
Try to scan bison sources with zebu to see why it's not enough.
--
__Pascal Bourguignon__
Matthew Danish <··········@cmu.edu> writes:
> Petter Gustad <·············@gustad.com> writes:
> > You mean using zebu, meta or other parser generators? Cool! I think
> > zebu is great, but I wish it had a lexical analyzer generator as well.
>
> Last time I used Zebu, it generated a lexical analyzer for me. What
> are you missing?
It's somewhat limited. You have only the lex-cats regular expressions
and the identifier-start-chars. I seem to remember that it was a
hassle to handle comments for VHDL (start with --) and Verilog (starts
with //).
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?
Gerry Quinn <······@DELETETHISindigo.ie> wrote
> > > customisation comes mostly from defining classes and methods - the
> > > language syntax remains consistent throughout.
>
> > Not really.
>
> What do you mean? Rabbit::Jump() seems a perfectly applicable example.
Ordinary function call:
C++: jump(rabbit, 3)
Lisp: (jump rabbit 3)
Method call:
C++: rabbit.jump(3)
Lisp: (jump rabbit 3)
Class method call:
C++: Rabbit::jump(rabbit, 3)
Lisp: (jump rabbit 3)
Well, *one* language has syntax that remains consistent throughout.
>
> Ordinary function call:
> C++: jump(rabbit, 3)
> Lisp: (jump rabbit 3)
C: rabbit_jump(rabbit, 3)
>
> Method call:
> C++: rabbit.jump(3)
> Lisp: (jump rabbit 3)
C: rabbit_jump(rabbit, 3)
>
> Class method call:
> C++: Rabbit::jump(rabbit, 3)
> Lisp: (jump rabbit 3)
C++: Rabbit::jump(3)
C: rabbit_jump(3)
I don't know lisp, but it doesn't look right. A class call would have no
concept of a rabbit object as there is no data related to the class call. So
what does the "rabbit" do in your line.
Its effectively just a namespace so you can have different Jump functions
without them clashing (as well as some other properties in C++ like being
able to access private sections of any Rabbit object it has access to).
>
> Well, *one* language has syntax that remains consistent throughout.
*two* languages.
"Maahes" <······@internode.on.net> wrote
> > Method call:
> > C++: rabbit.jump(3)
> > Lisp: (jump rabbit 3)
>
> C: rabbit_jump(rabbit, 3)
C doesn't have classes and methods AFAIK. The Lisp call above is
really to a method of the rabbit class, but it looks exactly the same
as an ordinary function call.
> > Class method call:
> > C++: Rabbit::jump(rabbit, 3)
> > Lisp: (jump rabbit 3)
>
> C++: Rabbit::jump(3)
> C: rabbit_jump(3)
>
> I don't know lisp, but it doesn't look right. A class call would have no
> concept of a rabbit object as there is no data related to the class call. So
> what does the "rabbit" do in your line.
I assumed that even if the design decision was made to make jump a
class method, one would like to know which rabbit object the caller
wanted to have jump. Hence it is passed as an argument.
> > Well, *one* language has syntax that remains consistent throughout.
> *two* languages.
Lisp and C? Well, in C's case that's because there is really one one
kind of call, so it's not all that surprising that the syntax for that
kind of call is consistent.
>> > Method call:
>> > C++: rabbit.jump(3)
>> > Lisp: (jump rabbit 3)
>>
>> C: rabbit_jump(rabbit, 3)
>
> C doesn't have classes and methods AFAIK. The Lisp call above is
> really to a method of the rabbit class, but it looks exactly the same
> as an ordinary function call.
>
class's and methods are just a structural concept. C has structs and if you
wanted to implement a class with methods, its just as easy to do it in C.
Of course, virtuals and hierachy get messier, though still possible.
== C++ ==
class Rabbit
{
Vector pos;
public:
Jump(int distance);
};
== C ==
struct Rabbit
{
Vector pos;
};
Rabbit_Jump(int distance);
>> > Class method call:
>> > C++: Rabbit::jump(rabbit, 3)
>> > Lisp: (jump rabbit 3)
>>
>> C++: Rabbit::jump(3)
>> C: rabbit_jump(3)
>>
>> I don't know lisp, but it doesn't look right. A class call would have no
>> concept of a rabbit object as there is no data related to the class call.
>> So
>> what does the "rabbit" do in your line.
>
> I assumed that even if the design decision was made to make jump a
> class method, one would like to know which rabbit object the caller
> wanted to have jump. Hence it is passed as an argument.
>
Sorry, I assumed you had made a mistake, since it makes no sense to pass in
a "rabbit" object to a static method of a rabbit class. Static methods have
a different syntax coz they don't require any object data. If you choose to
pass in a rabbit to try and make the code interface look inconsistent, I
guess you can do that.
>> > Well, *one* language has syntax that remains consistent throughout.
>> *two* languages.
>
> Lisp and C? Well, in C's case that's because there is really one one
> kind of call, so it's not all that surprising that the syntax for that
> kind of call is consistent.
How many kinds of calls does Lisp have?
"Maahes" <······@internode.on.net> wrote
> class's and methods are just a structural concept.
I disagree, but that's probably another discussion (and we might
possibly agree if it is pursued).
> C has structs and if you
> wanted to implement a class with methods, its just as easy to do it in C.
Yes, but that doesn't create new types of function calls.
> If you choose to pass in a rabbit to try and make the code interface
> look inconsistent, I guess you can do that.
I passed in a rabbit to make the examples as similar as possible.
It's not the parameters that makes the syntax inconsistent:
foo( ... )
bar.foo( ... )
Bar::foo( ... )
are still inconsistent.
> How many kinds of calls does Lisp have?
In this area of comparison, two: 'Ordinary' function call and method
call, basically.
"Maahes" <······@internode.on.net> writes:
> struct Rabbit
> {
> Vector pos;
> };
> Rabbit_Jump(int distance);
No, for equivalence, you'd need something more like
void Rabbbit_Jump(Rabbit* this, int distance);
with the constraint that "this" is nonzero.
--
Steven E. Harris
"Steven E. Harris" <···@panix.com> wrote in message
····················@W003275.na.alarismed.com...
> "Maahes" <······@internode.on.net> writes:
>
>> struct Rabbit
>> {
>> Vector pos;
>> };
>> Rabbit_Jump(int distance);
>
> No, for equivalence, you'd need something more like
>
> void Rabbbit_Jump(Rabbit* this, int distance);
>
> with the constraint that "this" is nonzero.
>
yes, my bad.
Maahes wrote:
>> Lisp and C? Well, in C's case that's because there is really one one
>> kind of call, so it's not all that surprising that the syntax for that
>> kind of call is consistent.
>
> How many kinds of calls does Lisp have?
Hmm...
Standard function calls, of course.
Generic function calls, for OO.
I'd say that's... two.
Macros/specials don't count, because although they usually look *similar* to
ordinary function calls, they have different evaluation order, at least. If
they didn't, they wouldn't need a macro.
Of course, it's possible to define generic functions in terms of ordinary
functions, so in effect you could say there's just one call, and you can
also add different kinds of calls such as Prolog evaluation or foreign
calls. I'd say the answer is "N".
Maahes wrote:
> class's and methods are just a structural concept. C has structs and if you
> wanted to implement a class with methods, its just as easy to do it in C.
> Of course, virtuals and hierachy get messier, though still possible.
>
> == C++ ==
>
> class Rabbit
> {
> Vector pos;
>
> public:
> Jump(int distance);
> };
>
>
> == C ==
>
> struct Rabbit
> {
> Vector pos;
> };
> Rabbit_Jump(int distance);
are those two really the same? afaiu, with
Rabbit nick;
nick.jump(3)
the rabbit nick gets passed as an implicit argument to the function
hs
>> == C++ ==
>>
>> class Rabbit
>> {
>> Vector pos;
>>
>> public:
>> Jump(int distance);
>> };
>>
>>
>> == C ==
>>
>> struct Rabbit
>> {
>> Vector pos;
>> };
>> Rabbit_Jump(int distance);
>
> are those two really the same? afaiu, with
>
> Rabbit nick;
>
> nick.jump(3)
>
> the rabbit nick gets passed as an implicit argument to the function
>
> hs
Yeah, my bad. It should have been Rabbit_Jump(Rabbit *this, int distance)
Hello!
Maahes <······@internode.on.net> wrote:
>[...]
>class's and methods are just a structural concept. C has structs and if you
>wanted to implement a class with methods, its just as easy to do it in C.
>Of course, virtuals and hierachy get messier, though still possible.
Of course, as witnessed by Xt/Xaw.
Kind regards,
Hannah.
Maahes wrote:
>>Ordinary function call:
>> C++: jump(rabbit, 3)
>> Lisp: (jump rabbit 3)
>
>
> C: rabbit_jump(rabbit, 3)
>
>
>
>>Method call:
>> C++: rabbit.jump(3)
>> Lisp: (jump rabbit 3)
>
>
> C: rabbit_jump(rabbit, 3)
>
>
>>Class method call:
>> C++: Rabbit::jump(rabbit, 3)
>> Lisp: (jump rabbit 3)
>
What is this? are you saying that the class rabbit has a static member
function that takes a rabbit and a 3? I'm not sure why you would want
such a thing..
Also are you saying in lisp when I write (jump rabbit 3) it's impossible
to tell if I'm calling a member function of Rabbit that takes a single
parameter, or a general function that takes two parameters? Is that
really an advantage?
If you don't want member functions in C++ of course, you can just not
write them. I find the distinction between jump(rabbit,3) and
rabbit.jump(3) helpful.
Chris
chris <···@cs.york.ac.uk> writes:
> Maahes wrote:
> >>Ordinary function call:
> >> C++: jump(rabbit, 3)
> >> Lisp: (jump rabbit 3)
> > C: rabbit_jump(rabbit, 3)
> >
> >>Method call:
> >> C++: rabbit.jump(3)
> >> Lisp: (jump rabbit 3)
> > C: rabbit_jump(rabbit, 3)
> >
> >>Class method call:
> >> C++: Rabbit::jump(rabbit, 3)
> >> Lisp: (jump rabbit 3)
> >
> What is this? are you saying that the class rabbit has a static member
> function that takes a rabbit and a 3? I'm not sure why you would want
> such a thing..
>
> Also are you saying in lisp when I write (jump rabbit 3) it's
> impossible to tell if I'm calling a member function of Rabbit that
> takes a single parameter, or a general function that takes two
> parameters? Is that really an advantage?
The function 'jump' is generic, for each class that cares about having
an action for jump, the programmer defines a function named that with
the parameters specialized accordingly so Lisp will call the proper
one. Its analagous to function/operator overloading in C++. In
general, you cannot have regular functions named the same as generic
functions, so there is no confusion about which function is going to
be called.
There are no "member functions" in Lisp, all functions exist outside
the definition of classes. That will sound strange to people only
familiar with the C++ style of OO, but it works very nicely once you
get used to it.
Gregm
Greg Menke wrote:
> chris <···@cs.york.ac.uk> writes:
>
> There are no "member functions" in Lisp, all functions exist outside
> the definition of classes. That will sound strange to people only
> familiar with the C++ style of OO, but it works very nicely once you
> get used to it.
>
In that case, you could simply write C++ and not use member functions.
Arguing that C++'s member functions don't look like normal function
calls and in lisp they do sounds stupid if in fact lisp doesn't have
member functions.
Chris
"Chris" <···@cs.york.ac.uk> writes:
[Greg Menke:]
> > There are no "member functions" in Lisp, all functions exist outside
> > the definition of classes. That will sound strange to people only
> > familiar with the C++ style of OO, but it works very nicely once you
> > get used to it.
[Chris:]
> In that case, you could simply write C++ and not use member
> functions. Arguing that C++'s member functions don't look like normal
> function calls and in lisp they do sounds stupid if in fact lisp
> doesn't have member functions.
I think you may have misunderstood Greg. Although it's true
that Lisp doesn't have "member functions", it isn't true that
Lisp is like C++-without-member-functions. If you abandon
member functions in C++, then inheritance becomes impossible.
Lisp's "generic functions" *do* support inheritance.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> "Chris" <···@cs.york.ac.uk> writes:
>
> [Greg Menke:]
>
>>>There are no "member functions" in Lisp, all functions exist outside
>>>the definition of classes. That will sound strange to people only
>>>familiar with the C++ style of OO, but it works very nicely once you
>>>get used to it.
>
>
> [Chris:]
>
>>In that case, you could simply write C++ and not use member
>>functions. Arguing that C++'s member functions don't look like normal
>>function calls and in lisp they do sounds stupid if in fact lisp
>>doesn't have member functions.
>
>
> I think you may have misunderstood Greg. Although it's true
> that Lisp doesn't have "member functions", it isn't true that
> Lisp is like C++-without-member-functions. If you abandon
> member functions in C++, then inheritance becomes impossible.
> Lisp's "generic functions" *do* support inheritance.
>
Ah, sorry. I know a (little) lisp, so I should have realised the point.
I find these lisp vs. C++ discussions fun, but also wonder if they have
any purpose. My opinion on the subject (in case anyone cares) is that I
enjoy programming in lisp more than C++, but one problem with lisp is
that it's incrediable flexability is it's greatest weakness. When
working on a number of large projects, the quite fixed structure imposed
by say Java or C++ can make life much easier in terms of debugging and
long term support, which in my opinion are actually much more important
than writing the original code (I'm sure 90% of the time I'm looking at
code it is code either I or someone else wrote more than 6 months ago).
C++ would be nicer if the type system didn't have holes you can drive a
bus through.
Chris
chris <···@cs.york.ac.uk> writes:
> Gareth McCaughan wrote:
> > "Chris" <···@cs.york.ac.uk> writes:
> > [Greg Menke:]
> >
> >>>There are no "member functions" in Lisp, all functions exist outside
> >>>the definition of classes. That will sound strange to people only
> >>>familiar with the C++ style of OO, but it works very nicely once you
> >>>get used to it.
> > [Chris:]
> >
> >>In that case, you could simply write C++ and not use member
> >>functions. Arguing that C++'s member functions don't look like normal
> >>function calls and in lisp they do sounds stupid if in fact lisp
> >>doesn't have member functions.
> > I think you may have misunderstood Greg. Although it's true
> > that Lisp doesn't have "member functions", it isn't true that
> > Lisp is like C++-without-member-functions. If you abandon
> > member functions in C++, then inheritance becomes impossible.
> > Lisp's "generic functions" *do* support inheritance.
> >
>
> Ah, sorry. I know a (little) lisp, so I should have realised the point.
>
> I find these lisp vs. C++ discussions fun, but also wonder
> if they have any purpose.
No, not really.
In article <·············@news.dtpq.com>,
······@news.dtpq.com (Christopher C. Stacy) wrote:
> chris <···@cs.york.ac.uk> writes:
>
> > Gareth McCaughan wrote:
> > > "Chris" <···@cs.york.ac.uk> writes:
> > > [Greg Menke:]
> > >
> > >>>There are no "member functions" in Lisp, all functions exist outside
> > >>>the definition of classes. That will sound strange to people only
> > >>>familiar with the C++ style of OO, but it works very nicely once you
> > >>>get used to it.
> > > [Chris:]
> > >
> > >>In that case, you could simply write C++ and not use member
> > >>functions. Arguing that C++'s member functions don't look like normal
> > >>function calls and in lisp they do sounds stupid if in fact lisp
> > >>doesn't have member functions.
> > > I think you may have misunderstood Greg. Although it's true
> > > that Lisp doesn't have "member functions", it isn't true that
> > > Lisp is like C++-without-member-functions. If you abandon
> > > member functions in C++, then inheritance becomes impossible.
> > > Lisp's "generic functions" *do* support inheritance.
> > >
> >
> > Ah, sorry. I know a (little) lisp, so I should have realised the point.
> >
> > I find these lisp vs. C++ discussions fun, but also wonder
> > if they have any purpose.
>
> No, not really.
I discovered CL because someone noticed my thrashing search for A Better
Way (whined about periodically on macdev on CompuServe) and suggested
MCL. "Information. It's all good." (tm) Of course I would not say that
if this had degenerated into a silly flamewar, but it has not.
kt
··········@toadmail.com wrote:
>>chris writes:
>> > Greg Menke wrote:
>> > > chris <···@cs.york.ac.uk> writes:
>> > >
>> > > There are no "member functions" in Lisp, all functions exist outside
>> > > the definition of classes. That will sound strange to people only
>> > > familiar with the C++ style of OO, but it works very nicely once you
>> > > get used to it.
>> > >
>> >
>> > In that case, you could simply write C++ and not use member functions.
>> > Arguing that C++'s member functions don't look like normal function
>> > calls and in lisp they do sounds stupid if in fact lisp doesn't have
>> > member functions.
>> >
>> > Chris
>> >
>>
>>Can functions outside class definitions be overloaded?
>>
>>
>>
>
>
>That wasn't intended to be a clever question- I actually didn't know
>the answer. I just tested it, and it seems you can. I think I knew
>that at some point, but I've not used C++ for some time...
>
>So some of Lisp's object model could be put in C++ terms like this;
>Create a class with no member functions and all member variables
>public. Then create overloaded functions for each class the call
>should be applicable to.
>
>Lisp has rules for arranging the correct ordering of calls in
>situations where the derivation tree of a class yields multiple
>overloaded functions, which may not be present in C++, so that part of
>the question might still cause some trouble.
>
>
>
Also, in defence of lisp, while you could overload all the functions
outside of class definitions these functions will not be "virtual". For
example say that we have a class A from which we have derived B,C and D.
If I have a variable of type A* (so pointer to type A, which could
actually point to type A,B,C or D) and a function grab(A*) which you
want to overload for each of A,B,C or D then I don't think this is
possible without some very nasty fiddling (ie you couldn't just define
grab(A*), grab(B*), grab(C*) and grab(D*) and then when you call
grab(thing) where thing is an A* have it go to the approriate grab).
You could do this with nasty rtti, but that isn't really very nice under
C++ and quite error-prone...
Chris
>Gregm
>
>
>
chris wrote:
> Maahes wrote:
>
>>> Ordinary function call:
>>> C++: jump(rabbit, 3)
>>> Lisp: (jump rabbit 3)
>>
>>
>>
>> C: rabbit_jump(rabbit, 3)
>>
>>
>>
>>> Method call:
>>> C++: rabbit.jump(3)
>>> Lisp: (jump rabbit 3)
>>
>>
>>
>> C: rabbit_jump(rabbit, 3)
>>
>>
>>> Class method call:
>>> C++: Rabbit::jump(rabbit, 3)
>>> Lisp: (jump rabbit 3)
>>
>>
> What is this? are you saying that the class rabbit has a static member
> function that takes a rabbit and a 3? I'm not sure why you would want
> such a thing..
>
> Also are you saying in lisp when I write (jump rabbit 3) it's impossible
> to tell if I'm calling a member function of Rabbit that takes a single
> parameter, or a general function that takes two parameters?
If you mean to ask whether the syntax tells you whether it's a method
call or a non-method call, it doesn't.
> Is that
> really an advantage?
I think so; generic functions and ordinary functions are both appliable
objects that take arguments; I don't see any special reason why they
should have different syntax. Macro calls and uses of other special
operators also use the same general syntax:
(operator arg1 arg2 ... argn)
As an aside, in Lisp there is no such thing as a member function:
methods are not members of classes, because the particular method may be
selected by the types (or values) of any number of parameters. For example:
(defmethod foo ((x square)(y integer))
;; do first thing...
)
(defmethod foo ((x square)(y float))
;; do second thing...
)
(defmethod foo ((x circle)(y integer))
;; do third thing...
)
(defmethod foo ((x circle)(y float))
;; do fourth thing...
)
(defmethod foo ((x circle)(y (eql 5)))
;; do fifth thing...
)
[The last example shows an 'eql specializer' -- CLOS methods may be
selected by particular values, rather than by type.]
mikel <·····@evins.net> writes:
> > Is that really an advantage?
>
> I think so; generic functions and ordinary functions are both appliable
> objects that take arguments; I don't see any special reason why they should
> have different syntax. Macro calls and uses of other special operators also
> use the same general syntax:
>
> (operator arg1 arg2 ... argn)
The reason to have a difference syntax is to better model how humans think in
certain situations.
I have used Lisp's syntax. It is nicely general. Ada has a similar syntax for
OO method calls.
The problem is that very often I want to think about asking individual objects
to do certain behaviour. Saying:
obj.doSomething(withData)
clarifies that better than:
doSomething(obj, withData)
It is a mental organization thing.
Essentially, class scopes can indeed be useful.
Consider a record or struct syntax in the standard langages: data.field
Mind you, Lisp is consistent here too, calling a field accessor function/macro
on the data.
There is no question that Lisp's approach is more general, especially given
generic methods. Sometimes, the class scope/focus of things is useful.
E.g. in Lisp or scheme, something like:
(obj doSomething withData)
Don't know how to do that with macros, however. The approaches I have seen
usually force things like
(obj 'doSomething withData)
with the implied inefficient dynamic lookup of methods.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
In article <·············@STRIPCAPStelus.net>,
Ray Blaak <········@STRIPCAPStelus.net> wrote:
> mikel <·····@evins.net> writes:
> > > Is that really an advantage?
> >
> > I think so; generic functions and ordinary functions are both appliable
> > objects that take arguments; I don't see any special reason why they should
> > have different syntax. Macro calls and uses of other special operators also
> > use the same general syntax:
> >
> > (operator arg1 arg2 ... argn)
> The reason to have a difference syntax is to better model how humans think in
> certain situations.
[Let me return to this below.]
> It is a mental organization thing.
>
> Essentially, class scopes can indeed be useful.
Perhaps. I guess I believe you. Okay, class scope can sometimes
be useful.
> Mind you, Lisp is consistent here too, calling a field accessor function/macro
> on the data.
>
> There is no question that Lisp's approach is more general, especially given
> generic methods.
But what you (seem to) give up when you accept class scope is this
beautiful generality.
You claimed above that class scope models how humans think in certain
situations. Frankly, as a cognitive psychologist, I'm finding it hard
to think of data that support (or refute) your claim.
My intuition (and it is a just an intuition, not an established fact
about human cognition) is that taking a consistent, parsimonious
approach to function/method calls brings an increased economy to the
comprehension of Lisp code. Programming languages are formalisms, and
those who uses formalisms (e.g., mathematicians) have historically
worked awfully hard to eliminate special cases and unnecessary
redundancies.
Sashank Varma <····@vanderbilt.edu> writes:
> > There is no question that Lisp's approach is more general, especially given
> > generic methods.
>
> But what you (seem to) give up when you accept class scope is this
> beautiful generality.
Yes, but in the situations where I want the class scope I do not in fact
need/want the generality.
Note carefully that I do not want to give up the beautiful generality if
required: it is always there if I need it.
> You claimed above that class scope models how humans think in certain
> situations. Frankly, as a cognitive psychologist, I'm finding it hard
> to think of data that support (or refute) your claim.
Let me be precise: it is how *I* think when solving certain kinds of problems.
For other kinds of problems I think differently, and then the full generality
of multimethods can come into play.
> My intuition (and it is a just an intuition, not an established fact
> about human cognition) is that taking a consistent, parsimonious
> approach to function/method calls brings an increased economy to the
> comprehension of Lisp code. Programming languages are formalisms, and
> those who uses formalisms (e.g., mathematicians) have historically
> worked awfully hard to eliminate special cases and unnecessary
> redundancies.
The class scope view is a more restricted and simplied one. That simplicity
aids in understanding when it is in effect.
Anytime one builds absraction layers on top of general components and
features, there is a similar "restriction" coming into play. Any specific
solution is by definition a restriction of the set of possible solutions.
Or not. My essential point is that I have used both approaches in the past and
have found that there are times when I want the class scope view since it
guides the solution a certain way. Other times I need the general way.
I want both.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak wrote:
> mikel <·····@evins.net> writes:
>
>>>Is that really an advantage?
>>
>>I think so; generic functions and ordinary functions are both appliable
>>objects that take arguments; I don't see any special reason why they should
>>have different syntax. Macro calls and uses of other special operators also
>>use the same general syntax:
>>
>> (operator arg1 arg2 ... argn)
>
>
> The reason to have a difference syntax is to better model how humans think in
> certain situations.
>
> I have used Lisp's syntax. It is nicely general. Ada has a similar syntax for
> OO method calls.
>
> The problem is that very often I want to think about asking individual objects
> to do certain behaviour. Saying:
>
> obj.doSomething(withData)
>
> clarifies that better than:
>
> doSomething(obj, withData)
>
> It is a mental organization thing.
Fair enough. This is, however, just syntactic sugar, and if you really
want it you can build it with a macro. The Lispy result might look like,
for example,
(send obj do-something with-data)
Because the macro gets expanded to
(do-something obj with-data)
there is no difference, apart from the differenet surface syntax, which
is provided because the user happens to like it for this case.
As an aside, Dylan began as a Lisp dialect and later evolved an infix
syntax; for a while it had both syntaxes, and the syntax
obj.doSomething(withData)
was exactly equivalent to
doSomething(obj,withData)
or
(doSomething obj withData)
Indeed, it was fully general and worked the other way; anything that
could be called like this:
foo(bar)
could also be called like this:
bar.foo()
>
> Essentially, class scopes can indeed be useful.
That might be true, but doesn't mean the same thing. Assuming that by
'class scopes' you mean that you want objects that contain methods as
data elements, you can do that in Lisp as well, in a couple of different
ways, but if you want a comprehensive system of function-calling,
inheritance, and the like that resembles a Smalltalk-like object system
or a C++-like object system, then you have to do a little more work
defining metaclasses and method combinations and so on.
From: Marco Baringer
Subject: Re: C++ sucks for games
Date:
Message-ID: <m2y8hi921i.fsf@bese.it>
Ray Blaak <········@STRIPCAPStelus.net> writes:
> Sometimes, the class scope/focus of things is useful.
>
> E.g. in Lisp or scheme, something like:
>
> (obj doSomething withData)
[untested]
(defmacro with-svo (var &body body)
`(macrolet ((,var (gf-name &rest args)
`(,gf-name ,',var ,@args)))
,@body))
(with-svo (obj)
(obj doSomething withData))
this will only "work" when you work in your own world because the
entire clos culture thinks differently and you'll have issues (none of
them technical) when working with others.
p.s. - the above is only a short read macro away from:
(enable-svo-syntax)
[obj.doSomething withData]
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
>
>
>>Sometimes, the class scope/focus of things is useful.
>>
>>E.g. in Lisp or scheme, something like:
>>
>> (obj doSomething withData)
>
>
> [untested]
>
> (defmacro with-svo (var &body body)
> `(macrolet ((,var (gf-name &rest args)
> `(,gf-name ,',var ,@args)))
> ,@body))
>
> (with-svo (obj)
> (obj doSomething withData))
>
> this will only "work" when you work in your own world because the
> entire clos culture thinks differently and you'll have issues (none of
> them technical) when working with others.
>
> p.s. - the above is only a short read macro away from:
>
> (enable-svo-syntax)
>
> [obj.doSomething withData]
>
By the way, in addition to this approach and the alternative I posted,
I've also implemented this sort of thing by defining new appliable
classes (that is, classes of things that act like functions), which
would be another way to get the
(obj doSomething withData)
syntax.
chris <···@cs.york.ac.uk> wrote
> >>Class method call:
> >> C++: Rabbit::jump(rabbit, 3)
> >> Lisp: (jump rabbit 3)
> >
> What is this? are you saying that the class rabbit has a static member
> function that takes a rabbit and a 3? I'm not sure why you would want
> such a thing..
Most likely you wouldn't, but if you wanted it, that's how it would
look like. Maybe I should have just written f(a, b) / a.f(b) /
T::f(a, b), but I kind of wanted to go with the "rabbit jump" thing.
> Also are you saying in lisp when I write (jump rabbit 3) it's impossible
> to tell if I'm calling a member function of Rabbit that takes a single
> parameter, or a general function that takes two parameters?
No, that's not how it works.
To begin with, the method call actually takes two parameters; the
types of each parameter is matched against the set of available
methods with the same name and the best match is called. There is no
such thing as a member function of a class, but there may be a method
that's ready and willing to handle calls involving an instance of
Rabbit in the first parameter place.
This way, methods taking any type of object and methods specifically
taking only certain types of objects can co-exist peacefully.
In article <····························@posting.google.com>,
·············@swipnet.se says...
> chris <···@cs.york.ac.uk> wrote
>
> > >>Class method call:
> > >> C++: Rabbit::jump(rabbit, 3)
> > >> Lisp: (jump rabbit 3)
> > >
> > What is this? are you saying that the class rabbit has a static member
> > function that takes a rabbit and a 3? I'm not sure why you would want
> > such a thing..
>
> Most likely you wouldn't, but if you wanted it, that's how it would
> look like. Maybe I should have just written f(a, b) / a.f(b) /
> T::f(a, b), but I kind of wanted to go with the "rabbit jump" thing.
My diagnosis is that you don't actually know C++. Your function
"Rabbit::jump(rabbit, 3)" makes no sense whatsoever. If the rabbit is
being told to jump, it doesn't need to be told it's a rabbit. And if it
is jumping over another rabbit, the other rabbit should be passed as a
reference, not a copy.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> wrote
> My diagnosis is that you don't actually know C++.
ROFL, again. Half a year ago I was randomly chatting with some
colleagues in university. The complexity of C++ came up, and I said,
half-jokingly: "I think only a half-dozen people in the world actually
know C++ really good". The other guy said: "Well, you know Henrik
[one of our 'visiting lecturers'] is really good at C++". To which I
had the perfect once-in-a-lifetime reply: "Of course! After all, *I*
taught him!"
Bottom line, I've used C++ professionally for quite a few years as a
programmer, and I've taught it for some years more. I know it well
enough.
You really shouldn't attempt to make up for your lack of solid
arguments by questioning other people's knowledge. Prove that
*you're* correct, instead of just shouting that *I'm* wrong.
> Your function "Rabbit::jump(rabbit, 3)" makes no sense whatsoever.
Well, it *can* make sense, but that's not the point. You made the
point that C++ has a consistent syntax, and I demonstrated that it
does not, or at least not as consistent as Lisp's.
> If the rabbit is being told to jump, it doesn't need to be told it's a
> rabbit.
Presumably implemented as rabbit.jump(3), another example.
> And if it is jumping over another rabbit, the other rabbit should be
> passed as a reference, not a copy.
Firstly, how can you tell it's a copy and not a reference?
Secondly, it's still the case that if for some arcane reason it's
really imperative to call jump as a class method, there's no good way
of supplying the object that we wish to have jump except by passing it
as an argument. You may still say it's stupid and I might agree, but
it's valid C++.
In article <····························@posting.google.com>,
·············@swipnet.se says...
> Gerry Quinn <······@DELETETHISindigo.ie> wrote
> > Your function "Rabbit::jump(rabbit, 3)" makes no sense whatsoever.
>
> Well, it *can* make sense, but that's not the point. You made the
> point that C++ has a consistent syntax, and I demonstrated that it
> does not, or at least not as consistent as Lisp's.
> Secondly, it's still the case that if for some arcane reason it's
> really imperative to call jump as a class method, there's no good way
> of supplying the object that we wish to have jump except by passing it
> as an argument. You may still say it's stupid and I might agree, but
> it's valid C++.
Fair enough, and I apologise for doubting your knowledge of C++. I
think in part I was misled by your use of the term 'class method' for
what in a purely C++ context would usually be called a 'static method'.
Mainly though, it's probably just that the rabbit example is
exceptionally unsuited to an example of such a method! Sometimes
knowing a language can cause one to be blind to abnormal uses of it...
Of course C++ has a wide variety of usable function syntax, arguably too
wide. Though this is at a tangent to the original point of discussion
anyway.
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> wrote
> Fair enough, and I apologise for doubting your knowledge of C++.
No problem. I *was* being sloppy in my terminology: even if I
personally think 'class method' is a better term than 'static member
function', using a non-standard term will cause confusion.
> Of course C++ has a wide variety of usable function syntax, arguably too
> wide.
One could also argue the other case: 1) maybe different things
*should* be expressed differently. More to learn, but each case is
distinctive. 2) If someone really dislikes the variable syntaxa
(sp?), they could just use overloaded functions for type dispatch.
·············@swipnet.se (Peter Lewerin) writes:
> Gerry Quinn <······@DELETETHISindigo.ie> wrote
>
> > Fair enough, and I apologise for doubting your knowledge of C++.
>
> No problem. I *was* being sloppy in my terminology: even if I
> personally think 'class method' is a better term than 'static member
> function', using a non-standard term will cause confusion.
>
> > Of course C++ has a wide variety of usable function syntax, arguably too
> > wide.
>
> One could also argue the other case: 1) maybe different things
> *should* be expressed differently. More to learn, but each case is
> distinctive. 2) If someone really dislikes the variable syntaxa
> (sp?), they could just use overloaded functions for type dispatch.
Not really, because then they would lose all
polymorphism. Ie. overloaded functions can be used to achieve type
dispatch, but the dispatch will not be polymorphic. Polymorphism is
after all what OO is about.
Bj�rn
·······@nada.kth.se (Bj�rn Lindberg) wrote
> Not really, because then they would lose all
> polymorphism. Ie. overloaded functions can be used to achieve type
> dispatch, but the dispatch will not be polymorphic.
Not *all* polymorphism (if it's useful to cast back to the base class,
it will still work) but most of it is lost, yes. My statement was
more of an observation than an endorsement.
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> I think in part I was misled by your use of the term 'class method'
> for what in a purely C++ context would usually be called a 'static
> method'.
You must mean "static member function." The word "method" never occurs
in ISO/IEC 14882:1998(E) in reference to any kind of function.
--
Steven E. Harris
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <····························@posting.google.com>,
> ·············@swipnet.se says...
> > chris <···@cs.york.ac.uk> wrote
> >
> > > >>Class method call:
> > > >> C++: Rabbit::jump(rabbit, 3)
> > > >> Lisp: (jump rabbit 3)
> > > >
> > > What is this? are you saying that the class rabbit has a static member
> > > function that takes a rabbit and a 3? I'm not sure why you would want
> > > such a thing..
> >
> > Most likely you wouldn't, but if you wanted it, that's how it would
> > look like. Maybe I should have just written f(a, b) / a.f(b) /
> > T::f(a, b), but I kind of wanted to go with the "rabbit jump" thing.
>
> My diagnosis is that you don't actually know C++. Your function
> "Rabbit::jump(rabbit, 3)" makes no sense whatsoever. If the rabbit is
> being told to jump, it doesn't need to be told it's a rabbit. And if it
> is jumping over another rabbit, the other rabbit should be passed as a
> reference, not a copy.
Eh?
1 There is only one rabbit there.
2 You have no way of knowing that it's being passed as a copy
rather than by reference; if the first argument to Rabbit::jump
was declared, say, as "const Rabbit &" then the call would
look just the same.
Of course jumping rabbits as such are of no relevance here;
here's a legitimate circumstance in which you could get a
function call of the kind you're saying is proof that Peter
doesn't know C++.
- Your program has a logging subsystem, based around
a class called Log whose instances are suitable
recipients for logging information.
- The Log class also has some static member functions;
for instance, there's one called "stringify" that
accepts an object reference and returns a string
that describes the object. This is in the Log class
because its behaviour is affected by a number of
parameters that are used elsewhere in the logging
subsystem.
- When a Log object is created and ready to start
logging, the first thing it does is to record some
information about itself for debugging purposes.
- This is done using the "stringify" function.
- So in Log::Log, or perhaps Log::begin or something
of the kind, you have some code that looks like this:
string s = Log::stringify(*this, some, other, parameters);
write_line(... some stuff involving s ...);
This isn't the exact same form as Peter's example, but
I think it's clearly just as "bad". The first argument
(passed by reference) is statically known to be of type Log,
after all.
Note: I don't claim that the above is great design,
and if I were actually designing a logging subsystem
I wouldn't expect it to look quite like that. But
it's certainly not crazy enough to warrant saying
that anyone who'd do it "doesn't actually know C++".
--
Gareth McCaughan
.sig under construc
>>>Class method call:
>>> C++: Rabbit::jump(rabbit, 3)
>>> Lisp: (jump rabbit 3)
>>
> What is this? are you saying that the class rabbit has a static member
> function that takes a rabbit and a 3? I'm not sure why you would want such
> a thing..
>
Who are you replying to?
You've deleted the important part of my email in your response???
In C++, the syntax is:
Rabbit::jump(3)... you do not pass in "rabbit" to this class function.
in C that is:
rabbit_jump(3)... different parameters since we aren't dealing with
an actual object now.
C is consistent across all uses as far as syntax goes, though there is no
data involved in the class method, though there is a data object involved in
all other references, so obviously the syntax must change to reflect this.
"Maahes" <······@internode.on.net> wrote
> In C++, the syntax is:
>
> Rabbit::jump(3)... you do not pass in "rabbit" to this class function.
Is there any language rule that explicity says that?
My point was to show three different ways to call jump with two
parameters; rabbit and 3. Can you give any reason to exclude the
rabbit object in this particular case? What entity will do the
jumping in your scenario?
In any case, a call to a static member function will use the syntax
namespace::name, which is inconsistent with syntax for other calls.
Whether this is good or bad is another issue.
> C is consistent across all uses as far as syntax goes, though there is no
> data involved in the class method,
Again, why is there no data involved in a static member function call?
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <··············@nyct.net>, ·····@nyct.net says...
>> "Maahes" <······@internode.on.net> writes:
>>
>> > Ok, thanx for the heads up.
>> > So Jak and Daxter isn't even a proof that Lisp is useful for games, since
>> > even those programmers decided they needed a variant for it to be useful...
>>
>> This is how lisp always works. You customize the language to the
>> application domain, so that you can describe _what_ you want acheieved,
>> not _how_ you might want it done in some specific situation that may not
>> even be relevant to the final production application.
>
> Of course, this is true of any high level language. In C++,
> customisation comes mostly from defining classes and methods - the
> language syntax remains consistent throughout.
>
> Which seems like a win to me...
The syntax of Lisp is consistent throughout and is consistent even
_before_ you extend the behaviors.
But classes and methods don't encompass all of the ways you want to
express your application's various behaviors. If they did, why do you
need any syntax other than classes and methods?
Why do mathematical operators need to be infix? Just call an add()
method on a number object, passing it another number object and you'll
get the sum back as the result.
Why do you need looping constructs? Just define a class that has methods
for the four parts of the for construct in C -- constructor for the
initialization clause, a step() method for the step clause, a done()
method for the termination test, and a body() method for the loop's
body. Isn't that cleaner?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> And the "bugs in GOAL's compiler" I guess shows that Lisp isn't even
> prooven to be good for writing the compiler..
Don't be silly. You can't possibly expect a completely bug free optimising
compiler for a complex language to be written in a year. The fact that the
compiler was functional at all is a pretty good testament to the quality of
Lisp.
Alex
Maahes wrote:
> Ok, thanx for the heads up.
> So Jak and Daxter isn't even a proof that Lisp is useful for games, since
> even those programmers decided they needed a variant for it to be
> useful...
>
> And the "bugs in GOAL's compiler" I guess shows that Lisp isn't even
> prooven to be good for writing the compiler..
>
> :)
>
>
> "Rahul Jain" <·····@nyct.net> wrote in message
> ···················@nyct.net...
>> Philippa Cowderoy <······@flippac.org> writes:
>>
>>> AIUI GOAL's also a Lisp variant.
>>
>> Yes, but bugs in GOAL's compiler and confusing semantics of GOAL's
>> operators are not a problem with the Lisp that was used to create the
>> compiler. Language design is hard. This is the first attempt at making
>> something that encapsulates the architecture of the Emotion Engine, so
>> I'd expect there to be some impedance mismatches.
>>
>> --
>> Rahul Jain
>> ·····@nyct.net
>> Professional Software Developer, Amateur Quantum Mechanicist
On Sun, 31 Oct 2004, Maahes wrote:
> Ok, thanx for the heads up.
> So Jak and Daxter isn't even a proof that Lisp is useful for games, since
> even those programmers decided they needed a variant for it to be useful...
>
Er, AIUI there's no one language called Lisp so that's not really a valid
statement. You might say Common Lisp isn't useful for games, or Scheme...
--
······@flippac.org
Gerry Quinn wrote:
> In article <··············@yahoo.com>, ··········@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/cellophane-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
In article <······················@twister.nyc.rr.com>,
·······@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/cellophane-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:
> In article <······················@twister.nyc.rr.com>,
> ·······@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/cellophane-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
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <······················@twister.nyc.rr.com>,
> ·······@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/cellophane-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
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?
In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
·······@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
[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.
> 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.
[snips]
On Thu, 28 Oct 2004 18:56:10 +0000, Alex Drummond wrote:
> * Closures
Don't know about those, I'll check the thread - but are these particularly
significant, given that C++ (and presumably C, and presumably umpteen
other similar languages) don't support them? I mean, they can hardly be
the be-all and end-all of programming, right? Just how much of an
improvement _do_ they make over not having them?
> * Macros (ability to add your own control structures, etc.)
Not sure what you mean here, but last I checked, C++ did support macros.
* More sophisticated OO system (multiple dispatch, etc.)
Great. C++'s model is already sufficiently complex to be annoying, and
you want a more complex model?
* Garbage collection.
Never seen this one defended as being actually useful for anything but
hand-holding of incompetent coders.
* More sophisticated exception handling system (allows restarts).
Not sure what "allows restarts" means; if I catch an exception, it's up to
me how to proceed: free some resources and try the operation again, for
example.
> Better idioms for resource control (e.g. unwind-protect). * More
> paradigms suppported: Imperative, OO, functional, logic (if you use a
> library like Screamer).
Okay, this sounds reasonable. Not that I've ever needed imperative or
logic coding, but if one needs them and they can't be accomplished in C or
C++, then, sure.
In article <······························@xxnospamyy.lightspeed.bc.ca>,
Kelsey Bjarnason <·······@xxnospamyy.lightspeed.bc.ca> wrote:
> > * More sophisticated exception handling system (allows restarts).
>
> Not sure what "allows restarts" means; if I catch an exception, it's
> up to me how to proceed: free some resources and try the operation
> again, for example.
With one important difference - in C++ once you get in the handler the
stack has already been unwound. Once this happens, you've lost all your
state, and if there was a way to recover you now have to tediously
rebuild it.
The Common Lisp condition system does not require this - the exception
handler can be run in the dynamic environment of the exception, not the
handler.
More importantly, however, it provides a protocol to present multiple
ways of resolving the error and restarting the computation. These can
be selected either interactively or programatically. The restart is a
function that will usually perform some corrective procedure and then
transfer control to a point where computation can continue.
Of course, if you want "C++-style" exception behavior, where handlers
run after the stack unrolls, it's available.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Kelsey Bjarnason wrote:
> [snips]
>
> On Thu, 28 Oct 2004 18:56:10 +0000, Alex Drummond wrote:
>
>
>>* Closures
>
>
> Don't know about those, I'll check the thread - but are these particularly
> significant, given that C++ (and presumably C, and presumably umpteen
> other similar languages) don't support them? I mean, they can hardly be
> the be-all and end-all of programming, right? Just how much of an
> improvement _do_ they make over not having them?
Closures are a terrific advantage.
>>* Macros (ability to add your own control structures, etc.)
>
>
> Not sure what you mean here, but last I checked, C++ did support macros.
The previous poster is talking about Lisp macros; C and C++ support
nothing like them. C and C++ macros are entirely different animals.
Specifically, C and C++ macros are string substitutions at preprocessing
time; Lisp macros are syntax-tree-to-syntax-tree transformations
performed by a Lisp runtime, with all Lisp operators available to the
code that performs the transformation.
>
> * More sophisticated OO system (multiple dispatch, etc.)
>
> Great. C++'s model is already sufficiently complex to be annoying, and
> you want a more complex model?
'Sophisticated' and 'complex' don't mean the same thing. CLOS is not
distinguished by a startlingly large number of features, but by the
great power CLOS provides for constructing object-oriented language
features.
> * Garbage collection.
>
> Never seen this one defended as being actually useful for anything but
> hand-holding of incompetent coders.
People used to say the same thing about subroutines and recursive
function calls. Like those two once-controversial features, GC makes
programming much easier and less error-prone.
> * More sophisticated exception handling system (allows restarts).
>
> Not sure what "allows restarts" means
It refers to one of the features provided by the CL condition system.
Lisp systems are interactive. When something breaks, you enter an
interactive debugger with the incremental compiler built into it; you
can inspect the state of the runtime, redefine functions and data
structures interactively, and restart the computation from where it
broke. Restarts are user-definable options for resuming computation
after an exception occurs. They can be used either during development,
or to provide exception-handling features in a delivered app, or both.
This kind of exception-handling leads to an idiosyncratic form of
top-down and test-driven development, because you can start with the
toplevel function or with a test definition, and just run it. When it
hits an undefined function or data structure it will of course break,
but you can just define the missing features from the debugger and
continue, repeating that process until the toplevel function runs to
completion, or the test succeeds.
The previous two replies to your post have covered pretty much everything,
but with regard to your statement that most languages don't support
closures, it's not true. Take a look at (for starters):
Python
Ruby
Smalltalk
Perl
Lisp (of course)
Lua
Haskell, ML, etc.
Alex
Kelsey Bjarnason wrote:
> [snips]
>
> On Thu, 28 Oct 2004 18:56:10 +0000, Alex Drummond wrote:
>
>> * Closures
>
> Don't know about those, I'll check the thread - but are these particularly
> significant, given that C++ (and presumably C, and presumably umpteen
> other similar languages) don't support them? I mean, they can hardly be
> the be-all and end-all of programming, right? Just how much of an
> improvement _do_ they make over not having them?
>
>> * Macros (ability to add your own control structures, etc.)
>
> Not sure what you mean here, but last I checked, C++ did support macros.
>
> * More sophisticated OO system (multiple dispatch, etc.)
>
> Great. C++'s model is already sufficiently complex to be annoying, and
> you want a more complex model?
>
> * Garbage collection.
>
> Never seen this one defended as being actually useful for anything but
> hand-holding of incompetent coders.
>
> * More sophisticated exception handling system (allows restarts).
>
> Not sure what "allows restarts" means; if I catch an exception, it's up to
> me how to proceed: free some resources and try the operation again, for
> example.
>
>> Better idioms for resource control (e.g. unwind-protect). * More
>> paradigms suppported: Imperative, OO, functional, logic (if you use a
>> library like Screamer).
>
> Okay, this sounds reasonable. Not that I've ever needed imperative or
> logic coding, but if one needs them and they can't be accomplished in C or
> C++, then, sure.
Alex Drummond <··········@ucl.ac.uk> writes:
> The previous two replies to your post have covered pretty much
> everything, but with regard to your statement that most languages don't
> support closures, it's not true. Take a look at (for starters):
> Python
Afair, python do not have lexical closures (Perl and Ruby has).
> Ruby
> Smalltalk
> Perl
> Lisp (of course)
BTW, Emacs Lisp have them only as option [lexical-let].
> Lua
> Haskell, ML, etc.
>
>
> Alex
Regards, Szymon.
> Afair, python do not have lexical closures (Perl and Ruby has).
It didn't always, but it has now.
Alex
Szymon wrote:
> Alex Drummond <··········@ucl.ac.uk> writes:
>
>> The previous two replies to your post have covered pretty much
>> everything, but with regard to your statement that most languages don't
>> support closures, it's not true. Take a look at (for starters):
>
>> Python
>
> Afair, python do not have lexical closures (Perl and Ruby has).
>
>> Ruby
>> Smalltalk
>> Perl
>> Lisp (of course)
>
> BTW, Emacs Lisp have them only as option [lexical-let].
>
>> Lua
>> Haskell, ML, etc.
>>
>>
>> Alex
>
> Regards, Szymon.
Kelsey Bjarnason <·······@xxnospamyy.lightspeed.bc.ca> writes:
> * Garbage collection.
>
> Never seen this one defended as being actually useful for anything but
> hand-holding of incompetent coders.
Before I started programming in Common Lisp, I felt the same way. My
first introduction to GC was via Java. It looked exactly like a
system for holding the programmer's hand. New without delete?
Sacrilege!
Of course, scripting languages such as Perl, Python, and others all do
automatic memory management. It seems quite natural in that context.
With Lisp, the GC is even more natural. Modern Lisp implementations'
garbage collectors can even outperform manual memory management.
I am very familiar with this prejudice because I held it so long
myself.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Kelsey Bjarnason <·······@xxnospamyy.lightspeed.bc.ca> writes:
> [.....]
> Okay, this sounds reasonable.
> Not that I've ever needed imperative or logic coding,
If you are C/C++ programmer you do imperative programming all time...
example of imperative stuff:
[begin code snippet]
i++;
[end code snippet]
> but if one needs them and they can't be accomplished in C or C++, then,
> sure.
Regards, Szymon.
In article
<······························@xxnospamyy.lightspeed.bc.ca>,
Kelsey Bjarnason <·······@xxnospamyy.lightspeed.bc.ca> 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.
I was responding to something someone wrote about not seeing the
advantages of an interactive language. Come to think of it, I thought
everyone liked interactive languages. Not sure why it needs explaining.
The appeal gave birth to Python, and is giving birth to Groovy, which is
Java's attempt at an interactive extension.
I have heard that some C/C++ tools make brave attempts at interactivity.
If so, great. But I was just explaining to that one person why I liked
an interactive language.
Ah, just thought of another one. Component Workshop. A now-deceased
interactive C++.
As for language benefits: garbage collection, macros, special variables,
untyped variables/typed data; the list datastructure; multimethods,
editing-with-parentheses (shocked?); multiple-inheritance done right;
the meta-object protocol; lexical scoping; closures; first-class
functions; lack of syntax; native-compiled speed; reflection ala RTTI;
the loop macro; &rest, keyword and optional arguments to functions;
different kinds of method combinations; destructuring-bind (long
story);...
kenny
Kelsey Bjarnason <·······@xxnospamyy.lightspeed.bc.ca> writes:
> 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.
You mean that there's a specified protocol for updating instances of a
class when the class's definition has changed in C++? Interesting.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sat, 30 Oct 2004 15:18:27 -0400, Rahul Jain wrote:
> Kelsey Bjarnason <·······@xxnospamyy.lightspeed.bc.ca> writes:
>
>> 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.
>
> You mean that there's a specified protocol for updating instances of a
> class when the class's definition has changed in C++? Interesting.
Which part of "there's nothing preventing X" equates to "there is a
defined mechanism for doing X"?
Oh, right, no part.
> Which part of "there's nothing preventing X" equates to "there is a
> defined mechanism for doing X"?
>
> Oh, right, no part.
It doesn't equate; I think Rahul was just pointing out that the Lisp
language standard guarantees certain behaviour regarding instances of
modified classes, meaning that code which modifies classes can be written
portably. Stricly speaking, non-portable C++ code is not written in C++, it
is written in some sort of (C++)++
Alex
Kelsey Bjarnason wrote:
> On Sat, 30 Oct 2004 15:18:27 -0400, Rahul Jain wrote:
>
>> Kelsey Bjarnason <·······@xxnospamyy.lightspeed.bc.ca> writes:
>>
>>> 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.
>>
>> You mean that there's a specified protocol for updating instances of a
>> class when the class's definition has changed in C++? Interesting.
>
> Which part of "there's nothing preventing X" equates to "there is a
> defined mechanism for doing X"?
>
> Oh, right, no part.
In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
·······@nyc.rr.com says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@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
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
> ·······@nyc.rr.com says...
> > In article <··························@news.indigo.ie>,
> > Gerry Quinn <······@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.
Agreed. Most IDEs are primitive compared to C/C++/Java IDEs. Libraries
are scarcer, though that is beginning to improve a little.
The first Lisp IDE I used did not have an automatic project manager. But
there are a couple of Lisp "make" tools, and my IDE was hackable (in
Lisp), so I kinda just rolled my own project manager in a few hours. And
now it is something I can tweak as I like, which is mad cool and also a
traditional Lisp thing (building one's own little IDE).
And any time I want a library, I lose a few hours globally editing a C
header file until it turns into a set of Lisp bindings to that library.
Using a C++ library also means writing some C glue so Lisp can talk to
it.
But those are finite tasks, and then I am back up to full speed using
Lisp for months on end.
> Especially when Lisp has been touted the same way for about twenty
> years. I've got lots of time to get on the bandwagon...
Yep. I found Lisp when looking for A Better Way than C to do version two
of my commercial app. Something that would let me be vastly more
productive, enough to make up for the occasional one-time effort.
Believe me, Lisp roolz.
kt
Read all that. Understand your gripes, but that's not C++, that's how you
use it.
We've done 8 projects in C++ and never had a failure. And that's on
cross-platform consoles (Gamecube, ps2, xbox, pc) where you cannot have a
crash or significant bug or you can't release the game.
If anyone else has failures, I doubt its because of C++. I have noticed
that some C++ coders have the worst habits of overcomplicating simple
problems that I've ever seen. Again, not C++'s fault, though templates,
references, constructors and inheritance makes it easy to write code that is
unreadable without a debugger.
To stop from failures, we restrict usage of C++ to as simple as possible. 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.
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?
>
>> 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.
>
I've posted elsewhere on this, but in short, you can't reliably move any
memory around to defragment memory on a PS2, because any model that has been
rendered is locked for 3 consequetive frames by the double buffered DMA
lists... So when the GC goes to copy-collect, it will most likely fail...
> 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.
>
agreed.
> 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?
No. Not while a level is in progress. We "malloc" when loading / streaming
in a new level, and "free" when chucking out a previous level. But no
dynamic allocations during the gameplay.
Fredo wrote:
> lol. I can't believe how many people took the bait on this post.
>
> I don't know why anyone who even knows C++ well would respond to such a
> post.
My bad. The post rolled in just as I was investigating how the game industry
uses C++ and _Lua_.
I don't give a dang about trolling so long as the resulting thread can be
on-topic and educational.
However, Lua has no newsgroup, so I guess we must find other ways to fight
over it.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
On Sat, 30 Oct 2004 14:41:41 -0500, "Fredo" <·······@hotmail.com> wrote:
> lol. I can't believe how many people took the bait on this post.
>
> I don't know why anyone who even knows C++ well would respond to
> such a post.
You mean like you just did?
FWIW, because the OP crossposted this stuff I was able to see a lot of
postings that I usually don't see. Some of them contained interesting
technical information but most of them were elucidating more from a
sociological standpoint - I've never seen so many arguments in a short
time frame that were basically like "I've never heard of this, I don't
know what it is, but I can assure you I don't need it." Yeah, sure...
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, ········@agharta.de says...
> I've never seen so many arguments in a short
> time frame that were basically like "I've never heard of this, I don't
> know what it is, but I can assure you I don't need it." Yeah, sure...
It's a pretty valid argument, is it not? For all but evangelists,
anyway...
- Gerry Quinn
On Sun, 31 Oct 2004 12:49:25 -0000, Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·············@agharta.de>, ········@agharta.de says...
>
>> I've never seen so many arguments in a short time frame that were
>> basically like "I've never heard of this, I don't know what it is,
>> but I can assure you I don't need it." Yeah, sure...
>
> It's a pretty valid argument, is it not? For all but evangelists,
> anyway...
I'd say it's a valid argument for someone who routinely refuses to
learn new things. But YMMV, of course.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Why do 99.99% of game companies use C & C++ instead of Lisp...
There's plenty of startup companies that could use Lisp if they wanted to...
It would be extreme arrogance to assume they're all just stupid...
"Edi Weitz" <········@agharta.de> wrote in message
··················@agharta.de...
> On Sun, 31 Oct 2004 12:49:25 -0000, Gerry Quinn
> <······@DELETETHISindigo.ie> wrote:
>
>> In article <·············@agharta.de>, ········@agharta.de says...
>>
>>> I've never seen so many arguments in a short time frame that were
>>> basically like "I've never heard of this, I don't know what it is,
>>> but I can assure you I don't need it." Yeah, sure...
>>
>> It's a pretty valid argument, is it not? For all but evangelists,
>> anyway...
>
> I'd say it's a valid argument for someone who routinely refuses to
> learn new things. But YMMV, of course.
>
> Edi.
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
You talk about fashion (what language the mass uses) and claim that
the current most popular language is the best. Statements of that
form are rarely correct, and this particular one is spectacularly
wrong.
Instead of posting in this interminable (and mostly uninformed)
fashion, why not try to put your code where your mouth is? Pick some
problem that can be solved, without libraries, in some small
number-let's say 200-of lines of C/C++. Then I'll do the same in
lisp. Then we both solve both problems, and see how much
processor/memory/lines of code/time it takes for each of the 4
solutions.
"Maahes" <······@internode.on.net> wrote in message news:<········@duster.adelaide.on.net>...
> Why do 99.99% of game companies use C & C++ instead of Lisp...
> There's plenty of startup companies that could use Lisp if they wanted to...
>
> It would be extreme arrogance to assume they're all just stupid...
>
>
>
> "Edi Weitz" <········@agharta.de> wrote in message
> ··················@agharta.de...
> > On Sun, 31 Oct 2004 12:49:25 -0000, Gerry Quinn
> > <······@DELETETHISindigo.ie> wrote:
> >
> >> In article <·············@agharta.de>, ········@agharta.de says...
> >>
> >>> I've never seen so many arguments in a short time frame that were
> >>> basically like "I've never heard of this, I don't know what it is,
> >>> but I can assure you I don't need it." Yeah, sure...
> >>
> >> It's a pretty valid argument, is it not? For all but evangelists,
> >> anyway...
> >
> > I'd say it's a valid argument for someone who routinely refuses to
> > learn new things. But YMMV, of course.
> >
> > Edi.
> >
> > --
> >
> > Lisp is not dead, it just smells funny.
> >
> > Real email: (replace (subseq ·········@agharta.de" 5) "edi")
matt knox wrote:
> You talk about fashion (what language the mass uses) and claim that
> the current most popular language is the best. Statements of that
> form are rarely correct, and this particular one is spectacularly
> wrong.
>
> Instead of posting in this interminable (and mostly uninformed)
> fashion, why not try to put your code where your mouth is? Pick some
> problem that can be solved, without libraries, in some small
> number-let's say 200-of lines of C/C++. Then I'll do the same in
> lisp. Then we both solve both problems, and see how much
> processor/memory/lines of code/time it takes for each of the 4
> solutions.
>
Better yet, make the problems public.
I *love* a decent challenge.
On Sun, 31 Oct 2004 22:59:35 +0100, Svein Ove Aas wrote:
> matt knox wrote:
>> You talk about fashion (what language the mass uses) and claim that
>> the current most popular language is the best. Statements of that
>> form are rarely correct, and this particular one is spectacularly
>> wrong.
>>
>> Instead of posting in this interminable (and mostly uninformed)
>> fashion, why not try to put your code where your mouth is? Pick some
>> problem that can be solved, without libraries, in some small
>> number-let's say 200-of lines of C/C++. Then I'll do the same in
>> lisp. Then we both solve both problems, and see how much
>> processor/memory/lines of code/time it takes for each of the 4
>> solutions.
>>
> Better yet, make the problems public.
> I *love* a decent challenge.
http://www.frank-buss.de/challenge/index.html
Also http://shootout.alioth.debian.org/
--
"If all else fails, immortality can always be assured by spectacular
error." -- John Kenneth Galbraith
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley wrote:
> On Sun, 31 Oct 2004 22:59:35 +0100, Svein Ove Aas wrote:
>
>> matt knox wrote:
>>> You talk about fashion (what language the mass uses) and claim that
>>> the current most popular language is the best. Statements of that
>>> form are rarely correct, and this particular one is spectacularly
>>> wrong.
>>>
>>> Instead of posting in this interminable (and mostly uninformed)
>>> fashion, why not try to put your code where your mouth is? Pick some
>>> problem that can be solved, without libraries, in some small
>>> number-let's say 200-of lines of C/C++. Then I'll do the same in
>>> lisp. Then we both solve both problems, and see how much
>>> processor/memory/lines of code/time it takes for each of the 4
>>> solutions.
>>>
>> Better yet, make the problems public.
>> I *love* a decent challenge.
>
> http://www.frank-buss.de/challenge/index.html
>
> Also http://shootout.alioth.debian.org/
>
Been there, done that, didn't bother to get the t-shirt.
Thanks anyway, though.
···········@gmail.com (matt knox) wrote in message news:<····························@posting.google.com>...
[ ... ]
> Instead of posting in this interminable (and mostly uninformed)
> fashion, why not try to put your code where your mouth is? Pick some
> problem that can be solved, without libraries, in some small
> number-let's say 200-of lines of C/C++.
"without libraries" produces an artificial environment so the results
become meaningless at best. C++ is defined to include a standard
library, and for most practical purposes is non-functional without it
(e.g. the language proper includes no I/O facilities at all). Worse,
one of the major (and explicit) motivations in the design of C++ is to
improve the ability to both design and use libraries.
> Then I'll do the same in
> lisp. Then we both solve both problems, and see how much
> processor/memory/lines of code/time it takes for each of the 4
> solutions.
I've seen a few challenges on this general order, but while the
results are usually interesting, I've yet to see many that were really
very meaningful.
Consider, for example, what happens if I post 200 lines from an OS
kernel. Now, many of the algorithms in an OS kernel are pretty simple,
and could certainly be expressed in Lisp quite easily -- but in most
cases, the result wouldn't be usable.
Another possibility is when something that looks like (and really IS)
C or C++ is interpreted as SystemC, which compiles the code all the
way down to gates for an FPGA (or CPLD, ASIC, etc.) Just for example,
I could write something that emulates a CPU in C. It could be
translated to Lisp and also emulate a CPU. But the C can also be
compiled as SystemC to produce a real, live CPU. In theory the same
thing _should_ probably be possible from Lisp -- but I'm not aware of
a toolset that will really do it. By contrast, I've taken a fair
number of algorithms written in C and C++, and made them run on a FPGA
with only minimal extra work (mostly doing a constraints file that
designates what pins will be used for the inputs and outputs).
--
Later,
Jerry.
The univserse is a figment of its own imagination.
·······@taeus.com (Jerry Coffin) wrote in message news:<···························@posting.google.com>...
[ ... ]
> Now, many of the algorithms in an OS kernel are pretty simple,
> and could certainly be expressed in Lisp quite easily -- but in most
> cases, the result wouldn't be usable.
Rereading this, it occurs to me that it could be interpreted as
implying that only "pretty simple" algorithms can be expressed in
Lisp, which was NOT my intent at all -- I was thinking of the hundred
to two hundred line limit previously expressed, and thinking that
quite a few of them could fit within this limit in either C++ or Lisp.
I apologize if anybody was insulted by my poor wording.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin wrote:
> ...
> Another possibility is when something that looks like (and really IS)
> C or C++ is interpreted as SystemC, which compiles the code all the
> way down to gates for an FPGA (or CPLD, ASIC, etc.) Just for example,
> I could write something that emulates a CPU in C. It could be
> translated to Lisp and also emulate a CPU. But the C can also be
> compiled as SystemC to produce a real, live CPU. In theory the same
> thing _should_ probably be possible from Lisp -- but I'm not aware of
> a toolset that will really do it.
afaik, AMD used a lisp written system to verify the design of their 64
bit processors. search for ACL2 (sorry, don't have the url handy)
> By contrast, I've taken a fair
> number of algorithms written in C and C++, and made them run on a FPGA
> with only minimal extra work (mostly doing a constraints file that
> designates what pins will be used for the inputs and outputs).
i briefly looked at the ACL2 website, and it seems quite capable of dong
that
hs
Hartmann Schaffer <··@hartmann.schaffernet> writes:
> afaik, AMD used a lisp written system to verify the design of their 64
> bit processors. search for ACL2 (sorry, don't have the url handy)
It's a debian package, if anyone cares.
The code is at:
ftp://ftp.cs.utexas.edu:/pub/moore/acl2/v2-8/
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
·······@taeus.com (Jerry Coffin) writes:
> Another possibility is when something that looks like (and really
> IS) C or C++ is interpreted as SystemC, which compiles the code all
I don't think this apply to a lot of applications. Further most
programs will benefit using a different algorithm when mapped to a
FPGA (or ASIC) from a Von Neumann architecture. An example is CRC
calculation which is usually implemented using a table in software,
but the using xor gates which have been parallelized from the serial
form in hardware.
You will find quite a bit of Lisp influence in the EDA world. Take a
look at the EDIF format, it's Lisp. SDF files for back annotation,
it's Lisp. Also some major EDA applications like Cadence Design
Planner was written in Lisp.
I use Common Lisp to increase my design productivity. I've written
tools to parallelize CRC, explore architectures, microcode assembler
generators, test environment to ASIC's that I've designed, etc. Even
though I know C++ (started C++ programming in the late 80's) better
than Common Lisp I'm more productive in Common Lisp and hence this is
the language of my choice.
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?
"Maahes" <······@internode.on.net> writes:
> Why do 99.99% of game companies use C & C++ instead of Lisp...
> There's plenty of startup companies that could use Lisp if they wanted to...
>
> It would be extreme arrogance to assume they're all just stupid...
It would not be arrogant to suppose that they are largely uninformed.
absolutely it would.
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> "Maahes" <······@internode.on.net> writes:
>
>> Why do 99.99% of game companies use C & C++ instead of Lisp...
>> There's plenty of startup companies that could use Lisp if they wanted
>> to...
>>
>> It would be extreme arrogance to assume they're all just stupid...
>
> It would not be arrogant to suppose that they are largely uninformed.
"Maahes" <······@internode.on.net> writes:
> Why do 99.99% of game companies use C & C++ instead of Lisp...
> There's plenty of startup companies that could use Lisp if they wanted to...
>
> It would be extreme arrogance to assume they're all just stupid...
It took a while for things like electricity and telephones to catch on
as well. Don't even get me started on indoor plumbing.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
everyone loves a good Language Vs Language argument, no matter what the
languages...
"Fredo" <·······@hotmail.com> wrote in message
···························@giganews.com...
> lol. I can't believe how many people took the bait on this post.
>
> I don't know why anyone who even knows C++ well would respond to such a
> post.
>
> Fredo
>
>
I agree.
On 25 Oct 2004 05:11:44 -0700, Neo-LISPer <··········@yahoo.com>
wrote:
>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.
Are you kidding or what?
Do you actually think games should be written in Lisp???
C++ is slow???
C++ is fast and the speed comes from it beeing non interpreted. The
speed also comes from other things like non-garbage collecting.
OK you do sacrify some flexibility by using a non interpreted
language, but what you gain is speed.
And when it comes to Lisp, have you even considered the huge function
overhead?
If you think C++ is slow then you must be doing it wrong!
CII <·····@laposte.net> wrote in message news:<··································@4ax.com>...
> I agree.
>
> On 25 Oct 2004 05:11:44 -0700, Neo-LISPer <··········@yahoo.com>
> wrote:
>
> >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.
[Note followups]
marcus wrote:
> C++ is fast and the speed comes from it beeing non interpreted.
> The speed also comes from other things like non-garbage
> collecting.
Believe what you like to believe. The fact that C++ is compiled
does not automatically make your programs fast.
> OK you do sacrify some flexibility by using a non interpreted
> language, but what you gain is speed.
Prove it.
> And when it comes to Lisp, have you even considered the huge
> function overhead?
What does that mean?
> If you think C++ is slow then you must be doing it wrong!
In the hands of someone who knows nothing about other programming
languages, it is quite likely that some problems are solved in
less efficient ways.
-tom!
--
There's really no reason to send a copy of your
followup to my email address, so please don't.
On 4 Apr 2005 23:00:07 -0700, ··············@koping.net (marcus) wrote:
> Are you kidding or what?
> Do you actually think games should be written in Lisp???
> C++ is slow???
> C++ is fast and the speed comes from it beeing non interpreted.
That sounds as if you think that Lisp is interpreted. You probably
don't know better but then you shouldn't publicly discuss these things
in several newsgroups.
Edi.
PS: Follow-ups set.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
marcus schrieb:
> Are you kidding or what?
> Do you actually think games should be written in Lisp???
> C++ is slow???
> C++ is fast and the speed comes from it beeing non interpreted. The
> speed also comes from other things like non-garbage collecting.
>
> OK you do sacrify some flexibility by using a non interpreted
> language, but what you gain is speed.
>
> And when it comes to Lisp, have you even considered the huge function
> overhead?
Did you know that Lisp code usually gets compiled to native machine
code? During programming you sometimes use an interpreter to do little
tests which speed up programming (because you can see results without
compiling and testing the running program).
Did you also know that you can change compiled code with Lisp *during
runtime*? How would you like it to fix some bugs or change some
algorithms while you are testing the running program without the need to
stop it (and thereby possibly lose a lot of data)?
Andr�
--
You cant just agree mate - you need reason
You say c++ is no good for games....
And yet 90% of modern games on PC and ported to ( consoles ) are designed
and implemented using c++ with a directx library. The top speck 3D game
engines of
their time quake2, unreal, now Halo - all built with C++ & DirectX (or
variant ).
If you don't need a class structure use a struct. Only use c++ structure
where
it is beneficial. For example:
My 3d engines graphics class (not using direct x)
contains an set of void functions such as plot, line , polyfill, raster etc
When the engine loads these functions are assigned to a fully optimised
version
of that function for the specified graphics mode!
for example i have mode13, 64k, + 16.7 million colours and 32Bit plotting
functions
each optimised to to their specific function. A global version of the
graphics class
exists MX3D_GRAPHICS and is declared in the class header file.
All of my functions simply reference MX3D_GRAPHICS->plot(x,y,r,g,b)
and have instant access to a fully optimised plotting function
Not only is this an extreme optimisation to performance but build time
is exponentially reduced, debugging time is limited a function call rather
than a trace through countless ifs and switch / case statements.
I really don't see your problem with C++, its mostly backward compatible
you can still implement asm, linear frame buffer (no memory restrictions)
most of the C functions still work the same - the only diference is that
there is
some extra functionality- polymorphism, inheritance etc that can make
programming
easier for you.
It seems like your looking for an excuse not to use it, maybe your just not
very
good at it.
From the rest of us who don't mind using C++, your negative comments don't
serve any productive purpose so - get fucked!
On Tue, 5 Apr 2005 13:31:20 +1000, "nokturnal"
<··········@sapiersoftware.com> wrote:
>You cant just agree mate - you need reason
>
>You say c++ is no good for games....
>
>And yet 90% of modern games on PC and ported to ( consoles ) are designed
>... blah blah
>
>It seems like your looking for an excuse not to use it, maybe your just not
>very
>good at it.
>
>From the rest of us who don't mind using C++, your negative comments don't
>serve any productive purpose so - get fucked!
>
>
>
Hmm.. So my comments are negative simply because I happen to agree
with a point of view.. Interesting.
I posted that I AGREE for two reasons:
1- Because I do agree that C and C++ do suck for game programming,
and
2- To show my support of opinion no matter how old the thread.
Not all of us are "turned" yet you know. I for one still stand.
C++ is not "sacrus selectus" either . I have a Right to dissent and
to be myself. This should be a place for discussions, not for fights,
I believe. You C plusplusmongers make it sound like there's no life
outside of C. Oh brother.
Some C++ users I've known sound to me much like GW Bush when one
happens to disagree with their point of view. If C++ is so great, why
the anger and insults towards anyone who happens to disagree with
them?
I could give you many technical reasons for why I don't like or use C
(or C++, I don't care which), but I just don't have the time.
Besides, it seems to me that it all boils down to a matter of beliefs.
Incredible isn't it, how a high level "neat and bubbly" programming
language has managed to turn into some kind of sect.
Either way, a fact is a fact. It's true that C plus plus is used
widely over the industry, but that doesn't necessarily mean it's a
good language because of that. Another fact is that C p p as a
language is wasteful and obscure at best. Those are facts too.
I'll stick to hardware and machine language in the mean time.
Like I said, my opinion is my opinion and I have a right to it, so
move on with your life and be content with whatever it is that you do,
df.
Cheers.
The Soul is the Warrior.
CII wrote:
> Some C++ users I've known sound to me much like GW Bush when one
> happens to disagree with their point of view.
i think you're misunderestimating us c++ programmers.
indi
p.s. you should be properly shocked and awed by that response that i
declare victory in this exchange. i do not believe this to be premature.
--
Mark A. Gibbs (aka. Indi)
Administrator
#c++ on irc.Rizon.net
·····························@rogers.com/
(temporary website)
On Tue, 05 Apr 2005 02:39:37 -0400, "Mark A. Gibbs"
<···········@rogers.com_x> wrote:
>
>CII wrote:
>
>> Some C++ users I've known sound to me much like GW Bush when one
>> happens to disagree with their point of view.
>
>i think you're misunderestimating us c++ programmers.
>
>indi
>
>p.s. you should be properly shocked and awed by that response that i
>declare victory in this exchange. i do not believe this to be premature.
I'm not "misunderestimating" anybody. I mean no offense.
Note how I said "Some C++ users I've known".
how can you say:
" I'm not "misunderestimating" anybody. I mean no offense.
Note how I said "Some C++ users I've known"."
when you agreed with this comment:
>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.
"nokturnal" <··········@sapiersoftware.com> writes:
> how can you say:
>
> " I'm not "misunderestimating" anybody. I mean no offense.
> Note how I said "Some C++ users I've known"."
>
> when you agreed with this comment:
>
> >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.
The original original post was a parody in the first place. It's
unfortunate that this thread has been resurrected.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
In article <··································@4ax.com>,
·····@laposte.net says...
> On Tue, 5 Apr 2005 13:31:20 +1000, "nokturnal"
> <··········@sapiersoftware.com> wrote:
>
> >You cant just agree mate - you need reason
> >
> >You say c++ is no good for games....
> >
> >And yet 90% of modern games on PC and ported to ( consoles ) are designed
> >... blah blah
>
> Hmm.. So my comments are negative simply because I happen to agree
> with a point of view.. Interesting.
>
> I posted that I AGREE for two reasons:
>
> 1- Because I do agree that C and C++ do suck for game programming,
> and
> 2- To show my support of opinion no matter how old the thread.
And it IS an old thread. There was a long and extensive thread to the
original silly post by a Lisp fanatic. Who, like most, has never
produced even a shareware game.
> C++ is not "sacrus selectus" either . I have a Right to dissent and
> to be myself. This should be a place for discussions, not for fights,
> I believe. You C plusplusmongers make it sound like there's no life
> outside of C. Oh brother.
There certainly are games outside of C/C++. Very few of them are in
Lisp, though, although they are not completely unknown (there was one
discussed recently here). And reading down, very few are coded in
assembly nowadays, though I don't doubt that the odd inner loop still
benefits.
What irritates some of us is the frequent assertion by Lisp-ers that
they are somehow superior to the common herd, coupled with the somewhat
modest ouevre of games - and other software - actually produced using
what is quite a long-established language with a vociferous crowd of
advocates.
[Cue, no doubt, presentation of The List, with about ten programs on it
from all fields, some of which have been re-written in other languages
since.]
> Some C++ users I've known sound to me much like GW Bush when one
> happens to disagree with their point of view. If C++ is so great, why
> the anger and insults towards anyone who happens to disagree with
> them?
I always wonder at the mentality of the US left-wingers who regularly
screech the vilest abuse while still taking great offence if anyone on
the right makes a civil observation that hurts their little feelingses.
I've heard Bush can be a little tetchy when provoked, but that is
hardly something confined to any particular shade of political opinion.
I don't recall him directing a stream of insults at anyone just for
having a different opinion. Still, off-topic here.
> I could give you many technical reasons for why I don't like or use C
> (or C++, I don't care which), but I just don't have the time.
>
> Besides, it seems to me that it all boils down to a matter of beliefs.
> Incredible isn't it, how a high level "neat and bubbly" programming
> language has managed to turn into some kind of sect.
Uh... which language are you talking about here? Because of the three
languages mentioned so far, C, C++ and Lisp, only one looks anything
like a sect from where I sit. [Reading a thread started by a Lisp
prosyletiser who shows the usual signs. Note the name 'NeoLisper'
which shows identification with the fictional superhero Neo who through
his intuitive understanding of virtual reality code can bring about
miracles simply by desiring a particular end. This is of course an
expression of the Lisp-AI fantasy of, I don't know, twenty years ago,
in which users believed that if they used a sufficiently self-
referential language, AI would appear by magic. Evidently some people
still believe that, or something like it.]
Certainly C-ers and C++-ers often criticise each others' language
vigorously. But both somehow manage to Get Stuff Done. You rarely see
somebody posting unprovoked all over usenet about how C or C++ is the
best thing since sliced bread without actually having developed some
non-trivial program using it. And I've often been involved in
arguments about how to use C++. If C/C++ is a sect, it's a fissiparous
one.
> Either way, a fact is a fact. It's true that C plus plus is used
> widely over the industry, but that doesn't necessarily mean it's a
> good language because of that. Another fact is that C p p as a
> language is wasteful and obscure at best. Those are facts too.
>
> I'll stick to hardware and machine language in the mean time.
> Like I said, my opinion is my opinion and I have a right to it, so
> move on with your life and be content with whatever it is that you do,
> df.
Hardware and machine language. Read - modern programming languages are
too complicated and I'm frightened. If you've actually produced a
worthwhile distributable game (even a simple freeware one), I withdraw
that comment. Otherwise, I'd recommend you at least try one of the
game-related Basics, if you want to produce an actual game.
- Gerry Quinn
["Followup-To:" header set to comp.lang.c++.]
On Tue, 5 Apr 2005 09:55:45 +0100,
Gerry Quinn <······@DELETETHISindigo.ie> wrote
in Msg. <··························@news.indigo.ie>
> What irritates some of us is the frequent assertion by Lisp-ers that
> they are somehow superior to the common herd, coupled with the somewhat
> modest ouevre of games - and other software - actually produced using
> what is quite a long-established language with a vociferous crowd of
> advocates.
Programming language advocacy is beyond my mental capacities anyway. If
you are happy using some language to solve certain problems, then by all
means continue to do so. And if the majority of people use the wrong
approach you can even commercially exploit your competetive edge you. Why
annoy the errant majority on Usenet?
--Daniel
firstly i find it offensive that you agree with this comment!
>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.
secondly - Quake 2 source code downloadable from ftp.idsoftware.com check it
out
if memory serves me correct c++ was the language of choice - if not it is
definately C.
finally - Contrary to your view of my response I do not recall saying any
negative
comments regarding lisp'ers. Im sure there isn't a real programmer out there
who
wouldn't agree with me when i say you should learn every language you can
before
choosing a speciality. I tried lisp in Emacs on my linux box - didn't like
it
i also do assemby, VB, Java and wouldn't use anything else but C / C++ for
3D programming.
Im sure lisp has its forte - AI but then again my partner asures me that
prolog is a much better.
So since you decided to agree with captain anal about our herd of neglegent
c++ programmers
please enlighten me as to what lisp has to offer that other languages don't!
..nokturnal
"nokturnal" <··········@sapiersoftware.com> wrote:
> secondly - Quake 2 source code downloadable from ftp.idsoftware.com
> check it out
> if memory serves me correct c++ was the language of choice - if not it
> is definately C.
why didn't you load the source? I don't know how it looks like for the
current version, because it needs a Quake2 installation, but in the "old"
directory on the server is a file q2source_12_11.zip, with about 1 mb C
sources and headers and about 500 kb scripts. And the C source has many
inline defined lists, for example the AI code. Looks a bit like if I would
write it in Lisp :-)
> So since you decided to agree with captain anal about our herd of
> neglegent c++ programmers
> please enlighten me as to what lisp has to offer that other languages
> don't!
one of the main advantages of Lisp, at least for me, is the interactive
environment. Other languages has it, too, like Smalltalk or BeanShell for
Java, but I don't know a C++ implementation, which provides something
similar.
Another nice feature are Lisp macros. A Lisp macro is Lisp code, executed
at compile time to produce Lisp code, for example you can enhance the
language by a "foreach" statement with a macro. This is not possible with C
and complicated with C++.
A buggy example of a Lisp game I'm writing:
http://www.frank-buss.de/lisp/aqueduct.html
This proves at least that it is possible to write games in Lisp. And you
can access the OS from Lisp, like I've done in CL-Canvas, which I've used
in my texture generator:
http://www.frank-buss.de/lisp/texture.html
The version on the website took some minutes to calculate the last texture,
but an optimized version, in Lisp of course, creates and shows the last
texture in 0.4 seconds. So together with ephemeral GCs, like enabled by
default in LispWorks, it should be possible to create modern games with
smooth and flicker free animations in Lisp.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
okay it got the better of me - i downloaded it again
and i have to say - Its C. there are a few java class files
as well but the majority of the files contain C.
Extraction:
void chick_pain (edict_t *self, edict_t *other, float kick, int damage)
{
float r;
if (self->health < (self->max_health / 2))
self->s.skinnum = 1;
if (level.time < self->pain_debounce_time)
return;
self->pain_debounce_time = level.time + 3;
r = random();
if (r < 0.33)
gi.sound (self, CHAN_VOICE, sound_pain1, 1, ATTN_NORM, 0);
else if (r < 0.66)
gi.sound (self, CHAN_VOICE, sound_pain2, 1, ATTN_NORM, 0);
else
gi.sound (self, CHAN_VOICE, sound_pain3, 1, ATTN_NORM, 0);
if (damage <= 10)
self->monsterinfo.currentmove = &chick_move_pain1;
else if (damage <= 25)
self->monsterinfo.currentmove = &chick_move_pain2;
else
self->monsterinfo.currentmove = &chick_move_pain3;
}
I don't usually like to nitpick, but please spell-check!
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: C++ sucks for games
Date:
Message-ID: <d2v5ka$sp9$1@ulric.tng.de>
nokturnal schrieb:
> Im sure lisp has its forte - AI but then again my partner asures me that
> prolog is a much better.
The funny thing is that you can do logic programming in Lisp. With
around one day of work you can program proglog inside of Lisp.
Andr�
--
CII wrote:
> C++ is not "sacrus selectus" either . I have a Right to dissent and
> to be myself. This should be a place for discussions, not for fights,
> I believe. You C plusplusmongers make it sound like there's no life
> outside of C. Oh brother.
I found the first post with which you agreed, more of an attempt to
fight than the response that you reply to here.
I'm not biased either as C++ isn't a my primary programming language,
nor do I do any games development. The first post was purely a troll and
has no place here.
Lionel.
nokturnal wrote:
> You cant just agree mate - you need reason
>
> You say c++ is no good for games....
>
> And yet 90% of modern games on PC and ported to ( consoles ) are
> designed and implemented using c++ with a directx library. The
> top speck 3D game engines of their time quake2, unreal, now Halo
> - all built with C++ & DirectX (or variant ).
You might try spending some time learning a thing or two about
what you're talking about.
Alas, it is true that an easy way to learn without much effort is
to post completely incorrect information on the Usenet and just
wait for someone to come by and learn ya.
Quake 2 in C++ and DirectX? Ha that's funny.
Halo in C++ on the PC and ported to the console? Ha, that's
funny too.
(Tip- the answer to the above two mini-paragraphs' questions are
both "no and no".)
> If you don't need a class structure use a struct. Only use c++
> structure where it is beneficial.
Oh master of C++ enlighten us on the differences between a struct
and a class. I'm guessing your answer will be totally wrong, and
searching Google for the C++-FAQ-Lite on parashift.com might in
fact learn ya some more.
> My 3d engines graphics class (not using direct x) contains an set
> of void functions such as plot, line , polyfill, raster etc When
> the engine loads these functions are assigned to a fully
> optimised version of that function for the specified graphics
> mode!
Don't assume that because you use something in school that it's
used in "the real world." Oftentimes the school environment is
tailored for learning more than doing.
When I was in college there was this graphics class that I took,
and guess what, it was all in C and it was just as Bjarne was
rolling out the first versions of CFront! Yay me!
> for example i have mode13, 64k, + 16.7 million colours and 32Bit
> plotting functions each optimised to to their specific function.
> A global version of the graphics class exists MX3D_GRAPHICS and
> is declared in the class header file.
And the reason you couldn't do exactly the same thing in C or
Java or Lisp is what exactly?
> All of my functions simply reference MX3D_GRAPHICS->plot(x,y,r,g,b)
> and have instant access to a fully optimised plotting function
>
> Not only is this an extreme optimisation to performance but build time
> is exponentially reduced, debugging time is limited a function call rather
> than a trace through countless ifs and switch / case statements.
What in the hell are you talking about? "Extreme optimization"
in what appears to be using virtual functions? <Cue Christer
Ericson.>
> I really don't see your problem with C++, its mostly backward
> compatible you can still implement asm, linear frame buffer (no
> memory restrictions) most of the C functions still work the same
> - the only diference is that there is some extra functionality-
> polymorphism, inheritance etc that can make programming easier
> for you.
You might take some time to learn about some other languages
before talking about how much better C++ is. For instance, there
are some "interpreted" languages that can have very good
performance characteristics compared to C or C++ because of the
way the language is built and because of how the interpreter is
allowed to cache off information.
> It seems like your looking for an excuse not to use it, maybe
> your just not very good at it.
One person who is in this thread has demonstrated not being very
good at it, and it's not the person you're responding to.
> From the rest of us who don't mind using C++, your negative
> comments don't serve any productive purpose so - get fucked!
Let's hear it for productive comments! Yay you!
Sorry to comp.lang.*. Note followups.
-tom!
--
There's really no reason to send a copy of your
followup to my email address, so please don't.
CII wrote:
> I agree.
>
> On 25 Oct 2004 05:11:44 -0700, Neo-LISPer <··········@yahoo.com>
> wrote:
>
>
>>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.
>
>
It would appear that this troll was fed.
Lionel.