An interesting post to comp.lang.lisp on generating code for C# (or Java)...
I am continuing to evolve a system that generates business applications for .NET in C#... it is giving us about a 10-1 productivity gain...Why not deliver Lisp that *connects* to the dotnet runtime? (e.g. Python.Net does this and Cincom Smalltalk is heading in the same direction with their Fall 2004 release.)Why do we not just use Lisp as the delivery language? It comes down to components. .NET (and Java) have huge choices of commercially available components for GUI, Infrastructure, Database, ... (not available in Lisp).
1 comment:
I am not convinced that having a Lisp or Smalltalk implemented in dotnet or the jvm is the preferable approach. Iron Python should plow through the issues, but I think this is going to be a tough rowto hoe.
Certainly Python.Net provides today (I've used it a good bit with WinForms and GDI+) and within a few weeks or so, Cincom Smalltalk should also provide, a viable approach that is usable today. Going forward the need to be "in the same runtime" should become less of an issue.
Meanwhile the ability to rely on for example all the goodness of the mature Cincom Smalltalk virtual machine will remain a strong argument. As would a similar integration of, say, the mature Franz Common Lisp implementation or the high-performance and open-source Gambit Scheme implementation.
Would you really want to reimplement each language that has a mature advantage (consider Erlang and the OLTP runtime) in an immature VM just to get at the foreign language features? Integration seems the way to go.
Post a Comment