I'm a C++ programmer, and have to use lisp because I want to use
emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
looking language syntax wise. What is up with this: (defun(foo()).
What were the lisp authors thinking? Why did Stallman use lisp in
emacs so extensively? Why oh why does such a weird and strange
looking language end up in a major software package so now I have to
learn it? My mind boggles at the craziness of lisp, and stallman's
decision to add so much of it to lisp.
If someone can answer my questions, I will spend less time with the
emacs psychiatrist!
On Fri, 27 Feb 2004 16:47:41 -0800, Mike Cox wrote:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
> What were the lisp authors thinking?
They were thinking that everything was an atomic element or a list. To
specify a list, you put a sequence of elements between an opening and
closing paren. All else is commentary...
> Why did Stallman use lisp in emacs so extensively?
Because, quite simply, it is the best programming language ever built.
Your inability to appreciate it is your problem.
> Why oh why does such a weird and strange
> looking language end up in a major software package so now I have to
> learn it?
See above.
> My mind boggles at the craziness of lisp, and stallman's
> decision to add so much of it to lisp.
You have an easily boggled and undereducated mind. Fix this and much else
will become clear.
> If someone can answer my questions, I will spend less time with the
> emacs psychiatrist!
Supposedly, there are no stupid questions, but yours come close...
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
> What were the lisp authors thinking? Why did Stallman use lisp in
> emacs so extensively? Why oh why does such a weird and strange
> looking language end up in a major software package so now I have to
> learn it? My mind boggles at the craziness of lisp, and stallman's
> decision to add so much of it to lisp.
>
> If someone can answer my questions, I will spend less time with the
> emacs psychiatrist!
Be patient, or you'll miss a very beautiful thing.
This is coming from someone who have programmed in C/C++ for many
years.
-kin
Mike Cox wrote:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
> What were the lisp authors thinking? Why did Stallman use lisp in
> emacs so extensively? Why oh why does such a weird and strange
> looking language end up in a major software package so now I have to
> learn it?
We'll answer these questions after you stop being so incredibly obnoxious, ok?
Paul
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
You will get used to the look of Lisp after you've done some Lisp
programming. Most people I know who've tried it find the syntax extremely
convenient after a week or two. The above rant is simply a declaration that
you like what you already know. It's also a clear indication that you've
been badly educated.
> What were the lisp authors thinking? Why did Stallman use lisp in
> emacs so extensively? Why oh why does such a weird and strange
> looking language end up in a major software package so now I have to
> learn it? My mind boggles at the craziness of lisp, and stallman's
> decision to add so much of it to lisp.
After a Google search or two we find that Richard has answered this question
himself during a Linuxcare interview:
Linuxcare: How did you come to choose LISP as the EMACS engine?
Richard: LISP is the most powerful programming language, and if you want
an interpreter, LISP is the best. None of the other languages come
anywhere near LISP in their power.... [1]
I'm glad to see that Richard chose Lisp for all the right reasons.
> If someone can answer my questions, I will spend less time with the
> emacs psychiatrist!
I can't believe I took the time to answer Mike's obnoxious questions.
bob
[1] http://karmak.org/archive/2003/01/12-14-99.epl.html
Robert E. Brown wrote:
> ············@yahoo.com (Mike Cox) writes:
>
>
>>I'm a C++ programmer, and have to use lisp because I want to use
>>emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
>>looking language syntax wise. What is up with this: (defun(foo()).
> I can't believe I took the time to answer Mike's obnoxious questions.
Look at it this way. Anyone who knows Lisp loves any excuse (however
obnoxious) to sing its praises. Mad Mike is just the vehicle du jour for
anyone needing to get a little Lisp euphoria off their chest.
Yes? No?
kenny
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
No you're not.
> emacs. I've gotten a book on lisp, and I must say lisp is the
No, you haven't.
> If someone can answer my questions, I will spend less time with the
> emacs psychiatrist!
Less time with a psychiatrist is the *last* thing you need.
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise.
Which book?
Lisp syntax is like modern art. You need to expose yourself to it for
about two weeks before deciding whether you like it.
> What is up with this: (defun(foo()).
It should be (defun foo () ...
In C++, what is the syntax for sequential execution? It depends, is
that sequential forms, or sequential expressions? What about a
conditional? It depends, is that a conditional expression or a
conditional statement? Do I need to put parenthesis around this
expression? That depends, what are the precedences of the surrounding
expressions, or are you using this for a conditional?
In lisp, what is the syntax for a definition?
Open paren, DEFUN, more stuff, close paren
What about an unwind-protect?
Open paren, UNWIND-PROTECT, more stuff, close paren.
What about the magic FOO special form that Kenny Tilton will invent
next year?
Open paren, FOO, more stuff, close paren.
Are you seeing a pattern here?
> What were the lisp authors thinking?
They were thinking that this was a quick and easy way to finesse a lot
of hard work.
> Why did Stallman use lisp in emacs so extensively?
He had a lot of experience in lisp and realized that only lisp had the
extensibility and power he needed.
> Why oh why does such a weird and strange looking language end up in
> a major software package so now I have to learn it? My mind boggles
> at the craziness of lisp, and stallman's decision to add so much of
> it to lisp.
>
> If someone can answer my questions, I will spend less time with the
> emacs psychiatrist!
As I said before, give it a good try for about two weeks and you'll
come to appreciate it.
--
~jrm
In article <···························@posting.google.com>,
············@yahoo.com (Mike Cox) wrote:
> What were the lisp authors thinking?
That they didn't want to waste half their lives writing parsers.
Consider:
int x[3] = {1, 2, 3};
^^^^^^^^^
Focus just on the highlighted part.
Get rid of the commas (they're not needed)
Change the curly braces to parens.
The result is:
(1 2 3)
Turns out that's all the syntax you need for a programming language.
What's more, once you adopt that as your syntax, writing parsers,
interpreters and compilers for that language becomes very easy. It's so
easy, in fact, that writing compilers for little languages (we call them
macros) becomes part of the day to day business of using the language.
It's really very cool once you grok it.
E.
On Sat, 28 Feb 2004 09:46:44 -0800, Erann Gat wrote:
> What's more, once you adopt that as your syntax, writing parsers,
> interpreters and compilers for that language becomes very easy.
Well, a parser is a tiny part of a modern compiler. I'm not talking about
pathologic grammars of a few languages but average grammars. It might have
been a significant aspect 40 years ago, when parsing techniques weren't
so widely developed *and* perhaps some languages invented weird syntaxes.
Parsing is usually not a big problem, and Lispish syntax doesn't help in
further stages of a compiler.
Macros is a different story. Good macros require the ability to parse
source into some kind of a tree without understanding its contents, but it
doesn't have to be sexprs - any tree with sufficiently explicit grouping
is adequate.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Parsing is usually not a big problem, and Lispish syntax doesn't help in
> further stages of a compiler.
>
I find the relative simplicity of lisp syntax helps me write+parse it, never
mind the computer. I know some other people just don't seem to work that
way. Sure, it's possible and easy for a computer to parse much more
complicated syntaxes. But I wouldn't use them much anyway...
In article <·····························@knm.org.pl>, Marcin 'Qrczak'
Kowalczyk <······@knm.org.pl> wrote:
> On Sat, 28 Feb 2004 09:46:44 -0800, Erann Gat wrote:
>
> > What's more, once you adopt that as your syntax, writing parsers,
> > interpreters and compilers for that language becomes very easy.
>
> Well, a parser is a tiny part of a modern compiler. I'm not talking about
> pathologic grammars of a few languages but average grammars.
What constitutes an "average" grammar depends on how you weight your
averages. As a practical matter it makes sense to weight a language
according to how much it's used, so the C++ grammar pathology has a huge
imact on the "average" grammar.
Furthermore, there is no way to leverage the C++ parser at run time, so
even people who don't write compilers are forever writing parsers for
little languages for input data. And the vast majority of these parsers
are buggy (I can't even keep count of the number of security breaches that
are the result of buffer overflows in input handlers) and they all have
different syntax and the result is a huge mess.
> Parsing is usually not a big problem, and Lispish syntax doesn't help in
> further stages of a compiler.
You're wrong about that too. Because I can hand a tree directly to the
Lisp compiler, I don't have to have a separate code generation phase.
"Compilation" becomes a simple tree-to-tree transformation, and very often
it can be expressed directly as a pattern substitution using backquote
syntax. A Lisp macro is, quite literally, a compiler.
> Macros is a different story.
Only because most of the world draws an artificial boundary between macros
and compilers. The difference between macros and compilers is not part of
the "physics" of programming. It's a purely artificial distinction, and
one which, while it does exist, is much less stark in the Lisp world than
in the non-Lisp world.
> Good macros require the ability to parse
> source into some kind of a tree without understanding its contents, but it
> doesn't have to be sexprs - any tree with sufficiently explicit grouping
> is adequate.
Yes, but you need a means for manipulating the trees. You can do that
purely programmatically, but for many common cases that is unnecessarily
cumbersome. If you have sexprs then you can used backquote to make your
life a lot easier 90% of the time.
Another cool thing about sexprs is it's really easy to reverse-parse a
sexpr so that you can find the beginning of a sexpr from the end of one.
This makes it much easier to write syntax-directed editors and interactive
programming environments.
The syntax really does matter, and sexprs really are a feature.
E.
On Sat, 28 Feb 2004 22:30:41 -0800, Erann Gat wrote:
> Furthermore, there is no way to leverage the C++ parser at run time, so
> even people who don't write compilers are forever writing parsers for
> little languages for input data.
You can use "read" only if you are free to choose the input format.
The program I had to write last week needed to parse an already existing
file with lines looking like this:
<f>pobudzaj�c�<l>pobudza�<t>pact:sg:acc:f:imperf:aff<t><N>pact:sg:inst:f:imperf:aff
The parser took 25 lines of Perl.
> And the vast majority of these parsers are buggy (I can't even keep
> count of the number of security breaches that are the result of buffer
> overflows in input handlers)
I advocate using safe languages whenever possible. Lisp is not an
exception here; C and C++ are exceptions.
>> Parsing is usually not a big problem, and Lispish syntax doesn't help
>> in further stages of a compiler.
>
> You're wrong about that too. Because I can hand a tree directly to the
> Lisp compiler, I don't have to have a separate code generation phase.
Only if it's easy to embed the language's semantics in Lisp semantics.
This can either constrain the language (if you are allowed to change it)
or be horribly slow (if you must emulate some existing semantics
accurately and you don't perform sophisticated analysis which infers where
Lisp objects and operations can be used directly without wrapping and
dispatching).
See
<http://www.google.pl/groups?as_umsgid=m2ptc91l0d.fsf%40rh220-50.resnet.ucsd.edu>
- embedding Python in Scheme made it 2 to 3 orders of magnitude slower.
It will need much work to make it competetive with the original Python
implementation. My compiler of my own language to C is already about 3
times faster than CPython in a small benchmark, while it does almost no
static analysis and each arithmetic operation is dispatched on types of
numbers. I couldn't reuse Lisp dispatch because I don't use the same
rules. Also, it's much easier to interface with C libraries directly
(since it's compiled into C) than to do it through a Lisp layer.
> A Lisp macro is, quite literally, a compiler.
It's a special case of a compiler. Most compilers can't be expressed
with just macros. So even if sexprs can help with a particular sort of
macros, they don't help in writing compilers in general.
> Yes, but you need a means for manipulating the trees. You can do that
> purely programmatically, but for many common cases that is unnecessarily
> cumbersome. If you have sexprs then you can used backquote to make your
> life a lot easier 90% of the time.
Building and examining trees is easy enough in my non-sexpr-based
language. For me its more natural. Lisp puts much emphasis on literal vs.
computed values, with quoting and quasiquoting and unquoting. Embedding a
known symbolic label (i.e. using a "constructor" directly) looks
differently from running a smart constructor which makes a few tree nodes
at a time or different kinds of nodes basing on parameters. I prefer a
uniform syntax for constructing values, which in my case is simply done
with function calls.
It implies that I must specify each possible constructor somewhere rather
than just use random symbols directly. I treat this as an advantage. They
would have to be documented anyway - a rich tree-like data structure with
code producing and examining it is unmaintainable without a description
of possible names of constructors and its parameters. A description of a
constructor takes one line. Sexprs would not make it easier.
With my organization of code I can easily turn a kind of node into a smart
constructor without changing code which uses it. I get a compile time
error on mismatched constructor arity (not on mismatched argument types
unfortunately, because my language is dynamically typed like Lisp) or on
using a non-existant constructor name, and I get compile errors on many
stage mixups because each stage imports modules only for the code
representations it needs (usually two, input and output).
I can still use quite generic functions for walking the tree. For example
when computing free variables of an expression / pattern / definition,
I specify only "positive" (uses) and "negative" (binds) field names for
each kind of node, and a generic piece of code walks the tree generically
computing sets of used and bound names. Lisp doesn't have a monopoly in
the ability of writing generic tree walkers.
The only thing which sexprs would make it easier is printing intermediate
trees for debugging. With a loss of quality though. For example I don't
print source code locations embedded in trees - they would make the output
less readable; and I don't print all the details I keep inside names. Even
ignoring these cases sexprs would be significantly more verbose, and they
would not be so nicely indented because a very good indentation can't be
chosen automatically (e.g. "else if"'s in an intermediate representation
don't increase the indent, although they formally enter a subexpression).
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <······························@knm.org.pl>, Marcin 'Qrczak'
Kowalczyk <······@knm.org.pl> wrote:
> On Sat, 28 Feb 2004 22:30:41 -0800, Erann Gat wrote:
>
> > Furthermore, there is no way to leverage the C++ parser at run time, so
> > even people who don't write compilers are forever writing parsers for
> > little languages for input data.
>
> You can use "read" only if you are free to choose the input format.
Not so (and I must say your ignorant pontification on Lisp's limitations
is starting to get annoying). You can modify the readtable.
> The program I had to write last week needed to parse an already existing
> file with lines looking like this:
>
>
<f>pobudzaj�c�<l>pobudza�<t>pact:sg:acc:f:imperf:aff<t><N>pact:sg:inst:f:imperf:aff
>
> The parser took 25 lines of Perl.
It's impossible to back a grammar out of a single example, but I suspect I
could parse that in a lot less than 25 lines of Lisp (and you'd be able to
read the code afterwards).
> >> Parsing is usually not a big problem, and Lispish syntax doesn't help
> >> in further stages of a compiler.
> >
> > You're wrong about that too. Because I can hand a tree directly to the
> > Lisp compiler, I don't have to have a separate code generation phase.
>
> Only if it's easy to embed the language's semantics in Lisp semantics.
Again, not so. Most Lisps have a built-in assembler, so I can generate
machine code directly this way. Look up
http://vorlon.cwru.edu/~beer/Software/FPC-PPC/FPC-PPC-DOC-0.1.txt for an
example.
> This can either constrain the language (if you are allowed to change it)
> or be horribly slow (if you must emulate some existing semantics
> accurately and you don't perform sophisticated analysis which infers where
> Lisp objects and operations can be used directly without wrapping and
> dispatching).
Yes, of course it *can* be slow, but it doesn't have to be. FPC, for
example (the link above) actualy augments the native Lisp compiler to make
floating point math run faster.
> - embedding Python in Scheme made it 2 to 3 orders of magnitude slower.
So someone wrote some slow code. So what? That proves exactly nothing.
> > A Lisp macro is, quite literally, a compiler.
>
> It's a special case of a compiler. Most compilers can't be expressed
> with just macros. So even if sexprs can help with a particular sort of
> macros, they don't help in writing compilers in general.
Again, this is false. But I am getting tired of doing your homework for
you so you're going to have to figure this one out on your own. Two
hints: 1) DEFUN is a macro, and 2) while backquote syntax is a very
convenient shortcut in a large number of cases, nothing mandates that you
use it every time.
[ Much snippage ]
Your arguments all fall into two catgories of basic logical fallacies:
1) I can't figure out how to do X, therefore X must be impossible.
2) Someone tried to do X and it turned out to be hard/slow/buggy,
therefore, doing X is necessarily hard/slow/buggy.
E.
On Sun, 29 Feb 2004 08:56:16 -0800, Erann Gat wrote:
> <f>pobudzaj�c�<l>pobudza�<t>pact:sg:acc:f:imperf:aff<t><N>pact:sg:inst:f:imperf:aff
>>
>> The parser took 25 lines of Perl.
>
> It's impossible to back a grammar out of a single example, but I suspect I
> could parse that in a lot less than 25 lines of Lisp (and you'd be able to
> read the code afterwards).
Really? I'm curious. Most lines have this form:
<f> or <d>
a word - anything not containing "<"
one or more repetitions of:
<l>
a word
one or more repetitions of:
<t>
optional <N>
a vector of tags separated by ":"'s
Other lines are to be ignored. There is no need for error checking, we can
safely assume that each line starting with <f> or <d> has the above format.
The input is split at lines whose word after <d> is ".", "!" or "?".
Within such a sentence each non-ignored line yields an element of a
sequence created for further processing. An element contains:
* the word after <f> or <d>
* a sequence of objects, where each object has three fields:
- the word after <l>
- the vector of tags (split at ":"'s)
- whether there was an <N> or not
Each <l> yields as many objects as there are <t>'s in it, with the same
word after <l> in each object.
It's actually 21 lines in Perl when I changed processing of the sequences
being built to a single function invocation:
while(<>) {
chomp;
if (/^<(f|d)>([^<]+)/g) {
my ($rodzaj, $forma) = ($1, $2);
my @inter = ();
while (/\G<l>([^<]+)/gc) {
my $leksem = $1;
while (/\G<t>(<N>)?([^<]+)/gc) {
my $dobra = !defined $1;
my $tagi = $2;
my @tagi = split /:/, $tagi;
push @inter, {l => $leksem, t => ·@tagi, d => $dobra};
}
}
push @zdanie, {f => $forma, i => ·@inter};
if ($rodzaj eq "d" && $forma =~ /^[.!?]$/) {
process(@zdanie);
@zdanie = ();
}
}
}
Can Lisp make it easier? Perhaps by changing the readtable as you
suggested?
This is a real life example. I chose Perl, I didn't choose the file format.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <······························@knm.org.pl>, Marcin 'Qrczak'
Kowalczyk <······@knm.org.pl> wrote:
> Can Lisp make it easier?
Yes.
> Perhaps by changing the readtable as you suggested?
That's one way, but in this case I'd just replace all the angle brackets
with parens, all the colons with spaces, and then just use READ to
tokenize the stream. The parsing itself is trivial after that.
E.
On Sun, 29 Feb 2004 15:06:08 -0800, Erann Gat wrote:
> That's one way, but in this case I'd just replace all the angle brackets
> with parens, all the colons with spaces, and then just use READ to
> tokenize the stream. The parsing itself is trivial after that.
The words contain parens (locally unbalanced), quotes, semicolons, colons
in other places than tag vectors, dots, even unbalanced ">" characters (I
said they are delimited with "<" only), non-ASCII letters, and are case
sensitive.
I know you can escape such characters in symbols, but I don't believe that
a preprocessor which does it (written in Lisp of course) + a read loop +
a postprocessor which transforms the list structure into the form suitable
for further processing (i.e. two levels of repetition flattened into one,
split at sentence breaks, remaining lines filtered etc.) - all this done
lazily, without reading the whole file into memory - is simpler than my
Perl loop.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <·····························@knm.org.pl>, Marcin 'Qrczak'
Kowalczyk <······@knm.org.pl> wrote:
> On Sun, 29 Feb 2004 15:06:08 -0800, Erann Gat wrote:
>
> > That's one way, but in this case I'd just replace all the angle brackets
> > with parens, all the colons with spaces, and then just use READ to
> > tokenize the stream. The parsing itself is trivial after that.
>
> The words contain parens (locally unbalanced), quotes, semicolons, colons
> in other places than tag vectors, dots, even unbalanced ">" characters (I
> said they are delimited with "<" only), non-ASCII letters, and are case
> sensitive.
Ah. Then you'd need to do some readtable tweaking.
> I know you can escape such characters in symbols, but I don't believe that
> a preprocessor which does it (written in Lisp of course) + a read loop +
> a postprocessor which transforms the list structure into the form suitable
> for further processing (i.e. two levels of repetition flattened into one,
> split at sentence breaks, remaining lines filtered etc.) - all this done
> lazily, without reading the whole file into memory - is simpler than my
> Perl loop.
Maybe, maybe not. But it would almost certainly be more readable.
But the larger point is that if the world used Lisp no one would have ever
invented such a brain damaged file format to begin with.
E.
Marcin 'Qrczak' Kowalczyk wrote:
> [blah, blah].
Maybe emacs lisp or scsh would be better for this
(than CL without extra libraries).
-------------
little-off-topic, but interesting:
(from: [http://www.perl.com/lpt/a/2000/09/ilya.html])
-----
" ... Let me also mention that classifying the text handling
facilities of Perl as "extremely agile" gives me the willies. Perl's
regular expressions are indeed more convenient than in other
languages. However, the lack of a lot of key text-processing
ingredients makes Perl solutions for many averagely complicated
tasks either extremely slow, or not easier to maintain than
solutions in other languages (and in some cases both).
I wrote a (heuristic-driven) Perlish syntax parser and transformer
in Emacs Lisp, and though Perl as a language is incomparably
friendlier than Lisps, I would not be even able of thinking about
rewriting this tool in Perl: there are just not enough text-handling
primitives hardwired into Perl. I will need to code all these
primitives first. And having these primitives coded in Perl, the
solution would turn out to be (possibly) hundreds times slower than
the built-in Emacs operations. ... "
-------------
regards, szymon.
> From: Marcin 'Qrczak' Kowalczyk <······@knm.org.pl>
> Erann Gat wrote:
> > Furthermore, there is no way to leverage the C++ parser at run time, so
> > even people who don't write compilers are forever writing parsers for
> > little languages for input data.
> You can use "read" only if you are free to choose the input format.
Correct. But whenever the original data is not in machine readable
format, you might as well enter it in s-expression format rather than
any other format, at which point LISP can read it naturally. Or if data
is collected by a form, where each field of data is within a single
field of the form, it's trivial to build an s-expression from the
fields, and so you might as well do that instead of build some
non-s-expression format and hassle with somehow parsing it. Even if the
data is in some machine-readable but non-s-expression format
originally, often you can manually convert it to s-expressions in a
text editor, or use editor macros to convert it semi-automatically. In
all those cases, passing it to READ can test whether you've done that
data-entry or conversion task correctly, that is whether you get an
error when trying to READ it.
In the worst case, you have to write an actual parser to convert it to
internal form, whereupon you can print it out to generate external
s-expression format.
In any of those cases, you can prettyprint it and just look at it to
see whether it's structured correctly, hence whether your editor macros
or parser did *really* the right thing, not just s-expressions
externally or pointy structures internally, but hierarchial levels of
the data structure all correct.
> The program I had to write last week needed to parse an already existing
> file with lines looking like this:
<f>pobudzaj1c1<l>pobudzaf<t>pact:sg:acc:f:imperf:aff<t><N>pact:sg:inst:f:imperf:aff
The important thing is how that is supposed to represent hierarchial
data. What are the "words" and what are the operators that connect
those words together and what is operator precedence needed to say
which two words are combined into a sub-structure before that whole
sub-structure is then combined with another word or another
sub-structure. Once you know the answer to that question, you can write
a parser for that kind of data. Then as I said above, prettyprint the
result and just look at it to see if you got the hierarchial levels
correct.
> The parser took 25 lines of Perl.
And how do you know you got it correct without a default prettyprinter
to show you the levels of hierarchy? Did you have to write your own
prettyprinter from scratch just to see the data in structured form?
So when the parse of that one line was prettyprinted, what did it look
like?
> I advocate using safe languages whenever possible.
I suppose I agree. LISP is a safe language for server-side applications
if you take certain precautions:
- Collect all input (from HTTP/CGI transaction) into a string before
starting to process it further, so it's impossible for an error to
throw the LISP environent into a read-eval-print BREAK loop whereupon
it might then read some not-yet-read input and try to EVALuate it.
- Set up a special package which imports only the symbols you know for
sure are safe for your situation, re-defining any that would be unsafe
if imported as-is from the LISP package. Use this special package for
all your parsing of input.
- Disable all read-time evaluation when reading in the fields from the
HTML FORM contents.
- Traverse the result of safe-read-from-string to verify there aren't
any symbols outside that special package, i.e. to verify the user
didn't say otherpackage:symbolname somewhere in the form contents.
Did I leave out any necessary precautions?
> Date: Sun, 29 Feb 2004 17:12:53 +0100
(I didn't see your article when it first appeared, because I didn't
have any efficient method for finding all followups (to stuff I had
posted) until just a few nights ago when I finally found your article
and put it in the queue to compose a followup myself. Sorry for very
belated response.)
Marcin 'Qrczak' Kowalczyk wrote:
> On Sat, 28 Feb 2004 09:46:44 -0800, Erann Gat wrote:
>
>
>>What's more, once you adopt that as your syntax, writing parsers,
>>interpreters and compilers for that language becomes very easy.
>
>
> Well, a parser is a tiny part of a modern compiler. I'm not talking about
> pathologic grammars of a few languages but average grammars. It might have
> been a significant aspect 40 years ago, when parsing techniques weren't
> so widely developed *and* perhaps some languages invented weird syntaxes.
> Parsing is usually not a big problem, and Lispish syntax doesn't help in
> further stages of a compiler.
>
You are quite wrong. Lisp data provides an immediate representation
for trees and intermediate forms of programs. You don't have to write
input and output and traversal routines for trees, etc. if you
represent them as lists in lisp.
> Macros is a different story. Good macros require the ability to parse
> source into some kind of a tree without understanding its contents, but it
> doesn't have to be sexprs - any tree with sufficiently explicit grouping
> is adequate.
>
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the
> ugliest looking language syntax wise. What is up with this:
> (defun(foo()).
(defun foo ()) if you please. Lisp does not tolerate unnecessary
parentheses.
> What were the lisp authors thinking?
To create a list processing language with simple unambiguous grammar.
> Why did Stallman use lisp in emacs so extensively? Why oh why does
> such a weird and strange looking language end up in a major software
> package so now I have to learn it?
At the time, Emacs started coming into being, there was no C++.
Heck, even C is younger than Lisp. The only thing that is a pity is
that the language Lisp has made greater strides (Common Lisp) than
Emacs Lisp has. But you don't sound like you would have been too
happy over the additional available power, flexibility and
complexity, so this is probably a minor point.
But it also means that apart from the basics, the Lisp book you
acquired will make you wish Emacs Lisp to be more powerful in some
circumstances.
> My mind boggles at the craziness of lisp, and stallman's decision to
> add so much of it to lisp.
To add Lisp to Lisp?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup wrote:
> ············@yahoo.com (Mike Cox) writes:
>
>
>>I'm a C++ programmer, and have to use lisp because I want to use
>>emacs. I've gotten a book on lisp, and I must say lisp is the
>>ugliest looking language syntax wise. What is up with this:
>>(defun(foo()).
>
>
> (defun foo ()) if you please. Lisp does not tolerate unnecessary
> parentheses.
>
>
>>What were the lisp authors thinking?
>
>
> To create a list processing language with simple unambiguous grammar.
>
Well, to be exact, when LISP was designed in 1956 - 1958, they wanted a
separate notation for the m-expressions, or meta-expressions. They
decided to use the a bracket for these. The following quote is taken from:
"History of Lisp"
John McCarthy,
Artificial Intelligence Laboratory,
Stanford University [1]
12 february 1979
(quote
The M-notation also used brackets instead of parentheses to enclose the
arguments of functions in order to reserve parentheses for
list-structure constants. It was intended to compile from some
approximation to the M-notation, but the M-notation was never fully
defined, because representing LISP functions by LISP lists became the
dominant programming language when the interpreter later became
available. A machine readable M-notation would have required
redefinition, because the pencil-and-paper M-notations used characters
unavailable on the IBM 026 key punch
)
And later on in the same article, when talking about the future of LISP:
(quote
One can even conjecture that LISP owes its survival specifically to the
fact that its programs are lists, which everyone, including me, has
regarded as a disadvantage.
)
So, if even the creator of LISP initially thought that using parentheses
for the M-expressions was a bad idea, it's no wonder anyone else,
unfamiliar with LISP would think the same.
Arjan
[1] could this have anything to do with RMS' interest in LISP?
--
--
If you really want to contact me, then replace the "I see you" text by
its three letter accronym, ICU.
Fabricate Diem PVNC, Motto of the Night Watch -- Terry Pratchett
Arjan Bos <·········@nospam.ISeeYou.nl> writes:
> "History of Lisp"
> John McCarthy,
> Artificial Intelligence Laboratory,
> Stanford University [1]
> 12 february 1979
[snip]
> [1] could this have anything to do with RMS' interest in LISP?
I don't see why it would. Stallman went to Harvard and MIT.
--
~jrm
David Kastrup <···@gnu.org> writes:
> At the time, Emacs started coming into being, there was no C++.
> Heck, even C is younger than Lisp.
I think C is even younger than emacs. The original one on TECO. C has
been invented for unix, any software that predates unix predates C.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon wrote:
> David Kastrup <···@gnu.org> writes:
>
>>At the time, Emacs started coming into being, there was no C++.
>>Heck, even C is younger than Lisp.
>
>
> I think C is even younger than emacs. The original one on TECO. C has
> been invented for unix, any software that predates unix predates C.
>
Tough call. Depending upon just how you look at the respective forebears
of C and Emacs, their origins seem to be pretty much contemporaneous.
See, for example:
http://www.multicians.org/mepap.html
Cheers,
--ag
--
Artie Gold -- Austin, Texas
"Yeah. It's an urban legend. But it's a *great* urban legend!"
>>>>> On Sat, 28 Feb 2004 20:27:28 -0600, Artie Gold ("Artie") writes:
Artie> Pascal Bourguignon wrote:
>> David Kastrup <···@gnu.org> writes:
>>
>>> At the time, Emacs started coming into being, there was no C++.
>>> Heck, even C is younger than Lisp.
>> I think C is even younger than emacs. The original one on TECO. C
>> has
>> been invented for unix, any software that predates unix predates C.
>>
Artie> Tough call. Depending upon just how you look at the respective
Artie> forebears of C and Emacs, their origins seem to be pretty much
Artie> contemporaneous.
Yes, Emacs is contemporaneous with C (but I don't remember
the exact dates and am too lazy to look it up at the moment).
TECO, the language in which Emacs was implemented,
was invented on the PDP-1 and is quite a bit older than C.
From: Alan Mackenzie
Subject: Re: Why is lisp so weird?
Date:
Message-ID: <tt8s1c.n7.ln@acm.acm>
Pascal Bourguignon <····@thalassa.informatimago.com> wrote on 29 Feb 2004
00:16:42 +0100:
> David Kastrup <···@gnu.org> writes:
>> At the time, Emacs started coming into being, there was no C++. Heck,
>> even C is younger than Lisp.
> I think C is even younger than emacs. The original one on TECO. C has
> been invented for unix, any software that predates unix predates C.
We don't use the original TECO Emacs anymore. We also don't use BCPL,
the ancestor of C, anymore. "BCPL was designed by one of the authors
[Martin Richards] in 1967." ("BCPL, the language and its compiler" by
Martin Richards and Colin Whitby-Strevens, published by Cambridge
[England] University Press 1980, ISBN 0 521 21965 5).
> __Pascal_Bourguignon__
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
* Alan Mackenzie wrote:
> We don't use the original TECO Emacs anymore. We also don't use
> BCPL, the ancestor of C, anymore.
But we do use languages which are at least as close to BCPL as CL is
to the Lisp dialects used in 1967.
--tim
Tim Bradshaw wrote:
> * Alan Mackenzie wrote:
>> We don't use the original TECO Emacs anymore. We also don't use
>> BCPL, the ancestor of C, anymore.
>
> But we do use languages which are at least as close to BCPL as CL is
> to the Lisp dialects used in 1967.
BCPL itself is still in use, in fact.
Jeremy.
David Kastrup wrote:
> The only thing that is a pity is
> that the language Lisp has made greater strides (Common Lisp) than
> Emacs Lisp has.
Why is this a pity? Common Lisp is better than Emacs Lisp. It's
statically scoped which makes programs easier to understand and run
faster. Plus, it does allow for dynamic scoping if you really have to
have it!
Lowell
Lowell Kirsh <······@cs.ubc.ca> writes:
> David Kastrup wrote:
> > The only thing that is a pity is
> > that the language Lisp has made greater strides (Common Lisp) than
> > Emacs Lisp has.
>
> Why is this a pity? Common Lisp is better than Emacs Lisp. It's
> statically scoped which makes programs easier to understand and run
> faster. Plus, it does allow for dynamic scoping if you really have
> to have it!
Well, it is a pity since this thread is a rant about Emacs Lisp.
Emacs Lisp would gain from common Lisp features.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup <···@gnu.org> writes:
> Well, it is a pity since this thread is a rant about Emacs Lisp.
> Emacs Lisp would gain from common Lisp features.
CMUCL has Hemlock. I do not know if it will compile under SBCL or
other CL implementations. Whether that is a good code base for a CL
Emacs I do not know. GNU Emacs has a hell of a user base and a lot
of ELisp that would likely have to be redone unless you wanted to
implement ELisp in Common Lisp for transitional purposes.
RMS has indicated that he would like to use Scheme instead of ELisp.
I think he means Guile. That is what it was written for, as an
extension language.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
David Steuber <·············@verizon.net> writes:
> CMUCL has Hemlock. I do not know if it will compile under SBCL or
> other CL implementations. Whether that is a good code base for a CL
> Emacs I do not know.
Just in case you do not know about the "Portable Hemlock" project,
here is the URL:
http://www.stud.uni-karlsruhe.de/~unk6/hemlock/
--
Robert Strandh
David Steuber <·············@verizon.net> writes:
> David Kastrup <···@gnu.org> writes:
>
> > Well, it is a pity since this thread is a rant about Emacs Lisp.
> > Emacs Lisp would gain from common Lisp features.
>
> CMUCL has Hemlock. I do not know if it will compile under SBCL or
> other CL implementations. Whether that is a good code base for a CL
> Emacs I do not know. GNU Emacs has a hell of a user base and a lot
> of ELisp that would likely have to be redone unless you wanted to
> implement ELisp in Common Lisp for transitional purposes.
>
> RMS has indicated that he would like to use Scheme instead of ELisp.
> I think he means Guile. That is what it was written for, as an
> extension language.
He does not seem to recognize that his own argument that made him use
a true programming language instead of teco commands hacked into a
programming language, now applies as well for the choice between a
"toy" programming language (a programming language designed _just_ as
an extension programming language) vs. a true "professionnal"
full-fleshed programming language. At a time, it may well be that you
had to keep the extention programming language small to stay inside
the RAM, but this is not the case anymore. Neither emacs lisp, scheme
or Common-Lisp will grow as fast as the available resource so with
time their size will have even less importance than nowaday.
Great, we can implement our own prefered programming language in
scheme or emacs lisp. But then why bother working with emacs-cl when
you can work with true Common-Lisp implementations and Hemlock?
There's maybe a counter argument in that begnin programming languages
may look more appealing to non-programmer users. I don't know if the
trick of making people program without telling them they're
programming is still available. Nowadays, there's enough computer
culture to let them know went they start programming (the first hint
being that they have to use the keyboard instead of the mouse). So I
don't think that it's worthwhile. Anyway for a non-programmer, it must
be as easy to customize an application with Common-Lisp than with
Scheme or emacs lisp.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
(message (Hello 'Mike)
(you :wrote :on '(27 Feb 2004 16:47:41 -0800))
(
MC> I'm a C++ programmer,
i'm also programming C++ most the time.
i also spent a lot of time programming Basic, Pascal/Delphi, Perl, PHP,C#.
also i've seen and even wrote some code on C, Python, Tcl, Haskell, O'CAML,
Ruby, Objective-C, Maxscript, Javascript..
MC> I've gotten a book
MC> on lisp, and I must say lisp is the ugliest looking language syntax
MC> wise.
as for me, lisp syntax (code as tree) is most natural thing.
when i needed some scripting language long time ago i've invented some,
based on xml. i haven't yet seen lisp that time.
then somebody showed me lisp code and i realized that my xml-syntaxed
language can be mapped onto lisp. i've abandoned that stuff and now i'm
writing interpreter with lisp based syntax(in this case i have parser for
free).
so, as for me Lisp syntax is most beatiful one. what i like it for is that
it's simple, clean and logical. it can be expressed in many ways(for example
in xml) but lisp way looks most natural. all other languages also map into
tree finaly, but they have wierd syntax with complex, inconsistent rules..
C++ is one of the most complex and wierd languages. all these ++ * --
constructs, operator priorities, variable visiblity rules, Koenig lookup
sutff and so on.. and with this modern template stuff real strain both to
compilers and human brain is needed.. compiler needs about 100 times more
time to parse C++ code that intensively uses templates than lisp one with
similar functionality.. human brain has to do proportional work for this i
think.
possibly that's why programming lisp is pleasure for me when all other
languages are some kind of strain.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
Hi Mike,
> is the ugliest looking language syntax wise.
You get familiar with it, very fast. Trust me ;-)
> My mind boggles at the craziness of lisp
It is one of the simplest programming languages i have ever seen, but
very powerful.
If you learned a procedural language before lisp, as most people did
(and i did), it seems to be weird at first. But i am sure, to anyone
which learns lisp at first, procedural languages seem much more weird.
Herzliche Gr��e,
Christoph
--
Wir sehen die Dinge nicht so wie sie sind - sondern wir sehen sie, wie
wir sind.
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the
> ugliest looking language syntax wise. What is up with this:
I am not a programmer at all. Nevertheless, over the past 15 years I
have written a lot of customizations to my Emacs, some of them pretty
elaborate, after browsing (at the beginning) in one elementary Lisp
textbook and consulting the Elisp manual and the online help.
My attitude is: parentheses in Lisp, like the common cold, should be
treated with the contempt they deserve. They are there for the
machine's sake, not yours. Elisp mode provides, or makes available,
tools that allow you to ignore the parens except in emergencies. Use
the facility (I forget its name) that, when you type a left paren,
also inserts its mate and puts point between them. Never type a right
paren, and never delete a paren. Then you are guaranteed a balanced
paren structure, and all you have to do is move around in it
intelligently. For that purpose, activate the service (once again, I
forget its name) that automatically signals the mate of the paren next
to point. That way, as you march across an inscrutable series of
right parens, you will be told exactly what piece of the defun you are
escaping from at each step. Finally, when starting a new line, always
use the insert key (newline-and-indent function), which indents the
new line so as to show you where you are in the local logic. And do
it often. The shorter the lines, the more the indentations, and the
easier it will be to see what you are doing.
You do not have to be a Lisp programmer, or any kind of programmer, to
write Elisp programs. In particular, for customizing Emacs there is
little need for the peculiarly Lispish constructs that Lisp books
philosophize & rhapsodize over. I can count on the fingers of one
hand the number of times I have resorted to cons, car, cdr, or
recursion. Using one of them always makes me feel especially grown
up, like putting on a necktie.
Enjoy.
--
--- Joe Fineman ···@TheWorld.com
||: The Balkan peninsula is the Europe of Europe. :||
Joe Fineman <···@TheWorld.com> writes:
> You do not have to be a Lisp programmer, or any kind of programmer,
> to write Elisp programs. In particular, for customizing Emacs there
> is little need for the peculiarly Lispish constructs that Lisp books
> philosophize & rhapsodize over. I can count on the fingers of one
> hand the number of times I have resorted to cons, car, cdr, or
> recursion. Using one of them always makes me feel especially grown
> up, like putting on a necktie.
The real grownups put on a succubus.
((lambda (f n) (funcall f f n))
(lambda (f n) (if (zerop n) 1 (* n (funcall f f (1- n)))))
5)
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
>>>>> On 28 Feb 2004 19:42:42 -0500, Joe Fineman ("Joe") writes:
Joe> My attitude is: parentheses in Lisp, like the common cold,
Joe> should be treated with the contempt they deserve.
Joe> They are here for the machine's sake, not yours.
My attitude is exactly the opposite: emacs parenthesis what
allows me to most easily and clearly express myself to other
people, and it's nice that the computer can read it, too.
For the same reason, I also loved APL.
Of course, that's the intent of all higher level languages.
I just don't like the other ones nearly as much.
(And oddly enough, neither does the computer!)
What the point of this was, I cannot fathom.
If someone hates Lisp syntax, I would advise
them to avoid it and use something they like.
+ ······@news.dtpq.com (Christopher C. Stacy):
| >>>>> On 28 Feb 2004 19:42:42 -0500, Joe Fineman ("Joe") writes:
| Joe> My attitude is: parentheses in Lisp, like the common cold,
| Joe> should be treated with the contempt they deserve.
| Joe> They are here for the machine's sake, not yours.
|
| My attitude is exactly the opposite: emacs parenthesis what
| allows me to most easily and clearly express myself to other
| people, and it's nice that the computer can read it, too.
And my attitude is somewhere in between: /Indentation/ is for
communicating with other people, including a future version of myself.
After all, newbies quickly discover the importance of proper
indentation when they post badly indented code here. The parentheses
have uses apart from the obvious one of making it easy for the
computer to parse our programs: They are a huge benefit while editing,
as Joe has evidently discovered. And they elucidate the connection
between the program we type and the parsed structure of that program,
without which we would have a hard time working with macros.
| What the point of this was, I cannot fathom.
| If someone hates Lisp syntax, I would advise
| them to avoid it and use something they like.
Either that, or learn not to hate it. Personally, I hate stuff that
wastes my time and energy. If I can make them work for me rather than
against me, I don't hate them anymore.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
+ Harald Hanche-Olsen <······@math.ntnu.no>:
| And my attitude is somewhere in between: /Indentation/ is for
| communicating with other people, including a future version of myself.
But as I am rereading what I just wrote, I realized that this is of
course not the whole story. Indentation gives you large scale
structure, but you still need the parentheses for local structure.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
> What were the lisp authors thinking? Why did Stallman use lisp in
So then, you are suggesting that C++ is pleasing to the eye?
--
-------------------------------------------------------------------------------
Jerry Sievers 305 854-3001 (home) WWW ECommerce Consultant
305 321-1144 (mobile http://www.JerrySievers.com/
From: Alan Mackenzie
Subject: Re: Why is lisp so weird?
Date:
Message-ID: <vkas1c.n7.ln@acm.acm>
Mike Cox <············@yahoo.com> wrote on 27 Feb 2004 16:47:41 -0800:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs.
Well you don't have to, but it helps.
> I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise.
Lisp was invented by people. From the point of view of just about every
other creature living on the earth, people are about as ugly and ungainly
as you can imagine, with stupid bits of hair adorning an otherwise naked
body, wierd shaped sticky-out bits, an unstable vertical stance, unable
to move fast, unable to fight fierce predators, ..... From such a
species you'd expect an ugly and ungainly looking language.
> What is up with this: (defun(foo()). What were the lisp authors
> thinking?
You mean "(defun foo ())", I think. They wanted to make it easy to write
content-free, do-nothing functions. I think they succeded.
> Why did Stallman use lisp in emacs so extensively? Why oh why does
> such a weird and strange looking language end up in a major software
> package so now I have to learn it?
Find a photograph of Richard Stallman (there are quite a few on the web),
and perhaps you'll undertand. ;-) [Please, nobody take offence here.
None is intended.]
> My mind boggles at the craziness of lisp, and stallman's decision to
> add so much of it to lisp.
Actually, I'm not sure RMS added much craziness to lisp. I think he
rather developed the craziness which was already there.
> If someone can answer my questions, I will spend less time with the
> emacs psychiatrist!
Hope I've been of some help!
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
Alan Mackenzie<····@example.invalid> writes:
> > Why did Stallman use lisp in emacs so extensively? Why oh why does
> > such a weird and strange looking language end up in a major software
> > package so now I have to learn it?
>
> Find a photograph of Richard Stallman (there are quite a few on the web),
> and perhaps you'll undertand. ;-) [Please, nobody take offence here.
> None is intended.]
Yeah! Find a photograph of Ken Thompson (C), Stroustrup (C++) and of
Niklaus Wirth (Pascal, Modula-2, Oberon) or Jean Ichbiah (ADA) too,
and compare! :-)))
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
On Mon, Mar 01, 2004 at 01:58:53AM +0100, Pascal Bourguignon wrote:
> Alan Mackenzie<····@example.invalid> writes:
> > > Why did Stallman use lisp in emacs so extensively? Why oh why does
> > > such a weird and strange looking language end up in a major software
> > > package so now I have to learn it?
> >
> > Find a photograph of Richard Stallman (there are quite a few on the web),
> > and perhaps you'll undertand. ;-) [Please, nobody take offence here.
> > None is intended.]
>
> Yeah! Find a photograph of Ken Thompson (C), Stroustrup (C++) and of
> Niklaus Wirth (Pascal, Modula-2, Oberon) or Jean Ichbiah (ADA) too,
> and compare! :-)))
While we're at it, take this quiz:
http://www.malevole.com/mv/misc/killerquiz/
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
············@yahoo.com (Mike Cox) writes:
> I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise.
You don't say explicitly, but it seems you're talking about all those
parentheses. I think people shouldn't get too worked up about them.
It is true that reading things like "))))))))))" and distinguishing
them from ")))))))))", say, is not so easy. I just tend to ignore the
issue and read it as "many closing parentheses".
The thing that really helps me to read Lisp programs is indentation.
And don't tell me you're not relying on indentation for C and C++! To
check, take some C or C++ code that you don't know so well that's a
bit longer than the Sieve of Eratosthenes (sp?) and remove all leading
whitespace from all lines. Then try to understand the code. Then run
it through some indenter (C-x h C-M-\ comes to mind, or perhaps GNU
indent) and try again.
Kai
············@yahoo.com (Mike Cox) wrote in message news:<···························@posting.google.com>...
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
What is up with that is that Lisp is designed in a particular way to
allow Lisp programmers to easily do something that is not even
possible in some other languages, and are at best difficult and clumsy
in others.
In Lisp you can write programs that write programs. To be able to do
this, it helsp tremendously to have a uniform lexical syntax that
corresponds to a data structure.
So you see it is designed for human convenience in doing something
that is not obvious to programmers who are not used to writing
program-writing programs.
In fact, Lisp's parentheses started out as a strictly pencil-and-paper
mathematical notation which was hand-translated to machine code, until
someone realized that a program could be written to do the job.
This is why Lisp is actually easy to read and write. It passed the
pencil-and-paper readability and writability litmus test even before
being implemented on a computer.
If you look at some other programming languages, they also have nested
lists. They are just embellished with inconsistent syntax. Let's take
C for instance. Consider the declaration:
unsigned long int x, y, z;
here you have two lists, represented differently: ``unsigned long
int'' is a declaration specifier list. And ``x, y, z'' is a declarator
list. Why are commas used for one type of list but not another? Then
there are lists of definitions and statements, like { tmp = x; x = y;
y = tmp; }. This list requires enclosure in braces and its elements
are semicolon-terminated (not separated---the last semi must be
there). Then consider parameter lists in a function call. These are
comma-separated, and round parentheses are required: foo(x, y, z).
These things are all just lists, but the notation varies. What on
earth for?
The Lisp language gets rid of this type of silly inconsistency. If
something is a list, then it looks the same everywhere. It's notated
by whitespace-separated tokens, and other syntactic elements which may
themselves be lists, enclosed in parentheses. End of story.
If C were transliterated into a Lisp-like notation in a rough way, you
might have something like this:
(((unsigned long int) (x y z))
((char) (c 'a'))
(= x 3)
(= y (foo x 3)))
instead of
{
unsigned long int x, y, z;
char c = 'a';
x = 3;
y = foo(x, 3);
}
all that has happened is that there is one way of writing anything
that is a list, or a pair, and that the operator-precedence grammar
has been reduced to a prefix notation.
What is the advantage of this? For one thing, you can write a program
which parses the parenthesized notation above, and that program does
not have to know anything about the C syntax; it just has to know how
to extract tokens and follow the parentheses. The parser for the
second version has to follow a complicated set of rules that
understands the C grammar. For example, it has to know that in the
declaration unsigned long int x, y, z, the x token is not another
declaration specifier, but a declarator. How does it know that? Well,
it has to know all the keywords that are declarators. It has to know a
good deal about the language just to unravel the syntax, and make a
many rigid assumptions.
A Lisp scanner doesn't have to know anything about the programming
language semantics in order to scan the syntax and produce the
corresponding data structure. The data structure can then be processed
by Lisp routines, some of which come from the program itself, and
finally handed off to the Lisp compile The real parsing, semantic
analysis and translation takes place on the data structure, where
notational issues like parentheses and ambiguity are no longer
factors. That data structure is in effect an abstract syntax tree.
That's what Lisp gives you; the notation to write an abstract syntax
tree almost directly.
Even if you like the embellished C notation better, or other similar
notations, you have to realize that they come at a big price.
Essentially, those notations are form of optimization. An optimization
takes place when the representation of something is transformed in
some way to achieve an improvement. As a result, it's usually hard for
that something to become something else without backing out of the
optimization first! The syntaxes of C or Python are, arguably,
optimizations with respect to some subjective readability criteria of
some programs. If suddenly other criteria become important, such as
efficient support for programmable syntax, these optimizations have to
be reexamined and undone; you have to reconsider whether these
allegedly readable representations for program source code are best.
Common Lisp leaves the syntactic optimization to the user. You can
achieve any notation you want. You can make a parser for a syntax
resembling Python or C, add that to your program, and then write the
rest of the program in that syntax, if you are so inclined. There is a
ready-made infix package that gives you notations like a +=
foo(b[++i], x). The lexical analyzer turns that into (INCF A (FOO
(AREF B (INCF I)) X)) before the rest of the Lisp system sees it.
It's a testimonial to the convenience of the parentheses that it's
extremely rare for Lisp programmers to make this type of thing, or
even use it when it's a readily available and highly portable piece of
freeware! There are better ways to optimize programmer time in Lisp
than to invent cryptic character-level read syntaxes.
···@ashi.footprints.net (Kaz Kylheku) writes:
> If you look at some other programming languages, they also have nested
> lists. They are just embellished with inconsistent syntax. Let's take
> C for instance. Consider the declaration:
>
> unsigned long int x, y, z;
>
> here you have two lists, represented differently: ``unsigned long
> int'' is a declaration specifier list. And ``x, y, z'' is a declarator
> list. Why are commas used for one type of list but not another? Then
> there are lists of definitions and statements, like { tmp = x; x = y;
> y = tmp; }. This list requires enclosure in braces and its elements
> are semicolon-terminated (not separated---the last semi must be
> there).
Assuming that they are in a statement context. If they are in an
expression context, they are separated (not terminated) by commas.
And wrapped in parens. Sort of like a function call, but with no
function.
--
~jrm
···@ashi.footprints.net (Kaz Kylheku) writes:
> [... Lisp is easy ...]
> If you look at some other programming languages, they also have nested
> lists. They are just embellished with inconsistent syntax. Let's take
> C for instance. Consider the declaration:
>
> unsigned long int x, y, z;
>
> here you have two lists, represented differently: ``unsigned long
> int'' is a declaration specifier list. And ``x, y, z'' is a declarator
> list. Why are commas used for one type of list but not another? Then
> there are lists of definitions and statements, like { tmp = x; x = y;
> y = tmp; }. This list requires enclosure in braces and its elements
> are semicolon-terminated (not separated---the last semi must be
> there). Then consider parameter lists in a function call. These are
> comma-separated, and round parentheses are required: foo(x, y, z).
> These things are all just lists, but the notation varies. What on
> earth for?
You missed the syntax for expressions:
tmp=x;x=y;y=tmp;
vs.:
y=(tmp=x,x=y,tmp);
As in, for example:
tmp=x;x=y;y=tmp;
if(y==0){
z=x;
}else{
z=y;
}
vs.:
z=(0==(y=(tmp=x,x=y,tmp)))?x:y;
Yes, THAT is crazy!
(And note the need of intensive use of parenthesis in C anyway!)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
···@ashi.footprints.net (Kaz Kylheku) writes:
> In fact, Lisp's parentheses started out as a strictly pencil-and-paper
> mathematical notation which was hand-translated to machine code, until
> someone realized that a program could be written to do the job.
The pencil-and-paper version of Lisp used M-expressions. The
parenthesis (s-exps) were supposed to be internal only. Steve Russell
noticed that you could get an instant lisp interpreter by hooking up
EVAL to READ and writing in the internal format. But then there was
no need for M-expressions.
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
> What were the lisp authors thinking?
Lisp is much older than C++. One advantage of its syntax is that it is
so extremely simple. You can write a complete Scheme (another Lisp
dialect) interpreter in a couple of weeks whereas a C++ compiler takes
years.
The simple syntax also means that you can extend the language with new
constructs completely seamlessly (perhaps except for the speed) within
the language itself. It is incredibly flexible; Lisp can support
object-oriented programming in a natural way through a _library_.
> Why did Stallman use lisp in emacs so extensively?
I don't know, but I think it was because Lisp is dynamically typed and
built for interpretation so you can extend the software easily, even
while it is running. Components and the like with C and C++ is
somewhat of an error-prone black art in comparison.
> Why oh why does such a weird and strange looking language end up in
> a major software package so now I have to learn it?
I think you, like me, are not old enough. It is only recently that
Pascal, C++, Java, Python etc. have become so popular that you don't
meet Lisp as much.
--
Ole Laursen
http://www.cs.auc.dk/~olau/
············@yahoo.com (Mike Cox) writes:
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
> What were the lisp authors thinking? Why did Stallman use lisp in
> emacs so extensively? Why oh why does such a weird and strange
> looking language end up in a major software package so now I have to
> learn it? My mind boggles at the craziness of lisp, and stallman's
> decision to add so much of it to lisp.
>
> If someone can answer my questions, I will spend less time with the
> emacs psychiatrist!
http://www.gnu.org/gnu/rms-lisp.html
http://www.gnu.org/software/emacs/emacs-paper.html
--
jan
I like!
How about this?
We don't need no obfuscation
We don't need no FORM-CONTROL
No CADR CADAR in the classroom
Hackers, leave them lists alone
Hey! Hackers! Leave them LISPs alone!
Chorus:
All in all, it's just another missing FUNCALL
All in all, purge LISP once and for all!
=============================================
In the following, Lisp == Common Lisp (ANSI):
---------------------------------------------
1. The fastest Lisp implementations are slow
(See any third-party benchmark)
2. Nobody but a small clique of fanatics likes it
(Whose existence proves nothing: No matter how odd
or perverted the cause, there will be followers)
3. The vast majority of people who study Lisp in
school, never want to use it out of their free will
later on.
3. Lisp is the most complicated language in the world
(It has the biggest standard specification document)
4. However, threads and GUI are not defined by the standard
5. There is no open-source cross-platform native code compiler
6. There is no standard C interface.
Phil Stripling <··············@cieux.zzn.com> wrote in message news:<··············@shell4.tdl.com>...
> ·······@fnord.io.com (MSCHAEF.COM) writes:
>
> > In article <····························@posting.google.com>,
> > nobody <··················@yahoo.com> wrote:
> > >············@yahoo.com (Mike Cox) wrote in message
> > >news:<···························@posting.google.com>...
> > >> I'm a C++ programmer, and have to use lisp because I want to use
> > >> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> > >> looking language syntax wise. What is up with this: (defun(foo()).
> > >
> > >(DEFUN FOO () NIL)
> >
> > The syntax of Lisp is that way primarily because of its regularity. Every
> > program is represented as a generalized list, with only a few concessions
> > to the more diverse syntax folks have come to expect from languages like
> > C, etc.
>
> From today's MOTD:
> We don't need no indirection
> We don't need no flow control
> No data typing or declarations
> Did you leave the lists alone?
>
> Hey! Hacker! Leave those lists alone!
>
> Chorus:
> All in all, it's just a pure-LISP function call.
> All in all, it's just a pure-LISP function call.
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <1xocvbzw.fsf@ccs.neu.edu>
··················@yahoo.com (nobody) writes:
> =============================================
> In the following, Lisp == Common Lisp (ANSI):
> ---------------------------------------------
>
> 1. The fastest Lisp implementations are slow
> (See any third-party benchmark)
Must be because it is interpreted. That and the fact that everything
is a list.
> 2. Nobody but a small clique of fanatics likes it
> (Whose existence proves nothing: No matter how odd
> or perverted the cause, there will be followers)
I don't understand why anyone would design a language without
putting emphasis on acceptance by the masses. Visual Basic is what we
all should be programming in! There are literally *millions* of
professional programmers who use it. That and Perl.
> 3. The vast majority of people who study Lisp in
> school, never want to use it out of their free will
> later on.
Exactly! Same as algebra or biology.
> 3. Lisp is the most complicated language in the world
> (It has the biggest standard specification document)
Commmon Lisp about 1400 pages
C++ (1998) 776 pages
Perl about 600 pages
Java Language Specification, second edition, 544 pages
Intercal - about 40 pages
> > 1. The fastest Lisp implementations are slow
> > (See any third-party benchmark)
>
> Must be because it is interpreted. That and the fact that everything
> is a list.
>
> > 2. Nobody but a small clique of fanatics likes it
> > (Whose existence proves nothing: No matter how odd
> > or perverted the cause, there will be followers)
>
> I don't understand why anyone would design a language without
> putting emphasis on acceptance by the masses. Visual Basic is what we
> all should be programming in! There are literally *millions* of
> professional programmers who use it. That and Perl.
>
> > 3. The vast majority of people who study Lisp in
> > school, never want to use it out of their free will
> > later on.
>
> Exactly! Same as algebra or biology.
>
> > 3. Lisp is the most complicated language in the world
> > (It has the biggest standard specification document)
>
> Commmon Lisp about 1400 pages
> C++ (1998) 776 pages
> Perl about 600 pages
> Java Language Specification, second edition, 544 pages
>
> Intercal - about 40 pages
Too funny! I especially like the Intercal reference :)
Joe Marshall wrote:
> ··················@yahoo.com (nobody) writes:
>> 3. Lisp is the most complicated language in the world
>> (It has the biggest standard specification document)
>
> Commmon Lisp about 1400 pages
> C++ (1998) 776 pages
> Perl about 600 pages
> Java Language Specification, second edition, 544 pages
SQL (2003; draft?): more than 3000 pages.
Jeremy.
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> ··················@yahoo.com (nobody) writes:
> > 3. Lisp is the most complicated language in the world
> > (It has the biggest standard specification document)
>
> Commmon Lisp about 1400 pages
> C++ (1998) 776 pages
> Perl about 600 pages
> Java Language Specification, second edition, 544 pages
>
> Intercal - about 40 pages
You remind me...
- Guy Steele made the interesting claim in the following video that
it's good to have what was once the largest spec and the smallest one.
(Common Lisp and Scheme respectively.)
http://www.ai.mit.edu/projects/dynlangs/wizards-panels.html
- If you add in something like the Javadocs, that'll pump up the code
heavily. And for those languages defined by a canonical
implementation, like Python, the pages of sourcecode should also be
considered.
For highly stylized languages, you probably want to add all the
tutorials and usenet posts needed to figure out the One True Way to
solve common problems. You wouldn't believe all the stuff my brain
accumulated while using Java. Fortunately Emacs is capable of
remembering a lot of Java patterns for me.
>>>>> "nobody" == nobody <··················@yahoo.com> writes:
nobody> =============================================
nobody> In the following, Lisp == Common Lisp (ANSI):
nobody> ---------------------------------------------
nobody> 1. The fastest Lisp implementations are slow
nobody> (See any third-party benchmark)
Says who? Says nobody!
What is the definition of "slow"? What particular third-party
benchmark are we talking about?
One analysis suggests that with the best of Lisp implementations you
should not accept a speed penality much above 10% relative to C.
The analysis in question was the Pfannkuch benchmark that was
thoroughly analysed in the ACM lisp journal some years back. I haven't
a reference at hand but will hunt one down if properly bullied.
Do not forget: benchmarking is roughly as reliable as statistics, you
can generally "prove" anything you like.
nobody> 2. Nobody but a small clique of fanatics likes it
nobody> (Whose existence proves nothing: No matter how odd
nobody> or perverted the cause, there will be followers)
And in what sense is that a problem for Lisp? It is merely the joy of
having infrared-capable 20/20 1000 mile vision on a planet of the
blind and deaf.
Can you say "business opportunity"?
nobody> 3. The vast majority of people who study Lisp in
nobody> school, never want to use it out of their free will
nobody> later on.
I have yet to encounter somebody who has aquired any useful
understanding of what Lisp is, that is not lamenting the difficulties
in finding a Lisp related job.
nobody> 3. Lisp is the most complicated language in the world
nobody> (It has the biggest standard specification document)
In what way did you arrive to "complicated language" from "big
standard document"?
C has more keywords than Lisp; the large part of the ANSI Lisp spec is
made up of library functions. My linux box has almost 4000 entries in
man3, how much do you think that would amount to if printed out on
paper?
This is not to dispute that Lisp is a big language but you probably
need to be a C programmer to consider that a problem. We Lisp
programmers prefer to have a large language in order to be able to
write small programs.
nobody> 4. However, threads and GUI are not defined by the standard
True, I am however curious about what examples of languages specifications,
including GUI and Threads, you are thinking about and what size these
specifications would be.
nobody> 5. There is no open-source cross-platform native code compiler
For what interesting definitions of "open-source", "cross-platform"
and "native code" do you use to make the above a valid statement?
It is true that the open-source implementations doesn't support
Windows well but they do cover the rest of the pack.
nobody> 6. There is no standard C interface.
As part of the standard no, as a separate open-source library yes.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
I apologize for not specifying a followup.
Follow-up set to comp.lang.lisp.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech wrote:
>>>>>>"nobody" == nobody <··················@yahoo.com> writes:
>
>
>
> nobody> =============================================
> nobody> In the following, Lisp == Common Lisp (ANSI):
> nobody> ---------------------------------------------
>
> nobody> 1. The fastest Lisp implementations are slow
> nobody> (See any third-party benchmark)
>
> Says who? Says nobody!
>
> What is the definition of "slow"? What particular third-party
> benchmark are we talking about?
>
> One analysis suggests that with the best of Lisp implementations you
> should not accept a speed penality much above 10% relative to C.
...which proves that it is slow, no?
> The analysis in question was the Pfannkuch benchmark that was
> thoroughly analysed in the ACM lisp journal some years back. I haven't
> a reference at hand but will hunt one down if properly bullied.
Since it helps to prove that Lisp is slow it's hardly vital information.
Feel free to pull it out if you want though.
> Do not forget: benchmarking is roughly as reliable as statistics, you
> can generally "prove" anything you like.
If you'd like we can all get together and write code in our language of
choice to perform a variety of common algos, find some sucker to run all
the samples sequentially on one computer, and see which languages excell
at which tasks. If Lisp comes out faster than the 'main-stream'
languages in any of those tests, we'll reconsider your objection.
> nobody> 2. Nobody but a small clique of fanatics likes it
> nobody> (Whose existence proves nothing: No matter how odd
> nobody> or perverted the cause, there will be followers)
>
> And in what sense is that a problem for Lisp? It is merely the joy of
> having infrared-capable 20/20 1000 mile vision on a planet of the
> blind and deaf.
Translation: I can see that Lisp is great, and all the rest of you are
morons. Sounds like a fanatic to me.
> Can you say "business opportunity"?
When was the last time you found a niche market screaming out for a Lisp
solution? A solution that could /only/ be implemented in Lisp?
> nobody> 3. The vast majority of people who study Lisp in
> nobody> school, never want to use it out of their free will
> nobody> later on.
>
> I have yet to encounter somebody who has aquired any useful
> understanding of what Lisp is, that is not lamenting the difficulties
> in finding a Lisp related job.
This could be because there aren't many Lisp-related jobs. Wonder why
that is?
> nobody> 3. Lisp is the most complicated language in the world
> nobody> (It has the biggest standard specification document)
>
> In what way did you arrive to "complicated language" from "big
> standard document"?
Actually I kind of agree with you here. A much better test would be to
measure the time taken to learn to /use/ the language. Hard to get
those kinds of stats in a usable fasion however.
> C has more keywords than Lisp; the large part of the ANSI Lisp spec is
> made up of library functions. My linux box has almost 4000 entries in
> man3, how much do you think that would amount to if printed out on
> paper?
Brainf*ck has fewer keywords... are you saying that it's a simple
language? Wow. There's a bold statement for you.
Also failing to see how 4000 man pages on a Linux box relates to
language complexity *shrug*
> This is not to dispute that Lisp is a big language but you probably
> need to be a C programmer to consider that a problem. We Lisp
> programmers prefer to have a large language in order to be able to
> write small programs.
...that don't run very fast :>
> nobody> 4. However, threads and GUI are not defined by the standard
>
> True, I am however curious about what examples of languages specifications,
> including GUI and Threads, you are thinking about and what size these
> specifications would be.
Agreed, most languages don't touch on GUI in their standards docs. A
couple do touch on threads though.
> nobody> 5. There is no open-source cross-platform native code compiler
>
> For what interesting definitions of "open-source", "cross-platform"
> and "native code" do you use to make the above a valid statement?
Find me an open-source Lisp compiler that produces native executables
that works on Windows, Linux and Mac... maybe Solaris too, just for fun.
> It is true that the open-source implementations doesn't support
> Windows well but they do cover the rest of the pack.
> nobody> 6. There is no standard C interface.
>
> As part of the standard no, as a separate open-source library yes.
This is a null point either way. The two languages should be kept
separate :>
> ------------------------+-----------------------------------------------------
> Christian Lynbech | christian ··@ defun #\. dk
> ------------------------+-----------------------------------------------------
> Hit the philistines three times over the head with the Elisp reference manual.
> - ·······@hal.com (Michael A. Petonic)
I refer you to point #3 :>
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
Corey Murtagh wrote:
> > One analysis suggests that with the best of Lisp implementations you
> > should not accept a speed penality much above 10% relative to C.
>
> ...which proves that it is slow, no?
If "slower than C" is equivalent to "slow," then, yeah, most
languages are "slow".
> If you'd like we can all get together and write code in our language of
> choice to perform a variety of common algos, find some sucker to run all
> the samples sequentially on one computer, and see which languages excell
> at which tasks. If Lisp comes out faster than the 'main-stream'
> languages in any of those tests, we'll reconsider your objection.
It's already been done. Doug Bagley has a project that tests a
bunch of languages beside one another in a variety of benchmarks.
(Some of his C++ samples could use some work, but I couldn't get
the benchmark to run on any of my machines because I'm dumb.) In
any event, Common Lisp performs admirably, coming in as "better"
than Python, Perl, and Java in the default benchmarks.
http://www.bagley.org/~doug/shootout/craps.shtml
Feel free to play with the numbers, though, to get the results
you're looking for. :)
-tom!
Tom Plunket wrote:
> Corey Murtagh wrote:
>
>>>One analysis suggests that with the best of Lisp implementations you
>>>should not accept a speed penality much above 10% relative to C.
>>
>>...which proves that it is slow, no?
>
> If "slower than C" is equivalent to "slow," then, yeah, most
> languages are "slow".
Well, I guess it kind of depends on your definitions. Comparison
against machine code is probably more useful, since that should give us
a baseline value to work against. Since C is closest to that, it's the
best baseline we have until something better comes along.
>>If you'd like we can all get together and write code in our language of
>>choice to perform a variety of common algos, find some sucker to run all
>>the samples sequentially on one computer, and see which languages excell
>>at which tasks. If Lisp comes out faster than the 'main-stream'
>>languages in any of those tests, we'll reconsider your objection.
>
> It's already been done. Doug Bagley has a project that tests a
> bunch of languages beside one another in a variety of benchmarks.
> (Some of his C++ samples could use some work, but I couldn't get
> the benchmark to run on any of my machines because I'm dumb.) In
> any event, Common Lisp performs admirably, coming in as "better"
> than Python, Perl, and Java in the default benchmarks.
>
> http://www.bagley.org/~doug/shootout/craps.shtml
>
> Feel free to play with the numbers, though, to get the results
> you're looking for. :)
It's close, but it enforces certain rules which I think are unrealistic.
For instance, some languages are much better with recursive algos than
the iterative equivalent.
I was more thinking that we produce the most optimal solution in our
chosen language rather than trying to find a common method and forcing
the language to work with that. After a few iterations of "oh, that's a
nice trick that'd work just as well in <language-of-choice>" the results
should stabilize somewhat... assuming roughly equivalent skill levels in
our chosen languages ;)
Oh, and let's get rid of the startup times to give Java a chance to
catch up, otherwise all the Java fans out there will bleat :>
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <1xocbbb7.fsf@ccs.neu.edu>
Corey Murtagh <·····@slingshot.no.uce> writes:
> Tom Plunket wrote:
>
>> Corey Murtagh wrote:
>>
>>>>One analysis suggests that with the best of Lisp implementations you
>>>> should not accept a speed penality much above 10% relative to C.
>>>
>>>...which proves that it is slow, no?
>> If "slower than C" is equivalent to "slow," then, yeah, most
>> languages are "slow".
>
Fortran isn't.
From: Christopher C. Stacy
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <u1xocl38w.fsf@news.dtpq.com>
>>>>> On Mon, 01 Mar 2004 14:46:04 -0500, Joe Marshall ("Joe") writes:
Joe> Corey Murtagh <·····@slingshot.no.uce> writes:
>> Tom Plunket wrote:
>>
>>> Corey Murtagh wrote:
>>>
>>>>> One analysis suggests that with the best of Lisp implementations you
>>>>> should not accept a speed penality much above 10% relative to C.
>>>>
>>>> ...which proves that it is slow, no?
>>> If "slower than C" is equivalent to "slow," then, yeah, most
>>> languages are "slow".
>>
Joe> Fortran isn't.
Clearly, the Best Language is machine code.
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <znb0593d.fsf@comcast.net>
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Mon, 01 Mar 2004 14:46:04 -0500, Joe Marshall ("Joe") writes:
>
> Joe> Corey Murtagh <·····@slingshot.no.uce> writes:
> >> Tom Plunket wrote:
> >>
> >>> Corey Murtagh wrote:
> >>>
> >>>>> One analysis suggests that with the best of Lisp implementations you
> >>>>> should not accept a speed penality much above 10% relative to C.
> >>>>
> >>>> ...which proves that it is slow, no?
> >>> If "slower than C" is equivalent to "slow," then, yeah, most
> >>> languages are "slow".
> >>
>
> Joe> Fortran isn't.
>
> Clearly, the Best Language is machine code.
Um, I dunno. Berlin and Surati were able to get a factor of 6 over
optimized Fortran using the `Supercomputer Toolkit'. The code was
able to achieve a better than a 12 MFlops sustained rate.
Hand-optimized Fortran for the same processor was only able to get 2
MFlops.
Oh wait. I forget to mention the language. Scheme.
@inproceedings{ berlin94partial,
author = "A. A. Berlin and R. J. Surati",
title = "Partial Evaluation for Scientific Computing: The Supercomputer Toolkit Experience",
booktitle = "Partial Evaluation and Seman\-tics-Based Program Manipulation, Orlando, Florida, June 1994 (Technical Report 94/9, Department of Computer Science, University of Melbourne)",
pages = "133--141",
year = "1994",
url = "citeseer.ist.psu.edu/berlin94partial.html" }
--
~jrm
Joe Marshall wrote:
> Corey Murtagh <·····@slingshot.no.uce> writes:
>
>>Tom Plunket wrote:
>>
>>>Corey Murtagh wrote:
>>>
>>>>>One analysis suggests that with the best of Lisp implementations you
>>>>>should not accept a speed penality much above 10% relative to C.
>>>>
>>>>...which proves that it is slow, no?
>>>
>>>If "slower than C" is equivalent to "slow," then, yeah, most
>>>languages are "slow".
>
> Fortran isn't.
I've always wondered about that. I've been hearing for years how
Fortran is faster than - or as fast as - C, and it seems strange. As
fast as, I'm not concerned about. Faster than... I'd be interested in
how and why, from a purely academic perspective.
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
Corey Murtagh <·····@slingshot.no.uce> writes:
> I've always wondered about that. I've been hearing for years how
> Fortran is faster than - or as fast as - C, and it seems strange. As
> fast as, I'm not concerned about. Faster than... I'd be interested in
> how and why, from a purely academic perspective.
One reason: Fortran guarantees that aliasing between arrays does not
occur. For instance, in the loop
for (i = 0; i < 100; ++i) {
c[i] = a[i-1] + b[i+1];
}
Fortran would not allow that c, a, and b point to identical memory
locations. This knowledge allows the compiler to do better
optimization in some cases. If recall correctly, the new C99 standard
introduces a "restrict" keyword which tells the C compiler to assume
non-aliasing arrays.
Matthias <··@spam.pls> writes:
> Corey Murtagh <·····@slingshot.no.uce> writes:
>
> > I've always wondered about that. I've been hearing for years how
> > Fortran is faster than - or as fast as - C, and it seems strange. As
> > fast as, I'm not concerned about. Faster than... I'd be interested in
> > how and why, from a purely academic perspective.
>
> One reason: Fortran guarantees that aliasing between arrays does not
> occur. For instance, in the loop
>
> for (i = 0; i < 100; ++i) {
> c[i] = a[i-1] + b[i+1];
> }
>
> Fortran would not allow that c, a, and b point to identical memory
> locations. This knowledge allows the compiler to do better
> optimization in some cases. If recall correctly, the new C99 standard
> introduces a "restrict" keyword which tells the C compiler to assume
> non-aliasing arrays.
Don't tell me that you'll find any programmer going to the pain of
writing things like
void arrmult(int n, int m, int l,
double (* restrict result)[l],
double const (* restrict a)[m],
double const (* restrict b)[l])
{
int i,j,k;
double sum;
for (i=0; i<n; i++)
for (k=0; k<l; k++) {
result[i][k] = 0.0;
for (j=0; j<m; j++)
result[i][k] += a[i][j]*b[j][k];
}
}
instead of the (mostly) equivalent
SUBROUTINE ARRMULT(N,M,L,RESULT,A,B)
INTEGER N,M,L,I,J,K
REAL*8 RESULT,A,B
DIMENSION RESULT(N,L),A(N,M),B(M,L)
DO 10 K=1,L
DO 10 I=1,N
RESULT(I,K)=0.0
DO 10 J=1,M
10 RESULT(I,K) = RESULT(I,K) + A(I,J) * B(J,K)
RETURN
END
The problem is that "restrict" can only apply to pointers, not to
arrays (even though arrays _are_ passed as pointers). That means
that you have to revert to pointer syntax.
The problem is that most good mathematicians tend to be bozo
programmers. The bozo Fortran version happens to be efficient (and
has been such for several decades). The bozo C version not. And the
efficient version could not be written until just recently.
All the old hands in mathematics have no clue about C9x.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
In article <···············@hundertwasser.ti.uni-mannheim.de>,
Matthias <··@spam.pls> wrote:
>Corey Murtagh <·····@slingshot.no.uce> writes:
>
>> I've always wondered about that. I've been hearing for years how
>> Fortran is faster than - or as fast as - C, and it seems strange. As
>> fast as, I'm not concerned about. Faster than... I'd be interested in
>> how and why, from a purely academic perspective.
>
>One reason: Fortran guarantees that aliasing between arrays does not
>occur. For instance, in the loop
>
>for (i = 0; i < 100; ++i) {
> c[i] = a[i-1] + b[i+1];
>}
>
>Fortran would not allow that c, a, and b point to identical memory
>locations.
Nitpick: I thought this was only disallowed when c, a, and b were
subprogram arguments? i.e., when a compiler couldn't reasonably
figure out whether the arrays overlapped? (And note that the concern
is about whether they overlap at all, not whether they're identical.
Maybe that's what you meant.)
>This knowledge allows the compiler to do better
>optimization in some cases. If recall correctly, the new C99 standard
>introduces a "restrict" keyword which tells the C compiler to assume
>non-aliasing arrays.
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
--
-- blm
······@myrealbox.com writes:
> In article <···············@hundertwasser.ti.uni-mannheim.de>,
> Matthias <··@spam.pls> wrote:
> >
> >for (i = 0; i < 100; ++i) {
> > c[i] = a[i-1] + b[i+1];
> >}
> >
> >Fortran would not allow that c, a, and b point to identical memory
> >locations.
>
> Nitpick: I thought this was only disallowed when c, a, and b were
> subprogram arguments? i.e., when a compiler couldn't reasonably
> figure out whether the arrays overlapped?
So what? All high-performance numerical work is done in libraries.
You don't have highly qualified people open-code such stuff at the
flick of a wrist.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Corey Murtagh wrote:
> I've always wondered about that. I've been hearing for years how
> Fortran is faster than - or as fast as - C, and it seems strange. As
> fast as, I'm not concerned about. Faster than... I'd be interested in
> how and why, from a purely academic perspective.
Too many programmers have grown up thinking of C as somehow closer to
the machine code than any other language. It's not. A _huge_ amount of
processing goes into compiling C well. It turns out that other
languages can do better, at least in certain domains. Fortran is better
than C at array-based and numerical code. Lisp is better than C at
linked structure manipulation. Scheme is better than C at some
recursive codes.
David
Corey Murtagh wrote:
> > If "slower than C" is equivalent to "slow," then, yeah, most
> > languages are "slow".
>
> Well, I guess it kind of depends on your definitions. Comparison
> against machine code is probably more useful, since that should
> give us a baseline value to work against. Since C is closest to
> that, it's the best baseline we have until something better comes
> along.
Maybe so, but at some level the actual machine code is irrelevant
anyway due to multi-pipeline processors and instruction
reordering. Consider that interpreted languages also have the
opportunity to optimize as they execute, while compiled languages
do not.
Lisp offers tail recursion optimization, too, which C does not.
This means that heavily recursive operations can actually be
faster and consume less memory than their C counterparts.
> > http://www.bagley.org/~doug/shootout/craps.shtml
> >
> > Feel free to play with the numbers, though, to get the results
> > you're looking for. :)
>
> It's close, but it enforces certain rules which I think are
> unrealistic. For instance, some languages are much better with
> recursive algos than the iterative equivalent.
The point was simply that he assembled this. He actually got all
of this "benchmarking" together. If someone wants to optimize
any of it, they should feel free. :)
I would agree with you though in principle, although I remember
the website author making a compelling case last time I really
read his argument.
I'm not a Lisp zealot. I haven't touched the stuff in ten years.
I do believe that C++ sucks though (even though I code in it
every day) despite the fact that it may compile to something
resembling fast, and despite being really good with it. ;)
-tom!
Tom Plunket wrote:
> Lisp offers tail recursion optimization, too, which C does not.
> This means that heavily recursive operations can actually be
> faster and consume less memory than their C counterparts.
IMO, to get use of tail recursion optimization, programmer should
take account that fact. In other words, programmer must write
in tail-recursive fashion. (Is this natural programming way for some
people? I wonder. I've had to pay more attention to write tail-recursive
procedure than iterative/ordinary recursive one)
Surely tail-recursive form gives somewhat natural logic abstraction.
But it is equivalent to corresponding iterative procedure. So C
programmer can just write in iterative form.
So I wonder the validity of Tom's above statement.
Regards,
Chul-Woong
On Tue, Mar 02, 2004 at 09:22:02AM +0000, Chul-Woong Yang wrote:
> Tom Plunket wrote:
> >Lisp offers tail recursion optimization, too, which C does not.
> >This means that heavily recursive operations can actually be
> >faster and consume less memory than their C counterparts.
>
> IMO, to get use of tail recursion optimization, programmer should
> take account that fact. In other words, programmer must write
> in tail-recursive fashion. (Is this natural programming way for some
> people? I wonder. I've had to pay more attention to write tail-recursive
> procedure than iterative/ordinary recursive one)
> Surely tail-recursive form gives somewhat natural logic abstraction.
> But it is equivalent to corresponding iterative procedure. So C
> programmer can just write in iterative form.
>
> So I wonder the validity of Tom's above statement.
Well, first of all, tail recursion optimization can be performed by C
compilers too, and GCC does for certain classes of it. However, I
prefer to be able to use either an iterative notation or a
tail-recursive notation depending on the problem. CL doesn't guarentee
tail recursion optimization but it is available from almost every
implementation. CL does provide plenty of decent iteration constructs,
better than C, so I am fairly satisfied by that. As for Tom's
statement, I don't generally find myself ``accidentally'' gaining from
tail recursion optimization--if it happens it is because I meant it to
be so. There are plenty of problems which benefit from such
optimization though, consider the implementation of a depth-first
search function using continuation-passing style (a very powerful method
of programming):
(defun depth-first-search (binary-tree test-fn success-fn fail-fn)
(cond ((not (binary-tree-p binary-tree))
(funcall fail-fn))
((funcall test-fn (node-value binary-tree))
(funcall success-fn nil))
(t
;; search left first
(depth-first-search
(left-child binary-tree)
test-fn
#'(lambda (path)
(funcall success-fn (cons 'left path)))
#'(lambda ()
;; try right
(depth-first-search
(right-child binary-tree)
test-fn
#'(lambda (path)
(funcall success-fn (cons 'right path)))
;; or else fall back
fail-fn))))))
;; let us define a binary tree to have nodes like so
;; (VALUE LEFT-CHILD RIGHT-CHILD) with NIL meaning "no child"
(defun node-value (node) (first node))
(defun left-child (node) (second node))
(defun right-child (node) (third node))
(defun binary-tree-p (node) (and (consp node) (= (length node) 3)))
(defun find-letter (tree letter)
(depth-first-search
tree
#'(lambda (x) (eql x letter))
#'identity
(constantly nil)))
(find-letter
'(A (B (C NIL NIL) (D NIL NIL)) (E (F NIL NIL) (G NIL NIL)))
'F)
==> (RIGHT LEFT)
I'll leave it as an exercise to the reader to generalize the algorithm
to n-ary trees (it involves using REDUCE on a higher-order local
function to generate the continuations =).
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <r7wb5ykq.fsf@comcast.net>
Chul-Woong Yang <······@aratech.co.kr> writes:
> Tom Plunket wrote:
>> Lisp offers tail recursion optimization, too, which C does not.
>> This means that heavily recursive operations can actually be
>> faster and consume less memory than their C counterparts.
>
> IMO, to get use of tail recursion optimization, programmer should
> take account that fact.
Not really. One primary advantage of having full tail call
optimization (not just self-tail call) is that you don't have to think
about it at all for it to work.
> In other words, programmer must write in tail-recursive fashion. (Is
> this natural programming way for some people?
It is for me, but no doubt some will think I've been `tainted'.
> I wonder. I've had to pay more attention to write
> tail-recursive procedure than iterative/ordinary recursive one)
> Surely tail-recursive form gives somewhat natural logic abstraction.
> But it is equivalent to corresponding iterative procedure. So C
> programmer can just write in iterative form.
It is not equivalent when you have several mutually tail recursive
procedures.
--
~jrm
Chul-Woong Yang <······@aratech.co.kr> wrote in message news:<·······················@news.bora.net>...
> Tom Plunket wrote:
> > Lisp offers tail recursion optimization, too, which C does not.
> > This means that heavily recursive operations can actually be
> > faster and consume less memory than their C counterparts.
>
> IMO, to get use of tail recursion optimization, programmer should
> take account that fact. In other words, programmer must write
> in tail-recursive fashion. (Is this natural programming way for some
> people? I wonder. I've had to pay more attention to write tail-recursive
> procedure than iterative/ordinary recursive one)
> Surely tail-recursive form gives somewhat natural logic abstraction.
> But it is equivalent to corresponding iterative procedure. So C
> programmer can just write in iterative form.
One unfortunate preconception is that Common Lisp forces use of
recursion. But in fact, there's a lot of do/for/loop constructs in
lisp. And you can create your own.
As a programmer, what I want is choice. Timothy Budd in
_Multiprogramming in Leda_ makes the interesting point that imperative
programming is about computation through incremental changes to state.
People don't often think in terms of boxes of state, except maybe
postal workers.
However, sometimes you do want to, so it's best to look for a language
that supports both points of view.
Tom Plunket wrote:
>
... snip ...
>
> Lisp offers tail recursion optimization, too, which C does not.
> This means that heavily recursive operations can actually be
> faster and consume less memory than their C counterparts.
Not so. Optimization is not language dependant, but
implementation dependant.
--
Chuck F (··········@yahoo.com) (··········@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer <··········@yahoo.com> writes:
> Tom Plunket wrote:
> >
> ... snip ...
> >
> > Lisp offers tail recursion optimization, too, which C does not.
> > This means that heavily recursive operations can actually be
> > faster and consume less memory than their C counterparts.
>
> Not so. Optimization is not language dependant, but
> implementation dependant.
Not so. The presence of certain language features can very well
preclude certain optimizations from being applicable.
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87smgr1bc5.fsf@nyct.net>
Matthias Blume <····@my.address.elsewhere> writes:
> CBFalconer <··········@yahoo.com> writes:
>
>> Tom Plunket wrote:
>> >
>> ... snip ...
>> >
>> > Lisp offers tail recursion optimization, too, which C does not.
>> > This means that heavily recursive operations can actually be
>> > faster and consume less memory than their C counterparts.
>>
>> Not so. Optimization is not language dependant, but
>> implementation dependant.
>
> Not so. The presence of certain language features can very well
> preclude certain optimizations from being applicable.
That's true. I've been spoiled by lisp where there is a culture of
always being able to flip a switch to turn off some genericity in
exchange for speed. (Except for inlining sealed generic-functions when
called with args that are sealed classes, but that's rather simple to
implement anyway, given a metaobject protocol: just get the effective
method and stick that in the code.)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
CBFalconer <··········@yahoo.com> writes:
> Tom Plunket wrote:
>>
> ... snip ...
>>
>> Lisp offers tail recursion optimization, too, which C does not. This
>> means that heavily recursive operations can actually be faster and
>> consume less memory than their C counterparts.
>
> Not so. Optimization is not language dependant, but implementation
> dependant.
Except in r5rs-compliant scheme.
~Tim
--
And today the millions cry, ·······@stirfried.vegetable.org.uk
We eat and drink while |http://spodzone.org.uk/cesspit/
tomorrow they die. |
Tim Haynes wrote:
> CBFalconer <··········@yahoo.com> writes:
>>Tom Plunket wrote:
>>
>>... snip ...
>>
>>>Lisp offers tail recursion optimization, too, which C does not. This
>>>means that heavily recursive operations can actually be faster and
>>>consume less memory than their C counterparts.
>>
>>Not so. Optimization is not language dependant, but implementation
>>dependant.
>
> Except in r5rs-compliant scheme.
And Postscript (and Forth?).
David
Feuer <·····@his.com> wrote:
> Tim Haynes wrote:
>
> > CBFalconer <··········@yahoo.com> writes:
> >>Tom Plunket wrote:
> >>
> >>... snip ...
> >>
> >>>Lisp offers tail recursion optimization, too, which C does not. This
> >>>means that heavily recursive operations can actually be faster and
> >>>consume less memory than their C counterparts.
> >>
> >>Not so. Optimization is not language dependant, but implementation
> >>dependant.
> >
> > Except in r5rs-compliant scheme.
>
> And Postscript (and Forth?).
>
You can do
: foo ( ... ) rdrop recurse ;
in Forth to get tail recursion, but even plain mutually recursive calls
require hacks & tricks.
But to pay justice to Forth model of computation, the cost of
function/word call is already minimal. I have implemented in Forth the
``change-account'' problem from SICP and it was a lot faster than in
Scheme. But not that easy to write.
--
~rv
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87ptbv2s02.fsf@nyct.net>
Vasile Rotaru <·······@seznam.cz> writes:
> You can do
>
> : foo ( ... ) rdrop recurse ;
>
> in Forth to get tail recursion, but even plain mutually recursive calls
> require hacks & tricks.
>
> But to pay justice to Forth model of computation, the cost of
> function/word call is already minimal.
But still constant. N may be smaller than 2N, but it's bigger than 5 for
many cases.
But you are technically correct, at least on the surface. A function
call in Lisp IS a much more complex thing, as it needs to support
dynamic redefinition. Redefinition of a word in forth requires blowing
away the dictionary down to that point, which removes definitions for
all words that might use that one in an optimized way.
Still, Common Lisp has declarations you can use to hint that the
compiler should perform optimizations that make the compilation more
static. Basically, Lisp lets the general case be flexible and lets you
do some very strong optimizations in the inner loops of your code.
> I have implemented in Forth the ``change-account'' problem from SICP
> and it was a lot faster than in Scheme. But not that easy to write.
That has nothing to do with TCO or any language. That has to do with
your scheme implementation. I'm continually surprised at just how
ineffecient the code emitted by many scheme compilers is. [Insert quip
about education and speed, or whatever.]
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87u1172sig.fsf@nyct.net>
Tom Plunket <·····@fancy.org> writes:
> Maybe so, but at some level the actual machine code is irrelevant
> anyway due to multi-pipeline processors and instruction
> reordering. Consider that interpreted languages also have the
> opportunity to optimize as they execute, while compiled languages
> do not.
Consider that languages are not interpreted or compiled. They are merely
implementation strategies. You can compile something, keep the source
around, and recompile at runtime with optimizations based on dynamic
observations.
> Lisp offers tail recursion optimization, too, which C does not.
> This means that heavily recursive operations can actually be
> faster and consume less memory than their C counterparts.
Eh? GCC does this. The only tail recursion that can be optimized is
recursion that is used to express an iterative process, anyway. TCO is
not anything unique to Lisp.
In fact, Common Lisp does not require it, as that would destroy
information useful for debugging and prevent redefinition of a function
from taking effect as a programmer might expect. Not to mention that no
one has yet given a universal definition of what is and is not a tail
call in Common Lisp because the details of handling stack vs. heap vs.
multiple-stack storage are left to the implementation to optimize for
the target architecture and the intended customers' needs.
In order to control these behaviors, there are declarations that can be
appled to any block of code to tell the compiler to optimize
(specifically sub-options for debuggability and speed) and to inline or
not inline certain functions. A self-tail call that has been optimized
to a jump can be considered a weak form of inlining.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Eh? GCC does this. The only tail recursion that can be optimized is
> recursion that is used to express an iterative process, anyway.
False. It can also optimize recursion that expresses coroutines.
> TCO is
> not anything unique to Lisp.
Not unique to Lisp, no. But Lisp (as Scheme) does it better than C ever
does. The calling conventions for Scheme are optimized for it, so even
across program modules TCO will happen.
> In fact, Common Lisp does not require it, as that would destroy
> information useful for debugging and prevent redefinition of a function
> from taking effect as a programmer might expect.
I don't know about function redefinition in CL, but it is possible to do
TCO while preserving some debugging information. It's not as efficient
as perfect TCO, but it's also not intended for production code.
Furthermore, stack traces are not nearly as useful in Lisp as they are
in large-function languages like C, Fortran, et al.
David
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87wu62pybp.fsf@nyct.net>
Feuer <·····@his.com> writes:
> Rahul Jain wrote:
>
>
>> Eh? GCC does this. The only tail recursion that can be optimized is
>> recursion that is used to express an iterative process, anyway.
>
> False. It can also optimize recursion that expresses coroutines.
That's not tail _recursion_.
>> TCO is
>> not anything unique to Lisp.
>
> Not unique to Lisp, no. But Lisp (as Scheme) does it better than C ever
> does. The calling conventions for Scheme are optimized for it, so even
> across program modules TCO will happen.
So? The same happens in C. TCO has nothing to do with modules. It has to
do with what is needed from the stack after the called function returns.
>> In fact, Common Lisp does not require it, as that would destroy
>> information useful for debugging and prevent redefinition of a function
>> from taking effect as a programmer might expect.
>
> I don't know about function redefinition in CL, but it is possible to do
> TCO while preserving some debugging information.
Then that information has nothing to do with the tail call that is being
elided.
> It's not as efficient as perfect TCO, but it's also not intended for
> production code.
You eiher elide the tail call or you don't. What's the inbetween? TCO
means _nothing_ is accumulated on the stack.
> Furthermore, stack traces are not nearly as useful in Lisp as they are
> in large-function languages like C, Fortran, et al.
I have no clue where you get this idea.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Feuer <·····@his.com> writes:
>
>>Rahul Jain wrote:
>>>Eh? GCC does this. The only tail recursion that can be optimized is
>>>recursion that is used to express an iterative process, anyway.
>>
>>False. It can also optimize recursion that expresses coroutines.
>
>
> That's not tail _recursion_.
Oof! So I used the wrong damn word. I meant tail calls of course.
>>Not unique to Lisp, no. But Lisp (as Scheme) does it better than C ever
>>does. The calling conventions for Scheme are optimized for it, so even
>>across program modules TCO will happen.
>
> So? The same happens in C. TCO has nothing to do with modules. It has to
> do with what is needed from the stack after the called function returns.
Excuse me? I was talking about the fact that compiled C codes really
have to work nicely with each other. If your program and your standard
library have different function-calling conventions then you have a
problem. It is true that this is an implementation issue rather than a
language issue, but it is AFAIK a universal implementation issue for C.
>>I don't know about function redefinition in CL, but it is possible to do
>>TCO while preserving some debugging information.
>
> Then that information has nothing to do with the tail call that is being
> elided.
True. The trick is when you elide the tail call.
>>It's not as efficient as perfect TCO, but it's also not intended for
>>production code.
>
> You eiher elide the tail call or you don't. What's the inbetween? TCO
> means _nothing_ is accumulated on the stack.
Holding on to the last N tail calls. There is a major Scheme
implementation (MIT Scheme?) that does this.
>>Furthermore, stack traces are not nearly as useful in Lisp as they are
>>in large-function languages like C, Fortran, et al.
>
> I have no clue where you get this idea.
Personal experience. You don't have to agree of course. I have found
other debugging techniques (mostly instrumenting code) to be much more
useful in Scheme.
David
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87d67qdqbe.fsf@nyct.net>
Feuer <·····@his.com> writes:
> Rahul Jain wrote:
>
>> Feuer <·····@his.com> writes:
>>
>>>Rahul Jain wrote:
> Oof! So I used the wrong damn word. I meant tail calls of course.
Fair enough. GCC also optimizes tail calls in general.
> Excuse me? I was talking about the fact that compiled C codes really
> have to work nicely with each other. If your program and your standard
> library have different function-calling conventions then you have a
> problem. It is true that this is an implementation issue rather than a
> language issue, but it is AFAIK a universal implementation issue for C.
So what? This does not make eliding tail calls any harder or easier.
It's the same thing in Lisp. If parameters go in certain registers and
then the stack, you have to follow that convention. What's stopping tail
call elision there?
>>>I don't know about function redefinition in CL, but it is possible to do
>>>TCO while preserving some debugging information.
>> Then that information has nothing to do with the tail call that is
>> being
>> elided.
>
> True. The trick is when you elide the tail call.
I can't divine any meaning in that statement...
>>>It's not as efficient as perfect TCO, but it's also not intended for
>>>production code.
>> You eiher elide the tail call or you don't. What's the inbetween? TCO
>> means _nothing_ is accumulated on the stack.
>
> Holding on to the last N tail calls. There is a major Scheme
> implementation (MIT Scheme?) that does this.
That's horribly strange and seems like a rather baroque way of dealing
with the problem. Oh well. leave it to a simple language to require
complex workarounds for its simplicity. :)
>>>Furthermore, stack traces are not nearly as useful in Lisp as they are
>>>in large-function languages like C, Fortran, et al.
>> I have no clue where you get this idea.
>
> Personal experience. You don't have to agree of course. I have found
> other debugging techniques (mostly instrumenting code) to be much more
> useful in Scheme.
I've found lisp to be FAR more debuggable (what with the ability to use
restarts, including restarting the current stack frame and forcing a
certain return value from the current stack frame, and redefine code
while in the debugger). With C and Java, I resort to instrumenting the
code and running it over and over again. Rather primitive technique.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <wu5xle16.fsf@comcast.net>
Rahul Jain <·····@nyct.net> writes:
> So what? This does not make eliding tail calls any harder or easier.
> It's the same thing in Lisp. If parameters go in certain registers and
> then the stack, you have to follow that convention. What's stopping tail
> call elision there?
The calling conventions in most C implementations (cdecl) is that the
caller is responsible for creating and destroying the stack frame for
the callee. If BAR took two arguments, but it wants to tail call BAZ
which takes three, how is the function FOO (which called out to BAR
with two arguments) going to know how to clean up when it gets control
again?
--
~jrm
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87vflhlcn7.fsf@nyct.net>
Joe Marshall <·············@comcast.net> writes:
> Rahul Jain <·····@nyct.net> writes:
>
>> So what? This does not make eliding tail calls any harder or easier.
>> It's the same thing in Lisp. If parameters go in certain registers and
>> then the stack, you have to follow that convention. What's stopping tail
>> call elision there?
>
> The calling conventions in most C implementations (cdecl) is that the
> caller is responsible for creating and destroying the stack frame for
> the callee. If BAR took two arguments, but it wants to tail call BAZ
> which takes three, how is the function FOO (which called out to BAR
> with two arguments) going to know how to clean up when it gets control
> again?
Doh. The only real experience I've had with C and assembly was on the
Mac 68k where you had a return instruction that would set the stack
pointer to the saved stack pointer. Rather retarded that at least the
function FOO doesn't remember where the stack was when it called BAR and
reset it to there, pulling the result from just beyond where it had the
stack before calling BAR. Oh well. That's the C world, I guess.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> > I don't know about function redefinition in CL, but it is possible to do
> > TCO while preserving some debugging information.
>
> Then that information has nothing to do with the tail call that is being
> elided.
>
> > It's not as efficient as perfect TCO, but it's also not intended for
> > production code.
>
> You eiher elide the tail call or you don't. What's the inbetween? TCO
> means _nothing_ is accumulated on the stack.
TCO does not necessarily mean that no information is kept about the
call. What we want to ensure is that the amount of information that
is kept cannot grow beyond a constant bound for any loop expressed
using tail calls (regardless of how many times the loop is executed).
This means that one cannot keep detailed information about every call,
but some summary information can very well be around without
disturbing the asymptotic space complexity of the code. For example,
one could keep information about the fact that (what looks like) a
loop has been executed and who participated in it.
(I have implemented such a scheme for an exception backtrace facility
in SML/NJ, so I know a little bit about it.)
Corey Murtagh <·····@slingshot.no.uce> writes:
>> Do not forget: benchmarking is roughly as reliable as statistics, you
>> can generally "prove" anything you like.
>
> If you'd like we can all get together and write code in our language of
> choice to perform a variety of common algos, find some sucker to run all
> the samples sequentially on one computer, and see which languages excell
> at which tasks. If Lisp comes out faster than the 'main-stream' languages
> in any of those tests, we'll reconsider your objection.
<http://www.bagley.org/~doug/shootout/craps.shtml> is one possible site of
interest.
HTH.
~Tim
--
These are the days when you wish ·······@stirfried.vegetable.org.uk
your bed was already made. |http://spodzone.org.uk/
Corey Murtagh <·····@slingshot.no.uce> writes:
> > Do not forget: benchmarking is roughly as reliable as statistics, you
> > can generally "prove" anything you like.
>
> If you'd like we can all get together and write code in our language
> of choice to perform a variety of common algos, find some sucker to
> run all the samples sequentially on one computer, and see which
> languages excell at which tasks. If Lisp comes out faster than the
> 'main-stream' languages in any of those tests, we'll reconsider your
> objection.
I had this stupid benchmark lying around anyway:
http://www.cvgpr.uni-mannheim.de/heiler/microbench/
It clearly shows that Lisp outperforms C++ in times of execution speed
in one test. Happy?
Matthias
Matthias <··@spam.pls> writes:
> Corey Murtagh <·····@slingshot.no.uce> writes:
>
> > > Do not forget: benchmarking is roughly as reliable as statistics, you
> > > can generally "prove" anything you like.
> >
> > If you'd like we can all get together and write code in our language
> > of choice to perform a variety of common algos, find some sucker to
> > run all the samples sequentially on one computer, and see which
> > languages excell at which tasks. If Lisp comes out faster than the
> > 'main-stream' languages in any of those tests, we'll reconsider your
> > objection.
>
> I had this stupid benchmark lying around anyway:
>
> http://www.cvgpr.uni-mannheim.de/heiler/microbench/
>
> It clearly shows that Lisp outperforms C++ in times of execution speed
> in one test. Happy?
What is stupid is to benchmark the processor time, instead of
benchmarking the programmer time!
The processors of most of the computers I use or administrate are
constantly at 90+% of idle time (hopefully used gratiously by nice
background processes). Why do you think Apple spends their time
adding useless graphic animations to their user interface? They've
got nothing better to keep their processors buzy!
The only valid benchmark is how soon can a Lisp programmer produce a
valid program vs. how soon can a C programmer produce a program that
does not crash half the time.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
"Pascal Bourguignon" <····@thalassa.informatimago.com> wrote
> > I had this stupid benchmark lying around anyway:
> >
> > http://www.cvgpr.uni-mannheim.de/heiler/microbench/
> >
> > It clearly shows that Lisp outperforms C++ in times of execution speed
> > in one test. Happy?
>
> What is stupid is to benchmark the processor time, instead of
> benchmarking the programmer time!
>
> The processors of most of the computers I use or administrate are
> constantly at 90+% of idle time (hopefully used gratiously by nice
> background processes). Why do you think Apple spends their time
> adding useless graphic animations to their user interface? They've
> got nothing better to keep their processors buzy!
>
> The only valid benchmark is how soon can a Lisp programmer produce a
> valid program vs. how soon can a C programmer produce a program that
> does not crash half the time.
You're making the common mistake of applying your criteria to measure other
people's needs. Maybe you don't need to squeeze as much out of your CPUs, but
it's naive to believe that everyone is in the same boat as you. In my own field
(financial systems), we have budgetary and space constraints that prevent us
from arbitrarily buying new systems. This results in the existing systems being
run to the maximum of their capacity most of the time. Having software that's
more efficient -- both by design and by using more efficient tools and
languages -- lets us do more on finite resources. That's for our operational
software. On the research side, there are various problems such as searching
through N-spaces, optimizations of various kinds, etc. that also use close to
100% of the CPU of whatever system we run them on. Again, efficiency allows us
to do more with what's available. If we can get 1% better results that our
competitors by being more efficient, this more than pays for the programmer
time. In fact, trying to economize programmer time in such cases can be too
costly.
So please abstain from coming down a mountain with stone tablets that
proselytize your personal and limited experiences as dogma from which only
"stupid" people deviate.
Claudio Puviani
From: Christopher C. Stacy
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <uvflob2sf.fsf@news.dtpq.com>
>>>>> On Mon, 01 Mar 2004 21:42:57 GMT, Claudio Puviani ("Claudio") writes:
Claudio> You're making the common mistake of applying your criteria
Claudio> to measure other people's needs. Maybe you don't need to
Claudio> squeeze as much out of your CPUs, but it's naive to believe
Claudio> that everyone is in the same boat as you.
That is very well put, and a good point.
Claudio> In my own field (financial systems), we have budgetary and
Claudio> space constraints that prevent us from arbitrarily buying
Claudio> new systems.
I would be very surprised if an accurate cost analysis had really
been made using the kind of information we're talking about here,
if for no other reason than that it's very difficult to identify
and quantify those things.
Most people most of the time are incompetent to do that, and just
middle along, and really just bullshitting about all that stuff.
Moreover, they also commonly employ such analysis as a smokescreen
for their own problems and political adgendas.
Besides, most such technical management business decisions (in all
domains, not just the financial services sector) are knowingly based
on non-technical criteria, anyway. Some bozo somewhere has decided
that the a particular technology is today's panacea, or that business
needs to be done with a particular vendor because of their reputation,
track record, company stability, or special deals or special contacts.
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87eksbafne.fsf@nyct.net>
······@news.dtpq.com (Christopher C. Stacy) writes:
> Besides, most such technical management business decisions (in all
> domains, not just the financial services sector) are knowingly based
> on non-technical criteria, anyway. Some bozo somewhere has decided
> that the a particular technology is today's panacea, or that business
> needs to be done with a particular vendor because of their reputation,
> track record, company stability, or special deals or special contacts.
I know for a fact that many financial insitiutions base their technology
decisions solely on these factors. In fact, they will replace an
existing system with a _slower_ one that provides no more features
(other than ones that could have been added to the existing system at a
fraction of the man-hours) just because they'll now be used the "latest"
technologies, not that anyone using the system will care.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Claudio Puviani" <·······@hotmail.com> writes:
> > > It clearly shows that Lisp outperforms C++ in times of execution speed
> > > in one test. Happy?
> > The only valid benchmark is how soon can a Lisp programmer produce a
> > valid program vs. how soon can a C programmer produce a program that
> > does not crash half the time.
>
> You're making the common mistake of applying your criteria to measure other
> people's needs.
No I'm not.
It's the other people who try to apply _their_ criteria to lisp. It
would not matter if it was impossible to have a lisp implementation
running fast enough to control a large hadron collider, of small
enough to fit the 4-bit processor of my washing machine. That's why
assembler and C are for.
You could want to compare the performance of python implementations
vs. lisp implementations, or between lisp implementations and scheme
implementations.
But it's meaningless to try to do it between C/C++ and Lisp (unless
you include lpp or ecl on one side, and another Common-Lisp
implementation on the other side).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
"Pascal Bourguignon" <····@thalassa.informatimago.com> wrote
>
> "Claudio Puviani" <·······@hotmail.com> writes:
> > > > It clearly shows that Lisp outperforms C++ in times of execution speed
> > > > in one test. Happy?
> > > The only valid benchmark is how soon can a Lisp programmer produce a
> > > valid program vs. how soon can a C programmer produce a program that
> > > does not crash half the time.
> >
> > You're making the common mistake of applying your criteria to measure other
> > people's needs.
>
> No I'm not.
When you say "the only valid benchmark", you're presuming to think for everyone
else. If you're going to be the conscience of the universe, at least try having
ideas that aren't absurd.
> It's the other people who try to apply _their_ criteria to lisp.
People are allowed to apply whatever criteria they choose to select a language
for their own use. You don't get to legislate what they can or cannot consider
to be desirable attributes.
Feel free to love lisp for whatever reason, but your opinion of "the only valid
benchmark" is completely worthless and can only bring you ridicule.
Claudio Puviani
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87ishnafr9.fsf@nyct.net>
"Claudio Puviani" <·······@hotmail.com> writes:
> On the research side, there are various problems such as searching
> through N-spaces, optimizations of various kinds, etc. that also use close to
> 100% of the CPU of whatever system we run them on. Again, efficiency allows us
> to do more with what's available. If we can get 1% better results that our
> competitors by being more efficient, this more than pays for the programmer
> time. In fact, trying to economize programmer time in such cases can be too
> costly.
Of course, the issue of a compiler's quality of code generation is just
a constant-factor improvement. Being able to redirect programmer time
towards improving the algorithm and allowing the programmer to explore
the problem and solution space to discover better algorithms might make
the problem take O(n) time instead of O(n^4) time.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <·····@nyct.net> wrote in message ···················@nyct.net...
> "Claudio Puviani" <·······@hotmail.com> writes:
>
> > On the research side, there are various problems such as searching
> > through N-spaces, optimizations of various kinds, etc. that also use close
to
> > 100% of the CPU of whatever system we run them on. Again, efficiency allows
us
> > to do more with what's available. If we can get 1% better results that our
> > competitors by being more efficient, this more than pays for the programmer
> > time. In fact, trying to economize programmer time in such cases can be too
> > costly.
>
> Of course, the issue of a compiler's quality of code generation is just
> a constant-factor improvement. Being able to redirect programmer time
> towards improving the algorithm and allowing the programmer to explore
> the problem and solution space to discover better algorithms might make
> the problem take O(n) time instead of O(n^4) time.
True, but that O(n) algorithm written in FastLanguage might run 10 times as fast
as the same algorithm implemented in SlowLanguage. The company that implements
that algorithm in FastLanguage can do 10 times more than their competitor that
uses SlowLanguage or it can use a system that's 10 times slower to achieve the
same goal.
The nonsensical argument that Pascal was making is that it might take a bit less
time to code the algorithm in one language and that that is the only valid
criterion for selecting the language.
Claudio Puviani
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87wu631bjl.fsf@nyct.net>
"Claudio Puviani" <·······@hotmail.com> writes:
> True, but that O(n) algorithm written in FastLanguage might run 10
> times as fast as the same algorithm implemented in SlowLanguage. The
> company that implements that algorithm in FastLanguage can do 10 times
> more than their competitor that uses SlowLanguage or it can use a
> system that's 10 times slower to achieve the same goal.
And if, by using said FastLanguage, it takes one a certain amount of
time to implement the O(n^4) algorithm, but with said SlowLanguage
(which is really only going to be at most 50% slower on the same
algorithm) the programmer was able to experiment with a half-dozen
different algorithms and managed to implement the O(n) algorithm in the
same amount of time. The remaining time could even be used to
reimplement the algorithm in FastLanguage to get the last teeny bit of
speedup, if it's really worth that time.
> The nonsensical argument that Pascal was making is that it might take
> a bit less time to code the algorithm in one language and that that is
> the only valid criterion for selecting the language.
Only because it's just as nonsensical as claiming that programmer time
can't be spent on speeding up the algorithm itself, but instead on
fiddling with minor details of the implementation so that the language
will accept the code.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Tue, Mar 02, 2004 at 02:49:18PM +0000, Claudio Puviani wrote:
> True, but that O(n) algorithm written in FastLanguage might run 10 times as fast
> as the same algorithm implemented in SlowLanguage. The company that implements
> that algorithm in FastLanguage can do 10 times more than their competitor that
> uses SlowLanguage or it can use a system that's 10 times slower to achieve the
> same goal.
However if one company implements a product in 10 months using
traditional-language and another company only takes 2 months to do it
using rapid-devel-language then is there not an advantage for the second
company? They will have a product out and earning money for 8 months
longer than the other company. In that time they can work on a faster
version if it actually becomes necessary. This is a far more likely
situation in real-world production, and I think a better argument, than
the time gain from the faster implementation of an individual algorithm
used in a small portion of some program. Obviously there may be other
considerations too. And the reason why this point is still very
debatable is because it is very difficult to conduct a conclusive and
objective study.
P.S. Languages are not fast and slow, implementations are. However a
language design could inhibit or promote rapid development.
P.P.S. Welcome to the 21st century. High level language compilers are
damn good these days. And yet, people are still satisfied with
so-called scripting languages. How can you complain about Lisp, with
its mature compilers?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
"Matthew Danish" <·······@andrew.cmu.edu> wrote
> On Tue, Mar 02, 2004 at 02:49:18PM +0000, Claudio Puviani wrote:
> > True, but that O(n) algorithm written in FastLanguage might run 10 times as
fast
> > as the same algorithm implemented in SlowLanguage. The company that
implements
> > that algorithm in FastLanguage can do 10 times more than their competitor
that
> > uses SlowLanguage or it can use a system that's 10 times slower to achieve
the
> > same goal.
>
> However if one company implements a product in 10 months using
> traditional-language and another company only takes 2 months to do it
> using rapid-devel-language then is there not an advantage for the second
> company?
Time to market is an important aspect, and one reason why systems are often
prototyped in one language and then rewritten in another. However, the 5:1
productivity ration that you're presenting is an extreme exaggeration, except
for very rare cases. The point, if you bother to actually READ what's written
instead of hunting for windmills to tilt at, is that programmer productivity is
only ONE criterion, not the ONLY criterion as the poster to whom I replied
asserted. Time to market is another. The skill set of your staff is yet another.
It's up to whoever is managing a project to weigh the pros an cons of a
particular approach. It is not up to the OP to make those decisions based on his
own distorted philosophies.
> P.S. Languages are not fast and slow, implementations are.
Incorrect. Language features can render a language inherently slower than
another. For example, in Java, object composition forces multiple levels of
indirection that no amount of compilation and optimization can remove. The
language itself mandates that. Any language that provides a better approach to
composition, such as C++, has a distinct and measurable advantage. Fortran's
calling conventions offer an inherently more efficient mechanism than that
offered by C or C++, albeit at the cost of flexibility. There's no philosophical
debate to be had on this topic. It's completely quantifiable even in the
abstract.
> High level language compilers are damn good these days. And yet,
> people are still satisfied with so-called scripting languages.
I use perl all the time where it's appropriate. I also use lisp and other
languages where appropriate. I just happen to know enough to NOT use them when
it's not appropriate and I certainly know enough to disregard absurd
generalizations.
> How can you complain about Lisp, with its mature compilers?
I don't know what you're smoking or sniffing, but it can't be good for your
health. Go back and read my posts and you'll see that I never once complained
about lisp, only about the ridiculous assertions of one poster. If you feel a
desperate need to defend lisp, you might want to do so against someone who has a
beef with lisp.
Claudio Puviani
>>>>> "Claudio" == Claudio Puviani <·······@hotmail.com> writes:
Claudio> True, but that O(n) algorithm written in FastLanguage might
Claudio> run 10 times as fast as the same algorithm implemented in
Claudio> SlowLanguage. The company that implements that algorithm in
Claudio> FastLanguage can do 10 times more than their competitor that
Claudio> uses SlowLanguage or it can use a system that's 10 times
Claudio> slower to achieve the same goal.
But that factor 10x only holds for a fixed small set of input. As the
input size goes up, no amount of FastLanguage trickery is going to
keep the SlowLanguage implementation from taking the lead.
That is why people do O() analysis and study algorithms. A good
algorithm will always end up beating even the fastest implementation
on the fastest hardware of a poor one.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
"Christian Lynbech" <·················@ericsson.com> wrote in message
···················@situla.ted.dk.eu.ericsson.se...
> >>>>> "Claudio" == Claudio Puviani <·······@hotmail.com> writes:
>
> Claudio> True, but that O(n) algorithm written in FastLanguage might
> Claudio> run 10 times as fast as the same algorithm implemented in
> Claudio> SlowLanguage. The company that implements that algorithm in
> Claudio> FastLanguage can do 10 times more than their competitor that
> Claudio> uses SlowLanguage or it can use a system that's 10 times
> Claudio> slower to achieve the same goal.
>
> But that factor 10x only holds for a fixed small set of input. As the
> input size goes up, no amount of FastLanguage trickery is going to
> keep the SlowLanguage implementation from taking the lead.
>
> That is why people do O() analysis and study algorithms. A good
> algorithm will always end up beating even the fastest implementation
> on the fastest hardware of a poor one.
Doh. I'm not arguing against finding a better algorithm. I'm saying that for a
given algorithm, including the most efficient one, there's an additional
advantage to be had by running in a more efficient environment. No one, least of
all I, ever said that you select a faster environment to the detriment of a
better algorithm. Read what I actually write.
Claudio Puviani
"Claudio Puviani" <·······@hotmail.com> writes:
> Doh. I'm not arguing against finding a better algorithm. I'm saying
> that for a given algorithm, including the most efficient one,
> there's an additional advantage to be had by running in a more
> efficient environment. No one, least of all I, ever said that you
> select a faster environment to the detriment of a better
> algorithm. Read what I actually write.
One problem to be noted is that the amount of complexity a human can
handle is limited. A language in which an efficient algorithm can be
most conveniently expressed will make the programmer tend to produce
efficient code.
If I can manage to produce an O(n^1.3 lg n) algorithm based on some
weird recursive arithmetic in modular rings in Lisp, but will fail the
same task in C before I finish it because I get drawn into complicated
storage size and index calculations for the intermediate results, the
program will run faster if I write in Lisp. Even though it can then
be automatically or manually translated into C. Because writing in C
I would never get to finish the algorithm, having my brain falling
apart before that time, and would need to use an O(n^1.6) algorithm
instead.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On 04 Mar 2004 00:57:53 +0100, David Kastrup <···@gnu.org> wrote:
[snip]
>One problem to be noted is that the amount of complexity a human can
>handle is limited. A language in which an efficient algorithm can be
>most conveniently expressed will make the programmer tend to produce
>efficient code.
>
>If I can manage to produce an O(n^1.3 lg n) algorithm based on some
>weird recursive arithmetic in modular rings in Lisp, but will fail the
>same task in C before I finish it because I get drawn into complicated
>storage size and index calculations for the intermediate results, the
>program will run faster if I write in Lisp. Even though it can then
>be automatically or manually translated into C. Because writing in C
>I would never get to finish the algorithm, having my brain falling
>apart before that time, and would need to use an O(n^1.6) algorithm
>instead.
But are you speaking only for yourself re the difficulties of using C
or are you claiming this for all programmers using C?
Richard Harter, ···@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
I used to do things that were good for me because they were fun.
Now I do them because they are good for me. Fun was better.
···@tiac.net (Richard Harter) writes:
> On 04 Mar 2004 00:57:53 +0100, David Kastrup <···@gnu.org> wrote:
>
> [snip]
>
> >One problem to be noted is that the amount of complexity a human can
> >handle is limited. A language in which an efficient algorithm can be
> >most conveniently expressed will make the programmer tend to produce
> >efficient code.
> >
> >If I can manage to produce an O(n^1.3 lg n) algorithm based on some
> >weird recursive arithmetic in modular rings in Lisp, but will fail the
> >same task in C before I finish it because I get drawn into complicated
> >storage size and index calculations for the intermediate results, the
> >program will run faster if I write in Lisp. Even though it can then
> >be automatically or manually translated into C. Because writing in C
> >I would never get to finish the algorithm, having my brain falling
> >apart before that time, and would need to use an O(n^1.6) algorithm
> >instead.
>
> But are you speaking only for yourself re the difficulties of using
> C or are you claiming this for all programmers using C?
I can send you mathematical descriptions of algorithms which I have
finally abandoned completing casting into C. The mathematics behind
it is trivial, just adding and multiplication. You just drown in
index calculation, storage allocations and so on.
And don't underestimate me: I am able to program complete standalone
projects including operating system and applications, I have written
BIOSses and systems and target compilers in a number of different
languages including assembly, and know C by heart.
Again, I can send you the descriptions of the algorithms if you want
that are concerned here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On 04 Mar 2004 12:58:12 +0100, David Kastrup <···@gnu.org> wrote:
>···@tiac.net (Richard Harter) writes:
>
>> On 04 Mar 2004 00:57:53 +0100, David Kastrup <···@gnu.org> wrote:
>>
>> [snip]
>>
>> >One problem to be noted is that the amount of complexity a human can
>> >handle is limited. A language in which an efficient algorithm can be
>> >most conveniently expressed will make the programmer tend to produce
>> >efficient code.
>> >
>> >If I can manage to produce an O(n^1.3 lg n) algorithm based on some
>> >weird recursive arithmetic in modular rings in Lisp, but will fail the
>> >same task in C before I finish it because I get drawn into complicated
>> >storage size and index calculations for the intermediate results, the
>> >program will run faster if I write in Lisp. Even though it can then
>> >be automatically or manually translated into C. Because writing in C
>> >I would never get to finish the algorithm, having my brain falling
>> >apart before that time, and would need to use an O(n^1.6) algorithm
>> >instead.
>>
>> But are you speaking only for yourself re the difficulties of using
>> C or are you claiming this for all programmers using C?
>
>I can send you mathematical descriptions of algorithms which I have
>finally abandoned completing casting into C. The mathematics behind
>it is trivial, just adding and multiplication. You just drown in
>index calculation, storage allocations and so on.
If you would be so good, please send me a description or two, and I
will take a stab at it. I don't guarantee a fast result (or any at
all) - I have a full plate and an empty mind.
>
>And don't underestimate me: I am able to program complete standalone
>projects including operating system and applications, I have written
>BIOSses and systems and target compilers in a number of different
>languages including assembly, and know C by heart.
If I may presume to offer a spot of advice: We are all of us here (or
at least most of us) quite capable and experienced programmers. I
have every confidence that you are among that select company. For
just that reason it does not do to puff off your wares, or to
generalize your experience into iron law. To say, "In my experience C
is such and such" is one thing and saying "C is such and such" is
quite something else.
>
>Again, I can send you the descriptions of the algorithms if you want
>that are concerned here.
Richard Harter, ···@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
I used to do things that were good for me because they were fun.
Now I do them because they are good for me. Fun was better.
Richard Harter wrote:
> David Kastrup <···@gnu.org> wrote:
>
... snip ...
> >
> >I can send you mathematical descriptions of algorithms which I have
> >finally abandoned completing casting into C. The mathematics behind
> >it is trivial, just adding and multiplication. You just drown in
> >index calculation, storage allocations and so on.
>
> If you would be so good, please send me a description or two, and I
> will take a stab at it. I don't guarantee a fast result (or any at
> all) - I have a full plate and an empty mind.
Yes, do post a few. Some people here (comp.programming) may be
willing to spend some time on them. The key is usually to isolate
those complications in suitable simpleminded functions.
They are probably OT on c.l.c++. Don't know about the other
groups.
--
Chuck F (··········@yahoo.com) (··········@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <878yiedq39.fsf@nyct.net>
"Claudio Puviani" <·······@hotmail.com> writes:
> Doh. I'm not arguing against finding a better algorithm. I'm saying that for a
> given algorithm, including the most efficient one, there's an additional
> advantage to be had by running in a more efficient environment. No one, least of
> all I, ever said that you select a faster environment to the detriment of a
> better algorithm. Read what I actually write.
Then you've been ignoring what we've said. By choosing an environment
that allows you to explore your algorithm and its behaviors more easily,
as well as express your desires more abstractly so that the exact
implementation is separated from the interface, you can spend more time
finidng a faster algorithm instead of being forced to microoptimize some
algorithm that you just want to play around with.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <·····@nyct.net> wrote
> "Claudio Puviani" <·······@hotmail.com> writes:
>
> > Doh. I'm not arguing against finding a better algorithm. I'm saying that for
a
> > given algorithm, including the most efficient one, there's an additional
> > advantage to be had by running in a more efficient environment. No one,
least of
> > all I, ever said that you select a faster environment to the detriment of a
> > better algorithm. Read what I actually write.
>
> Then you've been ignoring what we've said. By choosing an environment
> that allows you to explore your algorithm and its behaviors more easily,
> as well as express your desires more abstractly so that the exact
> implementation is separated from the interface, you can spend more time
> finidng a faster algorithm instead of being forced to microoptimize some
> algorithm that you just want to play around with.
Finding an algorithm is an analytical exercise that's completely abstract of the
programming environment -- and of programming. Unless one doesn't understand
algorithm analysis, there's no need to "explore" the behavior. In those sadly
too numerous cases where the programmer doesn't understand algorithm analysis,
both time and money would be better spent sending the individual to an
algorithmics class at the local university than they would giving that person a
tool that lets them experiment. Let me repeat this: you do not find better
algorithms more easily with one language than you do with another.
Claudio Puviani
"Claudio Puviani" <·······@hotmail.com> wrote in message news:<······················@news4.srv.hcvlny.cv.net>...
> "Rahul Jain" <·····@nyct.net> wrote
> Finding an algorithm is an analytical exercise that's completely abstract of the
> programming environment -- and of programming. Unless one doesn't understand
> algorithm analysis, there's no need to "explore" the behavior. In those sadly
> too numerous cases where the programmer doesn't understand algorithm analysis,
> both time and money would be better spent sending the individual to an
> algorithmics class at the local university than they would giving that person a
> tool that lets them experiment. Let me repeat this: you do not find better
> algorithms more easily with one language than you do with another.
Here, I think you'll find that multiparadigm programmers will disagree
with you. _Multiparadigm Programming in Leda_ by Timothy Budd argues
that different paradigms will make some solutions more obvious and
less painful to conceive.
He mentions the Sapir-Whorf hypothesis; and though he doesn't mention
the Leibniz/Newton notation schism, I think it's apropos. (And I hope
it is not an urban legend. ;)
Also it argues that the software crisis (where Moore's Law kinds of
advances are increasingly eaten up by the need to manage complexity)
http://en.wikipedia.org/wiki/Software_crisis
is due to singlemindedness in paradigms. Iterative programming is
about getting results through the gradual transformation of state. It
is definitely not the most natural solution-space for every problem,
though it does excel at some.
Now, I do think one will find it an uphill battle to argue that a
general purpose language should be singleparadigm when given a
sufficiently reasonable multiparadigm choice.
Claudio wrote:
) Let me repeat this: you do not find better
) algorithms more easily with one language than you do with another.
I beg to differ, and I suggest the language PROLOG as proof.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
"Claudio Puviani" <·······@hotmail.com> writes:
> "Rahul Jain" <·····@nyct.net> wrote
> Finding an algorithm is an analytical exercise that's completely abstract of the
> programming environment -- and of programming. Unless one doesn't understand
> algorithm analysis, there's no need to "explore" the behavior. In those sadly
> too numerous cases where the programmer doesn't understand algorithm analysis,
> both time and money would be better spent sending the individual to an
> algorithmics class at the local university than they would giving that person a
> tool that lets them experiment. Let me repeat this: you do not find better
> algorithms more easily with one language than you do with another.
I disagree. Not all (not even most) algorithms are examples of what
is taught in algorithms classes, nor can most algorithms used in a
complex program be easily analyzed in terms of traditional asymptotic
complexity.
In fact, there is a large, gray zone of algorithms that are specific
to a system, and that are best explored by coding them up and
observing their behavior (execution time, memory consumption) on real
data. Such experimentation requires a language that lets you write
such experimental code with very little effort, and that lets you
write code that is not critical in terms of execution time faster, so
as to allow more time to spend on critical parts of the system.
Therefore, a language that forces you to pay attention to low-level
issues in all parts of the system will take time from more important
work on crucial algorithms in a few, critical parts. Think of
assembler, that forces you to pay attention to things like parameter
passing and where you put local variables. It is the same with
higher-level languages. Some languages forces the programmer to pay
attention to low-level aspects of the system that other languages will
handle automatically.
In fact, there is a wonderful example of this phenomenon that was
presented at ILC 2002 (see for instance
http://www.paulgraham.com/carl.html). The predecessor was written in
assembler (for speed) and required a large number of mainframes to
run. Thanks to a programming language that allowed more clever
algorithms to be explored more easily (and less time spent on
unimportant stuff), the new system runs on PCs with GNU/Linux on them,
and it is much faster than the predecessor.
--
Robert Strandh
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
Rahul Jain wrote:
>
> "Claudio Puviani" <·······@hotmail.com> writes:
>
> > On the research side, there are various problems such as searching
> > through N-spaces, optimizations of various kinds, etc. that also use close to
> > 100% of the CPU of whatever system we run them on. Again, efficiency allows us
> > to do more with what's available. If we can get 1% better results that our
> > competitors by being more efficient, this more than pays for the programmer
> > time. In fact, trying to economize programmer time in such cases can be too
> > costly.
>
> Of course, the issue of a compiler's quality of code generation is just
> a constant-factor improvement. Being able to redirect programmer time
> towards improving the algorithm and allowing the programmer to explore
> the problem and solution space to discover better algorithms might make
> the problem take O(n) time instead of O(n^4) time.
This is not quite true. I've seen and used compilers that did all sorts of
nifty tricks with pure-functional routines. I've had order(n!) source code
compile to order(n) object code using ART*Lisp, for example: the compiler
memoized the function to eliminate a (stupid, mea culpa) branching recursion.
In side-effect-o-rama languages like c/c++, this is almost never worthwhile
because provably pure-functional routines are rare. But in Lisps, once people
get the hang of it and if you can keep them from using mutable objects for
everything, well over 90% of all functions are pure functional (ie, cause no
side-effects and are unaffected by anything other than their arguments).
Compilers can aggressively memoize or even algebraically rewrite such functions,
not just to reduce by a constant factor, but to lower their order of complexity.
Bear
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <ad2y6byn.fsf@comcast.net>
Ray Dillinger <····@sonic.net> writes:
> In side-effect-o-rama languages like c/c++, this is almost never worthwhile
> because provably pure-functional routines are rare. But in Lisps, once people
> get the hang of it and if you can keep them from using mutable objects for
> everything, well over 90% of all functions are pure functional (ie, cause no
> side-effects and are unaffected by anything other than their arguments).
I once wrote a compiler that turned out to be pure functional. It
wasn't a very sophisticated compiler, and I didn't explicitly try to
be pure functional, it just so happened that I never had a need for
side effects.
Once it was working, I memoized the crap out of it.
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> Once it was working, I memoized the crap out of it.
What does it mean to memoize something?
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
David Steuber <·············@verizon.net> wrote in message news:<··············@david-steuber.com>...
> Joe Marshall <·············@comcast.net> writes:
>
> > Once it was working, I memoized the crap out of it.
>
> What does it mean to memoize something?
(Nils explained by the time I typed this...) Norvig wrote some handy
memoization utils in PAIP, if you search for the term "memo" on this
page:
http://www.norvig.com/paip/auxfns.lisp
One caveat though. PAIP is a teaching book, and he used funky
defaults to maintain backwards-compatibility with an earlier, weaker
version in the chapter. So you don't want to use his defaults.
Better is:
:key #'identity
:test #'equal
From then on, you can do cool stuff like change the global definition
of a function to one that memoizes/caches itself. In ONE command.
This stuff is the reason I like lisp being non-mainstream, because
it's still fun to go on usenet and just write about any old thing I
learned about it. If it were mainstream, I'd take it for granted and
do something more useful.
David Steuber <·············@verizon.net> writes:
> Joe Marshall <·············@comcast.net> writes:
>
> > Once it was working, I memoized the crap out of it.
>
> What does it mean to memoize something?
Hm, I forgot ;-) Ah no, I remember. When your function is called,
you first check if you have computed the result for this particular
parameter before. If so, you return the previous result. If not, you
compute the result, store the parameter/result pair in a hashtable or
something, and return the result only then.
Some languages like Haskell do this automatically for you.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xEEFBA4AF
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <n06x4g8l.fsf@comcast.net>
···@cartan.de (Nils G�sche) writes:
> David Steuber <·············@verizon.net> writes:
>
>> Joe Marshall <·············@comcast.net> writes:
>>
>> > Once it was working, I memoized the crap out of it.
>>
>> What does it mean to memoize something?
>
> Hm, I forgot ;-) Ah no, I remember. When your function is called,
> you first check if you have computed the result for this particular
> parameter before. If so, you return the previous result. If not, you
> compute the result, store the parameter/result pair in a hashtable or
> something, and return the result only then.
Right. Since the code was purely functional, every function computed
exactly the same value whenever it was called with the same arguments
(while this *may* happen in a non-pure functional program as well, it
is trivial to prove that you cannot get a different answer for the
same input if you use pure functions). So once an answer is computed,
there is no need to ever compute it again, you can re-use the old answer.
Some of the inner routines were called very frequently on common
arguments, so memoizing the answers can really speed things up.
Just for kicks, here is a naive fibonacci program:
(defun fib (x)
(if (< x 2)
x
(+ (fib (- x 1)) (fib (- x 2)))))
If we call this with a moderately sized argument, it can take some
time to return:
(time (fib 40))
Timing the evaluation of (FIB 40)
user time = 15.021
system time = 0.060
Elapsed time = 0:00:15
Allocation = 39912 bytes standard / 40161 bytes fixlen
0 Page faults
102334155
(Fib 35) -> 1.35 sec
(fib 36) -> 2.20 sec
(fib 37) -> 3.55 sec
(fib 100) -> about 1.5 million years to compute
But since it is pure functional, we can memoize it:
(defvar *fib-values* (make-hash-table))
(defun memo-fib (x)
(let ((probe (gethash x *fib-values*)))
(or probe
(let ((answer (if (< x 2)
x
(+ (memo-fib (- x 1))
(memo-fib (- x 2))))))
(setf (gethash x *fib-values*) answer)
answer))))
The underlying algorithm is the same, but the memoization changes the
program from being exponential in growth to being linear in growth.
(time (memo-fib 1000))
Timing the evaluation of (MEMO-FIB 1000)
user time = 0.010
system time = 0.000
Elapsed time = 0:00:00
Allocation = 58072 bytes standard / 19800 bytes fixlen
0 Page faults
43466557686937456435688527675040625802564660517371780402481729089536555417949051890403879840079255169295922593080322634775209689623239873322471161642996440906533187938298969649928516003704476137795166849228875
For this example, we achieve a time savings of more than 600 orders of
magnitude.
--
~jrm
[Memoization saves input -> output mappings]
I see. This seems to introduce another problem. What about the case
where the input space is really large? How do you decide where to
draw the line with resource usage and thus whether or not memoization
is worthwhile?
On a side note, I only just found out what "currying" is from reading
http://www.mactech.com/articles/mactech/Vol.07/07.05/LambdaCalculus/
Is Haskell Curry related to the programming language?
I'm learning new concepts with my study of Lisp. I'm also picking up
the odd name here and there for concepts that I didn't know were
named. Sadly my retention for names is poor unless I use them
frequently.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
On Thu, Mar 04, 2004 at 01:28:56PM +0000, David Steuber wrote:
> [Memoization saves input -> output mappings]
>
> I see. This seems to introduce another problem. What about the case
> where the input space is really large? How do you decide where to
> draw the line with resource usage and thus whether or not memoization
> is worthwhile?
Where ever you see fit. Or where ever your memory runs out.
> On a side note, I only just found out what "currying" is from reading
>
> http://www.mactech.com/articles/mactech/Vol.07/07.05/LambdaCalculus/
Good, now go and figure out what the S-N-M theorem is. ;-)
> Is Haskell Curry related to the programming language?
The programming language Haskell is named after him. I don't know what
you mean by `related'.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> > On a side note, I only just found out what "currying" is from reading
> >
> > http://www.mactech.com/articles/mactech/Vol.07/07.05/LambdaCalculus/
>
> Good, now go and figure out what the S-N-M theorem is. ;-)
I'm not really into fetishes.
> > Is Haskell Curry related to the programming language?
>
> The programming language Haskell is named after him. I don't know what
> you mean by `related'.
You just described a relation even if not in an SQL sense.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
From: Joe Marshall
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <ad2wn07u.fsf@ccs.neu.edu>
David Steuber <·············@verizon.net> writes:
> [Memoization saves input -> output mappings]
>
> I see. This seems to introduce another problem.
Yes, you trade time for space.
The fib example (also see Baker's papers at
http://home.pipeline.com/~hbaker1/TakB.html
http://home.pipeline.com/~hbaker1/BoyerB.html
http://home.pipeline.com/~hbaker1/TriangB.html
) is one place where it really pays off to memoize. If a function is
rarely called with the same input twice you will get no speedup at
all.
> What about the case where the input space is really large?
For FIB, the input space is the positive integers, which is quite
large. It depends on if you end up using the same arguments more than
once.
> How do you decide where to draw the line with resource usage and
> thus whether or not memoization is worthwhile?
Experience and profiling. Sometimes it works to memoize only the last
few values computed instead of all of them. This adds very little
space and time overhead.
> I'm learning new concepts with my study of Lisp.
Good!
On Thu, 04 Mar 2004 00:39:21 +0100, Nils G�sche wrote:
> Hm, I forgot ;-) Ah no, I remember. When your function is called,
> you first check if you have computed the result for this particular
> parameter before. If so, you return the previous result. If not, you
> compute the result, store the parameter/result pair in a hashtable or
> something, and return the result only then.
>
> Some languages like Haskell do this automatically for you.
Haskell doesn't memoize function applications. It only memoizes a given
value (which is lazily evaluated, so its memoization makes sense at all).
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
David Steuber wrote:
> What does it mean to memoize something?
Exactly the same as it did the last time this question
was asked.
(Preferring the risk of spoiling a joke to that of causing
offence, I'll add: If you think I'm being rude, go and read
the explanations that have been posted by other people and
then think about it some more.)
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> David Steuber wrote:
>
> > What does it mean to memoize something?
>
> Exactly the same as it did the last time this question
> was asked.
It's a good joke.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
Pascal Bourguignon wrote:
> Matthias <··@spam.pls> writes:
>
<snip - read upthread if you need more context>
> What is stupid is to benchmark the processor time, instead of
> benchmarking the programmer time!
While the time taken to create a program is important, it can be just as
important to know that the program when completed will execute as
efficiently as possible... which with some languages is almost
guaranteed to be false. The two /should/ perhaps be weighed together
since separately they aren't very useful statistics.
> The processors of most of the computers I use or administrate are
> constantly at 90+% of idle time (hopefully used gratiously by nice
> background processes). Why do you think Apple spends their time
> adding useless graphic animations to their user interface? They've
> got nothing better to keep their processors buzy!
Now run a game, or a graphics app, or a sound processing app, or... you
should have the idea by now. My computer often runs at 100% CPU because
I often do things that require it. If 10% of those CPU cycles are being
wasted because the programs are written in an inefficient language, I'd
be pissed. As it is a huge enough number of CPU cycles are being wasted
by the OS, and I'm fairly unhappy about that.
> The only valid benchmark is how soon can a Lisp programmer produce a
> valid program vs. how soon can a C programmer produce a program that
> does not crash half the time.
For any reasonably simple coding task a competent C programmer (RH for
instance) will quite likely produce bug-free code very quickly indeed.
Really people, it's foolish to keep bringing up the horrible errors that
/can/ be made in C as being proof that C is inherently flawed. Just
because millions of C neophytes - and yes, many experienced C
programmers - have produced buggy C code is no proof that people of
similar skill level are incapable of producing buggy code in other
languages.
(As a side-point: I'm involved in a sport with a huge potential for
serious injury. Statistically however it's safer than golf... and we
all know how hazardous a sport /that/ is.)
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
>>>>> "Corey" == Corey Murtagh <·····@slingshot.no.uce> writes:
Corey> Now run a game, or a graphics app, or a sound processing app,
Corey> or... you should have the idea by now. My computer often runs at 100%
Corey> CPU because I often do things that require it. If 10% of those CPU
Corey> cycles are being wasted because the programs are written in an
Corey> inefficient language, I'd be pissed. As it is a huge enough number of
How would you know 10% is being wasted? How do you know it's not 50%?
0.001%?
Ray
From: Christopher C. Stacy
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <uznb0b383.fsf@news.dtpq.com>
>>>>> On Mon, 01 Mar 2004 17:11:18 -0500, Raymond Toy ("Raymond") writes:
>>>>> "Corey" == Corey Murtagh <·····@slingshot.no.uce> writes:
Corey> Now run a game, or a graphics app, or a sound processing app,
Corey> or... you should have the idea by now. My computer often runs at 100%
Corey> CPU because I often do things that require it. If 10% of those CPU
Corey> cycles are being wasted because the programs are written in an
Corey> inefficient language, I'd be pissed. As it is a huge enough number of
Raymond> How would you know 10% is being wasted? How do you know it's not 50%?
Raymond> 0.001%?
Or that the CPU meter is really showing you the truth? How much of
the machine is that GUI CPU meter in the corner using, anyway?
And how do you know that C++ is not wasting those cycles?
Or that 10% is significant compared to what's being wasted by the OS?
Or that 10% is significant at all?
There are certainly some speed-critical things in the world,
but analyzing them is more subtle than most people seem to think.
Anyway, if speed of execution is the most important thing to
your application, then Lisp may not be the best choice.
Lisp performs okay (or even "well"), but speed is not
what it is optimized for.
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87n06zafy6.fsf@nyct.net>
······@news.dtpq.com (Christopher C. Stacy) writes:
> Anyway, if speed of execution is the most important thing to
> your application, then Lisp may not be the best choice.
> Lisp performs okay (or even "well"), but speed is not
> what it is optimized for.
Of course, Lisp is excellent for building compilers for such low-level
languages, and you get the control structures provided by Lisp for free.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> "Christopher" == Christopher C Stacy <······@news.dtpq.com> writes:
>>>>> On Mon, 01 Mar 2004 17:11:18 -0500, Raymond Toy ("Raymond") writes:
>>>>> "Corey" == Corey Murtagh <·····@slingshot.no.uce> writes:
Corey> Now run a game, or a graphics app, or a sound processing app,
Corey> or... you should have the idea by now. My computer often runs at 100%
Corey> CPU because I often do things that require it. If 10% of those CPU
Corey> cycles are being wasted because the programs are written in an
Corey> inefficient language, I'd be pissed. As it is a huge enough number of
Raymond> How would you know 10% is being wasted? How do you know it's not 50%?
Raymond> 0.001%?
Christopher> Or that the CPU meter is really showing you the truth? How much of
Christopher> the machine is that GUI CPU meter in the corner using, anyway?
Christopher> And how do you know that C++ is not wasting those cycles?
Christopher> Or that 10% is significant compared to what's being wasted by the OS?
Christopher> Or that 10% is significant at all?
Christopher> There are certainly some speed-critical things in the world,
Christopher> but analyzing them is more subtle than most people seem to think.
Of course. But I was hoping Corey Murtagh would answer this. I'd
really like to know how he knows 10% (or x%) is being wasted.
In my own work, I know how much is wasted because I look at the
assembly code, measure the actual number of cycles taken on real
hardware, and rewrite the code in either C or assembly and re-measure
to find out if it got better. There's no cache, so the effects are
much easier to measure.
But there are also lots of other places where we use C code because we
can, and we have no idea whether the C function call overhead and
other issues don't swamp out whatever savings I just made to that
assembly routine. [1]
Ray
Footnotes:
[1] Of course, I only go with assembly for known profiled hotspots.
I'm not into assembly-for-the-sake-of-assembly-because-I-can.
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Mon, 01 Mar 2004 17:11:18 -0500, Raymond Toy ("Raymond") writes:
> Anyway, if speed of execution is the most important thing to
> your application, then Lisp may not be the best choice.
> Lisp performs okay (or even "well"), but speed is not
> what it is optimized for.
From my own experience, CMU CL can generate code that is en par with
gcc-compiled C, if you take some care when programming. IMHO the "Lisp is
too slow" problem is something that has been solved, generally, for at least
10 years, if you take a commercial grade implementation. Of course there
very likely are special cases where this does not hold.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
The key here is "take care".It requires effort to make lisp run fast. And
deep
insight into how functions and the compiler work.
On Mon, 17 May 2004 16:06:46 +0200, Matthias Buelow <···@mukappabeta.de>
wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>>>>>>> On Mon, 01 Mar 2004 17:11:18 -0500, Raymond Toy ("Raymond") writes:
>
>> Anyway, if speed of execution is the most important thing to
>> your application, then Lisp may not be the best choice.
>> Lisp performs okay (or even "well"), but speed is not
>> what it is optimized for.
>
> From my own experience, CMU CL can generate code that is en par with
> gcc-compiled C, if you take some care when programming. IMHO the "Lisp
> is
> too slow" problem is something that has been solved, generally, for at
> least
> 10 years, if you take a commercial grade implementation. Of course there
> very likely are special cases where this does not hold.
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Corey Murtagh wrote:
> Pascal Bourguignon wrote:
>
>> Matthias <··@spam.pls> writes:
>>
> <snip - read upthread if you need more context>
>
>> What is stupid is to benchmark the processor time, instead of
>> benchmarking the programmer time!
>
>
> While the time taken to create a program is important, it can be just as
> important to know that the program when completed will execute as
> efficiently as possible... which with some languages is almost
> guaranteed to be false.
Well, no. It's guaranteed to be false with all languages with the
possible exception of VHDL.
Once you start down the road of "as efficiently as possible given some
set of caveats known only to me, and subject to change depending on
perceived requirements" it's very difficult to find a principled
stopping place. Wall-clock time from spec to first error-free production
run (if finite) is one reasonable number, but it's not really principled
either.
paul
Corey Murtagh <·····@slingshot.no.uce> writes:
> (As a side-point: I'm involved in a sport with a huge potential for
> serious injury. Statistically however it's safer than golf... and
> we all know how hazardous a sport /that/ is.)
Statistically lawn bowling is the safest I think, followed by fencing
of all things. (I'm not sure whether all styles of fencing (epee,
sabre, foil (what's the one in the Norse tradition?)) were counted
together or whether one style is safer.)
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
> Corey Murtagh <·····@slingshot.no.uce> writes:
>
> > (As a side-point: I'm involved in a sport with a huge potential for
> > serious injury. Statistically however it's safer than golf... and
> > we all know how hazardous a sport /that/ is.)
>
> Statistically lawn bowling is the safest I think, followed by fencing
> of all things. (I'm not sure whether all styles of fencing (epee,
> sabre, foil (what's the one in the Norse tradition?)) were counted
> together or whether one style is safer.)
Whatever happened to lawn darts?
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
David Steuber <·············@verizon.net> writes:
> Whatever happened to lawn darts?
Quite dangerous. At least for the person who opens the door behind
which the target is hung! ;-)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
In article <·················@radsrv1.tranzpeer.net>,
Corey Murtagh <·····@slingshot.no.uce> wrote:
...
>While the time taken to create a program is important, it can be just as
>important to know that the program when completed will execute as
>efficiently as possible...
The key word in that phrase is _can_. With Moore's 'law' doubling CPU
performance every 18 months, CPU time gets progressively cheaper and
less and less important. Aside from the one-time gain associated
with moving to offshore development houses, the same cannot be said
for programmer time.
I agree with your thesis that you can't totally abrogate performance
in the name of developer efficiency, but each incremental increase in CPU
power makes it more and more possible to shift the burden from the
developer to the tools. This is supported by the last 50 years of
the computer history, and more generally, by everybody who's ever
spent time developing a tool, jig, or fixture to save time later on
in their work.
>If 10% of those CPU cycles are being
>wasted because the programs are written in an inefficient language, I'd
>be pissed.
I find myself getting a lot more aggrevated when a language costs me
a few hours of development time than over piddling little 10% efficiency
penalties. Back to Moore's 'law', 10% represents only about 2.5 months
of CPU development.
-Mike
--
http://www.mschaef.com
Matthias wrote:
> Corey Murtagh <·····@slingshot.no.uce> writes:
>
>>>Do not forget: benchmarking is roughly as reliable as statistics, you
>>>can generally "prove" anything you like.
>>
>>If you'd like we can all get together and write code in our language
>>of choice to perform a variety of common algos, find some sucker to
>>run all the samples sequentially on one computer, and see which
>>languages excell at which tasks. If Lisp comes out faster than the
>>'main-stream' languages in any of those tests, we'll reconsider your
>>objection.
>
>
> I had this stupid benchmark lying around anyway:
>
> http://www.cvgpr.uni-mannheim.de/heiler/microbench/
>
> It clearly shows that Lisp outperforms C++ in times of execution speed
> in one test. Happy?
To quote exchange.lsp:
(declaim (optimize (speed 3)
(compilation-speed 0)
(safety 0)
(debug 0)))
I guess we'll just have to assume you used similar options for the other
tests. I'd still like to see some timing done of the internal execution
time, since startup times in such a small test are likely to sway the
test results somewhat, expecially since you're using iostreams in the
C++ variant.
And you should know by now that I'm /never/ happy :P
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
Corey Murtagh <·····@slingshot.no.uce> writes:
> Matthias wrote:
> > I had this stupid benchmark lying around anyway:
> > http://www.cvgpr.uni-mannheim.de/heiler/microbench/
> > It clearly shows that Lisp outperforms C++ in times of execution
> > speed in one test. Happy?
>
> To quote exchange.lsp:
>
> (declaim (optimize (speed 3)
> (compilation-speed 0)
> (safety 0)
> (debug 0)))
>
> I guess we'll just have to assume you used similar options for the
> other tests.
No, you don't have to assume anything: The web-page tells you
_explicitly_, which compilers and which compiler switches were used.
> I'd still like to see some timing done of the internal
> execution time, since startup times in such a small test are likely to
> sway the test results somewhat
The source code is on the page. Go ahead.
> expecially since you're using iostreams in the C++ variant.
iostream is how IO is done in c++.
>>>>> "Corey" == Corey Murtagh <·····@slingshot.no.uce> writes:
> One analysis suggests that with the best of Lisp implementations you
> should not accept a speed penality much above 10% relative to C.
Corey> ...which proves that it is slow, no?
No it doesn't, it only proves that it is a little slower than C which
is fast enough. And when it isn't you put the critical part of the
code into C or assembly or microcode, just as a C programmer would.
> Can you say "business opportunity"?
Corey> When was the last time you found a niche market screaming out for a
Corey> Lisp solution? A solution that could /only/ be implemented in Lisp?
Ah, but there obviously is no such thing as "could /only/ be implemented in".
Turing has assured us that there is a formal equivalence between the
expressiveness power of all programming languages, so from a
theoretical standpoint there is no difference.
However, experience tells us that in practice there is a huge
difference in the *productivity* of deriving a correct solution to a
problem. There is a reason why very few people today write whole
applications in assembly or Turing Machines.
Lisp just happens to be the most productive language around.
> C has more keywords than Lisp; the large part of the ANSI Lisp spec
> is made up of library functions. My linux box has almost 4000
> entries in man3, how much do you think that would amount to if
> printed out on paper?
Corey> Brainf*ck has fewer keywords... are you saying that it's a simple
Corey> language? Wow. There's a bold statement for you.
Not that I know Brainf*ck or that it matters, but I was merely
challenging the thinking that the size of the language translates to
the complexity of it. If there was such a causality, you could claim
Lisp to be simpler than C which probably wasn't what nobody was trying
to say.
Corey> Also failing to see how 4000 man pages on a Linux box relates to
Corey> language complexity *shrug*
Agreed, it should however attest to the size of UNIX (ie. C+libs).
(And I never said that I wasn't a fanatic, but at least I am a fanatic
with a superior language)
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech wrote:
>>>>>>"Corey" == Corey Murtagh <·····@slingshot.no.uce> writes:
>
>>One analysis suggests that with the best of Lisp implementations you
>>should not accept a speed penality much above 10% relative to C.
>
> Corey> ...which proves that it is slow, no?
>
> No it doesn't, it only proves that it is a little slower than C which
> is fast enough. And when it isn't you put the critical part of the
> code into C or assembly or microcode, just as a C programmer would.
A matter of referrents and definitions really. 10% slower than the
equivalent in another language may well fit many definitions of 'slow' :>
<snip>
>>C has more keywords than Lisp; the large part of the ANSI Lisp spec
>>is made up of library functions. My linux box has almost 4000
>>entries in man3, how much do you think that would amount to if
>>printed out on paper?
>
> Corey> Brainf*ck has fewer keywords... are you saying that it's a simple
> Corey> language? Wow. There's a bold statement for you.
>
> Not that I know Brainf*ck or that it matters, but I was merely
> challenging the thinking that the size of the language translates to
> the complexity of it. If there was such a causality, you could claim
> Lisp to be simpler than C which probably wasn't what nobody was trying
> to say.
Hey, you snipped the bit where I was agreeing with you :>
Language complexity can't be readily measured in terms of specification
size, number of keywords, etc. Closer might be the size of the minimum
syntax description in whatever form. I'd tend to add the size of the
required [by the standard] RTL, although I'd weight that fairly low.
After all, you have to know the libraries you're working with to get the
most out of the language, right?
<snip>
> (And I never said that I wasn't a fanatic, but at least I am a fanatic
> with a superior language)
lol :P
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87hdx8z1b7.fsf@nyct.net>
Corey Murtagh <·····@slingshot.no.uce> writes:
> After all, you have to know the libraries you're working with to get the
> most out of the language, right?
Not really. There are large parts of Lisp that I have (mostly) ignored,
since either I use libraries that abstract over them or I just don't
need those features regularly. For the rare occasions when I do need
them, they're available for me to use and well-specified (ok, it's
actually, the badly-specified bits that I tend to avoid the most,
surprisingly enough) so that I can quickly write what I need while
referring to the spec for guidance.
A fair bit of what I've been doing lately is actually language-building,
so the existing libraries are really only useful when they provide data
structures that happen to be useful in my language extensions or when
they let me better mesh my language constructs with those already in
Lisp or those provided by others.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> > Corey> Brainf*ck has fewer keywords... are you saying that it's a simple
> > Corey> language? Wow. There's a bold statement for you.
Is it? I wouldn't have thought this was controversial at all.
> > Not that I know Brainf*ck or that it matters, but I was merely
> > challenging the thinking that the size of the language translates to
> > the complexity of it. If there was such a causality, you could claim
> > Lisp to be simpler than C which probably wasn't what nobody was trying
> > to say.
>
> Hey, you snipped the bit where I was agreeing with you :>
>
> Language complexity can't be readily measured in terms of specification
> size, number of keywords, etc. Closer might be the size of the minimum
> syntax description in whatever form. I'd tend to add the size of the
> required [by the standard] RTL, although I'd weight that fairly low.
> After all, you have to know the libraries you're working with to get the
> most out of the language, right?
Brainfuck is one of the simplest Turing-complete languages in
existence by any reasonable measure. The syntax, for instance, is:
<bf> ::= <bf> <bf> | "[" <bf> "]" | <other> | ""
where <other> is any single character that isn't '[' or ']'.
The semantics are extremely simple too (the most complex part being
the i/o commands), and the libraries are so small as to be
nonexistent.
All this shows is that the simplest languages are not necessarily the
easiest to perform complex tasks in.
-Daniel Cristofani.
>>>++[<++++++++[<[<++>-]>>[>>]+>>+[-[->>+<<<[<[<<]<+>]>[>[>>]]]<[>>[-]]>[>[-
<<]+<[<+<]]+<<]<[>+<-]>>-]<.[-]>>]http://www.hevanet.com/cristofd/brainfuck/
Corey Murtagh <·····@slingshot.no.uce> wrote:
> Christian Lynbech wrote:
>
> >>>>>>"Corey" == Corey Murtagh <·····@slingshot.no.uce> writes:
> >
> >>One analysis suggests that with the best of Lisp implementations you
> >>should not accept a speed penality much above 10% relative to C.
> >
> > Corey> ...which proves that it is slow, no?
> >
> > No it doesn't, it only proves that it is a little slower than C which
> > is fast enough. And when it isn't you put the critical part of the
> > code into C or assembly or microcode, just as a C programmer would.
>
> A matter of referrents and definitions really. 10% slower than the
> equivalent in another language may well fit many definitions of 'slow' :>
I think the point here is that if this fits your definition of "slow"
then nearly every implementation of every high level language aside from
C, C++, Fortran and a few special purpose languages is "slow".
If a 10% drop in execution speed is a significant issue, then C may be
your language for that reason alone. 20 years ago, that was true for a
*lot* of problems. Or assembler might be your language.
These days, it's true for a significant but fairly small subset of
potential development tasks. People do plenty of real work in languages
that are an order of magnitude slower than lisp.
Michael
Michael Sullivan wrote:
> I think the point here is that if this fits your definition of "slow"
> then nearly every implementation of every high level language aside from
> C, C++, Fortran and a few special purpose languages is "slow".
C++ does not belong in that list. Scheme (Stalin), ML (O'Caml and the
ML Kit), and Erlang likely do belong there.
One thing that's very important is that certain language facilities make
it much easier to write certain kinds of code efficiently. Doing any
serious linked-structure manipulation efficiently in C is unbearably
difficult because C lacks automatic garbage collection (or at least
lacks the capacity to support the most efficient forms of it). Is it
possible to write such manipulations efficiently in C? Yes. But it
could be like pulling teeth. A good C programmer faced with the task
would most likely write a "fast enough" implementation instead. Only
the most dedicated library writers with the best CS training might go to
the trouble of doing the best C can do for such. In a mostly-functional
language, it is easy to write implementations that are as good as or
better than the "fast enough" C. A little hand tuning can then make
them faster than a C programmer would be willing to take them.
David
From: Duane Rettig
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <4vflnrqb7.fsf@franz.com>
Feuer <·····@his.com> writes:
> A good C programmer faced
> with the task would most likely write a "fast enough" implementation
> instead. Only the most dedicated library writers with the best CS
> training might go to the trouble of doing the best C can do for such.
> In a mostly-functional language, it is easy to write implementations
> that are as good as or better than the "fast enough" C. A little hand
> tuning can then make them faster than a C programmer would be willing
> to take them.
Q: How fast is "fast enough"?
A: Just a little bit faster.
--
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
Michael Sullivan wrote:
> Corey Murtagh <·····@slingshot.no.uce> wrote:
>
>
>>Christian Lynbech wrote:
>>
>>
>>>>>>>>"Corey" == Corey Murtagh <·····@slingshot.no.uce> writes:
>>>
>>>>One analysis suggests that with the best of Lisp implementations you
>>>>should not accept a speed penality much above 10% relative to C.
>>>
>>>Corey> ...which proves that it is slow, no?
>>>
>>>No it doesn't, it only proves that it is a little slower than C which
>>>is fast enough. And when it isn't you put the critical part of the
>>>code into C or assembly or microcode, just as a C programmer would.
>>
>>A matter of referrents and definitions really. 10% slower than the
>>equivalent in another language may well fit many definitions of 'slow' :>
>
>
> I think the point here is that if this fits your definition of "slow"
> then nearly every implementation of every high level language aside from
> C, C++, Fortran and a few special purpose languages is "slow".
>
> If a 10% drop in execution speed is a significant issue, then C may be
> your language for that reason alone. 20 years ago, that was true for a
> *lot* of problems. Or assembler might be your language.
Yeah. I'm afraid the whole point of a 10% difference in execution speed
being significant escapes me. There's a good deal more difference than
that between the Intel C++ and g++ compilers on more than a few
benchmarks. Differences between various libraries can easily be even
greater. Unless close to the limits of acceptable performance to begin
with, worrying about this is silly.
--Larry
Corey Murtagh <·····@slingshot.no.uce> writes:
> If you'd like we can all get together and write code in our language
> of choice to perform a variety of common algos, find some sucker to
> run all the samples sequentially on one computer, and see which
> languages excell at which tasks. If Lisp comes out faster than the
> 'main-stream' languages in any of those tests, we'll reconsider your
> objection.
There's a thought. I propose as one benchmark calculating all the
Fibonacci numbers less than 10^100000 and then printing out the
largest number calculated. I'm still a learner, but here is my
code:
(let ((max-f (expt 10 100000)))
(do ((a 1 b) (b 1 (+ a b)))
((>= b max-f) b)))
When the above expression returns, the next Fibonacci number past
10^100000 is printed. 'a contains a number less than max-f.
Java has a class for dealing with large ints, so that should be no
problem with the standard language. C has libraries available for
large integer arithmetic even though they are not standard.
I tested the above Lisp with OpenMCL although I did not time it. It
revs up the CPU fan on my PowerBook G4.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
From: Christopher C. Stacy
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <uptbwb2pe.fsf@news.dtpq.com>
>>>>> On Mon, 01 Mar 2004 22:34:26 GMT, David Steuber ("David") writes:
David> Java has a class for dealing with large ints
Does this mean that when comparing the amount of code required
to solve a problem, the code for any available "libraries"
may be subtracted from the total?
Or maybe that such metrics are generally pointless...
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Mon, 01 Mar 2004 22:34:26 GMT, David Steuber ("David") writes:
> David> Java has a class for dealing with large ints
>
> Does this mean that when comparing the amount of code required
> to solve a problem, the code for any available "libraries"
> may be subtracted from the total?
From a programming point of view, I would be most concerned with how
much code *I* had to write. If there are library functions or
language facilities available to me that work well, I'm going to use
them. Code reuse is a good thing.
> Or maybe that such metrics are generally pointless...
Quite possibly. On the one hand there is how much typing you have to
do and whatever problem solving goes along with it. On the other,
the problem you are trying to solve may make all that trivial. Or
not.
If I personally had to implement an edge detection algorithm or OCR
type program for dealing with some bitmapped image, I would take a
long time indeed regardless of the language simply because I have no
idea how to do that. The problem itself would be large enough that
the little bit of boiler plate code for reading in the image would be
trivial.
I'm sure there is plenty of literature now for doing edge detection
and OCR, not to mention libraries of code. I would still be starting
from a blank slate.
The simple Fibonacci program would take me longer to write in Java
because I would have to look up the APIs for the BigInteger class (I
think that's the one). It would be more code than the Lisp version.
The program would be larger still in C because I would either have to
track down a bignum library (I think GNU has one under GPL) or work
out how to do that myself. The extra programming time in Java is
likely to be fairly minor. I don't think that is the case in C.
As far as execution time goes, in C I would at least have the power
to preallocate RAM for the math. It is easy enough to figure out how
much is required. I don't have to worry about the cost of consing or
GC as I do in Lisp or Java. I picked a rather large sequence just to
get the Lisp code to run slowly enough that I could perceive it. A
100 digit sized Fibonacci number comes up in the blink of the eye.
I'm impressed enough with Lisp implementation speeds that I don't
think the "Lisp is slow" argument is really valid. If that argument
is given as a reason not to use the language, then you can throw out
scripting languages and Java. They will also be too slow.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
"Corey Murtagh" <·····@slingshot.no.uce> wrote in message
······················@radsrv1.tranzpeer.net...
> Christian Lynbech wrote:
>
...
> > One analysis suggests that with the best of Lisp implementations you
> > should not accept a speed penality much above 10% relative to C.
>
> ...which proves that it is slow, no?
Wow! I can't believe you saw through our sleight of hand! The jig is up,
Lispers. Time to stop using Lisp. He figured us out. He's got us cold. Darn!
Just when I was about to get that VC money, too. Couldn't you have waited
another month?
>
> > The analysis in question was the Pfannkuch benchmark that was
> > thoroughly analysed in the ACM lisp journal some years back. I haven't
> > a reference at hand but will hunt one down if properly bullied.
>
> Since it helps to prove that Lisp is slow it's hardly vital information.
> Feel free to pull it out if you want though.
Heh! I like how you really put it to the Lisp zealot! Brilliant! And that
"feel free" comment, so offhand and casual but cutting like a knife! You
really know how to form a logical argument. I especially appreciate how you
eschew emotion for a logical development of facts, of which you demonstrate
a firm grasp.
>
> > Do not forget: benchmarking is roughly as reliable as statistics, you
> > can generally "prove" anything you like.
>
> If you'd like we can all get together and write code in our language of
> choice to perform a variety of common algos, find some sucker to run all
> the samples sequentially on one computer, and see which languages excell
> at which tasks. If Lisp comes out faster than the 'main-stream'
> languages in any of those tests, we'll reconsider your objection.
http://weitz.de/cl-ppcre/#performance
Since you put so much stake in performance issues, and since you are
intellectually honest and honorable, I expect you now to start posting to
Perl forums about how much Perl sucks, since Common Lisp kicks Perl's
you-know-what in so many of the performance tests. Yeah. Performance tests,
that's what makes a language great. No 10% slack cut for any reason
whatsoever. Run-time performance, that's the only worthwhile measure. Anyone
who thinks otherwise is simply begging to be insulted. I can see that, now
that you have posted your logical arguments and conclusions. You make it all
so clear to me. Now that I think about it, every application in the world
depends upon a 10% CPU performance edge when compared to C! Bash clearly
is out now and RedHat and Debian will have to replace all their Bash scripts
with C programs in their next release. Thank you! I just hadn't thought
about it that way. All applications are the same! You make me realize there
is simply nothing else to consider in the world other than CPU performance.
Thank you! Bless you! Really! Bless you!
...
> When was the last time you found a niche market screaming out for a Lisp
> solution? A solution that could /only/ be implemented in Lisp?
You seem to enjoy flaming those who like programming in Lisp more tthan you
enjoy spending time programming in your favorite language. What is your
favorite language? Do you think it should be my favorite language, too? I am
sure your opinion is correct!
=
>
> > nobody> 3. The vast majority of people who study Lisp in
> > nobody> school, never want to use it out of their free will
> > nobody> later on.
> >
> > I have yet to encounter somebody who has aquired any useful
> > understanding of what Lisp is, that is not lamenting the difficulties
> > in finding a Lisp related job.
>
> This could be because there aren't many Lisp-related jobs. Wonder why
> that is?
The average programmer is much too smart to think that Lisp is a good
language choice. Only dumb and inferior people enjoy Lisp. Lisp is a bad
choice for the average programmer, who cannot afford the silliness and
stupidity of Lisp. Everyone who uses Lisp is too stupid to see what how
incredibly inferior Lisp is as a programming language. What is the average
IQ of a professional Lisp programmer, 70 or 80? It obviously is much lower
than the IQ of an average professional programmer.
Your clear and logical arguments have made it obvious that it's not just a
personality difference. There's no way that Lisp programmers simply enjoy
something you don't enjoy. It is not like they like anchovies and you don't.
If that were the case, since you are intellectually honest and honorable,
you might feel obligated to go flame in alt.i.like.anchovies for a while.
Oh, I forgot, anchovies take 10% longer to eat than grouper. Of course
anchovies are no good. Can you show me the stats on the fastest-to-eat fish?
That's the fish I want to eat from now on!
Thanks to your argument, I now know that the most popular car in the world
must be the best car in the world! The most popular music in the world must
be the best music in the world! The most popular beer in the world must be
the best beer in the world! There is no room for any other beer! Long live
the most popular beer! Down with all the other beer! You have shown me the
lite!
...
> ...that don't run very fast :>
Faster than Perl. Do you hate Perl? Are you making anti-Perl posts to the
Perl newsgroups? Back off your emotion and make fully-rational posts, in
which you make logical arguments and concede logical points made by those
with whom you debate, or accept that your emotions rule your existance and
that you have no ability to make fully-rational posts.
...
> Find me an open-source Lisp compiler that produces native executables
> that works on Windows, Linux and Mac... maybe Solaris too, just for fun.
Do you think the evolution of computer science is at its zenith and whatever
does not exist today does not exist because of eternal qualities, never to
be altered? The lack of exactly the implementation you desire is a valid
condemnation of a language specification.
You're very rational. You marshall your arguments well. You present all the
relevant facts. You have an organized thought process. I am very impressed
with the materials you have presented.
From: Alan Mackenzie
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <kcs12c.ud.ln@acm.acm>
Corey Murtagh <·····@slingshot.no.uce> wrote on Tue, 02 Mar 2004 07:04:10
+1300:
> Christian Lynbech wrote:
> Since it helps to prove that Lisp is slow it's hardly vital
> information. Feel free to pull it out if you want though.
Is it perhaps worth mentioning, that these benchmarks have all been on
processors optimised for languages like C? If you wrote a C compiler for
a processor, that processor being optimised for Lisp-like languages, I
suspect lisp would be faster, quite a bit faster. Has anybody ever
written a C compiler for a Symbolics?
[ .... ]
> When was the last time you found a niche market screaming out for a
> Lisp solution? A solution that could /only/ be implemented in Lisp?
Er, how about Emacs? I don't think Emacs could have been written in a
C-like language, and RMS was wise enough to realise that 20 years ago.
> Corey Murtagh
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
From: Rahul Jain
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <87smgqpy49.fsf@nyct.net>
Alan Mackenzie<····@example.invalid> writes:
> Has anybody ever written a C compiler for a Symbolics?
It _came_ with a C compiler. ZETA-C has recently been put into the
public domain, too.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Christopher C. Stacy
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <ubrnesfuv.fsf@news.dtpq.com>
>>>>> On Tue, 02 Mar 2004 19:34:14 -0500, Rahul Jain ("Rahul") writes:
Rahul> Alan Mackenzie<····@example.invalid> writes:
>> Has anybody ever written a C compiler for a Symbolics?
Rahul> It _came_ with a C compiler.
Symbolics C was a layered product, and I think you had to pay for
it seperately. Zeta-Soft was a from a third party, and would
run on other Lisp Machines as well.
From: Alan Mackenzie
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <cc442c.q5.ln@acm.acm>
Christopher C. Stacy <······@news.dtpq.com> wrote on Wed, 03 Mar 2004
04:40:24 GMT:
>>>>>> On Tue, 02 Mar 2004 19:34:14 -0500, Rahul Jain ("Rahul") writes:
> Rahul> Alan Mackenzie<····@example.invalid> writes:
> >> Has anybody ever written a C compiler for a Symbolics?
> Rahul> It _came_ with a C compiler.
I didn't know that.
> Symbolics C was a layered product, and I think you had to pay for it
> seperately. Zeta-Soft was a from a third party, and would run on other
> Lisp Machines as well.
Did anybody do any comparitive benchmarks on it between C and Lisp?
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
From: Christopher C. Stacy
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <uk7213j8r.fsf@news.dtpq.com>
>>>>> On Wed, 3 Mar 2004 08:18:20 +0000, Alan Mackenzie (" Alan") writes:
Alan> Christopher C. Stacy <······@news.dtpq.com> wrote on Wed, 03 Mar 2004
Alan> 04:40:24 GMT:
>>>>>>> On Tue, 02 Mar 2004 19:34:14 -0500, Rahul Jain ("Rahul") writes:
Rahul> Alan Mackenzie<····@example.invalid> writes:
>> >> Has anybody ever written a C compiler for a Symbolics?
Rahul> It _came_ with a C compiler.
Alan> I didn't know that.
>> Symbolics C was a layered product, and I think you had to pay for it
>> seperately. Zeta-Soft was a from a third party, and would run on other
>> Lisp Machines as well.
Alan> Did anybody do any comparitive benchmarks on it between C and Lisp?
This is the "Lisp Machine" -- all the languages compiled down to the
same instruction set, which was designed for running, guess what?
From: Alan Mackenzie
Subject: Re: off-topic: Why is lisp so weird?
Date:
Message-ID: <ng852c.q5.ln@acm.acm>
Christopher C. Stacy <······@news.dtpq.com> wrote on Wed, 03 Mar 2004
17:58:44 GMT:
>>>>>> On Wed, 3 Mar 2004 08:18:20 +0000, Alan Mackenzie (" Alan")
>>>>>> writes:
> Alan> Christopher C. Stacy <······@news.dtpq.com> wrote on Wed, 03
> Mar 2004 Alan> 04:40:24 GMT:
> >>>>>>> On Tue, 02 Mar 2004 19:34:14 -0500, Rahul Jain ("Rahul")
> >>>>>>> writes:
> Rahul> Alan Mackenzie<····@example.invalid> writes:
> >> >> Has anybody ever written a C compiler for a Symbolics?
> Rahul> It _came_ with a C compiler.
> Alan> I didn't know that.
> >> Symbolics C was a layered product, and I think you had to pay for
> >> it seperately. Zeta-Soft was a from a third party, and would run
> >> on other Lisp Machines as well.
> Alan> Did anybody do any comparitive benchmarks on it between C and
> Lisp?
> This is the "Lisp Machine" -- all the languages compiled down to the
> same instruction set, which was designed for running, guess what?
Hah! I know (or knew) that instruction set well indeed. Twenty years
ago, I was working for a firm called Racal-Norsk in England, which was
producing a lisp-machine, first by emulation, then by microcoding, on a
Norsk-Data 500 minicomputer. We succeed technically, but deadlines were
such a joke that the project was pulled around the time that the first
(emulated) version was about to ship. :-(
But I didn't know there was a C-compiler for it.
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
(message (Hello 'Corey)
(you :wrote :on '(Tue, 02 Mar 2004 07:04:10 +1300))
(
>> For what interesting definitions of "open-source", "cross-platform"
>> and "native code" do you use to make the above a valid statement?
CM> Find me an open-source Lisp compiler that produces native
CM> executables that works on Windows, Linux and Mac... maybe Solaris
CM> too, just for fun.
ECL(Embedable Common Lisp) is written on pure C, and it uses C (gcc) to
compile it's code.
so it can be used to build native executables everywhere where C works(in
theory).
i tried it under win32/mingw and linux and it appeared to be working..
by the way, some benchmark code compiled with it (float math) outperformed
Intel C Compiler(well, it was gcc more aggresive optimizations, i think) -
so we can say lisp is faster than c?
GCL(GNU Common Lisp) works in similar way too..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
Greetings! Just to followup, gcl has been providing native
executables for maxima,acl2, and axiom on all 11 Debian platforms,
macosx, windows, and some bsd's for quite a while now. It is closely
linked to gcc, but much of it is written in lisp.
Take care,
"Alex Mizrahi" <·········@xhotmail.com> writes:
> (message (Hello 'Corey)
> (you :wrote :on '(Tue, 02 Mar 2004 07:04:10 +1300))
> (
>
> >> For what interesting definitions of "open-source", "cross-platform"
> >> and "native code" do you use to make the above a valid statement?
>
> CM> Find me an open-source Lisp compiler that produces native
> CM> executables that works on Windows, Linux and Mac... maybe Solaris
> CM> too, just for fun.
>
> ECL(Embedable Common Lisp) is written on pure C, and it uses C (gcc) to
> compile it's code.
> so it can be used to build native executables everywhere where C works(in
> theory).
> i tried it under win32/mingw and linux and it appeared to be working..
> by the way, some benchmark code compiled with it (float math) outperformed
> Intel C Compiler(well, it was gcc more aggresive optimizations, i think) -
> so we can say lisp is faster than c?
>
> GCL(GNU Common Lisp) works in similar way too..
>
> )
> (With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
> (prin1 "Jane dates only Lisp programmers"))
>
>
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
············@yahoo.com (Mike Cox) wrote in message news:<···························@posting.google.com>...
> I'm a C++ programmer, and have to use lisp because I want to use
> emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
> looking language syntax wise. What is up with this: (defun(foo()).
What's up with this?
foo<x, y<z>> w;
^^ oops, right shift operator! Not double close.
What's up with this?
template <typename X, typename Y> FooClass &FooClass::operator ++
(int)
{
...
return *this;
}
What's up with this?
int (FooClass::*pmemb)(char *) = &FooClass::FrobString;
(fooObj->*pmemb)("blah");
How do you parse this?
X(Y);
Is this a call to function X with parameter Y, or a declaration of Y
to be of type X? Depends on whether or not X is a typedef name. In
other words, parsing depends on earlier type declarations. Oops!
Y = (X)(Z);
Is this a function call to X with parameter Z, or a cast of the
expression (Z) to type X? Again, parser can't decide without
consulting symbol table for type info. You can't write a context-free
grammar for this language!
> What were the lisp authors thinking?
1. Ambiguity is bad. A language should not have
conflicting syntax rules that are resolved by hidden knowledge,
like operator precedence, or else-goes-with-closest-if.
When humans and computers disagree about the
meaning of an expression, software defects arise.
2. Notational inconsistency is bad. For instance, there should
not be a half dozen different conventions for writing lists.
There is no reason why a function parameter list should
look different from a list of declarators, etc.
3. A language should be easy to parse:
- no complicated phrase structure grammar that requires parsing
algorithms that earned a whole bunch of Ph. D's in the 60's.
- no level-violating silliness like the actions of the
*parser* requiring input from partially analyzed
*semantic* information!
4. Give programmers a well-defined data structure that represents
programs, and straightforward two-way conversion between a
printed notation and that structure. This paves the way for
easy development and debugging of program-writing-programs,
and also provides a notation for storing and retrieving
rich, structured data---a concept badly reinvented in XML.
···@ashi.footprints.net (Kaz Kylheku) writes:
> ············@yahoo.com (Mike Cox) wrote in message
> news:<···························@posting.google.com>...
> > I'm a C++ programmer, and have to use lisp because I want to use
> > emacs. I've gotten a book on lisp, and I must say lisp is the
> > ugliest looking language syntax wise. What is up with this:
> > (defun(foo()).
>
> What's up with this?
Oh, and this is one of my favorites; the use of "template". Consider
the following from _C++ Templates: The Complete Guide_, section 9.3.3,
which I'm reading at the moment:
template<typename T>
class Shell {
public:
template<int N>
class In {
public:
template<int M>
class Deep {
public:
virtual void f();
};
};
};
template<typename T, int N>
class Weird {
public:
void case1(Shell<T>::template In<N>::template Deep<N>* p) {
p->template Deep<N>::f();
}
void case2(Shell<T>::template In<T>::template Deep<T>& p) {
p.template Deep<N>::f();
}
};
And who can tell which uses of "typename" are valid/invalid, ibid,
section 9.3.2?
template<typename/*1*/ T>
struct S : typename/*2*/ X<T>::Base {
S() : typename/*3*/ X<T>::Base(typename/*4*/ X<T>::Base(0)) {}
typename/*5*/ X<T> f() {
typename/*6*/ X<T>::C * p;
X<T>::D * q;
}
typename/*7*/ X<int>::C * s;
};
struct U {
typename/*8*/ X<int>::C * pc;
}
And yet Lisp syntax is ugly? And I'm sure the same "Lisp is ugly"
crowd thinks Perl is pretty, too.
Damien Kick <······@email.mot.com> writes:
> Oh, and this is one of my favorites; the use of "template". Consider
> the following from _C++ Templates: The Complete Guide_, section 9.3.3,
> which I'm reading at the moment:
>
> template<typename T>
> class Shell {
> public:
> template<int N>
> class In {
> public:
> template<int M>
> class Deep {
> public:
> virtual void f();
> };
> };
> };
Is it my imagination, or are those template declerations completely
superfluous?
If you want to have some fun (in the same sense that rolling around
naked in broken glass is fun), have a look at the template classes
included in the GCC header files. Some bits aren't so bad, but when
you get to the STL stuff...
I used to really like C++. But somewhere along the line, it got away
from me. I can handle it OK when it doesn't get too esoteric. The
same goes for Perl. Used lightly, Perl can be fun.
As I start to get used to Lisp syntax, I begin to appreciate the
relative consistency of it. There _are_ some odd markers in the
language. I guess nothing is perfect. Even so, those markers (like
#') act as a form of manifest typing in the source that I'll take
over Hungarian notation any day.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
a voice in the darkness: "why is lisp so weird?"
procrastinating, eyes REMming, the dream had me seared:
tavolo alto senza albero visto
guarda lo spazio, ma sembro non ci sto
chie^\u na^\y d-e^/n ma.nh ma.nh
do/ d-e^m tho?/i la.nh la.nh
mo^.t ngu?o?\i co/ the^~ da.i qua/!
kho^ng d-u?.o?c kho^/c, ma la^\m pha/!
esco stasera cercando ambiente
ma il mondo si peggiora; non fa niente
waking, i shake clear these cobwebs of thought,
a choice that in far less certain times i had sought.
thi