Language Transcendent Computing

The idea may apply to both computer languages and human languages. However, I use this term in the computer language context for my BasilProject. This term applies to use of an environment where one is able to work with, code in, and integrate any computer language, even one they designed. -- JonRiehl

The human language version of this is ConceptOrientedProgramming (from DDJ June 1999.)

Have you seen Microsoft VisualStudio/DevEnv? (aka VisualBasic, VisualInterDev?, VisualJ++)? Microsoft has written an environment where they just plug in new languages as they need them. Same basic compiler, syntax highlighter, etc. for all their languages. I suspect the grammars come as COM objects. Also, their vapourware COOL VM seeks to run many languages in one universal virtual machine so you can call Smalltalk code from Cobol code! And, of course, there is EMACS. (Is this what you mean?)

Actually, VisualBasic doesn't seem to really be integrated into VS yet (as of 6.0). It's one of those things that causes me much annoyance. And there seems to be a lot of difference between Interdev and VC also, although those differences could be attributed to features that just weren't implemented in the respective COM objects.

DotNet gets part, but not all, of the way to LanguageTranscendentComputing. Like all VirtualMachine definitions with a fixed interface between the VirtualMachine and the environment it creates, DotNet can support multiple languages -- so long as they conform to the behavior supported by the VirtualMachine interface. Alas, in spite of the marketing hype to the contrary, DotNet Smalltalk is not real Smalltalk. DotNet Java is not real Java. In fact, the languages supported by DotNet are little more than syntactic sugar layered on top of the underlying bytecode interface. In order to accomplish genuine LanguageTranscendentComputing, the VirtualMachine must be implemented in one or more of the languages being supported in the environment, and must be accessible and modifiable by the environment. The result is a reflective tower of metacircular interpreters, each capable of running whatever language it exists to run. The tower is grounded in a carefully-crafted metacircular intepreter like 3-Lisp. Brian Cantwell-Smith and Patti Maes have published rather extensively on this topic.

These are all good technologies, but I am talking about automagically building native interfaces, versus using MiddleWare such as COM or CORBA. This makes distributing the objects a pain, but I'd probably just fall back on XML-RPC for that. Not that any MiddleWare is precluded. Such an environment could also provide an IDL integration. See BasilProject (still high in vapor, but based in proof of concept.) -- JonRiehl

What is the benefit of doing this without MiddleWare?

The foundation of this concept was to build SimplifiedWrapperAndInterfaceGenerator without the interface language. Thus wrappers for legacy code come automatically. The back ends for our parsers were extended to build control flow and data flow models for test generation. It was then that I felt as if I were programming outside of computer language. I am trying to capture that experience and provide the infrastructure to do that. -- JonRiehl

How are you going to avoid the explosion of mappings that the LinguaFrancaPattern (as embodied in IDL or standard data encodings) exists to solve?

I think the explosion of mappings is avoided because mappings are based on need rather than providing a complete solution. LanguageTranscendentComputing would take place in the context of a framework rather than a universal solution. - Let me rephrase this, part of this idea is to support several central model targets, such as UML/IDL, as well as some form of intermediate language like the kind that is used by GCC. However, it would also be a platform for prototyping a LinguaFranca. -- JonRiehl