Howdy, Mike! mi**********@yahoo.com (Mike Cox) wrote in message news:<3d*************************@posting.google.c om>... 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)
What were the lisp authors thinking? Why did Stallman use lisp in
emacs so extensively?
C and C++ did not exist at the time. Do you think he should have used
Fortran for this? *shudder*
If someone, although not RMS, admittedly, was writing a new extensible
editor today, a combination of C++ and Python would have probably be
chosen.
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?
You can use better editors than Emacs. I'll give you a hint: no
12-finger key combinations with right clicking
and waving of a rubber wildebeest are happening in my office.
My mind boggles at the craziness of lisp, and stallman's
decision to add so much of it to lisp.
(SETF THIS-PARAGRAPH
`(PARAGRAPH
"do not eval this inside omega-forms unless you know what you
are doing!"
(SENTENCE
(HOPE I
(CLAUSE
(FEEL YOU (ADJECTIVE GOOD)))))
(SENTENCE
(WHO-ME-P
(PAST-TENSE
(USE (MAKE-SYMBOL "LISP")
:WHEN (PERIOD :FROM (YEAR 1982)
:TO (YEAR 1991)))))
(CLAUSE
(FEEL I (BELONGS :SUBJECT YOU PAIN)))
(BUT-CLAUSE
(PAST-PERFECT
SEE YOU (ONLY (THE (CL::FIRST ICEBERG))))))
;; *shudder* is a special variable !
(SENTENCE
(CAN YOU (USED GET (TO (THE (MANY PAREN))))
:WHEN ,(LAMBDA (X) (> X (SEVERAL (MANY WEEK))))))
,(LET ((SURFACE T))
`(SENTENCE
((DOUBLE MUCHO) :CONTENT 'ATROCITY
:WHERE? ,(LOCATION :TYPE
'ABOVE-BELOW NIL SURFACE))))))
(PRINT (TRANSLATE-INTO-ENGLISH THIS-PARAGRAPH))
--> "I hope you feel better. As someone who used Lisp from 1982 to
1991, I feel your pain, but you have only seen the tip of the iceberg.
You can get used to the parens after a few weeks of using them a lot.
Larger atrocities are beneath the surface"
If someone can answer my questions, I will spend less time with the
emacs psychiatrist!
Just walk away and never look back, if you value whatever sanity you
have left in you, mate!
HTH 82  5271 
In article <16**************************@posting.google.com >,
nobody <no****************@yahoo.com> wrote: mi**********@yahoo.com (Mike Cox) wrote in message
news:<3d*************************@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. As a result, Lisp is more dependant than many languages on tools
like auto-indenting editors that support paren-matching. Of course, since
I'd hate to read a un-indended C program, I think the indention argument
against Lisp is specious at best.
The brightest side of all this is that since Lisp programs are built using
a construct that's so fundamental to the language, it's much easier to
write higher level code transformations than in C. In C, the preprocessor
can at best work with sequences of characters in the source text. In Lisp,
the macro facility can manipulate code at the level of syntax trees.
Python is an example of a language that provides AST manipulation in an
infix language, and while I haven't used it myself, the code I've read
makes it obvious that it's far less convenient than Lisp-style macros.
What were the lisp authors thinking? Why did Stallman use lisp in
emacs so extensively?
C and C++ did not exist at the time. Do you think he should have used
Fortran for this? *shudder*
The first version of Emacs was written in Teco macros. (If you really
want to *shudder*, do some research on that... :-) The modern GNU
Emacs and X Emacs are written with a layer of C that implements the Lisp
system and some editing primitives. Most of the higher level functionality
is written in Lisp.
You can use better editors than Emacs. I'll give you a hint: no
12-finger key combinations with right clicking
and waving of a rubber wildebeest are happening in my office.
I can't say that such things happen in my office, even when I use Emacs.
Just walk away and never look back, if you value whatever sanity you
have left in you, mate!
Lisp gets a bad rap for a lot of reasons. IMO, if you enjoy programming,
and you haven't worked through writing some significant Lisp code, then
you've missed out on something useful. Even if you spend most of your time
in environments that have done better in the commercial space.
Consider this: 10 years ago (and for some of these features 30-40), Lisp
had syntax tree manipulation, multi-method dispatch, a metaobject
protocol, multiple inheritance, garbage collection, anonymous functions, a
highly interactive development environment, and first-class closures.
_All_ of these features are slowly finding there way into more mainstream
languages, with more chances of commercial success. If there truly was no
value in these concepts, and no value in knowing Lisp, this would not be
happening.
-Mike
-- http://www.mschaef.com ms*****@fnord.io.com (MSCHAEF.COM) writes: In article <16**************************@posting.google.com >,
nobody <no****************@yahoo.com> wrote:mi**********@yahoo.com (Mike Cox) wrote in message
news:<3d*************************@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.
--
Philip Stripling | email to the replyto address is presumed
Legal Assistance on the Web | spam and read later. email to philip@ http://www.PhilipStripling.com/ | my domain is read daily.
In article <3q************@shell4.tdl.com>,
Phil Stripling <ph************@cieux.zzn.com> wrote:
... 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?
Cute. Wrong, but cute. :-)
-Mike
-- http://www.mschaef.com
On 28 Feb 2004 21:12:28 -0800, no****************@yahoo.com (nobody) wrote: Howdy, Mike!
mi**********@yahoo.com (Mike Cox) wrote in message news:<3d*************************@posting.google.c om>... 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)
I dunno, something like APL makes LISP syntax look beautiful...
-leor
Leor Zolman
BD Software le**@bdsoft.com www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html
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 <ph************@cieux.zzn.com> wrote in message news:<3q************@shell4.tdl.com>... ms*****@fnord.io.com (MSCHAEF.COM) writes:
In article <16**************************@posting.google.com >,
nobody <no****************@yahoo.com> wrote:mi**********@yahoo.com (Mike Cox) wrote in message
news:<3d*************************@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.
>>>>> "nobody" == nobody <no****************@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.
- pe*****@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.
- pe*****@hal.com (Michael A. Petonic) no****************@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
Christian Lynbech wrote: >>"nobody" == nobody <no****************@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.
- pe*****@hal.com (Michael A. Petonic)
I refer you to point #3 :>
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
[Followups restricted to comp.programming. Remember, kids, crossposting
leads to new aggressive malign retroviruses and excess nose hair.]
In article <16**************************@posting.google.com >, no****************@yahoo.com (nobody) writes:
mi**********@yahoo.com (Mike Cox) wrote in message news:<3d*************************@posting.google.c om>... I'm a C++ programmer, and have to use lisp because I want to use
emacs.
Odd. I've used emacs without having to use LISP. It's not as much
fun as using LISP without emacs, but it works.
I've gotten a book on lisp, and I must say lisp is the ugliest
looking language syntax wise.
This is, of course, entirely subjective, but I can't imagine on what
aesthetic basis LISP would be the ugliest programming language in
existence.
What were the lisp authors thinking?
I can't say for sure what McCarthy was thinking when he created LISP,
but I'd guess it was something along the lines of "I think I'll create
a computer language which emphasizes function application rather than
procedural steps, which provides an easy-to-use list structure as a
generic data collection, and which sort of models Alonzo Church's
lambda calculus".
If someone, although not RMS, admittedly, was writing a new extensible
editor today, a combination of C++ and Python would have probably be
chosen.
That's one possibility, but I'm not sure I'd label it "probable".
There are other choices. vile, for example, is written in C.
Eclipse is written in Java. MS Visual Studio .NET is, what, C#?
Probably no Python in it, anyway.
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?
What's "weird and strange[-]looking" about LISP? Maybe your
experience is just limited.
C++ looks pretty weird to programmers who only know COBOL. SML looks
weird to kids who've grown up on a diet of Java. APL looks weird to
pretty much everyone who doesn't write APL programs. The various
evil languages (Intercal, Brainfuck, and the lot) generally look weird
to anyone who isn't perversely devoted to such things. LISP isn't
even in the running with that crowd.
--
Michael Wojcik mi************@microfocus.com
Proverbs for Paranoids, 1: You may never get to touch the Master,
but you can tickle his creatures. -- Thomas Pynchon
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!
Corey Murtagh <em***@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 |p*****@stirfried.vegetable.org.uk
your bed was already made. | http://spodzone.org.uk/
Joe Marshall wrote: no****************@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.
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!"
Corey Murtagh <em***@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.
Corey Murtagh <em***@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
Joe Marshall wrote: Corey Murtagh <em***@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!"
>>>>> On Mon, 01 Mar 2004 14:46:04 -0500, Joe Marshall ("Joe") writes:
Joe> Corey Murtagh <em***@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.
>>>>> "Corey" == Corey Murtagh <em***@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.
- pe*****@hal.com (Michael A. Petonic)
Matthias <no@spam.pls> writes: Corey Murtagh <em***@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/
Corey Murtagh <em***@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 wrote: Corey Murtagh <em***@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!"
Matthias <no@spam.pls> writes: Corey Murtagh <em***@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
Christian Lynbech wrote: >>"Corey" == Corey Murtagh <em***@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!"
Corey Murtagh <em***@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++.
Pascal Bourguignon wrote: Matthias <no@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!"
"Pascal Bourguignon" <sp**@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
Corey Murtagh <em***@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 rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> "Corey" == Corey Murtagh <em***@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
Corey Murtagh <em***@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.
> > 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 :)
>>>>> On Mon, 01 Mar 2004 17:11:18 -0500, Raymond Toy ("Raymond") writes: > "Corey" == Corey Murtagh <em***@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.
>>>>> 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.
"Claudio Puviani" <pu*****@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/
Corey Murtagh wrote: Pascal Bourguignon wrote:
Matthias <no@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 cs****@news.dtpq.com (Christopher C. Stacy) writes: >> On Mon, 01 Mar 2004 14:46:04 -0500, Joe Marshall ("Joe") writes:
Joe> Corey Murtagh <em***@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
Corey Murtagh <em***@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
Joe Marshall <jr*@ccs.neu.edu> wrote in message news:<1x**********@ccs.neu.edu>... no****************@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/dynla...ds-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.
"Corey Murtagh" <em***@slingshot.no.uce> wrote in message
news:10***************@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.
David Magda <dm****************@ee.ryerson.ca> writes: Corey Murtagh <em***@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. cs****@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 rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Claudio Puviani" <pu*****@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 rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist cs****@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 rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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:
.... 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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer <cb********@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, |p*****@stirfried.vegetable.org.uk
We eat and drink while | http://spodzone.org.uk/cesspit/
tomorrow they die. |
In article <10***************@radsrv1.tranzpeer.net>,
Corey Murtagh <em***@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
> > 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/
"Rahul Jain" <rj***@nyct.net> wrote in message news:87************@nyct.net... "Claudio Puviani" <pu*****@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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Frank |
last post by:
Whats best :
register_globals ON ?
OR
register_globals OFF ?
I currently use:
$_POST
|
by: Alexander Schmidt |
last post by:
Hi,
I am not very familiar with C++ programming, so before I do a dirty hack I
ask for a more elegant solution (but only the usage of STL is allowed, no
special libs).
So I need to read a file...
|
by: scorp7355 |
last post by:
I was wondering if there is some other way to turn autocomplete off
besides using "autocomplete=off", using a meta tag or something
similar. It would be great if there is some way to turn it off...
|
by: nicholas |
last post by:
Although in my web.config I have <customErrors mode="off" /> I still get no
detailed errors.
How comes ?
THX
This is what I get:
Server Error in '/mywebfolder'Application.
|
by: no_spam_for_gman |
last post by:
Hi,
I can turn off autocommit within the command window but I cannot figure
out how to turn it off when you are in the IBM DB2 Command Line
Processor. Does anybody knows how? By the way I mean...
|
by: Frank Rizzo |
last post by:
I have the following situation:
1. Application X1 runs under a regular user account (this user is also
the currently logged on user).
2. Application X1 kicks off Application X2 using an...
|
by: Rory Becker |
last post by:
A wise man once said: "Never put off until runtime what you can fix at compile
time."
Actually I think he said it about 10 minutes before I started this post.
I am a firm believer, like the...
|
by: =?Utf-8?B?R3JlZw==?= |
last post by:
We have an application in our office that has the Option Strict option set to
off right now. I do understand it should be set to ON, but right now, I'm
just going to continue with it this way since...
|
by: scooby dooby |
last post by:
Hi All,
I need to write a script for windows,which has the requirements as below.
1,It should log out the particuler user from windows at a particuler time ,say 6 o'clock in the evening...
|
by: Rain |
last post by:
Hi,
I noticed the other day when I was trying to optimise the traffic on a
particular web page that it had significant viewstate even though I had
turned it off for most of the controls. So in...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
