Thomas Kuehne
Fachgebiet Praktische Informatik
Technische Universitaet Darmstadt

(extracts)

Currently I know of no other method than Transframe that supports such a smooth migration of prototyping to production quality.

Almost any language has a special application area. For instance C was developed to build operating systems. It was not intended to be a general purpose language and the bad consequences of this misinterpretation causes many problems in software development (efficiency&hacking instead of reliability&design), continuing in the deplorable success of C++.

No language I know of, allows to use it in whatever fashion that is best for the application area. Typically you either are forced to use a given language or a especially suited language is chosen according to the application area (e.g. LOTOS for telecommunication). This separates the efforts of many developments, because there can not be any reuse or interoperability between the projects. A language which can change its appearance according to the needs of an application programmer (configurator) would not only be an elegant tool for the single programmer but also a gift to the software community as a whole.

Anyway, such a language is nothing but the technical support for the already applied modern method of 'middle-out' development.

The Eiffel experience shows that a good language has a hard stand against industrial standards like C++. Nevertheless, it covered a still increasing marketshare of its own.

Given the advantages of elegant application development (by first building an application language layer), smooth passage from prototyping to production quality, and inter-project reuse (the language kernel always stays the same), Transframe has the chance to be great success in the programming languages competition. A prerequisite will be a language standard, multi vendor-, and multi platform support.

The language contains many innovations or at least applications of good ideas, that justify its design. It is not just another language added to the pile.

John Backu's Turing Award Lecture Paper by referring to his critic of rigid frameworks that need to be big in order to suit users. By providing a small, lightweight, but expressive enough framework that is able to define all more complex things Transframe escapes his critic which holds true for many current languages still.

Concerning, dynamic programming better supporting rapid prototyping than static programming, my personal view is that much would be gained by an interactive interface to a static language. For instance, I would like to interactively create an Eiffel or Transframe object on a console and send various messages to it to see how it responds. Thus one would avoid to write test programs and go through the edit-compile-execute cycle again and again. MagicFrame should support such a mode (as Smalltalk does). Note that some people (BETA Designers) think rapid prototyping is a bad thing, but I don't agree.

I wholeheartedly support Transframe approach because I believe in the idea of a one paradigm basis which supports multi programming languages paradigms, which can be used to build application languages. It is important that the base language allows to assign a convenient syntax to new abstractions (C++ fixed set of redefinable operands is just a start) in order to enable application languages that appear as elegant as built-in abstractions. Another prerequisite, especially with regard to production quality software, is a type system powerful enough to allow all the flexibility (Eiffel falls short on this) but easy enough to be handled by the programmer. I think Transframe type system approach does very well relatively (compared to others) and absolutely. It is very intuitive (unlike more theoretic approaches) but still powerful.

Kohler Markus
Hewlett-Packard GmbH

Transframe is designed to be the first language as productive as Smalltalk, as efficient as C++, and more typesafe than Eiffel.

Jack Chen
DCE Support

I use several computer languages which include C++, delphi, python, tcl/tk, open script(toolbook) and UNIX shell to accomplish my tasks. One of the reason I do that is because there is no one language can suit all my need. Even the Transframe can't.

But There are two features in Transframe that convince me that Transframe will "The Programming Language" of next decade. One is its operator overloading and another one is Transframe's smart name.

Unlike C++, Transframe impose nearly no restriction on operator overloading the enable you to transform Transframe into your application domain.

Smart name encapsulates the knowledge about the object that it represent into the name itself. You can use smart name to encapsulate all kind of resources without the user to worry about resouce leak because you already handle it in the name object itself.

As a user who forced to program in different languages, I believe Transframe will provide the necessary cure before I retired from my job.

Chris Thewalt
Department of Civil and Environmental Engineering
University of California, Berkeley

I have been working for 2 years on the development of a three dimensional nonlinear finite element package. Although considerable nonlinear development work occurs it is fragmented and usually only implemented on specific systems. On other words, it is very hard to share the development work.

We believe that we need an object oriented model of FE systems in order to share advances made by researchers and make the results useful to practitioners (technology transfer). Furthermore, we believe the new system needs to be easily extensible. Current systems are fixed in their capabilities and invariably one can't do the analysis one wants to and has to "hack" to get the desired results.

With this application area in mind, we strongly believe that the environment we require is exactly that proposed in Transframe where we can have developed high performance objects (such as linear algebra libraries) together with an interpreted interface for developing: (1) new elements, (2) new constitutive models, and (3) new nonlinear algorithms for global system solution.

Although we have designed and implemented a prototype of the system in C++ this system clearly is not useful for prototyping, which we believe is very important. Until we find a combined prototyping/static system like TransFrame we will not be able to tackle the project as we would like to.

Robert Hathaway
Edior in Chief, Object Online Magazine

I strongly approve of the TransFrame approach. I think there should be more projects like TransFrame/MagicFrame in the works and that great benefit will come from them. There is a dire need for metaobject protocols in powerful OO languages, as these can solve many interoperability and multilanguage problems, as well as specializing new frameworks when they are desperately required. Approaches that allow such systems to run efficiently is of paramount importance, as the theory is available to do so but very little progress in terms of industry backing has been made.

This indicates a lack of commitment by management to advance needed systems and proven ideas in research with innovation in terms of funding and allocation of resources. The returns should prove many times the investment as software systems require greater power and efficiency while growing ever larger and a more important part of business and everyday life. Such systems will be an enabling technology for much future advancement and will progress simultaneously together with many others with great benefit.

Object Software Group
Universite de Geneve, Swizerland

(extracts)

Different members of the Object Systems Group in Geneva have read the Transframe white paper. We agree that the language is an important step in the direction of cleaner and more efficient object-oriented programming languages.

Current object-oriented languages either compromise software engineering principles to achive some degree of run-time efficiensy, or sacrifice run-time efficiency in favor of clean semantics.

The first category includes the C++ programming langugae which has proven to be hard to teach and, also, to use... The second category of programming languages includes the like of SELF. There, object-oriented principles have been respected at all stages of the design only to yield a language that is hopelessly inefficient...

Transframe is a promising language that address the issues mentioned above. Our research group is interested in this project, we may consider some kind of collaboration