Carl Shapiro <cshapiro+s...@panix.com> writes: > Kenny Tilton <ktil...@nyc.rr.com> writes:
> I think you are missing the point. It is difficult to integrate Lisp > into an engineering environment where programmers are writing or > integrating software written in many different languages. The > suggested changes would make Lisp more easily hosted on top of a > contemporary runtime like the JVM or the CLR, in turn making it easier > to deliver the object code of applications written in Lisp. If you do > not think Lisp has a problem delivering applications, ask yourself why > Lisp completely missed the boat on component software.
So one of the fundamentally nice things about Lisp should be eviscerated for the convienence of a mythical advantage in "integration with other languages" where the "other languages" are warmed over C++ and Visual Basic?
I've worked on projects integrating C and Ada on embedded operating systems and the language integration issue has thus far been among the least of the issues- pretty much at the same level as getting the makefiles to work right. Its footprint as an issue pretty much extends to getting the various vendors and users to share enough info to work out the kinks down at the ABI. I'd approach a composite Common Lisp/C/C++ situation with something like ECLS, or an adaptation of a commercial vendor's product where I could host & control the Lisp elements as tasks & resources in the OS. Nothing especially subtle. Remember .NET isn't here to solve a technical problem, its to solve a lack of monopoly problem for Microsoft.
The big long-term issues are interrelationships of control and data and state, which is always the case. Sharing the types & classes is a 2nd order issue at best, and is generally mitigated by being thorough with the interface definitions- which you'd better have anyhow or you're writing spagetti code.
Not that vm's are useless, but they don't solve the hard problems.
