Speaking in a Native language



Many people working on digital arts are not professional programmers. What they need is a language that can describe things in their domain with their native languages. C or C++ looks like a foreign language and tongue-ties them.

Languages invented for non-programmers usually have specific application domains, and expressions are designed close to the way in which the users are thinking. For examples, VRML (Virtual Reality Modeling Language) is designed for describing muti-partcipant 3D simulations on the Internet, and it provides a description in a structure that naturally reflect a 3D graphic model. Lingo is a specific script language provided by Macromedia for computer animations and it provides a natural language-like syntax.

Let us consider an example. To describe a composite object, the most intuitive way is to write a hierarchical specification exactly in the structure the object should be composed:

object My_3DScene is World3D
{
	with Camera  //an existing object defined in World3D
	{
		style = Perspective;
		position = (-1.0, 2.00, 8.0);
		orientation = (-0.2, -0.9, -1.5, 1.1);
		focalDistance = 12.5;
	};
   	with Background
	{
		style = Picturesque;
		scenery = "bluesky.jpg"
	};
	object Light is DirectionalLight
	{
		direction = (0.0,-0.2,-1.0);
	};
	object RollingFrame is Frame3D
	{
		object SphereFrame is Sphere
		{
			radius = 8.0;
			draw_attr = DRAW_WIRE;
		};
		object BlueCylinder is Cylinder
		{
			with Material
			{
				style = PerPart;
				diffuseColor = (0,0,1);
				specularColor = (0.5,0.5,1);
				shiness = 0.5;
				transparency = 0.6;
			}	
			radius = 1.0;
			hight = 3.0;
		};
	};
};

Most procedural languages cannot give a description as shown above. Users have to use function calls to created component objects and then call a set of other functions to initialize their propertities, and then realize the object to show on the screen. This is a typical method that people used to create windows in the X or the MS Windows by using C or C++ programming interfaces, and the typical way people develop applets in Java. This method is far beyond the learning capibility of digital artists and other right-brained humans.

To help non-professional programmers to build their own applications, many advanced developing systems are equipped with their own domain-specific languages. Examples are most window user interface builder kits, 3D model developement tools, and animation studios.

Unfortuately, for each set of models in a specific domian, people need to create a new language. For examples, Lingo is tied specifically to the company's product, Director; VRML and Open Inventor are specific for 3D models. People are isolated by different application domains and cannot cooperate effectively.



Each time when the system functionality is modified and enhanced, the language built on the top of the system has to be changed and extended. People are constantly having to keep alert of the changes. The worse, not all the changes are downward compatible. For example, the new Lingo released in Director 4 makes a number of old Lingo features outdated.

It is impossible to reduce the complexity by providing a general language with full low-level details such as in C++ without a suitable support of high level domain-specific models. Without a high level native representation, we can hardly create an intuitive design interface for an easy application development environment.

On the other hand, it is also impracticable to invent each new domain specific language for individual problem domain, which makes people isolated by different languages and makes cooperations very difficult across mutiple application domains.

The only way left for us is to provide a single language that can suitably handle all the possible situations. Once a new set of models are created in the language, the same language can also be used as a native language to these model users. New language is then not required. And people can work across different domains in a single environment and create applications using multiple sets of models. Basic models can be enhanced without a need of a language extention.

But, is it realistic for us to equip a language with all possible domain-specific features, making a super hodge-podge language? Java is a small scale attempt. The language added to C++ threaded process, synchronized method, persistent object, etc. But we can never have a complete list in such exhaustive method. Demading for new models and features are constantly evolving.

Instead of providing domain specific computing models exhaustively, Transframe provides a transformable abstraction vehicle that can be adapted into various high-level models for diverse application domains. Such diversity is obtained from simplifying the fixed and built-in part of the framework; so that the user-definable part becomes larger and the framework are flexible enough to build various high-level models.

Built around Transframe, the environment can provide various high-level models in the form of application frameworks with a visual representation. Application developers will always use their own native model to describe what they are going to develop as if they were using their own domain specific language.

The My_3DScene example given at the begining of this page is not written in VRML or Open Inventor. It is written in Transframe, a general language not specifically designed for 3D models. My_3DScene is a singleton object instantiated from the class WorldD, which is a high level model developed by the professional programming team using the same language. If you have experience with VRML, you'll have no difficulty in composing the above program. If you are an advanced user that knows the language profoundly, you can add sophisticated behaviors to the object of My_3DScene, as if you were a member of the professional programming team.

Miscellaneous domain-specific models can be composed in the same language environment. Applications across multiple domains can be constructed without barriers. Whenever a system change or a new model is required, the language remains the same.

In general, Transframe has only two concepts: Class and Object. They are generalized so that various other concepts can be derived from the two basic concepts. In my future columns, I'll give details on how such flexibility can be achieved in simplification and unification.

Here are just two examples.


Functions are classes

References are objects