Hello Visual Languages... is anyone here?
Tom447
only post I see is dated July 11, 2000! I certainly hope there isn't a
problem with my newsgroup feed. Arriving here was like walking into an
empty auditorium! :)
If anyone is lurking, I'm new to the field and very interested in learning
more about Visual Programming and where the "state of the art" currently is
with production capable Iconic dialects. I've gotten quite a bit of help
and useful information from the folks on the Prograph forum, but I wondered
if there might be a few other comparable technologies that I might have
missed during my initial searches.
I became interested in this field out of practicality: good programmers are
hard to find! As a manager responsible for hiring and as a "text mode"
programmer for over 20 years, it's starting to look like we're reaching the
point of exponential diminishing returns when it comes to our existing 40
year old text based tools. They're not keeping up very well with projects
that are running on Internet time that include bloated requirement specs
and compressed delivery schedules.
I really can't accept the proposed solution which is to train and import
more programmers in addition to overworking the existing talent. Sure,
there's a future in doing this... but it isn't very bright.
To me, a more realistic approach would be to put a little effort into
creating and applying better tools that would make existing programmers
*vastly* more productive. Tools that basically overhaul and modernize the
act of programming instead of simply inventing new languages that rely on
the same old and error prone text entry paradigm.
Visual programming seems to be the most appropriate technology for this
transition and my goal is to find a production oriented tool if it exists
or to begin developing or co-developing one if it doesn't. Any comments,
suggestions or related links along these lines would be greatly
appreciated!
Thanks,
Tom
Joe Pfeiffer
> It doesn't seem like there's very much activity in Visual Languages. The
> only post I see is dated July 11, 2000! I certainly hope there isn't a
> problem with my newsgroup feed. Arriving here was like walking into an
> empty auditorium! :)
Yeah, I could swear that whenever there is a post here, there's an
echo...
> If anyone is lurking, I'm new to the field and very interested in learning
> more about Visual Programming and where the "state of the art" currently is
> with production capable Iconic dialects. I've gotten quite a bit of help
> and useful information from the folks on the Prograph forum, but I wondered
> if there might be a few other comparable technologies that I might have
> missed during my initial searches.
It's pretty safe to say that Prograph is the most mature,
general-purpose commercial VL available. Another one to look at is
LabView, though it's more aimed at controlling lab instruments.
Most of the VLs you will see are special-purpose, and their
descriptions won't mention ``Visual Language'' anywhere. There are
things out there like languages for fuzzy logic controllers or for
protocols...
One good place to come to learn about it would be Seattle next month!
See the URL in my .signature.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
VL 2000 Homepage: http://www.cs.orst.edu/~burnett/vl2000/
David C. DiNucci
> Arriving here was like walking into an empty auditorium! :)
And you seem to be starting a soliloquy. Hopefully I can help it turn
into a dialogue. (Actually, maybe more a soapbox.)
> If anyone is lurking, I'm new to the field and very interested in learning
> more about Visual Programming and where the "state of the art" currently is
> with production capable Iconic dialects.
Hmm. If "production capable" doesn't necessarily imply "existing", then
it seems to mean "I hope it will be useful enough for a wide enough
audience to survive in the market place". I'll mention one like that in
this message that I've been working on (i.e. not yet on the market). If
you want to find existing ones (the traditional examples are AVS,
Prograph, Labview, and to some extent, JavaBeans), you probably know
where to look. (Plug for an old acquaintence: Check out www.zat.com)
Two of the best sources around to research visual languages are the
excellent FAQ for this group (see
http://www.faqs.org/faqs/visual-lang/faq/) and Margaret Burnett's
bibliography (http://www.cs.orst.edu/~burnett/vpl.html).
> ...
> To me, a more realistic approach would be to put a little effort into
> creating and applying better tools that would make existing programmers
> *vastly* more productive. Tools that basically overhaul and modernize the
> act of programming instead of simply inventing new languages that rely on
> the same old and error prone text entry paradigm.
>
> Visual programming seems to be the most appropriate technology for this
> transition and my goal is to find a production oriented tool if it exists
> or to begin developing or co-developing one if it doesn't. Any comments,
> suggestions or related links along these lines would be greatly
> appreciated!
You seem to have high expectations for VL, and I'm not sure where you're
getting them. Just because something is different doesn't necessarily
mean it's better, and in fact it probably means it will be worse in some
ways, almost guaranteed by the very fact that it is different--e.g. lack
of tools, lack of information, experience, knowledgeable comrades. Yes,
there are reasons to believe that VLs could be superior in some ways,
and other ways may become apparent as they are used, but what will those
ways be? If error prone text entry is the problem, wouldn't a textual
syntax-directed editor help just as well as a graphical one? In fact,
almost any visual language is likely to have some textual form in any
case, so isn't the distinction there rather artificial?
OK, enough Devil's advocacy. My main point in the above is to say that
people are not going to adopt a VL (in the true sense of the word)
unless there are some very good reasons pushing them in that direction,
things that are always going to be harder to accomplish in a textual
language, even with extra tools, etc. Another point is that programming
is programming: i.e. it requires all decision points, computations,
subroutine/function invocations, etc. to be explicitly specified, and
this will be true whether you are using text or graphics (and almost
always quicker and easier using text). When some people hear about
iconic or visual programming, they envision just selecting pre-existing
modules (often represented by icons) from a toolbox and pasting them
together, but there is no reason that this modality will be any more
successful in visual programming than similar approaches have been for
text (e.g. reusable objects). The reason it doesn't work very well is
sometimes expressed as "Software is soft". To have general
applicability in a wide variety of contexts, the components would need
to be simple enough to be considered the syntactic atoms for the
language, or would be so general that just specifying the additional
arguments would be tantamount to writing the program anyway. (Brooks's
"No Silver Bullet" essay fits here.)
So, the question becomes, what specific concepts benefit from a
visual/spatial representation? I give three examples here.
The first becomes apparent whenever you look at any program these days.
The programmer is attempting, through indentation, to imply some sort of
proximity between statements which may be far apart in the program, as
well as the natural physical proximity of statements which are nearby.
The reason: Those far-apart statements may indeed end up in close
proximity in the calculation (i.e. the sequence of operations actually
performed by the program when executing), just as those closeby do. One
can imagine a computational sequence as unraveling or unfolding from the
program, and these indentations show where that sequence may loop back
upon itself or ignore certain operations in the program text. I say
that programs which have this property (i.e. that operations which may
be close together in a computation resulting from the program are also
close together topologically in the program itself) have the Proximity
Property. It can be considered as the generalization of structured
programming.
The second is related to the first, and deals with concurrency
(parallelism). That is, one reason that sequential textual languages
suffice at all is that computations traditionally are sequential. (The
time-space diagram of what goes on under the single head of a Turing
Machine is a line, a sequence of operations.) The single level of
indentation mentioned above works only because there's at most one
decision, with one outcome, occurring at a time. But the more general
notion that a computation (especially a concurrent computation) is a
partial ordered set of operations (e.g. Milner says "poset") throws a
monkey-wrench into this reasoning. We have attempted to squeeze these
concurrent/parallel computations back into our textual-language box by
saying that they are the result of lots of independent sequential
programs which run and intermittently communicate and/or synchronize,
but that's just plain unnatural, and very problematic when it comes to
analyzing or optimizing programs. The more natural approach is to say,
just as we did with sequential programs, that the computation (a partial
ordering) should unravel or unfold naturally from a single program or
algorithm, and for this to happen, the program or algorithm itself needs
to be more topologically complex, and that does not lend itself well to
a textual program.
The third is related to "arity", or the number of arguments taken by an
operation and/or returned by an operation, and functional composition.
For example, functional and dataflow fans might say that textual
representations do just fine for representing concurrent programs, but I
would argue that that's only true when the vast majority of the
operations are unary or binary with one result (and you have referential
transparency and determinism to fall back on, neither of which is true
in general for concurrent programs). Textual functional composition
depends on juxtaposition for representing relationships, and when
operations have higher arity, it requires that all the arguments be
strung out in a sequence. When these operations return multiple
results, then things really break down and results must take on
temporary names, with the programmer attempting to create associations
through name matching instead of some more obvious visual approach.
This is primarily why you see Software Engineering approaches (e.g. UML)
using dataflow-like diagrams: because software modules often take and
return several data items (often of different types), each which may go
to/come from a different direction. It can be considered a more general
form of functional composition.
Anyway, this is where I've been coming from (for the last decade plus,
with a running start from my advisor, Robert Babb, before that). First,
I developed a computational model called F-Nets (my PhD dissertation)
which formalizes this whole idea of partially-ordered computations
unfolding off of a program or algorithm. As a result, an F-Net serves
the same basic niche as a TM, but is more graphically oriented, and
resembles a Petri Net or dataflow program, and F-net algorithms have
that Proximity Property I mentioned. Then, I came up with a language
which uses this basic computational model called Software Cabling (or
simply SC). Lots more info on both of these can be found at my web site
(e.g. www.elepar.com/references, www.elepar.com/Primer), and I'll post a
workshop reference below. (Also, see first unpublished paper on the
references web page.) You won't really find any more hint of branching
or computation in an SC program than you would find in a Petri
Net--that's pretty much left to whatever sequential language the
programmer wants to use for the "guts". An F-Net or SC program only
focuses on the high-level inter-relationships of data and control.
Does all of this generalize to the "production capable" world? I am now
trying to argue, especially with the advent of the web, that the answer
is "yes". That is, first, I don't pretend that you are going to use the
visual representation for everything: you use your favorite textual
language for all the mundane parts, visual for high-level interactions
that you prefer to be visible, or to allow concurrency. If you can build
reusable modules, fine, SC will let you use them easily. Second, you
get some advantages (such as more formal, and therefore, more provable
programs, and I would argue, more visually obvious and debuggable
programs) even if you don't care anything about concurrency. And third,
with concurrency and web programming becoming more prevalent, you are
ready for the next generation.
So, I'd be interested in any feedback, and good luck with your search.
I've seen languages come and go over the last decade, people
understandably give up after a few years of trying. Maybe I'm just too
stupid to give up!
-Dave
DiNucci, David C, "Tolerant (Parallel) Programming with F-Nets and
Software Cabling". In 1997 Workshop on Software Engineering for Parallel
and Distributed Systems (PDSE97), Boston, MA, May 1997. Pages 198 to
209.
David McIntyre
However, like yourself, i am convinced that visual languages
will be the future. 10 years from now, today's text languages
will be dinosaurs.
One good tool i encountered is Sanscript (www.trulyvisual.com)
It is there only on windows, but it is one of the better tools.
Good luck!
Yatin
Christophe EYQUEM
So ask your questions and i'll try to answer in french or english...
A++
David McIntyre <dmci...@blackrock.com> a écrit dans le message :
39905414...@lucent.com...
Tom447
<8p2r04$ccs$1...@xsdev1.blackrock.com>...
> Hello, i'm here too and i'm watching this newsgroup...
> So ask your questions and i'll try to answer in french or english...
> A++
Thanks very much for your offer... I have many VL related questions! :)
Unfortunately it has been difficult to get things posted to this forum so I
have not tried recently. But since two items seem to have come through over
the last two days, perhaps moderation will be off this week with VL2000
going on in Seattle!
Another place to watch for VL related information is comp.lang.prograph. It
is an unmoderated forum and a lot of interesting discussions have been
going on there over the last several months.
As a result of some of these discussions, I have started an open source
project to create a multi-platform Visual Language called VLX. The project
is just starting and there are no papers, specifications or downloads
available yet. But the project does have a goal, website, public forums and
mailing lists available at:
http://sourceforge.net/projects/vlx
All are welcome to participate... and any comments or suggestions are
greatly appreciated!
Best regards,
-Tom
israel thomas
>general-purpose commercial VL available.
Looking at the Pictorious site gives the impression that they are
abandoning Prograph and have moved into enterprise application
development.