RFI: General Purpose Visual Languages

1. Let me admit up front that I am a newcomer to the realm of VPL. As
such, I am in need of as much information as users of this news- group are
willing to provide.


2. Allow me state the nature of my problem. At our facility, we develop
and administer large software development projects (500,000 - 1,000,000+
lines) for embedded systems. As one might imagine, maintaining these
types of projects can be, and generally is, a nightmare of significant
proportions. Naturally, we are investigating ways to reduce both the
development and maintenance effort and cost. VPLs appear to offer
significant potential both in this area and in software reuse.


3. We have looked at commercial tools, such as DataFlo from Dynetics,
Inc., and we are just now looking at Khorros from the University of New
Mexico consortium. Both have good points and bad points. The main
disadvantage of most visual programming languages/environments on the
market today are that they are directed at some particular area of
interest; for instance, DataFlo is geared toward signal processing, and
Khorros is used primarily for image processing. Though both of these
packages can be modified, what we are looking for is a general purpose
visual programming language and environment.


4. Let me describe some of the features we would want in our "dream"
VPL:
a. Hierarchical embedding of graphs.
b. Iterators (do, for) and conditionals (if, case) at the
glyph level.
c. Direct insertion of source code at any level. For example,
if the user is constructing an algorithm from glyphs,
and then finds that some needed functionality is not
provided by the glyph language, he should be able to
open up a window and dump the text code directly
into it. When the graph is compiled, this new code is
automatically compiled also, along with any "wrapper"
code the system would have to provide.
d. Direct access to hardware and memory at the glyph level
(Remember, we are a real-time, embedded systems house!).
e. Compilation of glyphs to either spawned processes or called
subroutines, depending on the execution environment.
f. Program generation, debug, and VERIFICATION within a single
environment.
g. Automatic generation of test vectors at the graph level and,
if applicable, the code level, to fully exercise all of
the branches of the program.
h. Automatic generation of statistics for use in scheduling.
i. Hooks into whatever the target operating system may be.


5. Now, allow me to ask a theoretical question. If one were to look at a
visual program in terms of an equivalent text program, the structure of
the program would be that of a single main routine which does nothing but
call other routines or, equivalently, spawn other processes. Admittedly,
this is good programming practice; however, what if this were the ONLY
thing the main routine could do? Keep in mind that a subroutine can still
do anything that it could do before, but the main routine can only call
other routines, store the values returned from these routines, and use
these stored values to call other routines. Does this impose any
theoretical limits on what this language can do? If it does, then it may
be necessary to develop a true compilable graphical grammar to get the
generic functionality we need.


6. If you have any comments on my "wish list" or my question, please
respond to this message or contact me at
gbradfor@redstone-emh2.army.mil or
gbradfor@gcs.redstone.army.mil. One or the other should get to me.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.