Lisp's IDE problem - and a proposed solution(iamsamy.blogspot.com)
iamsamy.blogspot.com
Lisp's IDE problem - and a proposed solution
http://iamsamy.blogspot.com/2008/06/lisps-ide-problem-and-proposed-solution.html
1 comments
I think Allegro has a binary creation process that removes unused code, but at $600 for a basic license, that is not going to lead to wide adoption.
If people want to see wide adoption of Lisp, a free modern library (Ala Cocoa) and IDE are needed. Thus far the only entities that have been willing to throw money at building and giving away such tools for free have been huge companies that try (Sun) or succeed (Apple) at using hardware sales to monetize the cash they spend on making such a nice environment.
To truly achieve such a thing would require at this point an organization with no baggage (NOT the FSF) with donation funding to pay for a large team of programmers to just get to work doing all that stuff, be it from scratch or by combining and polishing existing MIT/BSD licensed code.
I doubt this will ever happen.
If people want to see wide adoption of Lisp, a free modern library (Ala Cocoa) and IDE are needed. Thus far the only entities that have been willing to throw money at building and giving away such tools for free have been huge companies that try (Sun) or succeed (Apple) at using hardware sales to monetize the cash they spend on making such a nice environment.
To truly achieve such a thing would require at this point an organization with no baggage (NOT the FSF) with donation funding to pay for a large team of programmers to just get to work doing all that stuff, be it from scratch or by combining and polishing existing MIT/BSD licensed code.
I doubt this will ever happen.
I don't know of a readily available solution, but there are some discussion threads on comp.lang.lisp about "tree shaking" and how to could be used to remove unused parts of the runtime before writing the image. Some of those posts are quite interesting. And it seems some of those techniques are already implemented in commercial Lisp offerings.
For the time being, I think the way to go is to use Lisp for the cases that suit it best. My aim for using Lisp is for internal-use code generation or web stuff, so code size is not a big deal. Also if your program is already large and complex (which Lisp was designed for, being an AI language) then the initial runtime size wouldn't be too significant compared to the size of the program.
For the time being, I think the way to go is to use Lisp for the cases that suit it best. My aim for using Lisp is for internal-use code generation or web stuff, so code size is not a big deal. Also if your program is already large and complex (which Lisp was designed for, being an AI language) then the initial runtime size wouldn't be too significant compared to the size of the program.
1) Create an executable image that is HUGE, even for small/simple applications
2) Distribute a loadable image and force the users to make sure it's version matches their runtime (if they even have one, which isn't likely).
Perhaps there is a third option... and if there is I'd love to hear it. But if you can't distribute the program, whats the point in writing it?