It was while we were doing a vanity searches at work the other day, caused by my current manager claiming that his name would get the most hits. There, amoungst a few hits on me and another Clive Tong (from Malta), was an attribution on some Dylan code for a CORBA implementation. It’s nice to have some code out there in the public domain.
In around 1996, Harlequin were developing CORBA implementations in both the Common Lisp and Dylan groups. After a small amount of time working with another developer, I ended up doing all of the Common Lisp work. When the time came to do the Dylan work, Jason Trenouth and I worked together on a number of designs for the implementation, which I usually got to implement first in Common Lisp. Jason used some of this code as the basis for writing the Dylan implementation which, I assume, is the reason for the credit on the source files. As an aside, as I’d already worked on the early version of the company’s ML compiler, I had been due to work on a CORBA binding for ML before the company started getting into financial problems.
CORBA was a nice way to make our languages usable as part of a solution written in more mainstream languages. The trouble with the Lisp implementation, at the time, was that it wanted to control the whole address space of the process. It could interoperate by loading in other components, but at the time it wasn’t wasy to produce a dll or shared library which could be loaded into a different process. Exposing Common Lisp functionality as distributed objects made it easy for code written in Common Lisp to be used by other languages. At one point we had a demo that had components written in Common Lisp, Dylan, Java and C++ which all worked together. We also wrote, well Jason mainly wrote, a paper on the benefits of using interactive languages to script distributed objects.
For me, this has all come around again as I have been using F# to dynamically manage and debug a number of .NET components across remoting and web service boundaries. In this kind of scenario, the REPL (read-eval-print-loop) allows the inspection and modification of the components’ state without the pain of either writing a C# program or connecting to the component with Visual Studio.