On that page there is a section "Obtaining Fixed Software" with a sub-section "Customers without Service Contracts" where you can read "...Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade...".
The problem is not that Common Lisp programs are slow, the problem is that in CL it is possible to do 'exploratory' programming to an extend that is impossible in other languages. So while you chip at the problem one function at a time and you get closer and closer to the solution you might solve the problem, but you'll do it in a non-optimal way. The good Lisp programmers have then placed abstraction layers at the places that mattered and can then profile the program and find and elimitate the bottle-neck. I did this with a program of mine and I elimitated 99% of memory-use and 90% of run-time by re-writing one function. Then the real problem of Lisp shows up: managers. They don't see an almost-solved-problem that requires a bit more of work, they see a solution and want to get it into production NOW! I've seen the results of 15 years of that too: a slow, buggy program.
But in all horrors of Lisp programs I've seen it isn't the fault of Lisp that it is slow, it is due to Lisp the program exists! The fact that it is slow is only because nobody has the time to invest into making it fast.
You don't need to recode your problem in C++, you need a Lisp expert!
Slashdot Mirror
Full disclosure: I work for Cisco TAC.
> Fixes are only available after Cisco is paid for them and, once again, the fixes come without guarantees as well.
Now this is not what I remembered. So I went and checked.
Go to Cisco PSIRT (http://www.cisco.com/go/psirt) where I click on the H323 problem in IOS, I go to the advisory at http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4a300.shtml.
On that page there is a section "Obtaining Fixed Software" with a sub-section "Customers without Service Contracts" where you can read "...Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade...".
Peter
The problem is not that Common Lisp programs are slow, the problem is that in CL it is possible to do 'exploratory' programming to an extend that is impossible in other languages. So while you chip at the problem one function at a time and you get closer and closer to the solution you might solve the problem, but you'll do it in a non-optimal way. The good Lisp programmers have then placed abstraction layers at the places that mattered and can then profile the program and find and elimitate the bottle-neck. I did this with a program of mine and I elimitated 99% of memory-use and 90% of run-time by re-writing one function. Then the real problem of Lisp shows up: managers. They don't see an almost-solved-problem that requires a bit more of work, they see a solution and want to get it into production NOW! I've seen the results of 15 years of that too: a slow, buggy program.
But in all horrors of Lisp programs I've seen it isn't the fault of Lisp that it is slow, it is due to Lisp the program exists! The fact that it is slow is only because nobody has the time to invest into making it fast.
You don't need to recode your problem in C++, you need a Lisp expert!
Peter Van Eynde