Hey
Recently, I researched using C++ for game programming and here is what
I found:
C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
Unsurprisingly, there is a very high failure rate among projects using
C++ for modern game development.
You can not even change function definitions while the program is
running and see the effects live (the ultimate debugging tool).
Alternatively, you can't execute a small portion of the program
without compiling and linking the whole thing, then bringing your game
into a specific state where your portion of the code is being executed.
The static type system locks you into a certain design, and you can't
*test* new ideas, when they come to you, without redesigning your
whole class hierarchy.
C++ is so inflexible, even those who do use it for games, have to
write their game logic in some other language (usually very slow,
inexpressive and still garbage collected). They also have to interface
the two languages.
C++ lacks higher-order functions. Function objects emulate them
poorly, are slow and a pain to use. Additionally, C++ type system does
not work well with function objects.
C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.
C++ coding feels very repetitive, for example, when writing class
accessors, you often have to write const and non-const methods with
completely identical function bodies. Just look at STL.
When programming in C++ you feel like a blind person trying to draw
something. You don't _see_ the data structures that your procedures
will operate on. Lisp programming is much more visual.
Constructors and smart pointers make it hard to tell cheap operations
from expensive ones.
C++ lacks automatic memory management and so it encourages copying
objects around to make manual memory management manageable.
Reference-counting schemes are usually slower than modern garbage
collectors and also less general.
Most important, C++ syntax is irregular, and you often find yourself
typing repetitive patterns again and again - a task easily automated
in languages with simpler syntax. There are even books on C++
patterns, and some C++ experts take pride in being able to execute
those patterns with computer-like precision - something a computer
should be doing to begin with.
C++ programs are slow: even though the compilers are good at
micro-optimizing the code, programmers waste their time writing
repetitive patterns in C++ and debugging memory corruption instead of
looking for better algorithms that are far more important for speed
than silly micro-optimizations.
It's hard to find good programmers for C++ projects, because most of
the good programmers graduated to languages like Lisp or avoided C++
altogether. C++ attracts unimaginative fellows with herd mentality.
For creative projects, you want to avoid them like a plague.
It is my opinion that all of the above makes C++ a very bad choice for
commercial game development.
Jul 22 '05
761  28011 
> 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/custome...nichimen.lhtml.
Alex
Gerry Quinn wrote: In article <cm**********@uns-a.ucl.ac.uk>, a.********@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
> 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" <rj***@nyct.net> wrote in message
news:87************@nyct.net... Philippa Cowderoy <fl****@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
rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>> 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 <cm**********@uns-a.ucl.ac.uk>, a.********@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 <cm**********@uns-a.ucl.ac.uk>, a.********@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
Brian Downing <se***********@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 rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Maahes" <ma****@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 rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Gerry Quinn <ge****@DELETETHISindigo.ie> writes: In article <87************@nyct.net>, rj***@nyct.net says... Gerry Quinn <ge****@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 rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Gerry Quinn <ge****@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/ansidocstor...26-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?
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" <ma****@internode.on.net> wrote in message news:<41******@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" <sp******@agharta.de> wrote in message
news:uz***********@agharta.de... On Sun, 31 Oct 2004 12:49:25 -0000, Gerry Quinn
<ge****@DELETETHISindigo.ie> wrote:
In article <ui***********@agharta.de>, sp******@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 "sp******@agharta.de" 5) "edi")
Following up on myself :-/
David Steuber <da***@david-steuber.com> writes: jc*****@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 jc*****@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
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>"))
Alex Drummond <a.********@ucl.ac.uk> wrote in message news:<cm**********@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.
Gerry Quinn <ge****@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
"Maahes" <ma****@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
David Steuber <da***@david-steuber.com> writes: Gerry Quinn <ge****@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.
David Steuber wrote: Gerry Quinn <ge****@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 <ne*****@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/macr...g-our-own.html
cheers,
BM
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.
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
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. ma*********@gmail.com (matt knox) wrote in message news:<ab**************************@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.
In article <87************@p4.internal>, bm@acm.org says... >> "GQ" == Gerry Quinn <ge****@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 <87************@david-steuber.com>, da***@david-steuber.com
says... Gerry Quinn <ge****@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
In article <Jf********************@golden.net>, cm********@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
In article <cm**********@uns-a.ucl.ac.uk>, a.********@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
In article <cm**********@uns-a.ucl.ac.uk>, a.********@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 <87************@nyct.net>, rj***@nyct.net says... "Maahes" <ma****@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 <ge****@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
>> 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 <a.********@ucl.ac.uk> wrote in message
news:<cm**********@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.
> 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 <87************@p4.internal>, bm@acm.org says... >>>>> "GQ" == Gerry Quinn <ge****@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
On Mon, 1 Nov 2004, Gerry Quinn wrote: In article <cm**********@uns-a.ucl.ac.uk>, a.********@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.
-- fl****@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 <cm**********@uns-a.ucl.ac.uk>, a.********@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 <ge****@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 <ip******@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
jc*****@taeus.com (Jerry Coffin) wrote in message news:<b2*************************@posting.google.c om>...
[ ... ] 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.
Bulent Murtezaoglu <bm@acm.org> writes: >> "JB" == Jon Boone <ip******@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 jc*****@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?
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
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 <87************@g.mccaughan.ntlworld.com>,
Gareth McCaughan <ga**************@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
Petter Gustad <ne***********@gustad.com> writes: [.....]
(+ (complex 3 3) (complex 3 -3) 3) => 9
why not
(+ #C(3 3) #C(3 -3) 3)
;-)
[.....]
Regards, Szymon.
Szymon <r5**********@o2.pl> writes: Petter Gustad <ne***********@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?
In article <cm**********@uns-a.ucl.ac.uk>, a.********@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
In article <cm**********@uns-a.ucl.ac.uk>, a.********@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
In article <m3************@spiritus.delamancha.org>, ip******@delamancha.org says... Gerry Quinn <ge****@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
In article <2h************@vserver.cs.uit.no>, fr****@cs.uit.no says... Gerry Quinn <ge****@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
"Rahul Jain" <rj***@nyct.net> wrote in message
news:87************@nyct.net... "Computer Whizz" <ol*********@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
rj***@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) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Peter Lewerin |
last post by:
peter.lewerin@swipnet.se (Peter Lewerin) wrote
> There is a paradigm
> difference between CLOS and non-OOP Lisp code, but the language is the
> same, and it's quite possible to mix the two.
D'oh.
I first meant to write approximately "There is a complexity difference
but no paradigm difference.", but then I thought people would
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
| | |
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...
| |
