Newsgroups: comp.object,comp.lang.beta,comp.lang.c++,comp.lang.eiffel,comp.lang.python,comp.lang.sather,comp.lang.smalltalk
Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!mn6.swip.net!seunet!news2.swip.net!plug.news.pipex.net!pipex!tank.news.pipex.net!pipex!news.mathworks.com!uhog.mit.edu!uw-beaver!uw-coco!mdisea!mothost!schbbs!news
From: shang@corp.mot.com (David L. Shang)
Subject: Re: Rapid Prototyping + statically-typed OOPLs?
Reply-To: shang@corp.mot.com
Organization: MOTOROLA 
Date: Mon, 24 Jul 1995 14:53:21 GMT
Message-ID: <1995Jul24.145321.5863@schbbs.mot.com>
References: <3uoglp$ij9@locutus.rchland.ibm.com>
Sender: news@schbbs.mot.com (SCHBBS News Account)
Nntp-Posting-Host: 129.188.128.126
Lines: 106
Xref: news.daimi.aau.dk comp.object:33982 comp.lang.beta:484 comp.lang.c++:130900 comp.lang.eiffel:9607 comp.lang.python:5172 comp.lang.sather:2009 comp.lang.smalltalk:24779

In article <3uoglp$ij9@locutus.rchland.ibm.com> seurer@nordruth.rchland.ibm.com  
(Bill Seurer) writes:
> And who cares how terse they are anyway?  C++ is certainly NOT easy to
> learn because it is terse.  If anything is is more difficult because of
> the terseness.  Why is "terseness" supposed to be good?

Terseness might increase the difficulty in learning on
one hand, but might cut down the learning curve
significantly on the other hand.

Sounds contradictory? Let me explain.

In general, our software industry contains two different
groups: one group build the user-models and the other
group uses the user-models to build the systems or
applications. Lets call the formmer the model-developers
and the latter the model-users.

A terse language should have the power for model-developers
to create various native models for their model-users.
When I say the model is native, I mean that its archetecture
should resemble to structure of the real-world problem
domain and the users' perspective on the system.

For model-developers, they do not have an easy job to do.
They must learn to master the power of the language, and
get a deep and sound understanding of those "meta"
facilities to create various high-level models.

For models-users, they should have a easy job. They just
pick up the fitting shoes to wear. Since each developed
model is well-structured, it is possible to provide a
generic visual framework so that users can use an
automatically customized visual language for either rapid
prototyping or quick application development.

For example, the language should enable model-developers
to created multiple-thread task model, active object model
with communication ports, distributed server model with
remote services, mobile object model, data-flow model,
state-transition machine, database model with transactions,
recoverable object models, and so on. And the model users
can select one or several models fitting to their
application frameworks and develop their application
quickly and easily.

Unfortunately, the existing languages fail in this goal.
The obstacle is the conflict between high-level description
and the diversity of the representation. Often, people find
that a general purpose language cannot describe a problem
in a specific application domain in a high-level model.
They are facing a painful choice: either using low-level
programing methods to simulate the specific model (e.g.
a set of unstructured library functions), or developing
yet another language for describing this specific model.
The first choice results in ill-structured system, which
is hard to be understood, to be reused, and to be upgraded.
The second choice results in many specific versions of a
programming language, for example: real-time C++, concurrent
SmallTalk, parallel C, database language, and etc. Each
specific version provides a rigid built-in model that can
only be used in a narrow domain. When the application
requirement changes in future, yet another new language
is required. On the other hand, it is impossible for a
language to equip all of the possible models. We are
sadly in this situation: we have to adjust our thought
to fit the language that we are using. We cannot let the
language to express our new concept in a native way. The
language becomes a big obstacle that constrains our
software ideas.

One of the goals of the Transframe language is to
provide an abstract vehicle that can be transformed
into high-level computing models for different
requirements in various application domains. However,
It should not be a hodgepodge language. On the
contrary, such diversity shall be obtained from
simplifying the language framework: the set of the
fixed, built-in features, which shall be much smaller
than C++. One the other hand, the semantics of each
feature is naturally extended; so that the user-
definable parts are flexible enough to build various
high-level models for specific applications like
concurrent systems, real-time applications,
distributed systems, database applications, parallel
computing and etc. The chance for inventing yet
another language for a specific problem domain shall
be greatly reduced. The language shall provide a
generic framework to build various high level models
rather than a set of rigid built-in model. Various
computing models such as multiple thread task, active
object with communication ports, distributed server
with remote services, and database object with
transactions shall be created by language users
(preciely, model developers). The model created shall
well-put users' concept so that it helps 

   * people understand the concept easily when they
     read programs written in this model, and
   * visual programming environment generate a visual
     representation from the architecture of the model.

David Shang