If a Lisp vendor does not allow distribution of the Lisp compiler with runtimes, is there some other way to translate a special purpose programming language to Lisp and execute the result? Could the result be made as fast as C++ for handling large amounts of simple data?
I've been told not to continue considering Lisp, because of considerations such as the above. I would like to have some good arguments available, just in case I get a chance to argue in favor of Lisp again. The hardest point to argue against is that the fastest Lisp, Allegro, does not allow distribution of the compiler with runtimes, and the 2nd fastest Lisp, Xanalys, is several times slower.
I'm omitting my name because one of my coworkers has a nasty habit of doing global searches to see what each of us is posting about, and my name is unique enough to be easy to search on. I don't have a blind box handy for replies, so please post them. Thanks in advance.
In article <a21avscr983i8112jk4g00qacfd7ore...@4ax.com>,
anonym...@nosuchisp.com wrote: > If a Lisp vendor does not allow distribution of the Lisp compiler with > runtimes, is there some other way to translate a special purpose programming > language to Lisp and execute the result? Could the result be made as fast as > C++ for handling large amounts of simple data?
- one could use some of the CL->C compilers, compile the Lisp code to C and link the compiled code into the running Lisp system
- use a self-written (in Lisp) compiler (your language -> C) and link the resulting code to your running Lisp (this is the way a sound synthesis program written in Lisp works)
- maybe use CMU CL
> I've been told not to continue considering Lisp, because of considerations > such as the above. I would like to have some good arguments available, just > in case I get a chance to argue in favor of Lisp again. The hardest point to > argue against is that the fastest Lisp, Allegro, does not allow distribution > of the compiler with runtimes,
I think you can get a license from Franz for doing that - it may be expensive, though.
> and the 2nd fastest Lisp, Xanalys, is several > times slower.
Contact Xanalys with some simple benchmarks. In general I found LispWorks to be quite fast - maybe you need to change the code a bit to make it perform better (this is not unusual). Lisp compiler usually have different ideas of how and when to optimize. CMU CL at full verbosity gives a lot of ideas where code can be improved - its compiler tells you what kind of optimization it does and which not (and why not). The Lisp machine's compiler, for example, ignores almost all declarations - but there are plenty special tools to speed up execution. I guess, Xanalys would be happy to improve their compiler, in case there is a real problem.
> I'm omitting my name because one of my coworkers has a nasty habit of doing > global searches to see what each of us is posting about, and my name is > unique enough to be easy to search on. I don't have a blind box handy for > replies, so please post them. Thanks in advance.
This is the most redicoulous stuff I ever have written. Why do you care about a co-worker. It's your life and you're opinion. Times of slavery should have gone forever, and if you don't stand up, then resign. And search for a more open minded environment.
Why do you post this question here and do not ask the vendors directly? I'm quite sure that one can find an agreement which suits both sided.
anonym...@nosuchisp.com writes: > If a Lisp vendor does not allow distribution of the Lisp compiler with > runtimes, is there some other way to translate a special purpose programming > language to Lisp and execute the result? Could the result be made as fast as > C++ for handling large amounts of simple data?
I think that if you want native code compilation at some stage in the process, then you need the compiler, so your choice is really either to have the compiler or live with an interpreter. Of course the interpreter may be faster than C++...
> I've been told not to continue considering Lisp, because of considerations > such as the above. I would like to have some good arguments available, just > in case I get a chance to argue in favor of Lisp again. The hardest point to > argue against is that the fastest Lisp, Allegro, does not allow distribution > of the compiler with runtimes, and the 2nd fastest Lisp, Xanalys, is several > times slower.
There are other lisp systems which allow distributiion of the compiler and can certainly be competitive in terms of performance. CMUCL is often pretty good. As far as I'm aware none of the free systems competes very well with the commercial ones in terms of overall quality, support, completeness of implementation and number of platforms supported, but this is only a problem if you need these things. Significant commercial applications (yahoo store) have been written using noncommercial lisps.
* anonym...@nosuchisp.com | If a Lisp vendor does not allow distribution of the Lisp compiler | with runtimes, ...
Then the right approach is to ask that vendor what it would take to get permission to do that. All vendors allow distribution of the Lisp compiler with runtimes, but at different terms than without.
| I've been told not to continue considering Lisp, because of | considerations such as the above.
Most likely, you will be told not to continue to consider Lisp after this issue has been resolved, because it is so obviously bogus.
You can most probably do without the compiler. Provided that you compile enough of the support system, the interpreter can be used to process a higher-level language in such a way that more than 90% of the processing time is still spent in compiled code. This means designing your own application-level language, but that's part of the fun with programming in a powerful language.
| The hardest point to argue against is that the fastest Lisp, | Allegro, does not allow distribution of the compiler with runtimes,
This is fortunately just plain wrong. Just call them and ask.
| I'm omitting my name because one of my coworkers has a nasty habit | of doing global searches to see what each of us is posting about, | and my name is unique enough to be easy to search on.
Please accept my sympathies. Cow-orkers like that should be shot. (Now, if anyone of mine does the same, he sure won't tell anyone. :)
#:Erik -- I agree with everything you say, but I would attack to death your right to say it. -- Tom Stoppard
On 24 Oct 2000 10:27:59 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>anonym...@nosuchisp.com writes: >things. Significant commercial applications (yahoo store) have >been written using noncommercial lisps.
Do you know what lisp was used for Yahoo store? O:-) Just curious...
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
> > Do you know what lisp was used for Yahoo store? O:-) Just curious...
> CLISP (at least this was true sometime in late 98, when Paul Graham > gave his LUGM talk on it)
In my (limited) experience, CLISP is often fast enough. In the PC, well optimized code often runs as fast compiled in CLISP as it does in Corman Lisp (a machine-language compiler). Corman beats CLISP easily on sloppy code, though...
Corman is also a very good option for Windows machines. It's not free, but it's not very expensive either (at $200 it's just about $100 more than what i want to spend now). Still, Roger Corman is very nice to allow you to use the bare-bones character environment for free.
* glauber <theglau...@my-deja.com> | In my (limited) experience, CLISP is often fast enough. In the PC, well | optimized code often runs as fast compiled in CLISP as it does in Corman Lisp | (a machine-language compiler). Corman beats CLISP easily on sloppy code, | though...
CLISP is often good enough as long as you do not write any functions of your own that implement any abstractions that require multiple calls to user-land functions. CLISP's performance dichotomy between its C-implemented compiled runtime functions and your byte-compiled Lisp functions leads programmers to optimize at a low abstraction level because they are penalized for their abstractions. This is not a good thing for a Lisp environment, where we want to encourage function calls and make abstractions as inexpensive as possible. We don't want people _not_ to use Common Lisp because of performance issues or to think that only built-ins are fast because they are written in C. Approach CLISP as a good toy implementation of Common Lisp, and move on to a real compiler if you ever plan to investigate performance issues.
#:Erik -- I agree with everything you say, but I would attack to death your right to say it. -- Tom Stoppard
Paolo Amoroso wrote in message ... >On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>> CLISP (at least this was true sometime in late 98, when Paul Graham >> gave his LUGM talk on it)
>Which subsystems of Yahoo! Store were developed with CLISP?
It is my understanding that there is an, essentially, batch process in CLISP that is used to create the pages for the individual stores. CLISP isn't used to actually "run" the site, but rather to generate a set of related static pages.
Somewhere, perhaps PG's home page (not that I have the URL, mind you), is his enumerations about "Web Success". In them he frowns on server generated HTML pages, so this would fit in quite well philisophically.
It's also interesting because people have to be thinking "How the heck is Yahoo! driving a web site with CLISP?!?!??".
Simple, it isn't!
While everyone discusses the how to write web servers in Lisp, here's an application that simply punts on the entire issue.
Of course, not every web application can be met with a block of static pages, but many can.
>Paolo Amoroso wrote in message ... >>On 24 Oct 2000 14:32:46 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>>> CLISP (at least this was true sometime in late 98, when Paul Graham >>> gave his LUGM talk on it)
>>Which subsystems of Yahoo! Store were developed with CLISP?
>It is my understanding that there is an, essentially, batch process in CLISP >that is used to create the pages for the individual stores. CLISP isn't used >to actually "run" the site, but rather to generate a set of related static >pages.
>Somewhere, perhaps PG's home page (not that I have the URL, mind you), is >his enumerations about "Web Success". In them he frowns on server generated >HTML pages, so this would fit in quite well philisophically.
The thing that seems most relevant: Dynamically generated HTML is bad, because search engines ignore it.
And he comments that slow loading of pages is bad, and static generation certainly means that there's no "runtime" cost to a lot of this...
>It's also interesting because people have to be thinking "How the heck >is Yahoo! driving a web site with CLISP?!?!??".
>Simple, it isn't!
>While everyone discusses the how to write web servers in Lisp, here's an >application that simply punts on the entire issue.
If it gets too slow, they need only spawn a few more CLISP processes to do batch work. It doesn't forcibly hurt the runtime behaviour. Which is pretty cool.
It's not particularly visible in looking at some of the HTML that is generated; they don't have any <meta name="generator" content="CLISP"> tags :-). The HTML is very vaguely reminiscent in style to what is generated by the application in his book "Common Lisp"
>Of course, not every web application can be met with a block of static >pages, but many can.
This is in effect the same idea as the decision between: a) Resolving code at compile time, using macros, versus b) Resolving behaviour at runtime via some sort of dispatching.
Work that is done at compile time need never be done at runtime, obviously saving that bit of CPU then. It doesn't too much matter how slow CLISP is if the code is run at "compile" time.
In a sense, this application represents the opposite to the way people tend to promote Lisp; "Lisp as Dynamic Language."
And I fairly heartily agree. a) Search Engines Are Your Friend. b) Web Apps tend to make Really Stupid Use of dynamic evaluation. When they use JavaScript to do things that would be just as nicely represented by static links, That's Really Stupid. -- cbbro...@acm.org - <http://www.hex.net/~cbbrowne/linux.html> (THASSERT (PLANNER RG)) -- Example of HACKER statement.
glauber wrote: > In my (limited) experience, CLISP is often fast enough. In the PC, > well optimized code often runs as fast compiled in CLISP as it does in > Corman Lisp (a machine-language compiler). Corman beats CLISP easily > on sloppy code though...
My limited experience with Corman Lisp tells that undeclared, general code runs quite fast on it relative to other implementations (though declarations don't make much difference). I would not call undeclared code sloppy, and probably it's not what you have meant, so I'm wondering about the meaning of "sloppyness" that favors one implementation over the other. Any specifics?
+--------------- | Will Hartung said: | >Somewhere, perhaps PG's home page (not that I have the URL, mind you), is | >his enumerations about "Web Success". In them he frowns on server generated | >HTML pages, so this would fit in quite well philisophically. | | <http://www.paulgraham.com/mistakes.html> | The thing that seems most relevant: | Dynamically generated HTML is bad, because search engines ignore it. +---------------
Also see Philip Greenspun's comments on this issue, and his solution:
<URL:http://www.arsdigita.com/books/panda/publicizing> [...skip down 2/3 of the way...] Hiding Your Content from Search Engines (By Mistake) ... I built a question and answer forum...all the postings were stored in a relational database. ... The URLs end up looking like "http://photo.net/bboard/fetch-msg.tcl?msg_id=000037". ... AltaVista comes along and says, "Look at that question mark. Look at the strange .tcl extension. This looks like a CGI script to me. I'm going to be nice and not follow this link even though there is no robots.txt file to discourage me."
Then WebCrawler says the same thing.
Then Lycos.
I achieved oblivion.
Briefly, his solution was:
Write another AOLServer TCL program that presents all the messages from URLs that look like static files, e.g., "/fetch-msg-000037.html" and point the search engines to a huge page of links like that. The text of the Q&A forum postings will get indexed out of these pseudo-static files and yet I can retain the user pages with their *.tcl URLs. ... (see my discussion of why the AOLserver *.tcl URLs are so good in the chapters on Web programming; see http://photo.net/wtr/thebook/ bboard-for-search-engines.txt for the source code).
[Greenspun uses Tcl where many of us would choose Lisp (or even Scheme).]
-Rob
----- Rob Warnock, 31-2-510 r...@sgi.com Network Engineering http://reality.sgi.com/rpw3/ Silicon Graphics, Inc. Phone: 650-933-1673 1600 Amphitheatre Pkwy. PP-ASEL-IA Mountain View, CA 94043
On Wed, 25 Oct 2000 02:44:40 GMT, cbbro...@knuth.brownes.org (Christopher
Browne) wrote: >The thing that seems most relevant: > Dynamically generated HTML is bad, because search engines ignore it.
As long as your link doesn't look like a cgi script, you may fool a robot into following it and indexing it, but usually it's not a good idea (for you and the search engine).
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
Fernando Rodríguez <spam...@must.die> writes: > As long as your link doesn't look like a cgi script, you may fool a > robot into following it and indexing it, but usually it's not a good > idea (for you and the search engine).
Why? As long as my site provides a finite number of resources, I don't see how it's anyone else's business how the pages were generated. -- chr
>> As long as your link doesn't look like a cgi script, you may fool a >> robot into following it and indexing it, but usually it's not a good >> idea (for you and the search engine).
>Why? As long as my site provides a finite number of resources, I >don't see how it's anyone else's business how the pages were >generated.
As long as your contents is limited its ok, but systematically following cgi scripts could end up dumping huge databases into the index as well putting too much load on your server.
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
>>>>> "en" == Erik Naggum <e...@naggum.net> writes:
en> CLISP is often good enough as long as you do not write any en> functions of your own that implement any abstractions that en> require multiple calls to user-land functions.
en> Approach CLISP as a good toy implementation of Common Lisp, and en> move on to a real compiler if you ever plan to investigate en> performance issues.
I agree with your second statement, but don't see any justification for the first, unless you implicitly assume that every programmer is interested in performance on each problem. If I am not particularly concerned about performance, I will not notice the slowdown from user-defined functions, so I will not be discouraged from using abstraction.
* Eric Marsden <emars...@mail.dotcom.fr> | I agree with your second statement, but don't see any justification | for the first, unless you implicitly assume that every programmer is | interested in performance on each problem. If I am not particularly | concerned about performance, I will not notice the slowdown from | user-defined functions, so I will not be discouraged from using | abstraction.
This is a good point. I tend to stress that CLISP is not suitable if your goal is performance, anyhow, so I should also argue that it's good enough as long as you don't prioritize performance.
_However_, my experience is that even though you ignore performance (as long as you get your answers within a reasonable amount of time), a large number of programmers will want to know the "expensiveness" of what they do and then soon discover that builtins in CLISP are very fast (especially bignums) while their own code runs much, much slower. Even if you ignore performance consciously, I don't think you can completely ignore the effect of _observing_ that some things are much faster than others even if you did not set out to find out about this to begin with.
Hence my cautions. If you know about them and are aware of the conditions under which CLISP is and is not good enough, I don't think CLISP is a bad choice (as long as you use the ANSI mode with the -a option, but that that's not the default is another gripe).
#:Erik -- I agree with everything you say, but I would attack to death your right to say it. -- Tom Stoppard
In article <3181477127456...@naggum.net>, Erik Naggum <e...@naggum.net> wrote: [...]
> Hence my cautions. If you know about them and are aware of the > conditions under which CLISP is and is not good enough, I don't > think CLISP is a bad choice (as long as you use the ANSI mode with > the -a option, but that that's not the default is another gripe).
Erik, i'm curious to know if you have a favorite among the free Unix Common Lisp implementations.
* glauber <theglau...@my-deja.com> | Erik, i'm curious to know if you have a favorite among the free Unix | Common Lisp implementations.
When I looked around for Common Lisp environments back in late 1993 so I could program in a programming language instead of killing myself with C++, I tried a number of languages, including Ada, Smalltalk, Scheme and Common Lisp, all of which have reasonably good free implementations. (MIT Scheme was excellent, but Scheme is one of those languages that are OK only as long as you live in a dorm room and are unaware that you will eventually want to buy a house.)
Common Lisp implementations included CLISP and CMUCL at the time and CLISP was immature and nearly useless at the time, even worse than KCL, which a friend got his hands on sometime in 1987. CMUCL has been excellent all the time I have used it, but I was unimpressed with the CLOS (PCL) performance and hence did not work a lot with that part of CL until I got Allegro CL. I still have a complete CMUCL system installed on my system and occasionally use it to ensure that I know which parts of my code are portable to it, but I no longer use it in any "production system" sense.
#:Erik -- I agree with everything you say, but I would attack to death your right to say it. -- Tom Stoppard
In article <3181518131621...@naggum.net>, Erik Naggum <e...@naggum.net> wrote:
> * glauber <theglau...@my-deja.com> > | Erik, i'm curious to know if you have a favorite among the free Unix > | Common Lisp implementations.
> When I looked around for Common Lisp environments back in late 1993 > so I could program in a programming language instead of killing > myself with C++, I tried a number of languages, including Ada, > Smalltalk, Scheme and Common Lisp, all of which have reasonably good > free implementations. (MIT Scheme was excellent, but Scheme is one > of those languages that are OK only as long as you live in a dorm > room and are unaware that you will eventually want to buy a house.)
:-)
It's really nice, and it makes you reinvent the wheel each time, but hey, it's so easy to reinvent the wheel in Scheme that many people don't care. Some people apparently have a lot of free time.
> Common Lisp implementations included CLISP and CMUCL at the time and > CLISP was immature and nearly useless at the time, even worse than > KCL, which a friend got his hands on sometime in 1987. CMUCL has > been excellent all the time I have used it, but I was unimpressed > with the CLOS (PCL) performance and hence did not work a lot with > that part of CL until I got Allegro CL. I still have a complete > CMUCL system installed on my system and occasionally use it to > ensure that I know which parts of my code are portable to it, but I > no longer use it in any "production system" sense.
I downloaded CMUCL thinking maybe i could get it to compile for AIX and Windows (the platforms i currently work in), but it looks like setting it up is a daunting task.
CLISP has some pretty strange C source, but it compiled fine in AIX and had a pre-made Windows binary. I'm glad for CLISP, because if it wasn't for it i wouldn't have tried to learn Common Lisp (i'd probably be using some version of Scheme instead). I think it's nice of Franz to let people have a limited version of Allegro for free, but it's too limited for my needs and i'm just not going to pay for the full system. So i guess i'll be using "CLISP -a" for the time being until i have justification to buy a commercial system.
Incidentally, it seems that there's a lot more interest in developing free Scheme systems than Lisp. I guess it's to be expected, since Scheme is designed to be simple to implement.
On Thu, 26 Oct 2000 13:55:53 GMT, glauber <theglau...@my-deja.com> wrote: >In article <3181518131621...@naggum.net>, > Erik Naggum <e...@naggum.net> wrote: >> * glauber <theglau...@my-deja.com> >> | Erik, i'm curious to know if you have a favorite among the free Unix >> | Common Lisp implementations.
>> When I looked around for Common Lisp environments back in late 1993 >> so I could program in a programming language instead of killing >> myself with C++, I tried a number of languages, including Ada, >> Smalltalk, Scheme and Common Lisp, all of which have reasonably good >> free implementations. (MIT Scheme was excellent, but Scheme is one >> of those languages that are OK only as long as you live in a dorm >> room and are unaware that you will eventually want to buy a house.)
>:-)
>It's really nice, and it makes you reinvent the wheel each time, but hey, >it's so easy to reinvent the wheel in Scheme that many people don't care. >Some people apparently have a lot of free time.
You're missing the point: Scheme was designed as a teaching and investigation tool, not for "real world" programming. As a learning language it has been far more successful that CL as a general purpose language. :-P
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
Rodr?guez <spam...@must.die> wrote: > On Thu, 26 Oct 2000 13:55:53 GMT, glauber <theglau...@my-deja.com> wrote:
> >In article <3181518131621...@naggum.net>, > > Erik Naggum <e...@naggum.net> wrote: > >> * glauber <theglau...@my-deja.com> > >> | Erik, i'm curious to know if you have a favorite among the free Unix > >> | Common Lisp implementations.
> >> When I looked around for Common Lisp environments back in late 1993 > >> so I could program in a programming language instead of killing > >> myself with C++, I tried a number of languages, including Ada, > >> Smalltalk, Scheme and Common Lisp, all of which have reasonably good > >> free implementations. (MIT Scheme was excellent, but Scheme is one > >> of those languages that are OK only as long as you live in a dorm > >> room and are unaware that you will eventually want to buy a house.)
> >:-)
> >It's really nice, and it makes you reinvent the wheel each time, but hey, > >it's so easy to reinvent the wheel in Scheme that many people don't care. > >Some people apparently have a lot of free time.
> You're missing the point: Scheme was designed as a teaching and > investigation tool, not for "real world" programming. As a learning language > it has been far more successful that CL as a general purpose language. :-P
When is a general purpose language successful? How much in software sales would that be for example?
glauber <theglau...@my-deja.com> writes: > I downloaded CMUCL thinking maybe i could get it to compile for AIX and > Windows (the platforms i currently work in), but it looks like setting it up > is a daunting task.
Since Windows is not a supported OS, you'd have to write low-level support for the OS (e.g. signal handling code), etc. first. With AIX the situation is even worse, since CMUCL has neither support for AIX, nor a compiler back-end for the POWER processor.
In any case you'd need access to a platform that has a working CMUCL first, for the cross-compilation.
Regs, Pierre.
-- Pierre R. Mai <p...@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
