hi,
can someone plz clear my doubts...
* i have to implement a system for which execution time is an
important criteria. i have seen that other similar systems which have
been written in lisp do not perform as well as their own c/c++ (same
algo) implementations. so, apart from the advantage of 'automatic
memory management', does lisp provide anything more ? some people who
have worked with both langs say that sometimes its easier/faster to
develop the complete system in lisp. what's your opinion ?
* i'm well acquainted with c/c++. do u suggest me to learn lisp and
try it ? i mean.. will be worth the effort ?
* are ilisp,elisp etc independent versions of common lisp written by
different authors ? are they some kind of scaled down versions ?
* are they different from others like allegro lisp and cmu lisp
distributions?
thank you.
Regards,
praveen.
In an attempt to throw the authorities off his trail, ··········@yahoo.com (Praveen Kumar K) transmitted:
> * are ilisp,elisp etc independent versions of common lisp written by
> different authors ? are they some kind of scaled down versions ?
elisp is a version of Lisp that long predates Common Lisp, and is the
language in which the bulk of GNU Emacs and XEmacs are implemented.
There are some similarities between elisp and CL, but distinct
differences, too.
ilisp is bundle of elisp code (thus running atop Emacs) that allows
running various Lisps (many CL implementations, as well as several
Scheme implementations) in "inferior buffers," which represents a very
powerful way of controlling those Lisp environments. It's not a
language; it's a sophisticated interface between the Lisp environments
and the text editor.
> * are they different from others like allegro lisp and cmu lisp
> distributions?
Yes, they are very different from ACL and CMU/CL.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www3.sympatico.ca/cbbrowne/lisp.html
"What did we agree about a leader??"
"We agreed we wouldn't have one."
"Good. Now shut up and do as I say..."
Christopher Browne wrote:
> In an attempt to throw the authorities off his trail, ··········@yahoo.com (Praveen Kumar K) transmitted:
>
>>* are ilisp,elisp etc independent versions of common lisp written by
>>different authors ? are they some kind of scaled down versions ?
>>
>
> elisp is a version of Lisp that long predates Common Lisp, and is the
> language in which the bulk of GNU Emacs and XEmacs are implemented.
> There are some similarities between elisp and CL, but distinct
> differences, too.
IIRC, elisp does not predate CL by much if at all.
In article <····························@posting.google.com>, Praveen
Kumar K wrote:
>hi,
> can someone plz clear my doubts...
>
>* i have to implement a system for which execution time is an
>important criteria. i have seen that other similar systems which have
>been written in lisp do not perform as well as their own c/c++ (same
>algo) implementations. so, apart from the advantage of 'automatic
>memory management', does lisp provide anything more ? some people who
>have worked with both langs say that sometimes its easier/faster to
>develop the complete system in lisp. what's your opinion ?
If you have a well-understood algorithm which is easily rendered into
a statically typed language with relatively poor data types (e.g.
limited range integers, little support for flexible data manipulation
and symbolic programming), it's likely that you will be able to make an
efficient implementation of it in C or C++ with little effort.
C and C++ are basically ``high level assembly languages'' that are
suitable for implementing algorithms that have already been expressed in
terms of very machine-oriented data abstractions, or non-abstractions,
really.
However, these languages are very poor tools if, for instance, you don't
have a well-understood algorithm, or in general, if you don't have
a good understanding of the problem space in which you are working,
or if the domain requires some powerful abstractions.
Once you are writing code that is so impractical to write in any
other language that it's nearly impossible, performance comparisons
become meaningless: what is there to compare to? And of course there
are other criteria besides execution efficiency. Automatic memory
managment usually means better space efficiency, due to reduced memory
fragmentation and eliminated memory leaks. And then there is programmer
efficiency. Time to market can be more important than execution time. Some
Lisp practitioners claim being able to consistently churn out new features
ahead of competitors.
>* i'm well acquainted with c/c++. do u suggest me to learn lisp and
>try it ? i mean.. will be worth the effort ?
That depends on whether you value truth or comfort. Part of you may
regret learning Lisp due to the subsequent anguish of having to
continue to face C++ and other languages, and having fewer colleagues
who can understand you.
If you learn Lisp, and learn it well, you will at the same time learn
new approaches to programming and to thinking about programming.
Not being able to easily apply these approaches, or apply them at all,
outside of Lisp is going to be a nuisance. You may find that a lot of
what you think you know is wrong, which will require a readjustment.
Moreover, your peers who aren't learning Lisp will no longer be able to
grok all of what you are thinking.
This is exactly why you must learn Lisp; any programming language which
doesn't have these effects is not worth knowing.
Do you want the green pill, or the red pill, Neo?
>* are ilisp,elisp etc independent versions of common lisp written by
>different authors ? are they some kind of scaled down versions ?
Elisp is a dialect of Lisp understood exclusively by the Emacs editor.
It is not Common Lisp. It lacks many features of Common Lisp, such
as lexical variable scoping and lexical closures, an object oriented
programming system, conditions, and lots of other things.
Ilisp is not a language at all, but an interface that allows Emacs
to be used as a front end to various Lisp implementations.
>* are they different from others like allegro lisp and cmu lisp
>distributions?
Allegro and CMU strive to be implementations of Common Lisp. Common Lisp
is an ANSI standard language, the way C++ is an ANSI/ISO standard language.
There is another Lisp called ISLisp (ISO Standard Lisp). This is a
relatively obscure language that is different from and smaller than Common
Lisp. When ``Lisp'' is uttered nowadays, that should be assumed to mean
``ANSI Common Lisp'', unless it is clear that the context of discourse
is Lisp history or historic dialects.
--
Meta-CVS: version control with directory structure versioning over top of CVS.
http://users.footprints.net/~kaz/mcvs.html
···@accton.shaw.ca (Kaz Kylheku) writes:
> Do you want the green pill, or the red pill, Neo?
Blue and red, not green and red.
--
vsync
http://quadium.net/
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
Hello!
In article <····························@posting.google.com>,
Praveen Kumar K <··········@yahoo.com> wrote:
>hi,
> can someone plz clear my doubts...
>* i have to implement a system for which execution time is an
>important criteria. i have seen that other similar systems which have
>been written in lisp do not perform as well as their own c/c++ (same
>algo) implementations. so, apart from the advantage of 'automatic
>memory management', does lisp provide anything more ? some people who
>have worked with both langs say that sometimes its easier/faster to
>develop the complete system in lisp. what's your opinion ?
There are much more features to Lisp (some shared by other
higher programming languages) that C and C++ lack: Higher
order functions (or just: functions are completely first class
values), lexical closures (you have to emulate them when needed
in C++; been there, done that :-S) [those are in other languages
too, even to some extent in Java], a highly developed object
system (CLOS), strong meta-programming facilities (both
compile-time and run-time). I'm sure I've forgotten still other
things.
The performance gap you mentioned: You have not mentioned when
the comparison was made, using what C++ implementations, using
what Lisp implementations. If the Lisp based system was the first
implementation and the C/C++ the second one, the latter might have
gained from the experiences obtained by making and testing the
former. There may be more simple mistakes on the Lisp side which
could affect performance, even if it's simple things like spreading
a few declarations here and there, and behold, Lisp can often
gain quite some performance from them. Etc.
>* i'm well acquainted with c/c++. do u suggest me to learn lisp and
>try it ? i mean.. will be worth the effort ?
Yes, it will. Except if you see it as a loss that you'll hurt in
future when you're forced into C/C++ development :-)
>* are ilisp,elisp etc independent versions of common lisp written by
>different authors ? are they some kind of scaled down versions ?
Ilisp is just a package for Emacs to help developing Lisp software.
Ilisp interacts with some other Lisp system to host trial executions,
compilations, etc. Elisp is a shortcut for "Emacs-Lisp", the Lisp
dialect used in Emacs. It is significantly different to Common Lisp,
and the implementations in the current Emacsen seem to be not so
good, compared to current Common Lisp implementations.
I'd suggest restricting the usage of Emacs Lisp to the cases you
*do* want to program extensions for Emacs. For other programming,
you'll probably prefer Common Lisp (perhaps using Emacs and Ilisp
as development aids, but perhaps instead using IDE capabilities
of your favourite CL implementation instead).
>* are they different from others like allegro lisp and cmu lisp
>distributions?
As said. Allegro and CMU are (modulo perhaps some few compliance
bugs, and modulo specific extensions) implementations of Common Lisp,
as are Clisp, SBCL, CormanLisp, LispWorks, and others. What Ilisp and
Elisp are, see above.
>thank you.
>Regards,
>praveen.
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> Hello!
>
> In article <····························@posting.google.com>,
> Praveen Kumar K <··········@yahoo.com> wrote:
> >hi,
> > can someone plz clear my doubts...
>
> >* i have to implement a system for which execution time is an
> >important criteria. i have seen that other similar systems which have
> >been written in lisp do not perform as well as their own c/c++ (same
> >algo) implementations. so, apart from the advantage of 'automatic
> >memory management', does lisp provide anything more ? some people who
> >have worked with both langs say that sometimes its easier/faster to
> >develop the complete system in lisp. what's your opinion ?
>
> There are much more features to Lisp (some shared by other
> higher programming languages) that C and C++ lack: Higher
> order functions (or just: functions are completely first class
> values), lexical closures (you have to emulate them when needed
> in C++; been there, done that :-S) [those are in other languages
> too, even to some extent in Java], a highly developed object
> system (CLOS), strong meta-programming facilities (both
> compile-time and run-time). I'm sure I've forgotten still other
> things.
Yes you are: math! Arbitrary-precision integers, rationals, complex
numbers. All seamlessly [*] integrated with the rest of the language.
It's beautiful, really. I can't fathom why people do bioinformatics
in C or C++. All that futzing about with libraries when you should be
concentrating on the math. It boggles the mind. I was one big fit of
giggles the first time I wrote up a bio computation in Lisp, I was so
happy.
> The performance gap you mentioned: You have not mentioned when
> the comparison was made, using what C++ implementations, using
> what Lisp implementations. If the Lisp based system was the first
> implementation and the C/C++ the second one, the latter might have
> gained from the experiences obtained by making and testing the
> former. There may be more simple mistakes on the Lisp side which
> could affect performance, even if it's simple things like spreading
> a few declarations here and there, and behold, Lisp can often
> gain quite some performance from them. Etc.
Well, there's the obvious class of problems where Lisp is almost
always slower: problems where the performance-critical parts depend on
effecient arithmetic in the 28-32 bit range. But this is a very weird
place to focus, if you take a step back from C-think, and I've watched
C programmers go to some length to force their programs to use 32-bit
ints, because that's all they have. But when you don't go out of your
way to force your computation into 32-bit terms, you find yourself
bashing the tag bits no more than any other bits.
[*] "seamlessly". I'm guessing there were more engineers than
scientists when CL was being designed. (log (expt x x) x), should be
EQL to x. Integer in, float out is just not cool.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Hello!
In article <···············@conquest.OCF.Berkeley.EDU>,
Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
>[...]
>> compile-time and run-time). I'm sure I've forgotten still other
>> things.
>Yes you are: math! Arbitrary-precision integers, rationals, complex
>[...]
Yes, you're right of course. Perhaps because that's not too unique
to Lisp, if one looks away from the most awful examples of mainstream
languages. Erlang, Smalltalk, Haskell all have large integers and so
on, quite well integrated as well as in Lisp.
Kind regards,
Hannah.
Praveen Kumar K wrote:
>
> * i'm well acquainted with c/c++. do u suggest me to learn lisp and
> try it ? i mean.. will be worth the effort ?
Undoubtedly it will. Like you I've been working on C/C++ for a long while.
Now I only could say "The Common Lisp is the best language if you can manage it".
--
Vladimir Zolotykh
Praveen Kumar K wrote:
> * i'm well acquainted with c/c++. do u suggest me to learn lisp and
> try it ? i mean.. will be worth the effort ?
Yes. Of course you'll slow down some since you have to learn Lisp, but I
imagine you have already considered that.
btw, no need to choose between Lisp and C/C++. Go with Lisp for the
project, use C/C++ for the small chunk that has to scream -- if
necessary and if C/C++ really can do better than fully tuned Lisp.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"We have a pond and a pool. The pond would be good for you."
- Ty to Carl, Caddy Shack
[Followup posted to comp.lang.lisp only - Paolo]
On 19 Feb 2002 21:19:30 -0800, ··········@yahoo.com (Praveen Kumar K)
wrote:
> important criteria. i have seen that other similar systems which have
> been written in lisp do not perform as well as their own c/c++ (same
> algo) implementations. so, apart from the advantage of 'automatic
What are you specifically referring to? Personal experience with systems
written in different languages? Computer literature? Word of mouth?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Paolo Amoroso <·······@mclink.it> wrote in message news:<····························@4ax.com>...
> [Followup posted to comp.lang.lisp only - Paolo]
>
> What are you specifically referring to? Personal experience with systems
> written in different languages? Computer literature? Word of mouth?
>
>
> Paolo
Not computer literature, but yea.. about the personal experience of
persons who have worked with both langs.. their views/opinions...
As i said, i need to build a system - an automated ai planner to be
precise; and am trying to decide which lang to opt.
Quite a few systems have been written in lisp. But then, some people
have come up with similar c/c++ implementations which is much faster.
i don't exactly know how much effort and time went into developing it.
So i was wondering what the possible trade-offs could be. On one hand
i know c/c++ and on the other i've to learn lisp !.
Time and effort needed should eventually payoff as i work with its
development.
-Praveen.
Praveen Kumar K wrote:
> Quite a few systems have been written in lisp. But then, some people
> have come up with similar c/c++ implementations which is much faster.
The difference probably was not because of Lisp vs C++; a small
difference between two similar implementations can be enough to kill one
of them, especially if the functionality calls for a lot of brute-force
computation as well might an AI system. Lisp is very powerful, but some
innocent-looking operations can do a lot of unnecessary work where an
alternative, efficient operation was available. So one can end up with a
"slow" Lisp algorithm which, once it gets noticed, can be tuned
dramatically (and quite easily).
The key is remembering that Lisp is very fast, so if your algorithm runs
slowly, check your algorithm. Lisp includes a TIME function you can use
to probe the algorithm for bottlenecks. If no one bottleneck appears,
look for an efficiency in some low-level heavy-hitter.
Even knowing most of the gotchas i find that over time our app starts to
drag because of unthinking inefficiencies I have introduced. Then I
schedule a "Speed Week" (sometimes just a day) during which I hunt down
those gaffes and fix them up. Great fun, that.
kt
Kenny Tilton <·······@nyc.rr.com> writes:
> Praveen Kumar K wrote:
> > Quite a few systems have been written in lisp. But then, some people
> > have come up with similar c/c++ implementations which is much faster.
>
> The difference probably was not because of Lisp vs C++; a small
> difference between two similar implementations can be enough to kill one
> of them, especially if the functionality calls for a lot of brute-force
> computation as well might an AI system. Lisp is very powerful, but some
> innocent-looking operations can do a lot of unnecessary work where an
> alternative, efficient operation was available. So one can end up with a
> "slow" Lisp algorithm which, once it gets noticed, can be tuned
> dramatically (and quite easily).
Another important difference is that the Lisp systems seem to predate
the C/C++ implementations, which sounds like the latter were rewrites
of the former. Once a problem is well understood, it is usually much
easier to create an efficient solution to it, since unnecessary and/or
ill-suited abstractions can be ripped out, better datastructures and
algorithms selected, etc.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Ok, i understand your problem better now.
I'd suggest to develop it in lisp first to get it all correct. When
you have a bug-free version with all desired functionality, assess
speed. If you use a compiler which is good and gives optimization
hints it may be easy to make the lisp version "fast enough." If not,
you can transliterate the program to C/C++ and get the "ultimate
speed." ;)
dave